[Bug 67982] After boot, the APU is powered with its maximum voltage (trinity/ARUBA)
https://bugs.freedesktop.org/show_bug.cgi?id=67982 --- Comment #5 from Kertesz Laszlo --- I did some more poking and i found that setting the cpu governor to "conservative" i get correct voltage handling at bootup after logging into lightdm. But if i restart lightdm and log in, it will get stuck at the 1.34-1.36 levels. With ondemand after boot i always had (maybe 1 or 2 exceptions) the 1.34 and 1.36 voltage levels. Its weird that in that state changing to a vt and back sometimes elevates the voltage to 1.44v and keep it there. I also removed and loaded again the acpi-cpufreq driver - after unloading, the voltage is a fixed (it seems) 1.15v, after loading it again it jumps to 1.34 and stays there (or goes up to 1.36 and back sometimes) until i turn dpms force off and on the monitor, after which it starts to change the voltage levels correctly. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On 09/17/2013 09:34 PM, Igor Gnatenko wrote: > On Tue, 2013-09-17 at 17:23 +0800, Aaron Lu wrote: >> v1 has the subject of "Rework ACPI video driver" and is posted here: >> http://lkml.org/lkml/2013/9/9/74 >> Since the objective is really to fix Win8 backlight issues, I changed >> the subject in this version, sorry about that. >> >> This patchset has three patches, the first introduced a new API named >> backlight_device_registered in backlight layer that can be used for >> backlight interface provider module to check if a specific type backlight >> interface has been registered, see changelog for patch 1/3 for details. >> Then patch 2/3 does the cleanup to sepeate the backlight control and >> event delivery functionality in the ACPI video module and patch 3/3 >> solves some Win8 backlight control problems by avoiding register ACPI >> video's backlight interface if: >> 1 Kernel cmdline option acpi_backlight=video is not given; >> 2 This is a Win8 system; >> 3 Native backlight control interface exists. >> >> Technically, patch 2/3 is not required to fix the issue here. So if you >> think it is not necessary, I can remove it from the series. >> >> Apply on top of v3.12-rc1. >> >> Aaron Lu (3): >> backlight: introduce backlight_device_registered >> ACPI / video: seperate backlight control and event interface >> ACPI / video: Do not register backlight if win8 and native interface >> exists >> >> drivers/acpi/internal.h | 5 +- >> drivers/acpi/video.c| 442 >> >> drivers/acpi/video_detect.c | 14 +- >> drivers/video/backlight/backlight.c | 31 +++ >> include/acpi/video.h| 2 + >> include/linux/backlight.h | 4 + >> 6 files changed, 300 insertions(+), 198 deletions(-) >> > > Aaron, how about fix indicator on ThinkPads ? Can you please describe the problem in detail, is it that when you adjust brightness level through hotkey, there is no GUI indication? Thanks. -Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm/exynos-fimd] Display regression in v3.12-rc1
Hi Andrzej ,
I was testing the latest Linux kernel release (v3.12-rc1) on
Exynos4210 based Origen board.
I found a display regression with that. I do not get any display on
the LCD (other than backlight) with the latest kernel. Git bisect
pointed me to the following commit:
111e6055d4e0d35c6a4b6cd37d7bb00a88eaffb4 ("drm/exynos: fimd: replace
struct fb_videomode with videomode"). Reverting this patch does not
cause the issue. Let me know if you need any other info to help
identify the problem.
--
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote: > On 09/17/2013 09:34 PM, Igor Gnatenko wrote: > > On Tue, 2013-09-17 at 17:23 +0800, Aaron Lu wrote: > >> v1 has the subject of "Rework ACPI video driver" and is posted here: > >> http://lkml.org/lkml/2013/9/9/74 > >> Since the objective is really to fix Win8 backlight issues, I changed > >> the subject in this version, sorry about that. > >> > >> This patchset has three patches, the first introduced a new API named > >> backlight_device_registered in backlight layer that can be used for > >> backlight interface provider module to check if a specific type backlight > >> interface has been registered, see changelog for patch 1/3 for details. > >> Then patch 2/3 does the cleanup to sepeate the backlight control and > >> event delivery functionality in the ACPI video module and patch 3/3 > >> solves some Win8 backlight control problems by avoiding register ACPI > >> video's backlight interface if: > >> 1 Kernel cmdline option acpi_backlight=video is not given; > >> 2 This is a Win8 system; > >> 3 Native backlight control interface exists. > >> > >> Technically, patch 2/3 is not required to fix the issue here. So if you > >> think it is not necessary, I can remove it from the series. > >> > >> Apply on top of v3.12-rc1. > >> > >> Aaron Lu (3): > >> backlight: introduce backlight_device_registered > >> ACPI / video: seperate backlight control and event interface > >> ACPI / video: Do not register backlight if win8 and native interface > >> exists > >> > >> drivers/acpi/internal.h | 5 +- > >> drivers/acpi/video.c| 442 > >> > >> drivers/acpi/video_detect.c | 14 +- > >> drivers/video/backlight/backlight.c | 31 +++ > >> include/acpi/video.h| 2 + > >> include/linux/backlight.h | 4 + > >> 6 files changed, 300 insertions(+), 198 deletions(-) > >> > > > > Aaron, how about fix indicator on ThinkPads ? > > Can you please describe the problem in detail, is it that when you > adjust brightness level through hotkey, there is no GUI indication? > Thanks. > > -Aaron Yes. On my ThinkPad X230 I pressing backlight hotkeys. Actually brightnes changing, but have no indicator in GUI. -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.1-300.fc20.x86_64 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm/exynos-fimd] Display regression in v3.12-rc1
Hi Sachin,
Could you test it with removed display-timings::clock-frequency property.
Currently in arch/arm/boot/dts/exynos4210-origen.dts
display-timings::clock-frequency is set to 5,
this is incorrect value. With the property removed fimd calculates
clock-frequency from other properties with assumption of default
60Hz refresh rate.
It could work before because of_get_fb_videomode calculated refresh rate
from display-timings and with clock 5, the result was 0(due to
rounding down in some division),
so fimd assumed he should use default refresh rate of 60Hz.
Regards
Andrzej
On 09/18/2013 07:22 AM, Sachin Kamat wrote:
> Hi Andrzej ,
>
> I was testing the latest Linux kernel release (v3.12-rc1) on
> Exynos4210 based Origen board.
> I found a display regression with that. I do not get any display on
> the LCD (other than backlight) with the latest kernel. Git bisect
> pointed me to the following commit:
> 111e6055d4e0d35c6a4b6cd37d7bb00a88eaffb4 ("drm/exynos: fimd: replace
> struct fb_videomode with videomode"). Reverting this patch does not
> cause the issue. Let me know if you need any other info to help
> identify the problem.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67982] After boot, the APU is powered with its maximum voltage (trinity/ARUBA)
https://bugs.freedesktop.org/show_bug.cgi?id=67982 --- Comment #6 from Kertesz Laszlo --- It also seems that only if i use acpi=strict on the kernel command line the conservative governor works well. Otherwise it is exactly the same as ondemand. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65254] opengl flicker in xbmc / glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=65254 --- Comment #18 from Vladi --- http://gypsyops.aresgate.net/~vladi/dummy.mp4 video of the flicker in xbmc -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] New: R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 Priority: medium Bug ID: 69514 Assignee: dri-devel@lists.freedesktop.org Summary: R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode Severity: normal Classification: Unclassified OS: All Reporter: peteraspl...@gentoo.se Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI If I put my computer in sleep/hibernate (doesn't seem to matter which one) the screen gets corrupted with colors everywhere. It does update, and things jump around when I try to press buttons, bring out menus, etc. It's like the drawing buffer is all jumbled up and it's reading/writing from/to the wrong place. When something is updated, it's like I can see the picture/pixmap/icon for a fraction of a second, but then it's corrupted again. If I move the mouse continuously over a menu, to update the highlighting of it, I can see at least where I am on the screen. But the fonts are complete garbage, and it's unreadable. Perhaps I can photograph the screen if it's needed. I haven't tried taking a screenshot. I'm using Gentoo, 3.11 gentoo-kernel, with Systemd and Gnome 3.8. The TTY:s are not corrupted, so I'm able to switch to a TTY without problems. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #1 from Peter Asplund --- I'm using a green background, and the whole corrupted screen is green. The screen looks like big green chunks that flickers when it's updated as I move the mouse. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #29 from Michel Dänzer --- Created attachment 86051 --> https://bugs.freedesktop.org/attachment.cgi?id=86051&action=edit DRI2: Install client callback only once Does this patch fix the problem? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #8 from Michel Dänzer --- For CK II, you need an LLVM 3.4 snapshot from Git/SVN. Not sure what the problem is with KF, let's see if the newer LLVM helps for that as well. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
The drm/i915 gpu driver loves to hang onto as much memory as it can -
we cache pinned pages, dma mappings and obviously also gpu address
space bindings of buffer objects. On top of that userspace has its own
opportunistic cache which is managed by an madvise-like ioctl to tell
the kernel which objects are purgeable and which are actually used.
This is to cache userspace mmapings and a bit of other metadata about
buffer objects needed to be able to hit fastpaths even on fresh
objects.
We have routine encounters with the OOM killer due to all this crave
for memory. The latest one seems to be an artifact of the mm core
trying really hard to balance page lru evictions with shrinking
caches: The shrinker in drm/i915 doesn't actually free memory, but
only drops all the dma mappings and page refcounts so that the backing
storage (which is just shmemfs nodes) can actually be evicted.
Which means that if the core mm hasn't found anything to evict from
the page lru (most likely because drm/i915 has pinned down everything
available) it will also not shrink any of the caches. Which leads to a
premature OOM while still tons of pages used by gpu buffer objects
could be swapped out.
For a quick hack I've added a shrink-me-harder flag to make sure
there's at least a bit of forward progress. It seems to work. I've
called the flag evicts_to_page_lru, but that might just be uninformed
me talking ...
We should also probably have something with a bit more smarts to be more
aggressive when in a tight spot and avoid the minimal shrinking when
it's not really required, so maybe take scan_control->priority into
account somehow. But since I utterly lack clue I've figured sending
out a quick rfc first is better.
Also, this needs to be rebased to the new shrinker api in 3.12, I
simply haven't rolled my trees forward yet. In any case I just want to
get the discussion started on this.
Cc: Glauber Costa
Cc: Andrew Morton
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Johannes Weiner
Cc: Michal Hocko
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69247
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
include/linux/shrinker.h| 14 ++
mm/vmscan.c | 4
3 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d80f33d..7481d0a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4582,6 +4582,7 @@ i915_gem_load(struct drm_device *dev)
dev_priv->mm.inactive_shrinker.shrink = i915_gem_inactive_shrink;
dev_priv->mm.inactive_shrinker.seeks = DEFAULT_SEEKS;
+ dev_priv->mm.inactive_shrinker.evicts_to_page_lru = true;
register_shrinker(&dev_priv->mm.inactive_shrinker);
}
diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
index ac6b8ee..361cc2d 100644
--- a/include/linux/shrinker.h
+++ b/include/linux/shrinker.h
@@ -32,6 +32,20 @@ struct shrinker {
int seeks; /* seeks to recreate an obj */
long batch; /* reclaim batch size, 0 = default */
+ /*
+* Some shrinkers (especially gpu drivers using gem as backing storage)
+* hold onto gobloads of pinned pagecache memory (from shmem nodes).
+* When those caches get shrunk the memory only gets unpin and so is
+* available to be evicted with the page launderer.
+*
+* The problem is that the core mm tries to balance eviction from the
+* page lru with shrinking caches. So if there's nothing on the page lru
+* to evict we'll never shrink the gpu driver caches and so will OOM
+* despite tons of memory used by gpu buffer objects that could be
+* swapped out. Setting this flag ensures forward progress.
+*/
+ bool evicts_to_page_lru;
+
/* These are for internal use */
struct list_head list;
atomic_long_t nr_in_batch; /* objs pending delete */
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2cff0d4..d81f6e0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control *shrink,
total_scan = max_pass;
}
+ /* Always try to shrink a bit to make forward progress. */
+ if (shrinker->evicts_to_page_lru)
+ total_scan = max_t(long, total_scan, batch_size);
+
/*
* We need to avoid excessive windup on filesystem shrinkers
* due to large numbers of GFP_NOFS allocations causing the
--
1.8.4.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers
https://bugs.freedesktop.org/show_bug.cgi?id=69372 --- Comment #12 from Michel Dänzer --- The fix for bug 65964 landed in glamor Git today, can you try if that happens to help for any of these issues? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
On 18.09.2013 11:10, Daniel Vetter wrote: Just now I prepared a patch changing the same function in vmscan.c Also, this needs to be rebased to the new shrinker api in 3.12, I simply haven't rolled my trees forward yet. Well, you should. Since commit 81e49f shrinker->count_objects might be set to SHRINK_STOP, causing shrink_slab_node() to complain loud and often: [ 1908.234595] shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects to delete nr=-x The kernel emitted a few thousand log lines like the one quoted above during the last few days on my system. diff --git a/mm/vmscan.c b/mm/vmscan.c index 2cff0d4..d81f6e0 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control *shrink, total_scan = max_pass; } + /* Always try to shrink a bit to make forward progress. */ + if (shrinker->evicts_to_page_lru) + total_scan = max_t(long, total_scan, batch_size); + At that place the error message is already emitted. /* * We need to avoid excessive windup on filesystem shrinkers * due to large numbers of GFP_NOFS allocations causing the Have a look at the attached patch. It fixes my problem with the erroneous/misleading error messages, and I think it´s right to just bail out early if SHRINK_STOP is found. Do you agree ? cu, Knut >From 75ae570ce7b0bb6b40c76beb18fc075e9af3127a Mon Sep 17 00:00:00 2001 From: Knut Petersen Date: Wed, 18 Sep 2013 12:06:33 +0200 Subject: [PATCH] mm: respect SHRINK_STOP in shrink_slab_node() Since commit 81e49f811404f428a9d9a63295a0c267e802fa12 i915_gem_inactive_count() might return SHRINK_STOP. Unfortunately SHRINK_STOP is not handled propperly in shrink_slab_node(), causing a system log cluttered with kernel error messages complaining about "negative objects to delete". I think the proper way of handling SHRINK_STOP is obvious, we should obey ;-) Signed-off-by: Knut Petersen --- mm/vmscan.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c index 8ed1b77..b1e6f0d 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -244,6 +244,8 @@ shrink_slab_node(struct shrink_control *shrinkctl, struct shrinker *shrinker, max_pass = shrinker->count_objects(shrinker, shrinkctl); if (max_pass == 0) return 0; + if (max_pass == SHRINK_STOP) + return 0; /* * copy the current shrinker scan count into a local variable -- 1.8.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote: > On 18.09.2013 11:10, Daniel Vetter wrote: > > Just now I prepared a patch changing the same function in vmscan.c > >Also, this needs to be rebased to the new shrinker api in 3.12, I > >simply haven't rolled my trees forward yet. > > Well, you should. Since commit 81e49f shrinker->count_objects might be > set to SHRINK_STOP, causing shrink_slab_node() to complain loud and often: > > [ 1908.234595] shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects > to delete nr=-x > > The kernel emitted a few thousand log lines like the one quoted above during > the > last few days on my system. > > >diff --git a/mm/vmscan.c b/mm/vmscan.c > >index 2cff0d4..d81f6e0 100644 > >--- a/mm/vmscan.c > >+++ b/mm/vmscan.c > >@@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control *shrink, > > total_scan = max_pass; > > } > >+/* Always try to shrink a bit to make forward progress. */ > >+if (shrinker->evicts_to_page_lru) > >+total_scan = max_t(long, total_scan, batch_size); > >+ > At that place the error message is already emitted. > > /* > > * We need to avoid excessive windup on filesystem shrinkers > > * due to large numbers of GFP_NOFS allocations causing the > > Have a look at the attached patch. It fixes my problem with the > erroneous/misleading > error messages, and I think it´s right to just bail out early if SHRINK_STOP > is found. > > Do you agree ? Looking at the patch which introduced these error message for you, which changed the ->count_objects return value from 0 to SHRINK_STOP your patch below to treat 0 and SHRINK_STOP equally simply reverts the functional change. I don't think that's the intention behind SHRINK_STOP. But if it's the right think to do we better revert the offending commit directly. And since I lack clue I think that's a call for core mm guys to make. -Daniel > > cu, > Knut > > From 75ae570ce7b0bb6b40c76beb18fc075e9af3127a Mon Sep 17 00:00:00 2001 > From: Knut Petersen > Date: Wed, 18 Sep 2013 12:06:33 +0200 > Subject: [PATCH] mm: respect SHRINK_STOP in shrink_slab_node() > > Since commit 81e49f811404f428a9d9a63295a0c267e802fa12 > i915_gem_inactive_count() might return SHRINK_STOP. > > Unfortunately SHRINK_STOP is not handled propperly in > shrink_slab_node(), causing a system log cluttered with > kernel error messages complaining about "negative objects > to delete". > > I think the proper way of handling SHRINK_STOP is obvious, > we should obey ;-) > > Signed-off-by: Knut Petersen > --- > mm/vmscan.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 8ed1b77..b1e6f0d 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -244,6 +244,8 @@ shrink_slab_node(struct shrink_control *shrinkctl, struct > shrinker *shrinker, > max_pass = shrinker->count_objects(shrinker, shrinkctl); > if (max_pass == 0) > return 0; > + if (max_pass == SHRINK_STOP) > + return 0; > > /* >* copy the current shrinker scan count into a local variable > -- > 1.8.1.4 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On Wednesday 18 September 2013 04:38 PM, Archit Taneja wrote:
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require
regulators. The output's connect op tries to get a regulator which may not exist
yet because it might get registered later in the kernel boot.
omapdrm currently ignores those panels which return a non zero value when
connected. A better approach would be for omapdrm to request for probe
deferral if a panel's connect op returns -EPROBE_DEFER.
The connecting of panels is moved very early in the the drm device's probe
before anything else is initialized. When we enter omap_modeset_init(), we have
a set of panels that have been connected. We now proceed with registering only
those panels which are already connected.
Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.
This fixes boot with omapdrm on an omap4 panda ES board. The regulators used by
HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized
as it's pins are not configured because pinctrl is yet to probe.
Copying dri-devel list.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 5
drivers/gpu/drm/omapdrm/omap_drv.c | 51 +
drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
3 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..9c01311 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
dss_install_mgr_ops(&mgr_ops);
}
+void omap_crtc_pre_uninit(void)
+{
+ dss_uninstall_mgr_ops();
+}
+
/* initialize crtc */
struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2603d90..cbe5d8e 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -87,6 +87,24 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static int omap_connect_dssdevs(void)
+{
+ int r;
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ r = dssdev->driver->connect(dssdev);
+ if (r == -EPROBE_DEFER) {
+ return r;
+ } else if (r) {
+ dev_warn(dssdev->dev, "could not connect display: %s\n",
+ dssdev->name);
+ }
+ }
+
+ return 0;
+}
+
static int omap_modeset_init(struct drm_device *dev)
{
struct omap_drm_private *priv = dev->dev_private;
@@ -95,9 +113,6 @@ static int omap_modeset_init(struct drm_device *dev)
int num_mgrs = dss_feat_get_num_mgrs();
int num_crtcs;
int i, id = 0;
- int r;
-
- omap_crtc_pre_init();
drm_mode_config_init(dev);
@@ -119,26 +134,8 @@ static int omap_modeset_init(struct drm_device *dev)
enum omap_channel channel;
struct omap_overlay_manager *mgr;
- if (!dssdev->driver) {
- dev_warn(dev->dev, "%s has no driver.. skipping it\n",
- dssdev->name);
+ if (!omapdss_device_is_connected(dssdev))
continue;
- }
-
- if (!(dssdev->driver->get_timings ||
- dssdev->driver->read_edid)) {
- dev_warn(dev->dev, "%s driver does not support "
- "get_timings or read_edid.. skipping it!\n",
- dssdev->name);
- continue;
- }
-
- r = dssdev->driver->connect(dssdev);
- if (r) {
- dev_err(dev->dev, "could not connect display: %s\n",
- dssdev->name);
- continue;
- }
encoder = omap_encoder_init(dev, dssdev);
@@ -656,9 +653,19 @@ static void pdev_shutdown(struct platform_device *device)
static int pdev_probe(struct platform_device *device)
{
+ int r;
+
if (omapdss_is_initialized() == false)
return -EPROBE_DEFER;
+ omap_crtc_pre_init();
+
+ r = omap_connect_dssdevs();
+ if (r) {
+ omap_crtc_pre_uninit();
+ return r;
+ }
+
DBG("%s", device->name);
return drm_platform_init(&omap_drm_driver, device);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_dr
Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
Looking at the patch which introduced these error message for you, which changed the ->count_objects return value from 0 to SHRINK_STOP your patch below to treat 0 and SHRINK_STOP equally simply reverts the functional change. Yes, for i915* it de facto restores the old behaviour. I don't think that's the intention behind SHRINK_STOP. But if it's the right think to do we better revert the offending commit directly. But there is other code that also returns SHRINK_STOP. So i believe it´s better to adapt shrink_slab_node() to handle SHRINK_STOP properly than to revert 81e49f. And since I lack clue I think that's a call for core mm guys to make. I agree. They´ll probably have to apply some additional changes to shrink_slab_node(). It really doesn´t look right to me, but they certainly know better what the code is supposed to do ;-) cu, Knut ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 44995] Missing support for MGA G200eW WPCM450 [102b:0532]
https://bugs.freedesktop.org/show_bug.cgi?id=44995 --- Comment #6 from Alex Waite --- So, it seems that there is a KMS driver now for the MGA200eW card (thanks to you Dave :-). Any way this can be supported, even if it's just for software rendering? ---Alex -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 --- Comment #3 from samit vats --- yes, mesa is configured with "--with-egl-platforms=x11,drm" -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #2 from Alex Deucher --- You mean when you wake up from suspend/hibernate so see the corruption? Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #3 from Alex Deucher --- Also is this a regression? If so, can you bisect? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On Wednesday 18 September 2013 06:11 PM, Tomi Valkeinen wrote:
On 18/09/13 14:08, Archit Taneja wrote:
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require
regulators. The output's connect op tries to get a regulator which may not exist
yet because it might get registered later in the kernel boot.
omapdrm currently ignores those panels which return a non zero value when
connected. A better approach would be for omapdrm to request for probe
deferral if a panel's connect op returns -EPROBE_DEFER.
The connecting of panels is moved very early in the the drm device's probe
before anything else is initialized. When we enter omap_modeset_init(), we have
a set of panels that have been connected. We now proceed with registering only
those panels which are already connected.
Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.
This fixes boot with omapdrm on an omap4 panda ES board. The regulators used by
HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized
as it's pins are not configured because pinctrl is yet to probe.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 5
drivers/gpu/drm/omapdrm/omap_drv.c | 51 +
drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
3 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..9c01311 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
dss_install_mgr_ops(&mgr_ops);
}
+void omap_crtc_pre_uninit(void)
+{
+ dss_uninstall_mgr_ops();
+}
+
/* initialize crtc */
struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2603d90..cbe5d8e 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -87,6 +87,24 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static int omap_connect_dssdevs(void)
+{
+ int r;
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ r = dssdev->driver->connect(dssdev);
+ if (r == -EPROBE_DEFER) {
+ return r;
+ } else if (r) {
+ dev_warn(dssdev->dev, "could not connect display: %s\n",
+ dssdev->name);
+ }
+ }
+
+ return 0;
+}
There are two issues with this one:
for_each_dss_dev() uses omap_dss_get_next_device(), and that will
increase the ref count of the current dssdev. If you interrupt the loop,
the ref count won't be decreased. I have a hunch that we could have
similar bugs elsewhere too...
You are saying that the ref counts will be correct only if
for_each_dss_dev() is fully completed?
Maybe we can save the first dssdev which doesn't connect, save that
dssdev and let the loop continue for the refcount to get decremented again.
Or maybe use omap_dss_get_next_device in a custom loop, which takes care
of doing a put() for the device before returning.
Second, in case of error, the dssdevs that were already connected should
be disconnected. Although maybe that's not important, as they'll end up
being connected again when the omapdrm is probed the next time.
The one's that were already connected won't connect again and return an
error which isn't EPROBE_DEFER, so that should be okay right?
Archit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 --- Comment #4 from Michel Dänzer --- How are you starting the X server? Does the shell which starts the X server contatin the environment variable EGL_PLATFORM=x11, or does it help if you set EGL_PLATFORM=drm? Either way, please set the environment variable EGL_LOG_LEVEL=debug for starting the X server and attach its stderr output. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/radeon/cik: Program pipe configuration for 1D tiling modes as well
From: Michel Dänzer Signed-off-by: Michel Dänzer --- Not sure this is necessary, but AFAICT the pipe configuration applies to 1D tiling modes as well. drivers/gpu/drm/radeon/cik.c | 48 +--- 1 file changed, 32 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 8feaf51..35d8247 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -1788,7 +1788,8 @@ static void cik_tiling_mode_table_init(struct radeon_device *rdev) break; case 5: gb_tile_moden = (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | - MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)); + MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)) | + PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); break; case 6: gb_tile_moden = (ARRAY_MODE(ARRAY_PRT_2D_TILED_THIN1) | @@ -1808,7 +1809,8 @@ static void cik_tiling_mode_table_init(struct radeon_device *rdev) break; case 9: gb_tile_moden = (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | - MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)); + MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)) | + PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); break; case 10: gb_tile_moden = (ARRAY_MODE(ARRAY_2D_TILED_THIN1) | @@ -1830,7 +1832,8 @@ static void cik_tiling_mode_table_init(struct radeon_device *rdev) break; case 13: gb_tile_moden = (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | - MICRO_TILE_MODE_NEW(ADDR_SURF_THIN_MICRO_TILING)); + MICRO_TILE_MODE_NEW(ADDR_SURF_THIN_MICRO_TILING)) | + PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); break; case 14: gb_tile_moden = (ARRAY_MODE(ARRAY_2D_TILED_THIN1) | @@ -1852,7 +1855,8 @@ static void cik_tiling_mode_table_init(struct radeon_device *rdev) break; case 27: gb_tile_moden = (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | - MICRO_TILE_MODE_NEW(ADDR_SURF_ROTATED_MICRO_TILING)); + MICRO_TILE_MODE_NEW(ADDR_SURF_ROTATED_MICRO_TILING)) | + PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); break; case 28: gb_tile_moden = (ARRAY_MODE(ARRAY_2D_TILED_THIN1) | @@ -2007,7 +2011,8 @@ static void cik_tiling_mode_table_init(struct radeon_device *rdev) break; case 5: gb_tile_moden = (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | - MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)); + MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)) | + PIPE_CONFIG(ADDR_SURF_P4_16x16); break; case 6: gb_tile_moden = (ARRAY_MODE(ARRAY_PRT_2D_TILED_THIN1) | @@ -2027,7 +2032,8 @@ static void cik_tiling_mode_table_init(struct radeon_device *rdev) break; case 9: gb_tile_moden = (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | - MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)); + MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)) | + PIPE_CONFIG(ADDR_SURF_P4_16x16); break; case 10: gb_tile_moden = (ARRAY_MODE(ARRAY_2D_TILED_THIN1) | @@ -2049,7 +2055,8 @@ static void cik_tiling_mode_table_init(struct radeon_device *rdev) break; case 13:
[PATCH 2/3] drm/radeon/cik: Fix encoding of number of banks in tiling configuration info
From: Michel Dänzer Cc: sta...@vger.kernel.org Signed-off-by: Michel Dänzer --- drivers/gpu/drm/radeon/cik.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 4f1f419..8feaf51 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -2835,10 +2835,8 @@ static void cik_gpu_init(struct radeon_device *rdev) rdev->config.cik.tile_config |= (3 << 0); break; } - if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) - rdev->config.cik.tile_config |= 1 << 4; - else - rdev->config.cik.tile_config |= 0 << 4; + rdev->config.cik.tile_config |= + ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) << 4; rdev->config.cik.tile_config |= ((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >> PIPE_INTERLEAVE_SIZE_SHIFT) << 8; rdev->config.cik.tile_config |= -- 1.8.4.rc3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/radeon/cik: Fix printing of client name on VM protection fault
From: Michel Dänzer
The string is encoded from the MSB to the LSB of the register.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/cik.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index a77b593..4f1f419 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4721,12 +4721,13 @@ static void cik_vm_decode_fault(struct radeon_device
*rdev,
u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
- char *block = (char *)&mc_client;
+ char block[5] = { mc_client >> 24, (mc_client >> 16) & 0xff,
+ (mc_client >> 8) & 0xff, mc_client & 0xff, 0 };
- printk("VM fault (0x%02x, vmid %d) at page %u, %s from %s (%d)\n",
+ printk("VM fault (0x%02x, vmid %d) at page %u, %s from '%s' (0x%08x)
(%d)\n",
protections, vmid, addr,
(status & MEMORY_CLIENT_RW_MASK) ? "write" : "read",
- block, mc_id);
+ block, mc_client, mc_id);
}
/**
--
1.8.4.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] radeon: Fix 1D tiling for CIK
From: Michel Dänzer
The main difference is that the tiling mode index changed for 1D tiled
depth/stencil surfaces.
Signed-off-by: Michel Dänzer
---
include/drm/radeon_drm.h | 15 +++
radeon/radeon_surface.c | 15 ---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 86cef15..533c3dc 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -1004,4 +1004,19 @@ struct drm_radeon_info {
#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
+#define CIK_TILE_MODE_COLOR_LINEAR_ALIGNED 8
+#define CIK_TILE_MODE_COLOR_1D 13
+#define CIK_TILE_MODE_COLOR_1D_SCANOUT 9
+#define CIK_TILE_MODE_COLOR_2D_8BPP14
+#define CIK_TILE_MODE_COLOR_2D_16BPP 15
+#define CIK_TILE_MODE_COLOR_2D_32BPP 16
+#define CIK_TILE_MODE_COLOR_2D_64BPP 17
+#define CIK_TILE_MODE_COLOR_2D_SCANOUT_16BPP 11
+#define CIK_TILE_MODE_COLOR_2D_SCANOUT_32BPP 12
+#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D 0
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_2AA 3
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
+
#endif
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 818e26a..1710e34 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -1382,10 +1382,16 @@ static int si_surface_sanity(struct
radeon_surface_manager *surf_man,
break;
case RADEON_SURF_MODE_1D:
if (surf->flags & RADEON_SURF_SBUFFER) {
-*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+if (surf_man->family >= CHIP_BONAIRE)
+*stencil_tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
+else
+*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
}
if (surf->flags & RADEON_SURF_ZBUFFER) {
-*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+if (surf_man->family >= CHIP_BONAIRE)
+*tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
+else
+*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
} else if (surf->flags & RADEON_SURF_SCANOUT) {
*tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
} else {
@@ -1643,7 +1649,10 @@ static int si_surface_init_2d(struct
radeon_surface_manager *surf_man,
tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
break;
case SI_TILE_MODE_DEPTH_STENCIL_2D:
-tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+if (surf_man->family >= CHIP_BONAIRE)
+tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
+else
+tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
break;
default:
return -EINVAL;
--
1.8.4.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/radeon/cik: Program pipe configuration for 1D tiling modes as well
On Wed, Sep 18, 2013 at 9:39 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Signed-off-by: Michel Dänzer > --- > > Not sure this is necessary, but AFAICT the pipe configuration applies to > 1D tiling modes as well. I don't think pipe config applies to 1D modes since they are fixed size across asics. > > drivers/gpu/drm/radeon/cik.c | 48 > +--- > 1 file changed, 32 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c > index 8feaf51..35d8247 100644 > --- a/drivers/gpu/drm/radeon/cik.c > +++ b/drivers/gpu/drm/radeon/cik.c > @@ -1788,7 +1788,8 @@ static void cik_tiling_mode_table_init(struct > radeon_device *rdev) > break; > case 5: > gb_tile_moden = > (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | > - > MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)); > + > MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)) | > + > PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); > break; > case 6: > gb_tile_moden = > (ARRAY_MODE(ARRAY_PRT_2D_TILED_THIN1) | > @@ -1808,7 +1809,8 @@ static void cik_tiling_mode_table_init(struct > radeon_device *rdev) > break; > case 9: > gb_tile_moden = > (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | > - > MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)); > + > MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)) | > + > PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); > break; > case 10: > gb_tile_moden = > (ARRAY_MODE(ARRAY_2D_TILED_THIN1) | > @@ -1830,7 +1832,8 @@ static void cik_tiling_mode_table_init(struct > radeon_device *rdev) > break; > case 13: > gb_tile_moden = > (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | > - > MICRO_TILE_MODE_NEW(ADDR_SURF_THIN_MICRO_TILING)); > + > MICRO_TILE_MODE_NEW(ADDR_SURF_THIN_MICRO_TILING)) | > + > PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); > break; > case 14: > gb_tile_moden = > (ARRAY_MODE(ARRAY_2D_TILED_THIN1) | > @@ -1852,7 +1855,8 @@ static void cik_tiling_mode_table_init(struct > radeon_device *rdev) > break; > case 27: > gb_tile_moden = > (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | > - > MICRO_TILE_MODE_NEW(ADDR_SURF_ROTATED_MICRO_TILING)); > + > MICRO_TILE_MODE_NEW(ADDR_SURF_ROTATED_MICRO_TILING)) | > + > PIPE_CONFIG(ADDR_SURF_P8_32x32_16x16); > break; > case 28: > gb_tile_moden = > (ARRAY_MODE(ARRAY_2D_TILED_THIN1) | > @@ -2007,7 +2011,8 @@ static void cik_tiling_mode_table_init(struct > radeon_device *rdev) > break; > case 5: > gb_tile_moden = > (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | > - > MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)); > + > MICRO_TILE_MODE_NEW(ADDR_SURF_DEPTH_MICRO_TILING)) | > + > PIPE_CONFIG(ADDR_SURF_P4_16x16); > break; > case 6: > gb_tile_moden = > (ARRAY_MODE(ARRAY_PRT_2D_TILED_THIN1) | > @@ -2027,7 +2032,8 @@ static void cik_tiling_mode_table_init(struct > radeon_device *rdev) > break; > case 9: > gb_tile_moden = > (ARRAY_MODE(ARRAY_1D_TILED_THIN1) | > - > MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)); > + > MICRO_TILE_MODE_NEW(ADDR_SURF_DISPLAY_MICRO_TILING)) | > + > PIPE_CONFIG(ADDR_SURF_P4_16x16); >
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #4 from Peter Asplund --- Created attachment 86071 --> https://bugs.freedesktop.org/attachment.cgi?id=86071&action=edit Xorg log including sleep and wakeup cycle, as well as shutting down afterwards. Yes exactly, the corruption occurs when the computer wakes up from sleep/hibernation. The behavior started at least two kernel versions ago, probably at 3.10. I _think_ it was working with 3.8, but I will check that soon, and get back to you. Here's the Xorg.0.log.old from previous run. I was running for a while, and then put the computer in sleep mode, and then awoke it immediately. When the corruption has occurred, I shut it down normally. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #133 from Eugene --- I seems 3.12 RC1 still has not patch for my HD2600. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/radeon/cik: Fix printing of client name on VM protection fault
On Wed, Sep 18, 2013 at 9:39 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The string is encoded from the MSB to the LSB of the register.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michel Dänzer
Patches 1 and 2 applied. I don't think the 3rd one is necessary.
Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/cik.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index a77b593..4f1f419 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -4721,12 +4721,13 @@ static void cik_vm_decode_fault(struct radeon_device
> *rdev,
> u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >>
> MEMORY_CLIENT_ID_SHIFT;
> u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
> u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
> - char *block = (char *)&mc_client;
> + char block[5] = { mc_client >> 24, (mc_client >> 16) & 0xff,
> + (mc_client >> 8) & 0xff, mc_client & 0xff, 0 };
>
> - printk("VM fault (0x%02x, vmid %d) at page %u, %s from %s (%d)\n",
> + printk("VM fault (0x%02x, vmid %d) at page %u, %s from '%s' (0x%08x)
> (%d)\n",
>protections, vmid, addr,
>(status & MEMORY_CLIENT_RW_MASK) ? "write" : "read",
> - block, mc_id);
> + block, mc_client, mc_id);
> }
>
> /**
> --
> 1.8.4.rc3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #5 from Peter Asplund --- Created attachment 86072 --> https://bugs.freedesktop.org/attachment.cgi?id=86072&action=edit dmesg, including hibernate cycle Here's my dmesg output from last boot, including hibernation. The hibernation does not seem to work for some reason, because the computer wakes up immediately, but the screen still gets corrupted. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/cik: Add tiling mode index for 1D tiled depth/stencil surfaces
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
include/uapi/drm/radeon_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index fa8b3ad..46d41e8 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -1007,4 +1007,6 @@ struct drm_radeon_info {
#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
+#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
+
#endif
--
1.8.4.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/cik: Add tiling mode index for 1D tiled depth/stencil surfaces
On Wed, Sep 18, 2013 at 12:23 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
Applied. thanks!
Alex
> ---
> include/uapi/drm/radeon_drm.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
> index fa8b3ad..46d41e8 100644
> --- a/include/uapi/drm/radeon_drm.h
> +++ b/include/uapi/drm/radeon_drm.h
> @@ -1007,4 +1007,6 @@ struct drm_radeon_info {
> #define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
> #define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
>
> +#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
> +
> #endif
> --
> 1.8.4.rc3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/radeon/cik: Program pipe configuration for 1D tiling modes as well
On Wed, Sep 18, 2013 at 11:55 AM, Michel Dänzer wrote: > On Mit, 2013-09-18 at 09:56 -0400, Alex Deucher wrote: >> On Wed, Sep 18, 2013 at 9:39 AM, Michel Dänzer wrote: >> > From: Michel Dänzer >> > >> > Signed-off-by: Michel Dänzer >> > --- >> > >> > Not sure this is necessary, but AFAICT the pipe configuration applies to >> > 1D tiling modes as well. >> >> I don't think pipe config applies to 1D modes since they are fixed >> size across asics. > > Makes sense. I noticed that we're setting pipe config for 1D tiling > modes on SI as well, and the documentation I saw didn't explicitly say > that it only applies to 2D tiling. > > Maybe we should remove the setting of pipe config and friends for 1D > tiling modes on SI instead? > I suppose we should try and double check. The tiling settings spreadsheets sets the fields for SI, but no CIK, but I don't think the hw actually needs it. Alex > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Debian, X and DRI developer > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] radeon: Fix 1D tiling for CIK
On Wed, Sep 18, 2013 at 9:51 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The main difference is that the tiling mode index changed for 1D tiled
> depth/stencil surfaces.
>
> Signed-off-by: Michel Dänzer
One comment below, other than that,
Reviewed-by: Alex Deucher
> ---
> include/drm/radeon_drm.h | 15 +++
> radeon/radeon_surface.c | 15 ---
> 2 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index 86cef15..533c3dc 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -1004,4 +1004,19 @@ struct drm_radeon_info {
> #define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
> #define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
>
> +#define CIK_TILE_MODE_COLOR_LINEAR_ALIGNED 8
> +#define CIK_TILE_MODE_COLOR_1D 13
> +#define CIK_TILE_MODE_COLOR_1D_SCANOUT 9
> +#define CIK_TILE_MODE_COLOR_2D_8BPP14
> +#define CIK_TILE_MODE_COLOR_2D_16BPP 15
> +#define CIK_TILE_MODE_COLOR_2D_32BPP 16
> +#define CIK_TILE_MODE_COLOR_2D_64BPP 17
> +#define CIK_TILE_MODE_COLOR_2D_SCANOUT_16BPP 11
> +#define CIK_TILE_MODE_COLOR_2D_SCANOUT_32BPP 12
> +#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D 0
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_2AA 3
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
> +
Can you send a patch to add these to radeon_drm.h in the kernel as well?
> #endif
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 818e26a..1710e34 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -1382,10 +1382,16 @@ static int si_surface_sanity(struct
> radeon_surface_manager *surf_man,
> break;
> case RADEON_SURF_MODE_1D:
> if (surf->flags & RADEON_SURF_SBUFFER) {
> -*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> +if (surf_man->family >= CHIP_BONAIRE)
> +*stencil_tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
> +else
> +*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> }
> if (surf->flags & RADEON_SURF_ZBUFFER) {
> -*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> +if (surf_man->family >= CHIP_BONAIRE)
> +*tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
> +else
> +*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> } else if (surf->flags & RADEON_SURF_SCANOUT) {
> *tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
> } else {
> @@ -1643,7 +1649,10 @@ static int si_surface_init_2d(struct
> radeon_surface_manager *surf_man,
> tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
> break;
> case SI_TILE_MODE_DEPTH_STENCIL_2D:
> -tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> +if (surf_man->family >= CHIP_BONAIRE)
> +tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
> +else
> +tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> break;
> default:
> return -EINVAL;
> --
> 1.8.4.rc3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #134 from Francisco Pina Martins --- I just want to add that after upgrading to kernel 3.11.1 (from the -RC2 version I was using), I have not experienced any more crashes on my RV635. Nothing I have tried so far has been able to trigger it. Once again, thank you for all the hard work. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #7 from Peter Asplund --- I don't know if I can bisect... I need some help in that case. Gentoo has recently added a dependency on Systemd as a part of Gnome 3.8, and I think recovering from sleep/hibernate was working before that. But I'm not completely sure. Without systemd, sleep/hibernate doesn't work at all, so I'm unable to revert and test without it. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/radeon/cik: Program pipe configuration for 1D tiling modes as well
On Mit, 2013-09-18 at 09:56 -0400, Alex Deucher wrote: > On Wed, Sep 18, 2013 at 9:39 AM, Michel Dänzer wrote: > > From: Michel Dänzer > > > > Signed-off-by: Michel Dänzer > > --- > > > > Not sure this is necessary, but AFAICT the pipe configuration applies to > > 1D tiling modes as well. > > I don't think pipe config applies to 1D modes since they are fixed > size across asics. Makes sense. I noticed that we're setting pipe config for 1D tiling modes on SI as well, and the documentation I saw didn't explicitly say that it only applies to 2D tiling. Maybe we should remove the setting of pipe config and friends for 1D tiling modes on SI instead? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] radeon: Fix 1D tiling for CIK
On Wed, Sep 18, 2013 at 11:56 AM, Christian König
wrote:
> Am 18.09.2013 17:54, schrieb Alex Deucher:
>
>> On Wed, Sep 18, 2013 at 9:51 AM, Michel Dänzer wrote:
>>>
>>> From: Michel Dänzer
>>>
>>> The main difference is that the tiling mode index changed for 1D tiled
>>> depth/stencil surfaces.
>>>
>>> Signed-off-by: Michel Dänzer
>>
>> One comment below, other than that,
>>
>> Reviewed-by: Alex Deucher
>>
>>> ---
>>> include/drm/radeon_drm.h | 15 +++
>>> radeon/radeon_surface.c | 15 ---
>>> 2 files changed, 27 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
>>> index 86cef15..533c3dc 100644
>>> --- a/include/drm/radeon_drm.h
>>> +++ b/include/drm/radeon_drm.h
>>> @@ -1004,4 +1004,19 @@ struct drm_radeon_info {
>>> #define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
>>> #define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
>>>
>>> +#define CIK_TILE_MODE_COLOR_LINEAR_ALIGNED 8
>>> +#define CIK_TILE_MODE_COLOR_1D 13
>>> +#define CIK_TILE_MODE_COLOR_1D_SCANOUT 9
>>> +#define CIK_TILE_MODE_COLOR_2D_8BPP14
>>> +#define CIK_TILE_MODE_COLOR_2D_16BPP 15
>>> +#define CIK_TILE_MODE_COLOR_2D_32BPP 16
>>> +#define CIK_TILE_MODE_COLOR_2D_64BPP 17
>>> +#define CIK_TILE_MODE_COLOR_2D_SCANOUT_16BPP 11
>>> +#define CIK_TILE_MODE_COLOR_2D_SCANOUT_32BPP 12
>>> +#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
>>> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D 0
>
> And by the way, that looks a bit strange:
>
>>> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_2AA 3
>>> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
>
It's correct according to the tiling documentation.
Alex
>
>
> Christian.
>
>
>>> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
>>> +
>>
>> Can you send a patch to add these to radeon_drm.h in the kernel as well?
>>
>>> #endif
>>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>>> index 818e26a..1710e34 100644
>>> --- a/radeon/radeon_surface.c
>>> +++ b/radeon/radeon_surface.c
>>> @@ -1382,10 +1382,16 @@ static int si_surface_sanity(struct
>>> radeon_surface_manager *surf_man,
>>> break;
>>> case RADEON_SURF_MODE_1D:
>>> if (surf->flags & RADEON_SURF_SBUFFER) {
>>> -*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
>>> +if (surf_man->family >= CHIP_BONAIRE)
>>> +*stencil_tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
>>> +else
>>> +*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
>>> }
>>> if (surf->flags & RADEON_SURF_ZBUFFER) {
>>> -*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
>>> +if (surf_man->family >= CHIP_BONAIRE)
>>> +*tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
>>> +else
>>> +*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
>>> } else if (surf->flags & RADEON_SURF_SCANOUT) {
>>> *tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
>>> } else {
>>> @@ -1643,7 +1649,10 @@ static int si_surface_init_2d(struct
>>> radeon_surface_manager *surf_man,
>>> tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
>>> break;
>>> case SI_TILE_MODE_DEPTH_STENCIL_2D:
>>> -tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
>>> +if (surf_man->family >= CHIP_BONAIRE)
>>> +tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
>>> +else
>>> +tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
>>> break;
>>> default:
>>> return -EINVAL;
>>> --
>>> 1.8.4.rc3
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #6 from Peter Asplund --- The screen gets corrupted on kernel 3.8.5 (which is the oldest kernel I have lying around) as well. I'm typing this blindly. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] radeon: Fix 1D tiling for CIK
Am 18.09.2013 17:54, schrieb Alex Deucher:
On Wed, Sep 18, 2013 at 9:51 AM, Michel Dänzer wrote:
From: Michel Dänzer
The main difference is that the tiling mode index changed for 1D tiled
depth/stencil surfaces.
Signed-off-by: Michel Dänzer
One comment below, other than that,
Reviewed-by: Alex Deucher
---
include/drm/radeon_drm.h | 15 +++
radeon/radeon_surface.c | 15 ---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 86cef15..533c3dc 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -1004,4 +1004,19 @@ struct drm_radeon_info {
#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
+#define CIK_TILE_MODE_COLOR_LINEAR_ALIGNED 8
+#define CIK_TILE_MODE_COLOR_1D 13
+#define CIK_TILE_MODE_COLOR_1D_SCANOUT 9
+#define CIK_TILE_MODE_COLOR_2D_8BPP14
+#define CIK_TILE_MODE_COLOR_2D_16BPP 15
+#define CIK_TILE_MODE_COLOR_2D_32BPP 16
+#define CIK_TILE_MODE_COLOR_2D_64BPP 17
+#define CIK_TILE_MODE_COLOR_2D_SCANOUT_16BPP 11
+#define CIK_TILE_MODE_COLOR_2D_SCANOUT_32BPP 12
+#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D 0
And by the way, that looks a bit strange:
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_2AA 3
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
Christian.
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
+
Can you send a patch to add these to radeon_drm.h in the kernel as well?
#endif
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 818e26a..1710e34 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -1382,10 +1382,16 @@ static int si_surface_sanity(struct
radeon_surface_manager *surf_man,
break;
case RADEON_SURF_MODE_1D:
if (surf->flags & RADEON_SURF_SBUFFER) {
-*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+if (surf_man->family >= CHIP_BONAIRE)
+*stencil_tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
+else
+*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
}
if (surf->flags & RADEON_SURF_ZBUFFER) {
-*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+if (surf_man->family >= CHIP_BONAIRE)
+*tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
+else
+*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
} else if (surf->flags & RADEON_SURF_SCANOUT) {
*tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
} else {
@@ -1643,7 +1649,10 @@ static int si_surface_init_2d(struct
radeon_surface_manager *surf_man,
tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
break;
case SI_TILE_MODE_DEPTH_STENCIL_2D:
-tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+if (surf_man->family >= CHIP_BONAIRE)
+tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
+else
+tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
break;
default:
return -EINVAL;
--
1.8.4.rc3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #8 from Peter Asplund --- Here's a link to a video showing the problem. https://www.youtube.com/watch?v=t3RBRwMxrsk -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: sleeping function called from invalid context on 3.10.10-rt7
On Wed, Sep 18, 2013 at 12:52:07PM -0400, Peter Hurley wrote:
> On 09/17/2013 04:55 PM, Daniel Vetter wrote:
> > On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley
> > wrote:
> >> On 09/11/2013 03:31 PM, Peter Hurley wrote:
> >>>
> >>> [+cc dri-devel]
> >>>
> >>> On 09/11/2013 11:38 AM, Steven Rostedt wrote:
>
> On Wed, 11 Sep 2013 11:16:43 -0400
> Peter Hurley wrote:
>
> >> The funny part is, there's a comment there that shows that this was
> >> done even for "PREEMPT_RT". Unfortunately, the call to
> >> "get_scanout_position()" can call functions that use the rt-mutex
> >> "sleeping spin locks" and it breaks there.
> >>
> >> I guess we need to ask the authors of the mainline patch exactly why
> >> that preempt_disable() is needed?
> >
> >
> > The drm core associates a timestamp with each vertical blank frame #.
> > Drm drivers can optionally support a 'high resolution' hw timestamp.
> > The vblank frame #/timestamp tuple is user-space visible.
> >
> > The i915 drm driver supports a hw timestamp via this drm helper function
> > which computes the timestamp from the crtc scan position (based on the
> > pixel clock).
> >
> > For mainline, the preempt_disable/_enable() isn't actually necessary
> > because every call tree that leads here already has preemption disabled.
> >
> > For -RT, the maybe i915 register spinlock (uncore.lock) should be raw?
> >
>
> No, it should not. Note, any other lock that can be held when it is
> held would also need to be raw.
> >>>
> >>>
> >>> By that, you mean "any other lock" that might be claimed "would also need
> >>> to be raw"? Hopefully not "any other lock" already held?
> >>>
> And by taking a quick audit of the code, I see this:
>
> spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
>
> /* Reset the chip */
>
> /* GEN6_GDRST is not in the gt power well, no need to check
> * for fifo space for the write or forcewake the chip for
> * the read
> */
> __raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL);
>
> /* Spin waiting for the device to ack the reset request */
> ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) &
> GEN6_GRDOM_FULL) == 0, 500);
>
> That spin is unacceptable in RT with preemption and interrupts disabled.
> >>>
> >>>
> >>> Yep. That would be bad.
> >>>
> >>> AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included
> >>> in the force-wake set, so raw reads of the registers would
> >>> probably be acceptable (thus obviating the need for claiming the
> >>> uncore.lock).
> >>>
> >>> Except that _ALL_ register access is disabled with the uncore.lock
> >>> during a gpu reset. Not sure if that's meant to include crtc registers
> >>> or not, or what other synchronization/serialization issues are being
> >>> handled/hidden by forcing all register accesses to wait during a gpu
> >>> reset.
> >>>
> >>> Hopefully an i915 expert can weigh in here?
> >>
> >>
> >>
> >> Daniel,
> >>
> >> Can you shed some light on whether the i915+ crtc registers (specifically
> >> those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter())
> >> read as part of the vblank counter/timestamp handling need to
> >> be prevented during gpu reset?
> >
> > The depency here in the locking is a recent addition:
> >
> > commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a
> > Author: Chris Wilson
> > Date: Fri Jul 19 20:36:51 2013 +0100
> >
> > drm/i915: Serialize almost all register access
> >
> > It's a (slightly) oversized hammer to work around a hardware issue -
> > we could break it down to register blocks, which can be accessed
> > concurrently, but that tends to be more fragile. But the chip really
> > dies if you access (even just reads) the same block concurrently :(
>
> Ouch. But thanks for clarifying that.
>
> Ok, so register access needs to be serialized. And a separate but
> related concern is that gen6+ resets also need to hold-off register
> access where forcewake is required.
>
>
> While I was reviewing the registers that require forcewake handling,
> I saw this:
>
> from i915_reg.h:
> #define _DPLL_A (dev_priv->info->display_mmio_offset + 0x6014)
> #define _DPLL_B (dev_priv->info->display_mmio_offset + 0x6018)
>
> from i915_drv.c:
> static const struct intel_device_info intel_valleyview_m_info = {
> GEN7_FEATURES,
> .is_mobile = 1,
> .num_pipes = 2,
> .is_valleyview = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE, <<<---
> .has_llc = 0, /* legal, last one wins */
> };
>
> from intel_uncore.c:
> #define NEEDS_FORCE_WAKE(dev_priv, reg) \
> ((HAS_FORCE_WAKE((dev_priv)->dev)) && \
>((reg) < 0x4) &&\
>((reg) != FORCEWAKE))
>
> Is this is a mistake or do the valleyview PLLs not require the
> sa
Re: BUG: sleeping function called from invalid context on 3.10.10-rt7
On Wed, Sep 18, 2013 at 6:52 PM, Peter Hurley wrote:
> Ouch. But thanks for clarifying that.
>
> Ok, so register access needs to be serialized. And a separate but
> related concern is that gen6+ resets also need to hold-off register
> access where forcewake is required.
>
>
> While I was reviewing the registers that require forcewake handling,
> I saw this:
>
> from i915_reg.h:
> #define _DPLL_A (dev_priv->info->display_mmio_offset + 0x6014)
> #define _DPLL_B (dev_priv->info->display_mmio_offset + 0x6018)
>
> from i915_drv.c:
> static const struct intel_device_info intel_valleyview_m_info = {
> GEN7_FEATURES,
> .is_mobile = 1,
> .num_pipes = 2,
> .is_valleyview = 1,
> .display_mmio_offset = VLV_DISPLAY_BASE, <<<---
> .has_llc = 0, /* legal, last one wins */
> };
>
> from intel_uncore.c:
> #define NEEDS_FORCE_WAKE(dev_priv, reg) \
> ((HAS_FORCE_WAKE((dev_priv)->dev)) && \
> ((reg) < 0x4) &&\
> ((reg) != FORCEWAKE))
>
> Is this is a mistake or do the valleyview PLLs not require the
> same forcewake handling as the other intel gpus?
The DPLL offset from the macro at 0x6000 is from older platforms which
lacked forcewake and where the display block started already on
0x6000.
On recent big core platforms we have the north display block at
0x4 (i.e. forcewake is only used for the rendering side of
things). For those platforms the DPLL macro is called PCH_DPLL (and
it's in the south display range starting at 0xc. VLV itself
inherited the old display register blocks (mostly) but moved them all
by the vlv display base offset.
We have quite a bit of fun with hw engineers moving display blocks around ;-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BUG: sleeping function called from invalid context on 3.10.10-rt7
On 09/17/2013 04:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
"get_scanout_position()" can call functions that use the rt-mutex
"sleeping spin locks" and it breaks there.
I guess we need to ask the authors of the mainline patch exactly why
that preempt_disable() is needed?
The drm core associates a timestamp with each vertical blank frame #.
Drm drivers can optionally support a 'high resolution' hw timestamp.
The vblank frame #/timestamp tuple is user-space visible.
The i915 drm driver supports a hw timestamp via this drm helper function
which computes the timestamp from the crtc scan position (based on the
pixel clock).
For mainline, the preempt_disable/_enable() isn't actually necessary
because every call tree that leads here already has preemption disabled.
For -RT, the maybe i915 register spinlock (uncore.lock) should be raw?
No, it should not. Note, any other lock that can be held when it is
held would also need to be raw.
By that, you mean "any other lock" that might be claimed "would also need
to be raw"? Hopefully not "any other lock" already held?
And by taking a quick audit of the code, I see this:
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
/* Reset the chip */
/* GEN6_GDRST is not in the gt power well, no need to check
* for fifo space for the write or forcewake the chip for
* the read
*/
__raw_i915_write32(dev_priv, GEN6_GDRST, GEN6_GRDOM_FULL);
/* Spin waiting for the device to ack the reset request */
ret = wait_for((__raw_i915_read32(dev_priv, GEN6_GDRST) &
GEN6_GRDOM_FULL) == 0, 500);
That spin is unacceptable in RT with preemption and interrupts disabled.
Yep. That would be bad.
AFAICT the registers read in i915_get_crtc_scanoutpos() aren't included
in the force-wake set, so raw reads of the registers would
probably be acceptable (thus obviating the need for claiming the
uncore.lock).
Except that _ALL_ register access is disabled with the uncore.lock
during a gpu reset. Not sure if that's meant to include crtc registers
or not, or what other synchronization/serialization issues are being
handled/hidden by forcing all register accesses to wait during a gpu
reset.
Hopefully an i915 expert can weigh in here?
Daniel,
Can you shed some light on whether the i915+ crtc registers (specifically
those in i915_get_crtc_scanoutpos() and i915_/gm45_get_vblank_counter())
read as part of the vblank counter/timestamp handling need to
be prevented during gpu reset?
The depency here in the locking is a recent addition:
commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a
Author: Chris Wilson
Date: Fri Jul 19 20:36:51 2013 +0100
drm/i915: Serialize almost all register access
It's a (slightly) oversized hammer to work around a hardware issue -
we could break it down to register blocks, which can be accessed
concurrently, but that tends to be more fragile. But the chip really
dies if you access (even just reads) the same block concurrently :(
Ouch. But thanks for clarifying that.
Ok, so register access needs to be serialized. And a separate but
related concern is that gen6+ resets also need to hold-off register
access where forcewake is required.
While I was reviewing the registers that require forcewake handling,
I saw this:
from i915_reg.h:
#define _DPLL_A (dev_priv->info->display_mmio_offset + 0x6014)
#define _DPLL_B (dev_priv->info->display_mmio_offset + 0x6018)
from i915_drv.c:
static const struct intel_device_info intel_valleyview_m_info = {
GEN7_FEATURES,
.is_mobile = 1,
.num_pipes = 2,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE, <<<---
.has_llc = 0, /* legal, last one wins */
};
from intel_uncore.c:
#define NEEDS_FORCE_WAKE(dev_priv, reg) \
((HAS_FORCE_WAKE((dev_priv)->dev)) && \
((reg) < 0x4) &&\
((reg) != FORCEWAKE))
Is this is a mistake or do the valleyview PLLs not require the
same forcewake handling as the other intel gpus?
Regards,
Peter Hurley
We could try break the spinlock protected section a bit in the reset
handler - register access on a hung gpu tends to be ill-defined
anyway.
The implied wait with preemption and interrupts disabled is causing grief
in -RT, but also a 4ms wait inside an irq handler seems like a bad idea.
Oops, the magic code in wait_for which is just there to make the imo
totally misguided kgdb support work papered over the aweful long wait
in atomic context ever since we've added this in
commit b6e45f866465f42b53d803b0c574da0fc508a0e9
Author: Keith Packard
Date: Fri Jan 6 11:34:04 2012 -0800
drm/i915: Move reset
[Bug 69543] New: Radeon EXAPixmaps don't work with stretched XRender pictures
https://bugs.freedesktop.org/show_bug.cgi?id=69543 Priority: medium Bug ID: 69543 Assignee: dri-devel@lists.freedesktop.org Summary: Radeon EXAPixmaps don't work with stretched XRender pictures Severity: normal Classification: Unclassified OS: Linux (All) Reporter: juj...@gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI There is garbage on screen with some stretched XRender pictures with radeon driver and enabled EXAPixmaps, see for example MSEide without xorg.conf http://sourceforge.net/projects/mseide-msegui/ MSEgui uses stretched one pixel width or height pixmaps in order to draw linear color gradients. If you add Option "EXAPixmaps" "off" in Section "Device" of xorg.conf display is OK but performance falls. Same problem using NOUVEAU driver. I can't figure out how disable EXAPixmaps for nouveau driver. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69543] Radeon EXAPixmaps don't work with stretched XRender pictures
https://bugs.freedesktop.org/show_bug.cgi?id=69543 --- Comment #5 from Julio Jiménez --- Using Debian stable, testing, sid, Ubuntu 12.04 Really this happens since KMS was used IIRC. In fact using radeon.modeset=0 fixes it for some ATI cards -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69543] Radeon EXAPixmaps don't work with stretched XRender pictures
https://bugs.freedesktop.org/show_bug.cgi?id=69543 --- Comment #4 from Julio Jiménez --- Comment on attachment 86094 --> https://bugs.freedesktop.org/attachment.cgi?id=86094 Image showing the issue Running MSEide with -ns option (No skin) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69543] Radeon EXAPixmaps don't work with stretched XRender pictures
https://bugs.freedesktop.org/show_bug.cgi?id=69543 --- Comment #2 from Julio Jiménez --- Created attachment 86094 --> https://bugs.freedesktop.org/attachment.cgi?id=86094&action=edit Image showing the issue -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69543] Radeon EXAPixmaps don't work with stretched XRender pictures
https://bugs.freedesktop.org/show_bug.cgi?id=69543 --- Comment #3 from Julio Jiménez --- Created attachment 86095 --> https://bugs.freedesktop.org/attachment.cgi?id=86095&action=edit Showing the issue with default MSEide options -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69543] Radeon EXAPixmaps don't work with stretched XRender pictures
https://bugs.freedesktop.org/show_bug.cgi?id=69543 --- Comment #1 from Julio Jiménez --- Created attachment 86093 --> https://bugs.freedesktop.org/attachment.cgi?id=86093&action=edit Image OK -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69543] Radeon EXAPixmaps don't work with stretched XRender pictures
https://bugs.freedesktop.org/show_bug.cgi?id=69543 Alex Deucher changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |xorg-t...@lists.x.org |.org| QA Contact||xorg-t...@lists.x.org Product|DRI |xorg Version|XOrg CVS|unspecified Component|DRM/Radeon |Server/Acceleration/EXA -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #9 from José Suárez --- Thank you, Michel. I have compiled 9.3~git1309181129.ec44d5 with llvm 3.4~svn190862. CK II now works much better as the map can be seen. However, the faces of the characters do not show correctly. I am attaching two screenshots and the shader dump in case it helps. KF still shows the same problem, so it is probable that both problems were unrelated. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #10 from José Suárez --- Created attachment 86100 --> https://bugs.freedesktop.org/attachment.cgi?id=86100&action=edit CK II screenshot with LLVM 3.4 svn -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #11 from José Suárez --- Created attachment 86101 --> https://bugs.freedesktop.org/attachment.cgi?id=86101&action=edit CK II screenshot with LLVM 3.4 svn -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #12 from José Suárez --- Created attachment 86102 --> https://bugs.freedesktop.org/attachment.cgi?id=86102&action=edit CK II shader dump with LLVM 3.4 svn -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #13 from José Suárez --- Sorry, I should have specified the screenshots as images. Trying again... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #14 from José Suárez --- Created attachment 86105 --> https://bugs.freedesktop.org/attachment.cgi?id=86105&action=edit CK II screenshot #1 with LLVM 3.4 svn -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 Alex Deucher changed: What|Removed |Added Attachment #86100|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #15 from José Suárez --- Created attachment 86106 --> https://bugs.freedesktop.org/attachment.cgi?id=86106&action=edit CK II screenshot #2 with LLVM 3.4 svn -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 Alex Deucher changed: What|Removed |Added Attachment #86101|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #9 from Alex Deucher --- Make sure you kernel has this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=022374c02e357ac82e98dd2689fb2efe05723d69 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #19 from Marek Olšák --- Created attachment 86107 --> https://bugs.freedesktop.org/attachment.cgi?id=86107&action=edit possible fix Could you please try this patch? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #33 from Alex Deucher --- Created attachment 86111 --> https://bugs.freedesktop.org/attachment.cgi?id=86111&action=edit testing patch - force mclk to high Try this patch by itself. This patch will force the mclk to the highest for all performance levels. If it works, the issue is probably related to the changing of mclks, if not, then we are probably programming one of the mclk parameters wrong. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 Alex Deucher changed: What|Removed |Added Attachment #86111|0 |1 is obsolete|| --- Comment #34 from Alex Deucher --- Created attachment 86112 --> https://bugs.freedesktop.org/attachment.cgi?id=86112&action=edit testing patch - force mclk to high Sorry, had some garbage in my tree. use this one instead. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #30 from Jose P. --- (In reply to comment #29) > Created attachment 86051 [details] [review] > DRI2: Install client callback only once > > Does this patch fix the problem? This, plus the patch in comment 6, fixed it for me (Lubuntu saucy, kernel 3.12-rc1 amd64, xserver-xorg-video-radeon 1:7.2.0-0ubuntu6 ). Thanks people, thank you very much! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #35 from Alexandre Demers --- (In reply to comment #34) > Created attachment 86112 [details] [review] > testing patch - force mclk to high > > Sorry, had some garbage in my tree. use this one instead. Tested and the screen ended up blank or frozen somewhere near when Xorg and gdm are being launched (tried twice). Before that, the console was being displayed OK. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64600] r600g pyrit OpenCL issue on HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64600 --- Comment #10 from Erdem U. Altınyurt --- Created attachment 86118 --> https://bugs.freedesktop.org/attachment.cgi?id=86118&action=edit Debug output I am attaching debug output generated with R600_DEBUG=cs pyrit benchmark 2> debug.txt without the patch (attachment 86005). With the latest proposed patch, there are no output on debug. Just stalling. Don't know why. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm radeon/nouveau/core fixes
Hi Linus, mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix for AST driver. Dave. The following changes since commit 01172772c7c973debf5b4881fcb9463891ea97ec: drm/nouveau: fix oops on runtime suspend/resume (2013-09-10 12:38:53 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 928c2f0c006bf7f381f58af2b2786d2a858ae311: drm/fb-helper: don't sleep for screen unblank when an oops is in progress (2013-09-19 11:54:34 +1000) Alex Deucher (24): drm/radeon/cik: properly handle internal cp ints drm/radeon/si: properly handle internal cp ints drm/radeon/dce6/audio: make sure pin is valid before accessing it drm/radeon: add a connector property for audio drm/radeon: dpm updates for KV drm/radeon: protect concurrent smc register access with a spinlock drm/radeon: add spinlocks for indirect register accesss drm/radeon/cik: update gpu_init for an additional berlin gpu drm/radeon: add some additional berlin pci ids drm/radeon: fix typo in PG flags drm/radeon/r6xx: add a stubbed out set_uvd_clocks callback drm/radeon/dpm: fix fallback for empty UVD clocks drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2) drm/radeon/dpm: handle bapm on trinity drm/radeon/dpm: handle bapm on kb/kv drm/radeon/dpm: add infrastructure to properly handle bapm drm/radeon/dpm: add bapm callback for trinity drm/radeon/dpm: add bapm callback for kb/kv drm/radeon/dpm/rs780: use drm_mode_vrefresh() drm/radeon/dpm/rs780: add some sanity checking to sclk scaling drm/radeon/dpm/rs780: don't enable sclk scaling if not required drm/radeon/dpm/rs780: fix force_performance state for same sclks drm/radeon/dpm: rework auto performance level enable drm/radeon: fix panel scaling with eDP and LVDS bridges Anthoine Bourgeois (1): drm/radeon/dpm: implement force performance levels for rs780 (v2) Ben Skeggs (5): drm/nouveau/bios/init: stub opcode 0xaa drm/nouveau/kms: enable for non-vga pci classes drm/nouveau/bios/init: fix thinko in INIT_CONFIGURE_MEM drm/nouveau/ttm: prevent double-free in nouveau_sgdma_create_ttm() failure path drm/ttm: fix the tt_populated check in ttm_tt_destroy() Christian König (3): drm/radeon: remove stale radeon_fence_retire tracepoint drm/radeon: add command submission tracepoint drm/radeon: avoid UVD corruptions on AGP cards Damien Lespiau (1): drm/radeon: Fix hmdi typo Dan Carpenter (2): drm/radeon: clean up r600_free_extended_power_table() drm/radeon: signedness bug in kv_dpm.c Daniel Vetter (2): drm/udl: rip out set_need_resched drm/fb-helper: don't sleep for screen unblank when an oops is in progress Dave Airlie (4): drm/ast: fix the ast open key function Merge branch 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-fixes-3.12' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Jean Delvare (2): drm/radeon: simplify driver data retrieval drm/radeon: expose DPM thermal thresholds through sysfs Prarit Bhargava (1): drm, ttm Fix uninitialized warning drivers/gpu/drm/ast/ast_drv.h | 2 +- drivers/gpu/drm/drm_fb_helper.c | 8 ++ drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 21 ++- drivers/gpu/drm/nouveau/nouveau_display.c | 35 +++-- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c | 4 +- drivers/gpu/drm/radeon/atombios_encoders.c | 23 ++-- drivers/gpu/drm/radeon/btc_dpm.c| 6 - drivers/gpu/drm/radeon/ci_dpm.c | 6 - drivers/gpu/drm/radeon/ci_smc.c | 39 -- drivers/gpu/drm/radeon/cik.c| 36 +- drivers/gpu/drm/radeon/cypress_dpm.c| 6 - drivers/gpu/drm/radeon/dce6_afmt.c | 12 +- drivers/gpu/drm/radeon/kv_dpm.c | 164 +++- drivers/gpu/drm/radeon/kv_dpm.h | 1 + drivers/gpu/drm/radeon/kv_smc.c | 8 ++ drivers/gpu/drm/radeon/ni_dpm.c | 6 - drivers/gpu/drm/radeon/ppsmc.h | 2 + drivers/gpu/drm/radeon/r100.c | 7 + drivers/gpu/drm/radeon/r420.c | 7 + drivers/gpu/drm/radeon/r600.c | 19 +++ drivers/gpu/drm/radeon/r600_dpm.c | 38 ++ drivers/gpu/drm/radeon/r600d.h | 2 +- drivers/gpu/drm/radeon/radeon.h | 82 +++- drivers/gpu/drm/radeon/radeon_asic.c|
Re: [git pull] drm radeon/nouveau/core fixes
On Wed, Sep 18, 2013 at 9:07 PM, Dave Airlie wrote: > > mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix > for AST driver. Ugh. I hope things calm down from here. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm radeon/nouveau/core fixes
On Thu, Sep 19, 2013 at 12:20 PM, Linus Torvalds wrote: > On Wed, Sep 18, 2013 at 9:07 PM, Dave Airlie wrote: >> >> mostly radeon fixes, with some nouveau bios parser, ttm fix and a fix >> for AST driver. > > Ugh. I hope things calm down from here. It shouldn't be that bad, this stuff was a bit delayed, some of it was in my tree before the merge closed, I was just distracting myself with other stuff, The radeon stuff is for new hw that was merged in the merge window, and more DPM fixes which is still off by default, The only coming thing that worries me is the VGA arbitration fixes for Intel GPUs is really screwed up and fixing it looks like resorting to slightly drastic measures. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: bisected: commit 7c510133d93 breaks video
On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman wrote: > I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video card. > With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works > fine. > > Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm: > mark context support as a legacy subsystem" is the guilty commit. If I > revert that commit, the video works fine. > > Is there any more info I can provide? Full dmesg, and what driver you are using. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #36 from Alexandre Demers ---
A test of my own:
diff --git a/drivers/gpu/drm/radeon/ni_dpm.c b/drivers/gpu/drm/radeon/ni_dpm.c
index f7b625c..c1875d2 100644
--- a/drivers/gpu/drm/radeon/ni_dpm.c
+++ b/drivers/gpu/drm/radeon/ni_dpm.c
@@ -3952,10 +3952,14 @@ static void ni_parse_pplib_clock_info(struct
radeon_device *rdev,
pl->mclk = le16_to_cpu(clock_info->evergreen.usMemoryClockLow);
pl->mclk |= clock_info->evergreen.ucMemoryClockHigh << 16;
+ pl->mclk = 10;
+
pl->vddc = le16_to_cpu(clock_info->evergreen.usVDDC);
pl->vddci = le16_to_cpu(clock_info->evergreen.usVDDCI);
pl->flags = le32_to_cpu(clock_info->evergreen.ulFlags);
+ pl->vddci = 1150;
+
/* patch up vddc if necessary */
if (pl->vddc == 0xff01) {
if (radeon_atom_get_max_vddc(rdev, 0, 0, &vddc) == 0)
This works. I haven't pushed higher yet.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #37 from Alexandre Demers --- Went to pl->mclk = 115000, runs fine. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69372] Render issues in some GTK widgets with Mesa 9+ RadeonSI drivers
https://bugs.freedesktop.org/show_bug.cgi?id=69372 --- Comment #13 from Alexey --- Seems like that firefox works correct(today I have got update to ff24, so I'm not sure if the glamor patch fixed issue or ff fixed it by themselves). But GNOME's software still have the same issues. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #38 from Alexandre Demers --- Running with mclk at 12. I went under Windows and launch GPU-Z. We should be able to reach 1300MHz. I've read that some Cayman cards were made to use a VDDCi between 1.15 and 1.16. I'm pretty sure I can reach stability at 13 by rising VDDCI a bit. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #39 from Alexandre Demers --- Running with mclk at 125000 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote: > No, that's wrong. ->count_objects should never ass SHRINK_STOP. > Indeed, it should always return a count of objects in the cache, > regardless of the context. > > SHRINK_STOP is for ->scan_objects to tell the shrinker it can make > any progress due to the context it is called in. This allows the > shirnker to defer the work to another call in a different context. > However, if ->count-objects doesn't return a count, the work that > was supposed to be done cannot be deferred, and that is what > ->count_objects should always return the number of objects in the > cache. So we should rework the locking in the drm/i915 shrinker to be able to always count objects? Thus far no one screamed yet that we're not really able to do that in all call contexts ... So should I revert 81e49f or will the early return 0; completely upset the core shrinker logic? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
