[Bug 74863] [r600g] HyperZ broken on RV770 and CYPRESS (Left 4 Dead 2 trees corruption) bisected!
https://bugs.freedesktop.org/show_bug.cgi?id=74863 --- Comment #5 from smoki --- (In reply to comment #4) > Problem still persists with current master (git-e8f8353). Tested on > Evergreen. > > The apitrace can be downloaded here : > https://drive.google.com/file/d/0B7D2Y0QXFND2bUlVc1JyMHZKVWc > (364 MB, md5sum 3e80394465612a7f29aced09ea02bd78) Just as info... can not reproduce it on radeonsi with this apitrace, seems like r600 only issue :). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/a0639b83/attachment-0001.html>
[Bug 82918] [tahiti xt] dota2 crashes
https://bugs.freedesktop.org/show_bug.cgi?id=82918 Michel D?nzer changed: What|Removed |Added Attachment #105573|text/plain |application/x-7z-compressed mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/be652fd2/attachment.html>
[Bug 82918] [tahiti xt] dota2 crashes
https://bugs.freedesktop.org/show_bug.cgi?id=82918 --- Comment #15 from Michel D?nzer --- I can reproduce the failure with llc from LLVM 3.4, but it seems fixed in LLVM 3.5. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/b2a474d6/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #240 from Kajzer --- Update: just had a crash on boot, I guess Ill try your options for boot and see will it happen again. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/c3a81b87/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #68 from Michel D?nzer --- (In reply to comment #67) > This what you're looking for? No, we're looking for the /home/aaron/chromium.*.trace file generated by apitrace corresponding to the crash. BTW, can you try if Mesa 10.1 is stable for you as well? And if so, bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/d961f450/attachment.html>
[PATCH] drm/panel: update innolux n116bge timings
There are several different models of N116BGE. According to the commit
that added innolux_n116bge_mode [0], this N116BGE is for the eDP variety.
[0] commit 0a2288c06aab73c966e82045c8f20b0e713baf2a
Author: Thierry Reding
Date: Thu Jul 3 14:02:59 2014 +0200
drm/panel: simple: Add Innolux N116BGE panel support
The clock and htotal values from add by that patch are out of spec according to
the datasheets I have seen for the eDP N116BGE (-EA2 and -EB2).
This patch changes the values to the "Typ" values on the datasheet.
Signed-off-by: Daniel Kurtz
---
Thierry,
It is possible that your timings were correct for the panel you are using on
the norrin reference board. In that case I'm happy to upload a new patch
that creates a new panel entry. However, I'm pretty sure we are using the
same N116BGE.
drivers/gpu/drm/panel/panel-simple.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4ce1db0..776764a 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -519,15 +519,15 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
};
static const struct drm_display_mode innolux_n116bge_mode = {
- .clock = 71000,
+ .clock = 76420,
.hdisplay = 1366,
- .hsync_start = 1366 + 64,
- .hsync_end = 1366 + 64 + 6,
- .htotal = 1366 + 64 + 6 + 64,
+ .hsync_start = 1366 + 136,
+ .hsync_end = 1366 + 136 + 30,
+ .htotal = 1366 + 136 + 30 + 60,
.vdisplay = 768,
.vsync_start = 768 + 8,
- .vsync_end = 768 + 8 + 4,
- .vtotal = 768 + 8 + 4 + 8,
+ .vsync_end = 768 + 8 + 12,
+ .vtotal = 768 + 8 + 12 + 12,
.vrefresh = 60,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
};
--
2.1.0.rc2.206.gedb03e5
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 Aaron B changed: What|Removed |Added Attachment #105569|0 |1 is obsolete|| --- Comment #69 from Aaron B --- Created attachment 105581 --> https://bugs.freedesktop.org/attachment.cgi?id=105581&action=edit chromiumapitrace (In reply to comment #68) > (In reply to comment #67) > > This what you're looking for? > > No, we're looking for the /home/aaron/chromium.*.trace file generated by > apitrace corresponding to the crash. > > BTW, can you try if Mesa 10.1 is stable for you as well? And if so, bisect? If I get time I'll compile Mesa 10.1 32 and 64 bit and see if they work. No promises, as git always fails either on or right after receiving 99% of objects, so I have to try about 20 times to even attempt compile basically anything. Still, you're in luck as I started an API Trace and as soon as my browser started to open, it killed it, so it's a nice and pair of traces. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/eba6ccac/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 Aaron B changed: What|Removed |Added Attachment #105581|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/3023e657/attachment-0001.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #70 from Aaron B --- Wrong file. This is the right file: https://drive.google.com/file/d/0B1laUfqMuZQBeWpHSDYtV2N3RjQ/edit?usp=sharing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/c880db1a/attachment.html>
[PATCH] ipu-v3: ipu-smfc: Do not leave DEBUG defined
From: Fabio Estevam Let's only define DEBUG for debugging purpose and not by default to avoid printing debugging message unnecessarily. Signed-off-by: Fabio Estevam --- Russell, Are you still collecting ipu-v3 patches? ./scripts/get_maintainer.pl does not provide too many hints on who should take a patch like this. drivers/gpu/ipu-v3/ipu-smfc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/ipu-v3/ipu-smfc.c b/drivers/gpu/ipu-v3/ipu-smfc.c index e4f85ad..4939c50 100644 --- a/drivers/gpu/ipu-v3/ipu-smfc.c +++ b/drivers/gpu/ipu-v3/ipu-smfc.c @@ -8,7 +8,6 @@ * http://www.opensource.org/licenses/gpl-license.html * http://www.gnu.org/copyleft/gpl.html */ -#define DEBUG #include #include #include -- 1.9.1
[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
On 2 September 2014 14:05, Theodore Ts'o wrote: > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no > longer see the my Dell 30" monitor when it is connected via the > docking station using a Displayport connector. This worked using 3.16 > kernel. > > If I connect to the monitor using the mini-display, by passing the > docking station, things work fine (but of course it's annoying not to > be able to use the docking station). > > Is this a known problem? This is not the first time that we've had > regressions with this docking station. It's vaguely reminsicent of > > https://bugs.freedesktop.org/show_bug.cgi?id=71267 > > Except the system isn't hanging; it's just not seeing the monitor at all. Have you the Dell 30" set to Displayport 1.2 enabled mode? If so, then see if disabling that in the monitor menus helps. This is probably due to the fact we now attempt to talk to new DP devices with the protocol they provide. So previously the monitor exposed DP 1.2 and we just didn't care, now if it exposes it we attempt to talk to it. Dave.
[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no longer see the my Dell 30" monitor when it is connected via the docking station using a Displayport connector. This worked using 3.16 kernel. If I connect to the monitor using the mini-display, by passing the docking station, things work fine (but of course it's annoying not to be able to use the docking station). Is this a known problem? This is not the first time that we've had regressions with this docking station. It's vaguely reminsicent of https://bugs.freedesktop.org/show_bug.cgi?id=71267 Except the system isn't hanging; it's just not seeing the monitor at all. Thanks, - Ted
[Bug 83731] New: dpm still not working on radeon TURKS 1002:6840
https://bugzilla.kernel.org/show_bug.cgi?id=83731 Bug ID: 83731 Summary: dpm still not working on radeon TURKS 1002:6840 Product: Drivers Version: 2.5 Kernel Version: 3.17-rc Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: giancarlo.formicuccia at gmail.com Regression: No Created attachment 149011 --> https://bugzilla.kernel.org/attachment.cgi?id=149011&action=edit kernel messages with dpm enabled Now that dpm is enabled by default on TURKS cards, I'd like to give another try to get it working on my card. Booting a 3.17-rc3 kernel results in a blank screen; the computer is not locked up, I still can ssh into the machine and grab the kernel messages. lspci reports: 01:00.0 0300: 1002:6840 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: radeon Kernel modules: radeon 01:00.1 0403: 1002:aa90 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel modules: snd_hda_intel Loading the radeon module with dpm=0 works without problems. Note that dpm *did* work correctly until 3.13 kernels (using dpm=1); then it broke during the 3.14 delopement cycle. I bisected the bad commit in 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 drm/radeon/pm: move pm handling into the asic specific code and reported the problem on the dri-devel ml, without luck. My guess is that something changed during the initialization of the card which is confusing this GPU, but I was unable to identify the problem by myself. Attached the kernel messages after loading the radeon module on 3.17-rc3. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #11 from Pavel Ondra?ka --- Full test output with debugging patch: $ bin/shader_runner tests/shaders/glsl-fs-loop-continue.shader_test -auto r300: DRM version: 2.38.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES --- begin simplify --- got here with node 2 pushing node 2 onto the stack got here with node 1 pushing node 1 onto the stack got here with node 0 got here with node 0 --- end simplify --- Neopr?vn?n? p??stup do pam?ti (SIGSEGV) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/8ff645c8/attachment.html>
[PATCH] drm: Include task->name and master status in debugfs clients info
Showing who is the current master is useful for trying to decypher
errors when trying to acquire master (e.g. a race with X taking over
from plymouth). By including the process name as well as the pid
simplifies the task of grabbing enough information remotely at the point
of error.
v2: Add the command column header and flesh out a couple of comments.
(David Herrmann)
Signed-off-by: Chris Wilson
Cc: David Herrmann
Reviewed-by: David Herrmann
---
drivers/gpu/drm/drm_info.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index 15ec9f471ece..36aba980ea8b 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -183,15 +183,32 @@ int drm_clients_info(struct seq_file *m, void *data)
struct drm_device *dev = node->minor->dev;
struct drm_file *priv;
+ seq_printf(m,
+ "%20s %5s %3s master a %5s %10s\n",
+ "command",
+ "pid",
+ "dev",
+ "uid",
+ "magic");
+
+ /* dev->filelist is sorted youngest first, but we want to present
+* oldest first (i.e. kernel, servers, clients), so walk backwardss.
+*/
mutex_lock(&dev->struct_mutex);
- seq_printf(m, "a devpiduid magic\n\n");
- list_for_each_entry(priv, &dev->filelist, lhead) {
- seq_printf(m, "%c %3d %5d %5d %10u\n",
- priv->authenticated ? 'y' : 'n',
- priv->minor->index,
+ list_for_each_entry_reverse(priv, &dev->filelist, lhead) {
+ struct task_struct *task;
+
+ rcu_read_lock(); /* locks pid_task()->comm */
+ task = pid_task(priv->pid, PIDTYPE_PID);
+ seq_printf(m, "%20s %5d %3d %c%c %5d %10u\n",
+ task ? task->comm : "",
pid_vnr(priv->pid),
+ priv->minor->index,
+ priv->is_master ? 'y' : 'n',
+ priv->authenticated ? 'y' : 'n',
from_kuid_munged(seq_user_ns(m), priv->uid),
priv->magic);
+ rcu_read_unlock();
}
mutex_unlock(&dev->struct_mutex);
return 0;
--
2.1.0
[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"
On 30.08.2014 22:59, Mikael Pettersson wrote:
> Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
> after a while in X + firefox. This still occurs with yesterday's HEAD
> of Linus' repo. 3.16 and ealier kernels are fine.
>
> I ran a bisect, which identified:
>
> commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
> Author: Michel D??nzer
> Date: Thu Jul 31 18:43:49 2014 +0900
>
> drm/radeon: Always flush the HDP cache before submitting a CS to the GPU
>
> as the cause of my screen corruption. Reverting this from 3.17-rc2
> (which requires manual intervention due to subsequent changes in
> radeon_ring_commit()) eliminates the screen corruption.
Does the patch below help?
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4c5ec44..3ff9c53 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1070,6 +1070,20 @@ void r100_ring_hdp_flush(struct radeon_device *rdev,
struct radeon_ring *ring)
radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
}
+/**
+ * r100_mmio_hdp_flush - flush Host Data Path via MMIO
+ * rdev: radeon device structure
+ */
+void r100_mmio_hdp_flush(struct radeon_device *rdev)
+{
+ WREG32(RADEON_HOST_PATH_CNTL,
+ rdev->config.r100.hdp_cntl | RADEON_HDP_READ_BUFFER_INVALIDATE);
+ (void)RREG32(RADEON_HOST_PATH_CNTL);
+ WREG32(RADEON_HOST_PATH_CNTL,
+ rdev->config.r100.hdp_cntl);
+ (void)RREG32(RADEON_HOST_PATH_CNTL);
+}
+
static void r100_cp_load_microcode(struct radeon_device *rdev)
{
const __be32 *fw_data;
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index abe..c23a123 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -408,7 +408,7 @@ static struct radeon_asic r300_asic_pcie = {
.resume = &r300_resume,
.vga_set_state = &r100_vga_set_state,
.asic_reset = &r300_asic_reset,
- .mmio_hdp_flush = NULL,
+ .mmio_hdp_flush = r100_mmio_hdp_flush,
.gui_idle = &r100_gui_idle,
.mc_wait_for_idle = &r300_mc_wait_for_idle,
.gart = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 275a5dc..e9b1c35 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -150,6 +150,8 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
struct radeon_ring *ring);
void r100_ring_hdp_flush(struct radeon_device *rdev,
struct radeon_ring *ring);
+void r100_mmio_hdp_flush(struct radeon_device *rdev);
+
/*
* r200,rv250,rs300,rv280
*/
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index bfd7e1b..3d0f564 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -368,6 +368,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
r = radeon_bo_wait(robj, &cur_placement, false);
/* Flush HDP cache via MMIO if necessary */
if (rdev->asic->mmio_hdp_flush &&
+ !rdev->asic->ring[RADEON_RING_TYPE_GFX_INDEX]->hdp_flush &&
radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
robj->rdev->asic->mmio_hdp_flush(rdev);
drm_gem_object_unreference_unlocked(gobj);
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index d656079..b82843b 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -188,7 +188,8 @@ void radeon_ring_commit(struct radeon_device *rdev, struct
radeon_ring *ring,
/* If we are emitting the HDP flush via the ring buffer, we need to
* do it before padding.
*/
- if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush)
+ if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush &&
+ !rdev->asic->mmio_hdp_flush)
rdev->asic->ring[ring->idx]->hdp_flush(rdev, ring);
/* We pad to match fetch size */
while (ring->wptr & ring->align_mask) {
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #71 from Michel D?nzer --- (In reply to comment #70) > https://drive.google.com/file/d/0B1laUfqMuZQBeWpHSDYtV2N3RjQ/edit?usp=sharing Can you reproduce the crash by feeding those traces to glretrace? (In reply to comment #69) > If I get time I'll compile Mesa 10.1 32 and 64 bit and see if they work. No > promises, as git always fails either on or right after receiving 99% of > objects, so I have to try about 20 times to even attempt compile basically > anything. Note that you only really need to clone a Git repository once, after that all the history (including all the commits you might need to test during the bisection) is available locally. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/f9add177/attachment.html>
[PULL REQUEST] ttm fence conversion
Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
> Hey,
>
> On 01-09-14 18:21, Christian K?nig wrote:
>> Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
>>> Hey,
>>>
>>> Op 01-09-14 om 14:31 schreef Christian K?nig:
Please wait a second with that.
I didn't had a chance to test this yet and nobody has yet given it's rb on
at least the radeon changes in this branch.
>>> Ok, my fault. I thought it was implicitly acked. I haven't made any
>>> functional changes to these patches,
>>> just some small fixups and a fix to make it apply after the upstream
>>> removal of RADEON_FENCE_SIGNALED_SEQ.
>> Yeah, but the resulting patch looks to complex for my taste and should be
>> simplified a bit more. Here is a more detailed review:
>>
>>> +wait_queue_t fence_wake;
>> Only a nitpick, but please fix the indention and maybe add a comment.
>>
>>> +struct work_struct delayed_irq_work;
>> Just drop that, the new fall back work item should take care of this when
>> the unfortunate case happens that somebody tries to enable_signaling in the
>> middle of a GPU reset.
> I can only drop it if radeon_gpu_reset will always call radeon_irq_set after
> downgrading to read mode, even if no work needs to be done. :-)
>
> Then again, should be possible.
The fall back handler should take care of the rare condition that we
can't activate the IRQ because the driver is in a lockup handler.
The issue is that the delayed_irq_work handler needs to take the
exclusive lock once more and so would block an innocent process for the
duration of the GPU lockup.
Either reschedule as delayed work item if we can't take the lock
immediately or just live with the delay of the fall back handler. Since
IRQs usually don't work correctly immediately after an GPU reset I'm
pretty sure that the fallback handler will be needed anyway.
>>> /*
>>> - * Cast helper
>>> - */
>>> -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
>>> -
>>> -/*
>> Please define the new cast helper in radeon.h as well.
> The ops are only defined in radeon_fence.c, and nothing outside of
> radeon_fence.c should care about the internals.
Then define this as a function instead, I need a checked cast from a
fence to a radeon_fence outside of the fence code as well.
>
>>> if (!rdev->needs_reset) {
>>> -up_write(&rdev->exclusive_lock);
>>> +downgrade_write(&rdev->exclusive_lock);
>>> +wake_up_all(&rdev->fence_queue);
>>> +up_read(&rdev->exclusive_lock);
>>> return 0;
>>> }
>> Just drop that as well, no need to wake up anybody here.
> Maybe not, but if I have to remove delayed_irq_work I do need to add a
> radeon_irq_set here.
>
>>> downgrade_write(&rdev->exclusive_lock);
>>> +wake_up_all(&rdev->fence_queue);
>> Same here, the IB test will wake up all fences for recheck anyway.
> Same as previous comment. :-)
>
>>> + * radeon_fence_read_seq - Returns the current fence value without updating
>>> + *
>>> + * @rdev: radeon_device pointer
>>> + * @ring: ring index to return the seqno of
>>> + */
>>> +static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int ring)
>>> +{
>>> +uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
>>> +uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
>>> +uint64_t seq = radeon_fence_read(rdev, ring);
>>> +
>>> +seq = radeon_fence_read(rdev, ring);
>>> +seq |= last_seq & 0xLL;
>>> +if (seq < last_seq) {
>>> +seq &= 0x;
>>> +seq |= last_emitted & 0xLL;
>>> +}
>>> +return seq;
>>> +}
>> Completely drop that and just check the last_seq signaled as set by
>> radeon_fence_activity.
> Do you mean call radeon_fence_activity in radeon_fence_signaled? Or should I
> just use the cached value in radeon_fence_check_signaled.
Just check the cached value, it should be updated by
radeon_fence_activity immediately before calling this anyway.
>
> I can't call fence_activity in check_signaled, because it would cause
> re-entrancy in fence_queue.
>
>>> +if (!ret)
>>> +FENCE_TRACE(&fence->base, "signaled from irq context\n");
>>> +else
>>> +FENCE_TRACE(&fence->base, "was already signaled\n");
>> Is all that text tracing necessary? Probably better define a trace point
>> here.
> It gets optimized out normally. There's already a tracepoint called in
> fence_signal.
>
>>> +if (atomic64_read(&rdev->fence_drv[fence->ring].last_seq) >=
>>> fence->seq ||
>>> +!rdev->ddev->irq_enabled)
>>> +return false;
>> Checking irq_enabled here might not be such a good idea if the fence code
>> don't has a fall back on it's own. What exactly happens if enable_signaling
>> returns false?
> I thought irq_enabled couldn't happen under normal circumstances?
Not 100% sure, but I think it is temporary turned off during reset.
> Anyway the fence gets treated as signaled if it returns false, and
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 --- Comment #24 from funkydude --- Updated Oibaf and tried again. This time it does appear to be fixed! :-) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/88bf3d21/attachment.html>
[PULL REQUEST] ttm fence conversion
Op 02-09-14 om 10:51 schreef Christian K?nig:
> Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
>> Hey,
>>
>> On 01-09-14 18:21, Christian K?nig wrote:
>>> Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
Hey,
Op 01-09-14 om 14:31 schreef Christian K?nig:
> Please wait a second with that.
>
> I didn't had a chance to test this yet and nobody has yet given it's rb
> on at least the radeon changes in this branch.
Ok, my fault. I thought it was implicitly acked. I haven't made any
functional changes to these patches,
just some small fixups and a fix to make it apply after the upstream
removal of RADEON_FENCE_SIGNALED_SEQ.
>>> Yeah, but the resulting patch looks to complex for my taste and should be
>>> simplified a bit more. Here is a more detailed review:
>>>
+wait_queue_t fence_wake;
>>> Only a nitpick, but please fix the indention and maybe add a comment.
>>>
+struct work_struct delayed_irq_work;
>>> Just drop that, the new fall back work item should take care of this when
>>> the unfortunate case happens that somebody tries to enable_signaling in the
>>> middle of a GPU reset.
>> I can only drop it if radeon_gpu_reset will always call radeon_irq_set after
>> downgrading to read mode, even if no work needs to be done. :-)
>>
>> Then again, should be possible.
>
> The fall back handler should take care of the rare condition that we can't
> activate the IRQ because the driver is in a lockup handler.
>
> The issue is that the delayed_irq_work handler needs to take the exclusive
> lock once more and so would block an innocent process for the duration of the
> GPU lockup.
>
> Either reschedule as delayed work item if we can't take the lock immediately
> or just live with the delay of the fall back handler. Since IRQs usually
> don't work correctly immediately after an GPU reset I'm pretty sure that the
> fallback handler will be needed anyway.
Ok, rescheduling would be fine. Or could I go with the alternative, remove the
delayed_irq_work and always set irqs after downgrading the write lock?
/*
- * Cast helper
- */
-#define to_radeon_fence(p) ((struct radeon_fence *)(p))
-
-/*
>>> Please define the new cast helper in radeon.h as well.
>> The ops are only defined in radeon_fence.c, and nothing outside of
>> radeon_fence.c should care about the internals.
>
> Then define this as a function instead, I need a checked cast from a fence to
> a radeon_fence outside of the fence code as well.
Ok.
>>
if (!rdev->needs_reset) {
-up_write(&rdev->exclusive_lock);
+downgrade_write(&rdev->exclusive_lock);
+wake_up_all(&rdev->fence_queue);
+up_read(&rdev->exclusive_lock);
return 0;
}
>>> Just drop that as well, no need to wake up anybody here.
>> Maybe not, but if I have to remove delayed_irq_work I do need to add a
>> radeon_irq_set here.
>>
downgrade_write(&rdev->exclusive_lock);
+wake_up_all(&rdev->fence_queue);
>>> Same here, the IB test will wake up all fences for recheck anyway.
>> Same as previous comment. :-)
>>
+ * radeon_fence_read_seq - Returns the current fence value without
updating
+ *
+ * @rdev: radeon_device pointer
+ * @ring: ring index to return the seqno of
+ */
+static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int
ring)
+{
+uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
+uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
+uint64_t seq = radeon_fence_read(rdev, ring);
+
+seq = radeon_fence_read(rdev, ring);
+seq |= last_seq & 0xLL;
+if (seq < last_seq) {
+seq &= 0x;
+seq |= last_emitted & 0xLL;
+}
+return seq;
+}
>>> Completely drop that and just check the last_seq signaled as set by
>>> radeon_fence_activity.
>> Do you mean call radeon_fence_activity in radeon_fence_signaled? Or should I
>> just use the cached value in radeon_fence_check_signaled.
>
> Just check the cached value, it should be updated by radeon_fence_activity
> immediately before calling this anyway.
Ok. I think I wrote this as a workaround for unreliable interrupts. :-)
>>
>> I can't call fence_activity in check_signaled, because it would cause
>> re-entrancy in fence_queue.
>>
+if (!ret)
+FENCE_TRACE(&fence->base, "signaled from irq context\n");
+else
+FENCE_TRACE(&fence->base, "was already signaled\n");
>>> Is all that text tracing necessary? Probably better define a trace point
>>> here.
>> It gets optimized out normally. There's already a tracepoint called in
>> fence_signal.
>>
+if (atomic64_read(&rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!rdev->ddev->irq_enabled
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #46 from Michel D?nzer --- I've seen some stutters without any corresponding buffer moves though. Still not sure why it's stuttering so bad sometimes. BTW, Andy, does the stuttering also seem to get better for you if you run Valley repeatedly? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/5400e7f3/attachment-0001.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #47 from Andy Furniss --- (In reply to comment #45) > (In reply to comment #41) > > (In reply to comment #40) > > > (In reply to comment #39) > > > > If you let it run with Basic theme and few rounds you will spot i guess > > > > that only first round there is unusual maybe 2-3 times 1-2 sec stutters, > > > > then second time and later it is stutter free. > > > > > > Andy, you have behavior like that (more or less those seconds for stuter) > > > if PIPE_USAGE_STREAM is reverted, right? > > > > The Bad was with vanilla mesa (couple of days old) > > > > The good was that + the patch in Comment 19 > > I asked is Valley play the same with your good case here and with using > Basic theme in Windows :). That is the case for me, and average fps is > around 80% in comparasion. Next time I'm in Windows I'll try changing desktop - but as I said, with default desktop valley is 10x better than my best Linux case and that was the one and only run I did. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/93d8c8a2/attachment.html>
[PATCH] ipu-v3: ipu-smfc: Do not leave DEBUG defined
Hi Fabio, Am Dienstag, den 02.09.2014, 00:37 -0300 schrieb Fabio Estevam: > From: Fabio Estevam > > Let's only define DEBUG for debugging purpose and not by default to avoid > printing debugging message unnecessarily. > > Signed-off-by: Fabio Estevam > --- > Russell, > > Are you still collecting ipu-v3 patches? I have added this patch to git://git.pengutronix.de/git/pza/linux.git topic/ipu-fixes regards Philipp
[PULL REQUEST] ttm fence conversion
Am 02.09.2014 um 11:12 schrieb Maarten Lankhorst:
> Op 02-09-14 om 10:51 schreef Christian K?nig:
>> Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
>>> Hey,
>>>
>>> On 01-09-14 18:21, Christian K?nig wrote:
Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
> Hey,
>
> Op 01-09-14 om 14:31 schreef Christian K?nig:
>> Please wait a second with that.
>>
>> I didn't had a chance to test this yet and nobody has yet given it's rb
>> on at least the radeon changes in this branch.
> Ok, my fault. I thought it was implicitly acked. I haven't made any
> functional changes to these patches,
> just some small fixups and a fix to make it apply after the upstream
> removal of RADEON_FENCE_SIGNALED_SEQ.
Yeah, but the resulting patch looks to complex for my taste and should be
simplified a bit more. Here is a more detailed review:
> +wait_queue_t fence_wake;
Only a nitpick, but please fix the indention and maybe add a comment.
> +struct work_struct delayed_irq_work;
Just drop that, the new fall back work item should take care of this when
the unfortunate case happens that somebody tries to enable_signaling in
the middle of a GPU reset.
>>> I can only drop it if radeon_gpu_reset will always call radeon_irq_set
>>> after downgrading to read mode, even if no work needs to be done. :-)
>>>
>>> Then again, should be possible.
>> The fall back handler should take care of the rare condition that we can't
>> activate the IRQ because the driver is in a lockup handler.
>>
>> The issue is that the delayed_irq_work handler needs to take the exclusive
>> lock once more and so would block an innocent process for the duration of
>> the GPU lockup.
>>
>> Either reschedule as delayed work item if we can't take the lock immediately
>> or just live with the delay of the fall back handler. Since IRQs usually
>> don't work correctly immediately after an GPU reset I'm pretty sure that the
>> fallback handler will be needed anyway.
> Ok, rescheduling would be fine. Or could I go with the alternative, remove
> the delayed_irq_work and always set irqs after downgrading the write lock?
Always setting the IRQ's after downgrading the write lock would work for
me as well.
>
>/*
> - * Cast helper
> - */
> -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
> -
> -/*
Please define the new cast helper in radeon.h as well.
>>> The ops are only defined in radeon_fence.c, and nothing outside of
>>> radeon_fence.c should care about the internals.
>> Then define this as a function instead, I need a checked cast from a fence
>> to a radeon_fence outside of the fence code as well.
> Ok.
>
>if (!rdev->needs_reset) {
> -up_write(&rdev->exclusive_lock);
> +downgrade_write(&rdev->exclusive_lock);
> +wake_up_all(&rdev->fence_queue);
> +up_read(&rdev->exclusive_lock);
>return 0;
>}
Just drop that as well, no need to wake up anybody here.
>>> Maybe not, but if I have to remove delayed_irq_work I do need to add a
>>> radeon_irq_set here.
>>>
>downgrade_write(&rdev->exclusive_lock);
> +wake_up_all(&rdev->fence_queue);
Same here, the IB test will wake up all fences for recheck anyway.
>>> Same as previous comment. :-)
>>>
> + * radeon_fence_read_seq - Returns the current fence value without
> updating
> + *
> + * @rdev: radeon_device pointer
> + * @ring: ring index to return the seqno of
> + */
> +static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int
> ring)
> +{
> +uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
> +uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
> +uint64_t seq = radeon_fence_read(rdev, ring);
> +
> +seq = radeon_fence_read(rdev, ring);
> +seq |= last_seq & 0xLL;
> +if (seq < last_seq) {
> +seq &= 0x;
> +seq |= last_emitted & 0xLL;
> +}
> +return seq;
> +}
Completely drop that and just check the last_seq signaled as set by
radeon_fence_activity.
>>> Do you mean call radeon_fence_activity in radeon_fence_signaled? Or should
>>> I just use the cached value in radeon_fence_check_signaled.
>> Just check the cached value, it should be updated by radeon_fence_activity
>> immediately before calling this anyway.
> Ok. I think I wrote this as a workaround for unreliable interrupts. :-)
>
>>> I can't call fence_activity in check_signaled, because it would cause
>>> re-entrancy in fence_queue.
>>>
> +if (!ret)
> +FENCE_TRACE(&fence->base, "signaled from irq context\n");
> +else
> +FENCE_TRACE(&fence->base, "was already signaled\n");
Is all that text tracing necessary? Probably better define a t
[Bug 74803] [r600g] HyperZ broken on RV630 (Cogs shadows are broken)
https://bugs.freedesktop.org/show_bug.cgi?id=74803 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Marek Ol??k --- (In reply to comment #24) > Updated Oibaf and tried again. This time it does appear to be fixed! :-) Thanks. Closing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/4b27f8c3/attachment.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 Bug 75112 depends on bug 74803, which changed state. Bug 74803 Summary: [r600g] HyperZ broken on RV630 (Cogs shadows are broken) https://bugs.freedesktop.org/show_bug.cgi?id=74803 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/519abe7a/attachment.html>
[Bug 74863] [r600g] HyperZ broken on RV770 and CYPRESS (Left 4 Dead 2 trees corruption) bisected!
https://bugs.freedesktop.org/show_bug.cgi?id=74863 --- Comment #6 from Benjamin Bellec --- This is also not fixed on RV770. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/2e7c76f6/attachment-0001.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #48 from Andy Furniss --- (In reply to comment #46) > I've seen some stutters without any corresponding buffer moves though. Still > not sure why it's stuttering so bad sometimes. > > BTW, Andy, does the stuttering also seem to get better for you if you run > Valley repeatedly? No, it's quite consistent if I quit and re-run. The amount moved doesn't seem to correlate with the length of pause - and sometimes there are small moves without stutter, so maybe it's not totally this. Looking at Heaven 4.0 there are no moves at all after load, but there are a few very brief stutters on the night scenes - these are the same with or without patch though. What does num-bytes-moved measure - from where to where? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/8471ad9b/attachment.html>
[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote: > On 2 September 2014 14:05, Theodore Ts'o wrote: > > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no > > longer see the my Dell 30" monitor when it is connected via the > > docking station using a Displayport connector. This worked using 3.16 > > kernel. > > > > If I connect to the monitor using the mini-display, by passing the > > docking station, things work fine (but of course it's annoying not to > > be able to use the docking station). > > > > Is this a known problem? This is not the first time that we've had > > regressions with this docking station. It's vaguely reminsicent of > > > > https://bugs.freedesktop.org/show_bug.cgi?id=71267 > > > > Except the system isn't hanging; it's just not seeing the monitor at all. > > Have you the Dell 30" set to Displayport 1.2 enabled mode? No, it DP 1.2 was disabled. If I enable it, it breaks things when I try connecting via the MiniDP port (bypassing the dock), and it is still broken when I try to talk via the DisplayPort in the dock. If I disable DP 1.2 again, it works via the MiniDP port, but if I try to connect through the dock (which has a DP Hub which I believe is MST/DP 1.2 capable), it is still broken. It does seem that this might be related to 3.17-rc3 trying to talk DP 1.2 if it is available, since I can't control what the DP hub in the docking station advertises --- is there a commit or some kind of hack I can try to force talking to the DP hub using DP 1.1? - Ted
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #49 from Marek Ol??k --- (In reply to comment #48) > (In reply to comment #46) > > I've seen some stutters without any corresponding buffer moves though. Still > > not sure why it's stuttering so bad sometimes. > > > > BTW, Andy, does the stuttering also seem to get better for you if you run > > Valley repeatedly? > > No, it's quite consistent if I quit and re-run. > > The amount moved doesn't seem to correlate with the length of pause - and > sometimes there are small moves without stutter, so maybe it's not totally > this. > > Looking at Heaven 4.0 there are no moves at all after load, but there are a > few very brief stutters on the night scenes - these are the same with or > without patch though. > > What does num-bytes-moved measure - from where to where? The HUD always displays an average value per frame. It's the average of all values between the current and the last update of the HUD. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/db6c9af2/attachment.html>
[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
On 2 September 2014 21:03, Theodore Ts'o wrote: > On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote: >> On 2 September 2014 14:05, Theodore Ts'o wrote: >> > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no >> > longer see the my Dell 30" monitor when it is connected via the >> > docking station using a Displayport connector. This worked using 3.16 >> > kernel. >> > >> > If I connect to the monitor using the mini-display, by passing the >> > docking station, things work fine (but of course it's annoying not to >> > be able to use the docking station). >> > >> > Is this a known problem? This is not the first time that we've had >> > regressions with this docking station. It's vaguely reminsicent of >> > >> > https://bugs.freedesktop.org/show_bug.cgi?id=71267 >> > >> > Except the system isn't hanging; it's just not seeing the monitor at all. >> >> Have you the Dell 30" set to Displayport 1.2 enabled mode? > > No, it DP 1.2 was disabled. If I enable it, it breaks things when I > try connecting via the MiniDP port (bypassing the dock), and it is > still broken when I try to talk via the DisplayPort in the dock. > > If I disable DP 1.2 again, it works via the MiniDP port, but if I try > to connect through the dock (which has a DP Hub which I believe is > MST/DP 1.2 capable), it is still broken. > > It does seem that this might be related to 3.17-rc3 trying to talk DP > 1.2 if it is available, since I can't control what the DP hub in the > docking station advertises --- is there a commit or some kind of hack > I can try to force talking to the DP hub using DP 1.1? > Interesting, I have the same combo of hw available on my desk at work, but it might be a couple of days before I can get to the office to debug it, can you boot with drm.debug=6 and get me the dmesg? The attached hack turns off mst so might be useful as a workaround, but I should be able to fix this once I sit down at my desk. Dave. -- next part -- A non-text attachment was scrubbed... Name: i915-mst-hack.patch Type: text/x-patch Size: 332 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/b1b0b559/attachment.bin>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #50 from Andy Furniss --- (In reply to comment #49) > (In reply to comment #48) > > (In reply to comment #46) > > What does num-bytes-moved measure - from where to where? > > The HUD always displays an average value per frame. It's the average of all > values between the current and the last update of the HUD. Ahh, so the fact that HUD stops rendering during the pauses means that spikes are likely anyway. Though my question wasn't really about the HUD as such, I was wondering where they were moving to/from - I guess the answer may be too obvious, but just to confirm. I assume it's across PCIE to the card (or maybe from/both) - is it DMA or CPU transfer? Is it dependent on app behavior or driver - eg. running Unigine Reflections I saw a blip in the graph first run, but not again. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/71f04669/attachment.html>
[PATCH] ipu-v3: ipu-smfc: Do not leave DEBUG defined
Hi Philipp, On Tue, Sep 2, 2014 at 6:29 AM, Philipp Zabel wrote: > Hi Fabio, > > Am Dienstag, den 02.09.2014, 00:37 -0300 schrieb Fabio Estevam: >> From: Fabio Estevam >> >> Let's only define DEBUG for debugging purpose and not by default to avoid >> printing debugging message unnecessarily. >> >> Signed-off-by: Fabio Estevam >> --- >> Russell, >> >> Are you still collecting ipu-v3 patches? > > I have added this patch to > git://git.pengutronix.de/git/pza/linux.git topic/ipu-fixes Excellent, thanks. What about adding an entry to MAINTAINERS so that people know they should send you the IPUv3 related patches? Thanks, Fabio Estevam
[PULL REQUEST] ttm fence conversion
Op 02-09-14 om 11:52 schreef Christian K?nig:
> Am 02.09.2014 um 11:12 schrieb Maarten Lankhorst:
>> Op 02-09-14 om 10:51 schreef Christian K?nig:
>>> Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
Hey,
On 01-09-14 18:21, Christian K?nig wrote:
> Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
>> Hey,
>>
>> Op 01-09-14 om 14:31 schreef Christian K?nig:
>>> Please wait a second with that.
>>>
>>> I didn't had a chance to test this yet and nobody has yet given it's rb
>>> on at least the radeon changes in this branch.
>> Ok, my fault. I thought it was implicitly acked. I haven't made any
>> functional changes to these patches,
>> just some small fixups and a fix to make it apply after the upstream
>> removal of RADEON_FENCE_SIGNALED_SEQ.
> Yeah, but the resulting patch looks to complex for my taste and should be
> simplified a bit more. Here is a more detailed review:
>
>> +wait_queue_t fence_wake;
> Only a nitpick, but please fix the indention and maybe add a comment.
>
>> +struct work_struct delayed_irq_work;
> Just drop that, the new fall back work item should take care of this when
> the unfortunate case happens that somebody tries to enable_signaling in
> the middle of a GPU reset.
I can only drop it if radeon_gpu_reset will always call radeon_irq_set
after downgrading to read mode, even if no work needs to be done. :-)
Then again, should be possible.
>>> The fall back handler should take care of the rare condition that we can't
>>> activate the IRQ because the driver is in a lockup handler.
>>>
>>> The issue is that the delayed_irq_work handler needs to take the exclusive
>>> lock once more and so would block an innocent process for the duration of
>>> the GPU lockup.
>>>
>>> Either reschedule as delayed work item if we can't take the lock
>>> immediately or just live with the delay of the fall back handler. Since
>>> IRQs usually don't work correctly immediately after an GPU reset I'm pretty
>>> sure that the fallback handler will be needed anyway.
>> Ok, rescheduling would be fine. Or could I go with the alternative, remove
>> the delayed_irq_work and always set irqs after downgrading the write lock?
>
> Always setting the IRQ's after downgrading the write lock would work for me
> as well.
>
>
>>
>>/*
>> - * Cast helper
>> - */
>> -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
>> -
>> -/*
> Please define the new cast helper in radeon.h as well.
The ops are only defined in radeon_fence.c, and nothing outside of
radeon_fence.c should care about the internals.
>>> Then define this as a function instead, I need a checked cast from a fence
>>> to a radeon_fence outside of the fence code as well.
>> Ok.
>>
>>if (!rdev->needs_reset) {
>> -up_write(&rdev->exclusive_lock);
>> +downgrade_write(&rdev->exclusive_lock);
>> +wake_up_all(&rdev->fence_queue);
>> +up_read(&rdev->exclusive_lock);
>>return 0;
>>}
> Just drop that as well, no need to wake up anybody here.
Maybe not, but if I have to remove delayed_irq_work I do need to add a
radeon_irq_set here.
>>downgrade_write(&rdev->exclusive_lock);
>> +wake_up_all(&rdev->fence_queue);
> Same here, the IB test will wake up all fences for recheck anyway.
Same as previous comment. :-)
>> + * radeon_fence_read_seq - Returns the current fence value without
>> updating
>> + *
>> + * @rdev: radeon_device pointer
>> + * @ring: ring index to return the seqno of
>> + */
>> +static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int
>> ring)
>> +{
>> +uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
>> +uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
>> +uint64_t seq = radeon_fence_read(rdev, ring);
>> +
>> +seq = radeon_fence_read(rdev, ring);
>> +seq |= last_seq & 0xLL;
>> +if (seq < last_seq) {
>> +seq &= 0x;
>> +seq |= last_emitted & 0xLL;
>> +}
>> +return seq;
>> +}
> Completely drop that and just check the last_seq signaled as set by
> radeon_fence_activity.
Do you mean call radeon_fence_activity in radeon_fence_signaled? Or should
I just use the cached value in radeon_fence_check_signaled.
>>> Just check the cached value, it should be updated by radeon_fence_activity
>>> immediately before calling this anyway.
>> Ok. I think I wrote this as a workaround for unreliable interrupts. :-)
>>
I can't call fence_activity in check_signaled, because it would cause
re-entrancy in fence_queue.
>> +if (!ret)
>> +FENCE_TRACE(&fence->base, "signaled from irq context\n
Changing the connector output numbering
Hello, xrandr lists the connector outputs like this: HDMI1, HDMI2, DP1, DP2, etc. On our current mainboard with DVI and DisplayPort, the kernel driver assigns the number 2 to a pure DVI connection, so xrandr prints "HDMI2" for that connection. HDMI1 will be used, when I use a DP-to-DVI adapter on the DisplayPort while the other DVI port is used. The new board model (which uses the Intel i915 driver) has its DVI and DisplayPort connector switched and the DVI connection is now numbered with a "1". Using the adapter on the DP again, I get HDMI2. I found out, that these numbers are generated by calling "ida_simple_get()" in the function "drm_connector_init()" in drivers/gpu/drm/drm_crtc.c and saving its return value in the connectors attribute "connector_type_id". It would be preferable, to keep the current numbering scheme. Can I modify some code in order to achieve this? Or is there a way to influence the order in which the connectors are initialized? Best regards, Andreas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/af03dd3e/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #51 from Marek Ol??k --- num-bytes-moved comes from TTM. It's the size of all buffer moves done by TTM. This usually happens during command submission if VRAM is full. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/5ff39af6/attachment.html>
[PATCH/RESEND 0/8] tilcdc-panel: Backlight and GPIO devicetree support
Dave, I'm resending this, hoping it can be pushed for v3.18. The patchset was ready for v3.17, but it got no maintainer feedback or review. Maybe it fell through some crack? Just for reference, here goes the details about this series and why it's needed: This patchset adds the required changes to support an optional backlight and GPIO for the tilcdc panel driver. There was some code to support a backlight, but it was broken and undocumented. I've followed the nice implementation in panel-simple and added a similar one here. The enable GPIO is required to turn on and off devices with such capability. Also here, I've followed panel-simple which looks correct. In addition to this there are very minor cosmetic cleanups and a larger fix for the error path in tilcdc's DRM driver .load error path. Ezequiel Garcia (8): drm/tilcdc: Fix the error path in tilcdc_load() drm/tilcdc: panel: Add missing of_node_put drm/tilcdc: panel: Remove unused variable drm/tilcdc: panel: Spurious whitespace removal drm/tilcdc: panel: Use devm_kzalloc to simplify the error path drm/tilcdc: panel: Fix backlight devicetree support drm/tilcdc: panel: Set return value explicitly drm/tilcdc: panel: Add support for enable GPIO .../devicetree/bindings/drm/tilcdc/panel.txt | 7 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.c| 60 +++--- drivers/gpu/drm/tilcdc/tilcdc_panel.c | 74 +- 3 files changed, 114 insertions(+), 27 deletions(-) -- 2.0.1
[PATCH/RESEND 1/8] drm/tilcdc: Fix the error path in tilcdc_load()
The current error path calls tilcdc_unload() in case of an error to release
the resources. However, this is wrong because not all resources have been
allocated by the time an error occurs in tilcdc_load().
To fix it, this commit adds proper labels to bail out at the different
stages in the load function, and release only the resources actually allocated.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 60 ++---
1 file changed, 50 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 6be623b..000428e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -84,6 +84,7 @@ static int modeset_init(struct drm_device *dev)
if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
/* oh nos! */
dev_err(dev->dev, "no encoders/connectors found\n");
+ drm_mode_config_cleanup(dev);
return -ENXIO;
}
@@ -172,33 +173,37 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
dev->dev_private = priv;
priv->wq = alloc_ordered_workqueue("tilcdc", 0);
+ if (!priv->wq) {
+ ret = -ENOMEM;
+ goto fail_free_priv;
+ }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev->dev, "failed to get memory resource\n");
ret = -EINVAL;
- goto fail;
+ goto fail_free_wq;
}
priv->mmio = ioremap_nocache(res->start, resource_size(res));
if (!priv->mmio) {
dev_err(dev->dev, "failed to ioremap\n");
ret = -ENOMEM;
- goto fail;
+ goto fail_free_wq;
}
priv->clk = clk_get(dev->dev, "fck");
if (IS_ERR(priv->clk)) {
dev_err(dev->dev, "failed to get functional clock\n");
ret = -ENODEV;
- goto fail;
+ goto fail_iounmap;
}
priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
if (IS_ERR(priv->clk)) {
dev_err(dev->dev, "failed to get display clock\n");
ret = -ENODEV;
- goto fail;
+ goto fail_put_clk;
}
#ifdef CONFIG_CPU_FREQ
@@ -208,7 +213,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
CPUFREQ_TRANSITION_NOTIFIER);
if (ret) {
dev_err(dev->dev, "failed to register cpufreq notifier\n");
- goto fail;
+ goto fail_put_disp_clk;
}
#endif
@@ -253,13 +258,13 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
ret = modeset_init(dev);
if (ret < 0) {
dev_err(dev->dev, "failed to initialize mode setting\n");
- goto fail;
+ goto fail_cpufreq_unregister;
}
ret = drm_vblank_init(dev, 1);
if (ret < 0) {
dev_err(dev->dev, "failed to initialize vblank\n");
- goto fail;
+ goto fail_mode_config_cleanup;
}
pm_runtime_get_sync(dev->dev);
@@ -267,7 +272,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
pm_runtime_put_sync(dev->dev);
if (ret < 0) {
dev_err(dev->dev, "failed to install IRQ handler\n");
- goto fail;
+ goto fail_vblank_cleanup;
}
platform_set_drvdata(pdev, dev);
@@ -283,13 +288,48 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
priv->fbdev = drm_fbdev_cma_init(dev, bpp,
dev->mode_config.num_crtc,
dev->mode_config.num_connector);
+ if (IS_ERR(priv->fbdev)) {
+ ret = PTR_ERR(priv->fbdev);
+ goto fail_irq_uninstall;
+ }
drm_kms_helper_poll_init(dev);
return 0;
-fail:
- tilcdc_unload(dev);
+fail_irq_uninstall:
+ pm_runtime_get_sync(dev->dev);
+ drm_irq_uninstall(dev);
+ pm_runtime_put_sync(dev->dev);
+
+fail_vblank_cleanup:
+ drm_vblank_cleanup(dev);
+
+fail_mode_config_cleanup:
+ drm_mode_config_cleanup(dev);
+
+fail_cpufreq_unregister:
+ pm_runtime_disable(dev->dev);
+#ifdef CONFIG_CPU_FREQ
+ cpufreq_unregister_notifier(&priv->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+fail_put_disp_clk:
+ clk_put(priv->disp_clk);
+#endif
+
+fail_put_clk:
+ clk_put(priv->clk);
+
+fail_iounmap:
+ iounmap(priv->mmio);
+
+fail_free_wq:
+ flush_workqueue(priv->wq);
+ destroy_workqueue(priv->wq);
+
+fail_free_priv:
+ dev->dev_private = NULL;
+ kfree(priv);
return ret;
}
--
2.0.1
[PATCH/RESEND 2/8] drm/tilcdc: panel: Add missing of_node_put
This commit adds the missing calls to of_node_put to release the node
that's currently held by the of_get_child_by_name() call in the panel
info parsing code.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 4c7aa1d..d581c53 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -311,6 +311,7 @@ static struct tilcdc_panel_info *of_get_panel_info(struct
device_node *np)
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info) {
pr_err("%s: allocation failed\n", __func__);
+ of_node_put(info_np);
return NULL;
}
@@ -331,8 +332,10 @@ static struct tilcdc_panel_info *of_get_panel_info(struct
device_node *np)
if (ret) {
pr_err("%s: error reading panel-info properties\n", __func__);
kfree(info);
+ of_node_put(info_np);
return NULL;
}
+ of_node_put(info_np);
return info;
}
--
2.0.1
[PATCH/RESEND 3/8] drm/tilcdc: panel: Remove unused variable
Just a trivial cleanup to remove the variable.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index d581c53..8f88bfd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -340,8 +340,6 @@ static struct tilcdc_panel_info *of_get_panel_info(struct
device_node *np)
return info;
}
-static struct of_device_id panel_of_match[];
-
static int panel_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
--
2.0.1
[PATCH/RESEND 4/8] drm/tilcdc: panel: Spurious whitespace removal
Just a cosmetic cleanup.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 8f88bfd..4b36e68 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -348,7 +348,6 @@ static int panel_probe(struct platform_device *pdev)
struct pinctrl *pinctrl;
int ret = -EINVAL;
-
/* bail out early if no DT data: */
if (!node) {
dev_err(&pdev->dev, "device-tree data is missing\n");
--
2.0.1
[PATCH/RESEND 5/8] drm/tilcdc: panel: Use devm_kzalloc to simplify the error path
Using the managed variant to allocate the resource makes the code simpler and less error-prone. Tested-by: Darren Etheridge Signed-off-by: Ezequiel Garcia --- drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c index 4b36e68..c716c12 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c @@ -354,7 +354,7 @@ static int panel_probe(struct platform_device *pdev) return -ENXIO; } - panel_mod = kzalloc(sizeof(*panel_mod), GFP_KERNEL); + panel_mod = devm_kzalloc(&pdev->dev, sizeof(*panel_mod), GFP_KERNEL); if (!panel_mod) return -ENOMEM; @@ -391,7 +391,6 @@ fail_timings: display_timings_release(panel_mod->timings); fail_free: - kfree(panel_mod); tilcdc_module_cleanup(mod); return ret; } @@ -405,7 +404,6 @@ static int panel_remove(struct platform_device *pdev) tilcdc_module_cleanup(mod); kfree(panel_mod->info); - kfree(panel_mod); return 0; } -- 2.0.1
[PATCH/RESEND 6/8] drm/tilcdc: panel: Fix backlight devicetree support
The current backlight support is broken; the driver expects a backlight-class
in the panel devicetree node. Fix this by implementing it properly, getting
an optional backlight from a phandle.
This shouldn't cause any backward-compatibility DT issue because the current
implementation doesn't work and is not even documented.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/drm/tilcdc/panel.txt | 5 +
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 23 +-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
index 9301c33..10a06e8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
@@ -18,6 +18,9 @@ Required properties:
Documentation/devicetree/bindings/video/display-timing.txt for display
timing binding details.
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
muxing properly for pins that connect to TFP410 device
@@ -29,6 +32,8 @@ Example:
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
+ backlight = <&backlight>;
+
panel-info {
ac-bias = <255>;
ac-bias-intrpt= <0>;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index c716c12..3dcf08e 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -342,7 +342,7 @@ static struct tilcdc_panel_info *of_get_panel_info(struct
device_node *np)
static int panel_probe(struct platform_device *pdev)
{
- struct device_node *node = pdev->dev.of_node;
+ struct device_node *bl_node, *node = pdev->dev.of_node;
struct panel_module *panel_mod;
struct tilcdc_module *mod;
struct pinctrl *pinctrl;
@@ -358,6 +358,17 @@ static int panel_probe(struct platform_device *pdev)
if (!panel_mod)
return -ENOMEM;
+ bl_node = of_parse_phandle(node, "backlight", 0);
+ if (bl_node) {
+ panel_mod->backlight = of_find_backlight_by_node(bl_node);
+ of_node_put(bl_node);
+
+ if (!panel_mod->backlight)
+ return -EPROBE_DEFER;
+
+ dev_info(&pdev->dev, "found backlight\n");
+ }
+
mod = &panel_mod->base;
pdev->dev.platform_data = mod;
@@ -381,10 +392,6 @@ static int panel_probe(struct platform_device *pdev)
mod->preferred_bpp = panel_mod->info->bpp;
- panel_mod->backlight = of_find_backlight_by_node(node);
- if (panel_mod->backlight)
- dev_info(&pdev->dev, "found backlight\n");
-
return 0;
fail_timings:
@@ -392,6 +399,8 @@ fail_timings:
fail_free:
tilcdc_module_cleanup(mod);
+ if (panel_mod->backlight)
+ put_device(&panel_mod->backlight->dev);
return ret;
}
@@ -399,6 +408,10 @@ static int panel_remove(struct platform_device *pdev)
{
struct tilcdc_module *mod = dev_get_platdata(&pdev->dev);
struct panel_module *panel_mod = to_panel_module(mod);
+ struct backlight_device *backlight = panel_mod->backlight;
+
+ if (backlight)
+ put_device(&backlight->dev);
display_timings_release(panel_mod->timings);
--
2.0.1
[PATCH/RESEND 7/8] drm/tilcdc: panel: Set return value explicitly
Instead of setting an initial value for the return code, set it explicitly
on each error path. This is just a cosmetic cleanup, as preparation for the
enable GPIO support.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 3dcf08e..f2a5b23 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -346,7 +346,7 @@ static int panel_probe(struct platform_device *pdev)
struct panel_module *panel_mod;
struct tilcdc_module *mod;
struct pinctrl *pinctrl;
- int ret = -EINVAL;
+ int ret;
/* bail out early if no DT data: */
if (!node) {
@@ -381,12 +381,14 @@ static int panel_probe(struct platform_device *pdev)
panel_mod->timings = of_get_display_timings(node);
if (!panel_mod->timings) {
dev_err(&pdev->dev, "could not get panel timings\n");
+ ret = -EINVAL;
goto fail_free;
}
panel_mod->info = of_get_panel_info(node);
if (!panel_mod->info) {
dev_err(&pdev->dev, "could not get panel info\n");
+ ret = -EINVAL;
goto fail_timings;
}
--
2.0.1
[PATCH/RESEND 8/8] drm/tilcdc: panel: Add support for enable GPIO
In order to support the "enable GPIO" available in many panel devices,
this commit adds a proper devicetree binding.
By providing an enable GPIO in the devicetree, the driver can now turn
off and on the panel device, and/or the backlight device. Both the
backlight and the GPIO are optional properties.
Tested-by: Darren Etheridge
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/drm/tilcdc/panel.txt | 2 ++
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 37 +++---
2 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
index 10a06e8..4ab9e23 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt
@@ -20,6 +20,7 @@ Required properties:
Optional properties:
- backlight: phandle of the backlight device attached to the panel
+- enable-gpios: GPIO pin to enable or disable the panel
Recommended properties:
- pinctrl-names, pinctrl-0: the pincontrol settings to configure
@@ -33,6 +34,7 @@ Example:
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;
backlight = <&backlight>;
+ enable-gpios = <&gpio3 19 0>;
panel-info {
ac-bias = <255>;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index f2a5b23..7a03158 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,7 @@ struct panel_module {
struct tilcdc_panel_info *info;
struct display_timings *timings;
struct backlight_device *backlight;
+ struct gpio_desc *enable_gpio;
};
#define to_panel_module(x) container_of(x, struct panel_module, base)
@@ -55,13 +57,17 @@ static void panel_encoder_dpms(struct drm_encoder *encoder,
int mode)
{
struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
struct backlight_device *backlight = panel_encoder->mod->backlight;
+ struct gpio_desc *gpio = panel_encoder->mod->enable_gpio;
- if (!backlight)
- return;
+ if (backlight) {
+ backlight->props.power = mode == DRM_MODE_DPMS_ON ?
+FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+ backlight_update_status(backlight);
+ }
- backlight->props.power = mode == DRM_MODE_DPMS_ON
-? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
- backlight_update_status(backlight);
+ if (gpio)
+ gpiod_set_value_cansleep(gpio,
+mode == DRM_MODE_DPMS_ON ? 1 : 0);
}
static bool panel_encoder_mode_fixup(struct drm_encoder *encoder,
@@ -369,6 +375,25 @@ static int panel_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "found backlight\n");
}
+ panel_mod->enable_gpio = devm_gpiod_get(&pdev->dev, "enable");
+ if (IS_ERR(panel_mod->enable_gpio)) {
+ ret = PTR_ERR(panel_mod->enable_gpio);
+ if (ret != -ENOENT) {
+ dev_err(&pdev->dev, "failed to request enable GPIO\n");
+ goto fail_backlight;
+ }
+
+ /* Optional GPIO is not here, continue silently. */
+ panel_mod->enable_gpio = NULL;
+ } else {
+ ret = gpiod_direction_output(panel_mod->enable_gpio, 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to setup GPIO\n");
+ goto fail_backlight;
+ }
+ dev_info(&pdev->dev, "found enable GPIO\n");
+ }
+
mod = &panel_mod->base;
pdev->dev.platform_data = mod;
@@ -401,6 +426,8 @@ fail_timings:
fail_free:
tilcdc_module_cleanup(mod);
+
+fail_backlight:
if (panel_mod->backlight)
put_device(&panel_mod->backlight->dev);
return ret;
--
2.0.1
[PATCH v3 16/17] drm/exynos/ipp: remove file argument from node related functions
Since file pointer is preserved in c_node passing it
as argument in node functions is redundant.
Signed-off-by: Andrzej Hajda
---
v3:
- file check moved to next patch
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 05f0f4e..9e9714a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
static struct drm_exynos_ipp_mem_node
*ipp_get_mem_node(struct drm_device *drm_dev,
- struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
{
@@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
dma_addr_t *addr;
addr = exynos_drm_gem_get_dma_addr(drm_dev,
- qbuf->handle[i], file);
+ qbuf->handle[i], c_node->filp);
if (IS_ERR(addr)) {
DRM_ERROR("failed to get addr.\n");
ipp_put_mem_node(drm_dev, c_node, m_node);
@@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event *event)
}
static int ipp_get_event(struct drm_device *drm_dev,
- struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
{
@@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e) {
spin_lock_irqsave(&drm_dev->event_lock, flags);
- file->event_space += sizeof(e->event);
+ c_node->filp->event_space += sizeof(e->event);
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
return -ENOMEM;
}
@@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e->event.prop_id = qbuf->prop_id;
e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
e->base.event = &e->event.base;
- e->base.file_priv = file;
+ e->base.file_priv = c_node->filp;
e->base.destroy = ipp_free_event;
mutex_lock(&c_node->event_lock);
list_add_tail(&e->base.link, &c_node->event_list);
@@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
switch (qbuf->buf_type) {
case IPP_BUF_ENQUEUE:
/* get memory node */
- m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
+ m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
if (IS_ERR(m_node)) {
DRM_ERROR("failed to get m_node.\n");
return PTR_ERR(m_node);
@@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
*/
if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
/* get event for destination buffer */
- ret = ipp_get_event(drm_dev, file, c_node, qbuf);
+ ret = ipp_get_event(drm_dev, c_node, qbuf);
if (ret) {
DRM_ERROR("failed to get event.\n");
goto err_clean_node;
--
1.9.1
[PATCH v3 17/17] drm/exynos/ipp: add file checks for ioctls
Process should not have access to ipp nodes created by another
process. The patch adds necessary checks.
It also simplifies lookup for command node.
Signed-off-by: Andrzej Hajda
---
v3:
- added file check from previous commit
- simplified c_node lookup
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 69 +++--
1 file changed, 22 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 9e9714a..4f36a9d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -318,44 +318,6 @@ static void ipp_print_property(struct
drm_exynos_ipp_property *property,
sz->hsize, sz->vsize, config->flip, config->degree);
}
-static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property)
-{
- struct exynos_drm_ippdrv *ippdrv;
- struct drm_exynos_ipp_cmd_node *c_node;
- u32 prop_id = property->prop_id;
-
- DRM_DEBUG_KMS("prop_id[%d]\n", prop_id);
-
- ippdrv = ipp_find_drv_by_handle(prop_id);
- if (IS_ERR(ippdrv)) {
- DRM_ERROR("failed to get ipp driver.\n");
- return -EINVAL;
- }
-
- /*
-* Find command node using command list in ippdrv.
-* when we find this command no using prop_id.
-* return property information set in this command node.
-*/
- mutex_lock(&ippdrv->cmd_lock);
- list_for_each_entry(c_node, &ippdrv->cmd_list, list) {
- if ((c_node->property.prop_id == prop_id) &&
- (c_node->state == IPP_STATE_STOP)) {
- mutex_unlock(&ippdrv->cmd_lock);
- DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n",
- property->cmd, (int)ippdrv);
-
- c_node->property = *property;
- return 0;
- }
- }
- mutex_unlock(&ippdrv->cmd_lock);
-
- DRM_ERROR("failed to search property.\n");
-
- return -EINVAL;
-}
-
static struct drm_exynos_ipp_cmd_work *ipp_create_cmd_work(void)
{
struct drm_exynos_ipp_cmd_work *cmd_work;
@@ -391,6 +353,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
struct drm_exynos_ipp_property *property = data;
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
+ u32 prop_id;
int ret, i;
if (!ctx) {
@@ -403,6 +366,8 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
return -EINVAL;
}
+ prop_id = property->prop_id;
+
/*
* This is log print for user application property.
* user application set various property.
@@ -411,14 +376,24 @@ int exynos_drm_ipp_set_property(struct drm_device
*drm_dev, void *data,
ipp_print_property(property, i);
/*
-* set property ioctl generated new prop_id.
-* but in this case already asigned prop_id using old set property.
-* e.g PAUSE state. this case supports find current prop_id and use it
-* instead of allocation.
+* In case prop_id is not zero try to set existing property.
*/
- if (property->prop_id) {
- DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);
- return ipp_find_and_set_property(property);
+ if (prop_id) {
+ c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock, prop_id);
+
+ if (!c_node || c_node->filp != file) {
+ DRM_DEBUG_KMS("prop_id[%d] not found\n", prop_id);
+ return -EINVAL;
+ }
+
+ if (c_node->state != IPP_STATE_STOP) {
+ DRM_DEBUG_KMS("prop_id[%d] not stopped\n", prop_id);
+ return -EINVAL;
+ }
+
+ c_node->property = *property;
+
+ return 0;
}
/* find ipp driver using ipp id */
@@ -897,7 +872,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
/* find command node */
c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
qbuf->prop_id);
- if (!c_node) {
+ if (!c_node || c_node->filp != file) {
DRM_ERROR("failed to get command node.\n");
return -ENODEV;
}
@@ -1032,7 +1007,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev,
void *data,
c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
cmd_ctrl->prop_id);
- if (!c_node) {
+ if (!c_node || c_node->filp != file) {
DRM_ERROR("invalid command node list.\n");
return -ENODEV;
}
--
1.9.1
[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
On Tue, Sep 02, 2014 at 09:23:16PM +1000, Dave Airlie wrote: > > Interesting, I have the same combo of hw available on my desk at work, > but it might be a couple of days before I can get to the office to > debug it, > > can you boot with drm.debug=6 and get me the dmesg? I'll do that when I get home. In the meantime, here's an additional data point. At work, I have the same model docking station connected to a 2011 Dell 2410f Rev A04 (max resolution 1920x1200, and I suspect not DP 1.2 capable; at least, it doesn't mention DP in monitor menu) --- and connecting through the docking station, it does work (connecting through either DVI or DisplayPort). Here's the drm.debug=6 connecting to the docking station via DVI. I can get a drm.debug=6 connecting via the DP and the docking station if that would be helpful. Similarly, if you want, I can also try to get a debug run connecting to the HP ZRW30 monitor (either direct or via the docking station), since that's the monitor on the walkstation. :-) Cheers, - Ted -- next part -- A non-text attachment was scrubbed... Name: drm-debug.xz Type: application/octet-stream Size: 27396 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/5850058d/attachment-0001.obj>
[Bug 82581] CL_DEVICE_MAX_COMPUTE_UNITS increases by 100 every time runpm powers on 7970M pitcairn
https://bugzilla.kernel.org/show_bug.cgi?id=82581 Christoph Haag changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #5 from Christoph Haag --- Since it's in the 3.17 rc I use, I'm closing this as fixed. -- You are receiving this mail because: You are watching the assignee of the bug.
[PULL REQUEST] ttm fence conversion
> How does this patch look?
Looks better now, yes. This patch is Reviewed-by: Christian K?nig
The next one we need to take a look at is "drm/radeon: use rcu waits in
some ioctls":
> @@ -110,9 +110,12 @@ static int radeon_gem_set_domain(struct
> drm_gem_object *gobj,
> }
> if (domain == RADEON_GEM_DOMAIN_CPU) {
> /* Asking for cpu access wait for object idle */
> - r = radeon_bo_wait(robj, NULL, false);
> - if (r) {
> - printk(KERN_ERR "Failed to wait for object !\n");
> + r =
> reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 30 * HZ);
Here r is still an int, so this assignment might overflow.
Apart from that the patch has my rb as well.
Regards,
Christian.
Am 02.09.2014 um 14:29 schrieb Maarten Lankhorst:
> Op 02-09-14 om 11:52 schreef Christian K?nig:
>> Am 02.09.2014 um 11:12 schrieb Maarten Lankhorst:
>>> Op 02-09-14 om 10:51 schreef Christian K?nig:
Am 01.09.2014 um 20:43 schrieb Maarten Lankhorst:
> Hey,
>
> On 01-09-14 18:21, Christian K?nig wrote:
>> Am 01.09.2014 um 15:33 schrieb Maarten Lankhorst:
>>> Hey,
>>>
>>> Op 01-09-14 om 14:31 schreef Christian K?nig:
Please wait a second with that.
I didn't had a chance to test this yet and nobody has yet given it's
rb on at least the radeon changes in this branch.
>>> Ok, my fault. I thought it was implicitly acked. I haven't made any
>>> functional changes to these patches,
>>> just some small fixups and a fix to make it apply after the upstream
>>> removal of RADEON_FENCE_SIGNALED_SEQ.
>> Yeah, but the resulting patch looks to complex for my taste and should
>> be simplified a bit more. Here is a more detailed review:
>>
>>> +wait_queue_t fence_wake;
>> Only a nitpick, but please fix the indention and maybe add a comment.
>>
>>> +struct work_struct delayed_irq_work;
>> Just drop that, the new fall back work item should take care of this
>> when the unfortunate case happens that somebody tries to
>> enable_signaling in the middle of a GPU reset.
> I can only drop it if radeon_gpu_reset will always call radeon_irq_set
> after downgrading to read mode, even if no work needs to be done. :-)
>
> Then again, should be possible.
The fall back handler should take care of the rare condition that we can't
activate the IRQ because the driver is in a lockup handler.
The issue is that the delayed_irq_work handler needs to take the exclusive
lock once more and so would block an innocent process for the duration of
the GPU lockup.
Either reschedule as delayed work item if we can't take the lock
immediately or just live with the delay of the fall back handler. Since
IRQs usually don't work correctly immediately after an GPU reset I'm
pretty sure that the fallback handler will be needed anyway.
>>> Ok, rescheduling would be fine. Or could I go with the alternative, remove
>>> the delayed_irq_work and always set irqs after downgrading the write lock?
>> Always setting the IRQ's after downgrading the write lock would work for me
>> as well.
>>
>>
>>> /*
>>> - * Cast helper
>>> - */
>>> -#define to_radeon_fence(p) ((struct radeon_fence *)(p))
>>> -
>>> -/*
>> Please define the new cast helper in radeon.h as well.
> The ops are only defined in radeon_fence.c, and nothing outside of
> radeon_fence.c should care about the internals.
Then define this as a function instead, I need a checked cast from a fence
to a radeon_fence outside of the fence code as well.
>>> Ok.
>>>
>>> if (!rdev->needs_reset) {
>>> -up_write(&rdev->exclusive_lock);
>>> +downgrade_write(&rdev->exclusive_lock);
>>> +wake_up_all(&rdev->fence_queue);
>>> +up_read(&rdev->exclusive_lock);
>>> return 0;
>>> }
>> Just drop that as well, no need to wake up anybody here.
> Maybe not, but if I have to remove delayed_irq_work I do need to add a
> radeon_irq_set here.
>
>>> downgrade_write(&rdev->exclusive_lock);
>>> +wake_up_all(&rdev->fence_queue);
>> Same here, the IB test will wake up all fences for recheck anyway.
> Same as previous comment. :-)
>
>>> + * radeon_fence_read_seq - Returns the current fence value without
>>> updating
>>> + *
>>> + * @rdev: radeon_device pointer
>>> + * @ring: ring index to return the seqno of
>>> + */
>>> +static uint64_t radeon_fence_read_seq(struct radeon_device *rdev, int
>>> ring)
>>> +{
>>> +uint64_t last_seq = atomic64_read(&rdev->fence_drv[ring].last_seq);
>>> +uint64_t last_emitted = rdev->fence_drv[ring].sync_seq[ring];
>>> +uint64_t seq = radeon_fence_read(rdev, ring);
>>> +
>>> +s
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #72 from Aaron B --- (In reply to comment #71) > (In reply to comment #70) > > https://drive.google.com/file/d/0B1laUfqMuZQBeWpHSDYtV2N3RjQ/edit?usp=sharing > > Can you reproduce the crash by feeding those traces to glretrace? > > > (In reply to comment #69) > > If I get time I'll compile Mesa 10.1 32 and 64 bit and see if they work. No > > promises, as git always fails either on or right after receiving 99% of > > objects, so I have to try about 20 times to even attempt compile basically > > anything. > > Note that you only really need to clone a Git repository once, after that > all the history (including all the commits you might need to test during the > bisection) is available locally. Yeah, but I build it with yaourt, which likes to contain it's gits elsewhere and apparently deletes them every time as you can't keep a clone unless it's in the same session. I would work on getting 2-3 clones and uploading them to my git and copying from that if need be, but it's just tons of work for me. Like I said, I have to try about 20 times to even clone anything, it's a severe pain. And running glretrace about 10 times on the trace files, no beans on getting another crash. [aaron at Aaron-Arch Chromiumapitrace]$ glretrace chromium.trace 0 64 glXSwapIntervalMESA(interval = 1) = 0 64: warning: unsupported glXSwapIntervalMESA call Rendered 150 frames in 2.68355 secs, average of 55.8961 fps [aaron at Aaron-Arch Chromiumapitrace]$ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/863aa57f/attachment.html>
[Bug 73088] [HyperZ] Juniper (6770): Gone Home / Unigine Heaven 4.0 lock up system after several minutes of use
https://bugs.freedesktop.org/show_bug.cgi?id=73088 --- Comment #9 from appletorch at hotmail.com --- (In reply to comment #7) > appletorch, could you please test current Mesa git and see if it's fixed? Will do once I have a working monitor again, hopefully by the end of this week. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/c950bc65/attachment.html>
[Bug 78009] ETQW and TF2 creenshots have alpha=0
https://bugs.freedesktop.org/show_bug.cgi?id=78009 --- Comment #5 from Benjamin Bellec --- I don't think this is a Mesa bug. I already noted this problem with ETQW back to July 2012 (maybe even earlier) and found a workaround. You can convert the picture to PNG thanks to ImageMagick, just run : $ convert -alpha off shot00016.tga shot00016.png With my RV770, I just tested mesa-10.3-rc2, mesa-9.2.5 and mesa-9.1.7. All of them gives bad TGA screenshots. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/b06b0866/attachment.html>
[PATCH] ipu-v3: ipu-smfc: Do not leave DEBUG defined
Am Dienstag, den 02.09.2014, 09:00 -0300 schrieb Fabio Estevam: > Hi Philipp, > > On Tue, Sep 2, 2014 at 6:29 AM, Philipp Zabel > wrote: > > Hi Fabio, > > > > Am Dienstag, den 02.09.2014, 00:37 -0300 schrieb Fabio Estevam: > >> From: Fabio Estevam > >> > >> Let's only define DEBUG for debugging purpose and not by default to avoid > >> printing debugging message unnecessarily. > >> > >> Signed-off-by: Fabio Estevam > >> --- > >> Russell, > >> > >> Are you still collecting ipu-v3 patches? > > > > I have added this patch to > > git://git.pengutronix.de/git/pza/linux.git topic/ipu-fixes > > Excellent, thanks. > > What about adding an entry to MAINTAINERS so that people know they > should send you the IPUv3 related patches? Yes, I'll send a patch regards Philipp
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #12 from Connor Abbott --- Created attachment 105630 --> https://bugs.freedesktop.org/attachment.cgi?id=105630&action=edit another debugging patch Ok, it looks like the problem is that node 0's q_total is bogus, which means it never even gets considered for optimistic coloring. To help me figure out why this is, can you apply this patch to master (not on top of the other patch) and tell me the output of the piglit test now? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/380d1fdd/attachment.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #13 from Tom Stellard --- (In reply to comment #12) > Created attachment 105630 [details] [review] > another debugging patch > > Ok, it looks like the problem is that node 0's q_total is bogus, which means > it never even gets considered for optimistic coloring. To help me figure out > why this is, can you apply this patch to master (not on top of the other > patch) and tell me the output of the piglit test now? On (In reply to comment #12) > Created attachment 105630 [details] [review] > another debugging patch > > Ok, it looks like the problem is that node 0's q_total is bogus, which means > it never even gets considered for optimistic coloring. To help me figure out > why this is, can you apply this patch to master (not on top of the other > patch) and tell me the output of the piglit test now? I'm not sure if this matters, but r300g pre-allocates the input registers before calling ra_allocate_no_spills(). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/993b560a/attachment.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #14 from Connor Abbott --- (In reply to comment #13) > (In reply to comment #12) > > Created attachment 105630 [details] [review] [review] > > another debugging patch > > > > Ok, it looks like the problem is that node 0's q_total is bogus, which means > > it never even gets considered for optimistic coloring. To help me figure out > > why this is, can you apply this patch to master (not on top of the other > > patch) and tell me the output of the piglit test now? > > On (In reply to comment #12) > > Created attachment 105630 [details] [review] [review] > > another debugging patch > > > > Ok, it looks like the problem is that node 0's q_total is bogus, which means > > it never even gets considered for optimistic coloring. To help me figure out > > why this is, can you apply this patch to master (not on top of the other > > patch) and tell me the output of the piglit test now? > > I'm not sure if this matters, but r300g pre-allocates the input registers > before calling ra_allocate_no_spills(). I think there are no input registers in this case (there's a NumInputs = 0 somewhere in the backtrace) so there aren't any pre-allocated nodes here. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/530fbe44/attachment-0001.html>
[Bug 80878] [r600g][regression] Metro: Last Light freezes when trying to kill stealthily
https://bugs.freedesktop.org/show_bug.cgi?id=80878 --- Comment #5 from Benjamin Bellec --- Could you provides more information to reproduce this bug ? I tried to reproduce without success, with mesa-10.3-rc2 and with the commit fcac702, on RV770 too. I played the level where you have been captured by the Reich (at the beginning of the game), I'm escaping from the jail with a friend. In this stage there is an enemy to kill stealthily. But everything works fine here in my case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/845815e0/attachment.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #15 from Tom Stellard --- Can you post the output of RADEON_DEBUG=ps,vs ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/58b390b8/attachment.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #16 from Marek Ol??k --- (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Created attachment 105630 [details] [review] [review] [review] > > > another debugging patch > > > > > > Ok, it looks like the problem is that node 0's q_total is bogus, which > > > means > > > it never even gets considered for optimistic coloring. To help me figure > > > out > > > why this is, can you apply this patch to master (not on top of the other > > > patch) and tell me the output of the piglit test now? > > > > On (In reply to comment #12) > > > Created attachment 105630 [details] [review] [review] [review] > > > another debugging patch > > > > > > Ok, it looks like the problem is that node 0's q_total is bogus, which > > > means > > > it never even gets considered for optimistic coloring. To help me figure > > > out > > > why this is, can you apply this patch to master (not on top of the other > > > patch) and tell me the output of the piglit test now? > > > > I'm not sure if this matters, but r300g pre-allocates the input registers > > before calling ra_allocate_no_spills(). > > I think there are no input registers in this case (there's a NumInputs = 0 > somewhere in the backtrace) so there aren't any pre-allocated nodes here. What Tom probably meant is that inputs are loaded to temps before the fragment shader starts, so inputs and temps pretty much share the temporary file. Not sure how relevant it is to this issue, but obviously you can't rename the temps which are supposed to contain inputs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/4535d895/attachment.html>
[PATCH -v2 1/4] drm/i915: init sprites with univeral plane init function
From: Derek Foreman
Really just for completeness - old init function ends up making the plane
exactly the same way due to the way the enums are set up.
Signed-off-by: Derek Foreman
---
drivers/gpu/drm/i915/intel_sprite.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0bdb00b..4cbe286 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1375,10 +1375,10 @@ intel_plane_init(struct drm_device *dev, enum pipe
pipe, int plane)
intel_plane->plane = plane;
intel_plane->rotation = BIT(DRM_ROTATE_0);
possible_crtcs = (1 << pipe);
- ret = drm_plane_init(dev, &intel_plane->base, possible_crtcs,
-&intel_plane_funcs,
-plane_formats, num_plane_formats,
-false);
+ ret = drm_universal_plane_init(dev, &intel_plane->base, possible_crtcs,
+ &intel_plane_funcs,
+ plane_formats, num_plane_formats,
+ DRM_PLANE_TYPE_OVERLAY);
if (ret) {
kfree(intel_plane);
goto out;
--
1.9.3
[PATCH -v2 2/4] drm/i915: trivial: remove unneed set to NULL
From: Gustavo Padovan
At this point of the code the obj var is already NULL, so we don't
need to set it again to NULL.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b2e4eac..05937fe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8253,7 +8253,6 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc
*crtc,
if (!obj) {
DRM_DEBUG_KMS("cursor off\n");
addr = 0;
- obj = NULL;
mutex_lock(&dev->struct_mutex);
goto finish;
}
--
1.9.3
[PATCH -v2 3/4] drm/i915: create struct intel_plane_state
From: Gustavo Padovan
This new struct will be the storage of src and dst coordinates
between the check and commit stages of a plane update.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_drv.h | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4ab0d92..59c1675 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
/**
* _wait_for - magic (register) wait macro
@@ -227,6 +228,25 @@ typedef struct dpll {
int p;
} intel_clock_t;
+struct intel_plane_state {
+ struct drm_crtc *crtc;
+ struct drm_framebuffer *fb;
+ int crtc_x;
+ int crtc_y;
+ unsigned int crtc_w;
+ unsigned int crtc_h;
+ uint32_t src_x;
+ uint32_t src_y;
+ uint32_t src_w;
+ uint32_t src_h;
+ struct drm_rect src;
+ struct drm_rect dst;
+ struct drm_rect clip;
+ struct drm_rect orig_src;
+ struct drm_rect orig_dst;
+ bool visible;
+};
+
struct intel_plane_config {
bool tiled;
int size;
--
1.9.3
[PATCH -v2 4/4] drm/i915: split intel_update_plane into check() and commit()
From: Gustavo Padovan
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning procedure.
v2: use the new struct intel_plane_state to store information
between check and commit stages.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 236 ++--
1 file changed, 146 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 4cbe286..062eca2 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -845,57 +845,28 @@ static bool colorkey_enabled(struct intel_plane
*intel_plane)
}
static int
-intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h)
+intel_check_sprite_plane(struct drm_plane *plane,
+struct intel_plane_state *pstate)
{
- struct drm_device *dev = plane->dev;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(pstate->crtc);
struct intel_plane *intel_plane = to_intel_plane(plane);
- enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *fb = pstate->fb;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct drm_i915_gem_object *obj = intel_fb->obj;
- struct drm_i915_gem_object *old_obj = intel_plane->obj;
- int ret;
- bool primary_enabled;
- bool visible;
+ int crtc_x = pstate->crtc_x;
+ int crtc_y = pstate->crtc_y;
+ int crtc_w = pstate->crtc_w;
+ int crtc_h = pstate->crtc_h;
+ int src_x = pstate->src_x;
+ int src_y = pstate->src_y;
+ int src_w = pstate->src_w;
+ int src_h = pstate->src_h;
+ struct drm_rect *src = &pstate->src;
+ struct drm_rect *dst = &pstate->dst;
+ struct drm_rect *clip = &pstate->clip;
int hscale, vscale;
int max_scale, min_scale;
int pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
- struct drm_rect src = {
- /* sample coordinates in 16.16 fixed point */
- .x1 = src_x,
- .x2 = src_x + src_w,
- .y1 = src_y,
- .y2 = src_y + src_h,
- };
- struct drm_rect dst = {
- /* integer pixels */
- .x1 = crtc_x,
- .x2 = crtc_x + crtc_w,
- .y1 = crtc_y,
- .y2 = crtc_y + crtc_h,
- };
- const struct drm_rect clip = {
- .x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
- .y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
- };
- const struct {
- int crtc_x, crtc_y;
- unsigned int crtc_w, crtc_h;
- uint32_t src_x, src_y, src_w, src_h;
- } orig = {
- .crtc_x = crtc_x,
- .crtc_y = crtc_y,
- .crtc_w = crtc_w,
- .crtc_h = crtc_h,
- .src_x = src_x,
- .src_y = src_y,
- .src_w = src_w,
- .src_h = src_h,
- };
/* Don't modify another pipe's plane */
if (intel_plane->pipe != intel_crtc->pipe) {
@@ -927,55 +898,55 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
max_scale = intel_plane->max_downscale << 16;
min_scale = intel_plane->can_scale ? 1 : (1 << 16);
- drm_rect_rotate(&src, fb->width << 16, fb->height << 16,
+ drm_rect_rotate(src, fb->width << 16, fb->height << 16,
intel_plane->rotation);
- hscale = drm_rect_calc_hscale_relaxed(&src, &dst, min_scale, max_scale);
+ hscale = drm_rect_calc_hscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(hscale < 0);
- vscale = drm_rect_calc_vscale_relaxed(&src, &dst, min_scale, max_scale);
+ vscale = drm_rect_calc_vscale_relaxed(src, dst, min_scale, max_scale);
BUG_ON(vscale < 0);
- visible = drm_rect_clip_scaled(&src, &dst, &clip, hscale, vscale);
+ pstate->visible = drm_rect_clip_scaled(src, dst, clip, hscale, vscale);
- crtc_x = dst.x1;
- crtc_y = dst.y1;
- crtc_w = drm_rect_width(&dst);
- crtc_h = drm_rect_height(&dst);
+ crtc_x = dst->x1;
+ crtc_y = dst->y1;
+ crtc_w = drm_rect_width(dst);
+ crtc_h = drm_rect_height(dst);
- if (visible) {
+ if (pstate->visible) {
/* check again in case clipping clamped the results */
- hscale = drm_rect_calc_hscale
[PATCH 05/19] drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off()
Hi Ville, went through the vblank rework patch set, mostly looks good to me. I couldn't find any bugs in the code. A first quick test-run on my old Intel GMA-950 (Gen 3'ish i think?) also didn't show apparent problems with the OML_sync_control functions. I'll try to test more carefully with that card and maybe with a few more cards in the next days, if i can get my hands on something more recent. The problematic bits: Patch 3/19 [Don't clear vblank timestamp...] in combination with [5/19 below]: I agree that not clearing the timestamps during drm_vblank_off() is probably the better thing to do for userspace. The idea behind clearing the timestamps was that a ust timestamp of zero signals to userspace that the timestamp is invalid/undefined at the moment, so the client should retry the query if it needs a valid timestamp. This worked in practice insofar as a value of zero can't happen normally, unless a client would query a timestamp during the first microsecond since machine powerup. But i guess returning the last valid (msc, ust) pair to a client during vblank off may be better for things like compositors etc. I also wonder if we ever documented this ust == 0 -> -EAGAIN behaviour? The problem with patch 5/19 is gpus/drivers which don't provide precise instantaneous vblank timestamps - which are afaik everything except intel, radeon and nouveau. On such drivers, the old code would return a zero ust timestamp during queries after the first drm_vblank_get() and until the first vblank irq happens and initializes the timestamps to something valid. The zero ust would signal "please retry" to the client. With patch 5/19 you'd get an updated vblank counter with an outdated vblank timestamp - whatever is stored in the ringbuffer from the past, because drm_update_vblank_count() can't update the timestamp without support for the optional vblank-timestamp driver function. A mismatched msc, ust would be very confusing to clients. The only way one could get valid msc + ust on such drivers would be to enable vblank irq's and then wait for the next vblank irq to actually update the timestamp, at the cost of a couple of msecs waiting time. So either have drm_update_vblank_count() itself sleep until next vblank "if (!rc) ..." at the very end, as a rc == 0 would signal an imprecise/wrong vblank timestamp. Or have all callers of it do this, if locking makes it neccessary. Or only care about it for the drm_vblank_off() special case, e.g., if !vblank->enabled there, then drm_vblank_get() -> wait for a valid timestamp and count to show up -> drm_vblank_put() -> vblank_disable_and_save(). For Patch 11/19 [Add dev->vblank_disable_immediate flag]: Can we make it so that a drm_vblank_offdelay module parameter of zero always overrides the flag? The only reason why a user wants to set drm_vblank_offdelay to zero is if that user absolutely needs precise and reliable vblank counts/timestamps and finds out that something is broken with his driver+gpu, so uses this as an override to temporarily fix a broken driver. That doesn't work if the vblank_disable_immediate flag overrides the override from the user - the user couldn't opt out of the trouble. This might not be such an issue with Intel cards, as you have test suites and a QA team, and i assume/hope you tested every single intel gpu shipped in the last decade or so if the whole vblank off/on logic really is perfectly race-free now? At least it seems to work with that one gen-3 card i quickly tested. But for most other drivers with small teams and no dedicated QA this could end badly quickly for the user without any manual override. The docs should probably clarify that a hw vblank counter isn't enough for the vblank_disable_immediate flag to be set. Their vblank off/on/hardware counter query implementation must be completely race free. iirc this means the hw counter query must behave as if the vblank counter always increments at the leading edge of vblank. E.g., radeon has hw counter queries, but the counter increments either at the trailing edge, or somewhere in the middle of vblank, so there it wouldn't work without races, causing off-by-one errors sometimes. For Patch 14/19 [Don't update vblank timestamp when the counter didn't change] That would go wrong if a driver doesn't implement a proper vblank counter query. E.g., nouveau has precise vblank timestamping since Linux 3.14, but still no functional hw counter query. Almost all embedded gpu drivers currently implement completely bogus hw vblank counter queries, because that driver hook is mandatory. I think it would make sense if we would make that hook optional, allow a NULL function pointer and adapt to the lack of that query, e.g., by never disabling vblank irq's, except in drm_vblank_off() when a kms-driver insists on disabling its irq during modeset/dpms off/suspend etc. With these remarks somehow taken into account you have my Reviewed-by: Mario K
[Intel-gfx] [PATCH v2 0/7] Rename DP training vswing/pre-emph defines
On Fri, Aug 08, 2014 at 04:23:39PM +0530, sonika.jindal at intel.com wrote: > From: Sonika Jindal > > Rename the defines to have levels instead of values for vswing and pre-emph > levels as the values may differ in other scenarios like low vswing of eDP 1.4 > where the values are different. > Updated in all the drivers as well > > v2: Keeping the old defines in first patch and removing them in last patch. > Used > cocci semantic patch to replace the defines. > > Sonika Jindal (7): > drm: Renaming DP training vswing pre emph defines > drm/i915: Renaming DP training vswing pre emph defines > drm/exynos: Renaming DP training vswing pre emph defines > drm/gma500: Renaming DP training vswing pre emph defines > drm/radeon: Renaming DP training vswing pre emph defines > drm/tegra: Renaming DP training vswing pre emph defines > drm: Remove old defines for vswing and pre-emph values I've pulled in the entire series with Dave's irc-ack for the non-i915 bits. Thanks, Daniel > > drivers/gpu/drm/exynos/exynos_dp_core.c |4 +- > drivers/gpu/drm/gma500/cdv_intel_dp.c |4 +- > drivers/gpu/drm/gma500/intel_bios.c | 16 +-- > drivers/gpu/drm/i915/intel_bios.c | 16 +-- > drivers/gpu/drm/i915/intel_dp.c | 194 > +++ > drivers/gpu/drm/radeon/atombios_dp.c|4 +- > drivers/gpu/drm/tegra/dpaux.c |4 +- > include/drm/drm_dp_helper.h | 16 +-- > 8 files changed, 129 insertions(+), 129 deletions(-) > > -- > 1.7.10.4 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #17 from Pavel Ondra?ka --- output with second debug patch: bin/shader_runner tests/shaders/glsl-fs-loop-continue.shader_test -auto r300: DRM version: 2.38.0, Name: ATI RV530, ID: 0x71c5, GB: 1, Z: 2 r300: GART size: 509 MB, VRAM size: 256 MB r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: YES increasing q total, old q total = 0, n1 = 0, n2 = 1, value = 1 increasing q total, old q total = 0, n1 = 1, n2 = 0, value = 1 increasing q total, old q total = 1, n1 = 0, n2 = 2, value = 1 increasing q total, old q total = 0, n1 = 2, n2 = 0, value = 1 increasing q total, old q total = 1, n1 = 1, n2 = 2, value = 1 increasing q total, old q total = 1, n1 = 2, n2 = 1, value = 3 decreasing q total, old q total = 2, n = 2, n2 = 0, value = 0 decreasing q total, old q total = 2, n = 2, n2 = 1, value = 0 decreasing q total, old q total = 2, n = 1, n2 = 0, value = 3 Neopr?vn?n? p??stup do pam?ti (SIGSEGV) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/4671df24/attachment.html>
[Bug 83416] New: [radeonsi] Serious Sam 3 lockup during its start
https://bugs.freedesktop.org/show_bug.cgi?id=83416 Priority: medium Bug ID: 83416 Assignee: dri-devel at lists.freedesktop.org Summary: [radeonsi] Serious Sam 3 lockup during its start Severity: major Classification: Unclassified OS: Linux (All) Reporter: lordheavym at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 105638 --> https://bugs.freedesktop.org/attachment.cgi?id=105638&action=edit kernel.log file with kernel 3.17rc3 * Tested with both kernel 3.16.1 and kernel 3.17rc3, with and without hyperz * OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN * OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.4.0-devel (git-021e84f) I can reproduce the lockup with the trace: http://pkgbuild.com/~lcarlier/trace/Sam3.tar.xz -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/3beb1aa4/attachment.html>
[Bug 30102] [RADEON:KMS:RS780:CP] ring test failed
https://bugzilla.kernel.org/show_bug.cgi?id=30102 Alex Perez changed: What|Removed |Added CC||aperez at alexperez.com --- Comment #11 from Alex Perez --- Multiple users including myself are experiencing this problem on PPC64 (big-endian) with kernel 3.8.13. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #18 from Pavel Ondra?ka --- Created attachment 105641 --> https://bugs.freedesktop.org/attachment.cgi?id=105641&action=edit RADEON_DEBUG=fp,vp output (In reply to comment #15) > Can you post the output of RADEON_DEBUG=ps,vs ? I suppose you mean RADEON_DEBUG=fp,vp? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/603994d1/attachment.html>
[Bug 83418] New: EU IV is incorrectly rendered after git1409011930.d571f2
https://bugs.freedesktop.org/show_bug.cgi?id=83418 Priority: medium Bug ID: 83418 Assignee: dri-devel at lists.freedesktop.org Summary: EU IV is incorrectly rendered after git1409011930.d571f2 Severity: normal Classification: Unclassified OS: All Reporter: j.suarez.agapito at gmail.com Hardware: All Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 105643 --> https://bugs.freedesktop.org/attachment.cgi?id=105643&action=edit Screenshot showing the incorrect rendering The terreain map is incorrectly rendered in Europa Universalis IV with mesa git after d571f2 (1 September) on my Radeon HD 7870 (radeonsi). I am only attaching a screenshot since there is no relevant information on dmesg and Xorg logs. At first I thought the bug could be due to the recent glsl commits but after trying different versions (I cannot easily bisect) I believe it is more r600/radeonsi related. Please, let me know if anything else is needed. The system specs are as follows: Informaci?n sobre el procesador: Fabricante: AuthenticAMD Familia de la CPU: 0x15 Modelo de la CPU: 0x1 Stepping de la CPU: 0x2 Tipo de CPU: 0x0 Velocidad: 3700 MHz Procesadores l?gicos 8 Procesadores f?sicos 8 HyperThreading: No compatible FCMOV: Compatible SSE2: Compatible SSE3: Compatible SSSE3: Compatible SSE4a: Compatible SSE41: Compatible SSE42: Compatible Informaci?n sobre la red: Velocidad de la red: Versi?n del sistema operativo: Ubuntu 14.04.1 LTS (64 bits) Nombre de kernel: Linux Versi?n de kernel: 3.17.0-031700rc3-generic Editor de X Server: The X.Org Foundation Versi?n de X Server: 11501000 Gestor X Window: KWin Versi?n del runtime de Steam: steam-runtime-release_2014-08-20 Tarjeta de v?deo: Controlador: X.Org Gallium 0.4 on AMD PITCAIRN Versi?n de controlador: 3.0 Mesa 10.4.0-devel (git-d571f2b 2014-09-01 trusty-oibaf-ppa) Versi?n de OpenGL: 3.0 Densidad de color del escritorio: 24 bits por p?xel Frecuencia de actualizaci?n del monitor: 60 Hz Identificador del fabricante: 0x1002 Identificador del dispositivo: 0x6818 N?mero de monitores: 1 N?mero de tarjetas de v?deo l?gicas: 1 Resoluci?n de pantalla principal: 1920 x 1080 Resoluci?n de escritorio: 1920 x 1080 Tama?o de pantalla principal: 18,78" x 10,55" (21,54" diag) 47,7cm x 26,8cm (54,7cm diag) No se ha detectado la memoria VRAM principal Tarjeta de sonido: Dispositivo de sonido: Realtek ALC889 Memoria: RAM: 15865 Mb Varios: Idioma de la IU: Espa?ol IDIOMA: es_ES.UTF-8 Micr?fono: Not set Espacio total en disco disponible: 469324 MB Bloque libre m?s grande en el disco: 15703 MB Software Instalado: Informes de fallos recientes: -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/a7a56f40/attachment-0001.html>
[Bug 83418] EU IV is incorrectly rendered after git1409011930.d571f2
https://bugs.freedesktop.org/show_bug.cgi?id=83418 Ilia Mirkin changed: What|Removed |Added Attachment #105643|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/17589b2c/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #52 from Andy Furniss --- Just updated llvm and my perf on pyrit is back to normal - Computed 77586.36 PMKs/s total. #1: 'OpenCL-Device 'AMD PITCAIRN'': 73865.3 PMKs/s (RTT 0.8) #2: 'CPU-Core (SSE2)': 744.3 PMKs/s (RTT 2.9) #3: 'CPU-Core (SSE2)': 746.4 PMKs/s (RTT 3.0) #4: 'CPU-Core (SSE2)': 745.7 PMKs/s (RTT 2.9) #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/04ef717e/attachment.html>
[Bug 80878] [r600g][regression] Metro: Last Light freezes when trying to kill stealthily
https://bugs.freedesktop.org/show_bug.cgi?id=80878 yashax at windowslive.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #6 from yashax at windowslive.com --- I tested it again (now on Arch), and the bug exists with Mesa 10.2.6, 10.2.1, 10.1.0. Also, the bug exists only in my save. In new saves the bug is gone. This is clearly not a mesa bug/regression so I'm closing this. Sorry for the trouble. I will attach the broken save if anyone is interested in reproducing this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/703ce3ab/attachment.html>
[Bug 80878] Metro: Last Light freezes when trying to kill stealthily (RV770)
https://bugs.freedesktop.org/show_bug.cgi?id=80878 yashax at windowslive.com changed: What|Removed |Added Summary|[r600g][regression] Metro: |Metro: Last Light freezes |Last Light freezes when |when trying to kill |trying to kill stealthily |stealthily (RV770) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/aab28d5e/attachment.html>
[Bug 80878] Metro: Last Light freezes when trying to kill stealthily (RV770)
https://bugs.freedesktop.org/show_bug.cgi?id=80878 yashax at windowslive.com changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/f6c46ab5/attachment.html>
[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=82050 --- Comment #53 from Andy Furniss --- (In reply to comment #52) > Just updated llvm and my perf on pyrit is back to normal - > > Computed 77586.36 PMKs/s total. > #1: 'OpenCL-Device 'AMD PITCAIRN'': 73865.3 PMKs/s (RTT 0.8) > #2: 'CPU-Core (SSE2)': 744.3 PMKs/s (RTT 2.9) > #3: 'CPU-Core (SSE2)': 746.4 PMKs/s (RTT 3.0) > #4: 'CPU-Core (SSE2)': 745.7 PMKs/s (RTT 2.9) > #5: 'Network-Clients': 0.0 PMKs/s (RTT 0.0) Not llvm it's mesa - radeonsi: Compile dummy pixel shader on demand -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/c962061c/attachment.html>
[Bug 83416] [radeonsi] Serious Sam 3 lockup during its start
https://bugs.freedesktop.org/show_bug.cgi?id=83416 --- Comment #1 from smoki --- Can not reproduce it on Kabini, with same git version 021e84f. That with mesa builded against current llvm-3.6 svn just pass fine, and when i build mesa against 3.5 this this apitrace just segfault... in both cases no lockup. Debian. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/c8f8d4ae/attachment.html>
[Bug 80878] Metro: Last Light freezes when trying to kill stealthily (RV770)
https://bugs.freedesktop.org/show_bug.cgi?id=80878 --- Comment #7 from yashax at windowslive.com --- The broken save: https://drive.google.com/file/d/0B2jiKU0lRTBHd2JpQTI2RVpMQkE/edit?usp=sharing How to apply the save: Navigate to '~/.steam/steam/SteamApps/common/Metro Last Light'. Inside that folder, there is a folder with numbers and letter in name that contains user.cfg and save files. Backup this folder, and replace its content with my save (Metro: Last Light doesn't support multiple saves). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140902/5bc3b3db/attachment-0001.html>
[PATCH 0/2] drm/edid: Reduce horizontal timings for pixel
From: Clint Taylor Split original drm_edid.c changes and intel_hdmi.c HDMI pixel replciation changes into separate patches. Clint Taylor (2): drm/edid: Reduce horizontal timings for pixel replicated modes drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes drivers/gpu/drm/drm_edid.c| 96 ++--- drivers/gpu/drm/i915/intel_hdmi.c | 15 -- 2 files changed, 60 insertions(+), 51 deletions(-) -- 1.7.9.5
[PATCH 1/2] drm/edid: Reduce horizontal timings for pixel replicated modes
From: Clint Taylor
Pixel replicated modes should be non-2x horizontal timings and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change will
allow HDMI certification with 480i/576i modes once pixel replication
is turned on.
Signed-off-by: Clint Taylor
Cc: Daniel Vetter
Cc: Ville Syrj?l?
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_edid.c | 96 ++--
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index daf3cd8..1bdbfd0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,27 +632,27 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 6 - 1440x480i at 60Hz */
- { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
- 1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 6 - 720(1440)x480i at 60Hz */
+ { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 7 - 1440x480i at 60Hz */
- { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
- 1602, 1716, 0, 480, 488, 494, 525, 0,
+ /* 7 - 720(1440)x480i at 60Hz */
+ { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 8 - 1440x240 at 60Hz */
- { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
- 1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 8 - 720(1440)x240 at 60Hz */
+ { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 9 - 1440x240 at 60Hz */
- { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
- 1602, 1716, 0, 240, 244, 247, 262, 0,
+ /* 9 - 720(1440)x240 at 60Hz */
+ { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+ 801, 858, 0, 240, 244, 247, 262, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
@@ -714,27 +714,27 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 21 - 1440x576i at 50Hz */
- { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
- 1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 21 - 720(1440)x576i at 50Hz */
+ { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
- /* 22 - 1440x576i at 50Hz */
- { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
- 1590, 1728, 0, 576, 580, 586, 625, 0,
+ /* 22 - 720(1440)x576i at 50Hz */
+ { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 0, 576, 580, 586, 625, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
.vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
- /* 23 - 1440x288 at 50Hz */
- { DRM_MODE("1440x288", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
- 1590, 1728, 0, 288, 290, 293, 312, 0,
+ /* 23 - 720(1440)x288 at 50Hz */
+ { DRM_MODE("720x288", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+ 795, 864, 0, 288, 290, 293, 312, 0,
DRM_MODE_FLAG_NHSYNC | DRM_
[PATCH 2/2] drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes
From: Clint Taylor
Enable 2x pixel replication for modes the mode flag DBLCLK to double
horizontal timings and pixel clock across TMDS.
Signed-off-by: Clint Taylor
Cc: Daniel Vetter
Cc: Ville Syrj?l?
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_hdmi.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9169786..9695768 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -864,10 +864,15 @@ static enum drm_mode_status
intel_hdmi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- if (mode->clock > hdmi_portclock_limit(intel_attached_hdmi(connector),
- true))
+ int clock = mode->clock;
+
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ clock *= 2;
+
+ if (clock > hdmi_portclock_limit(intel_attached_hdmi(connector),
+true))
return MODE_CLOCK_HIGH;
- if (mode->clock < 2)
+ if (clock < 2)
return MODE_CLOCK_LOW;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
@@ -921,6 +926,10 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
intel_hdmi->color_range = 0;
}
+ if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) {
+ pipe_config->pixel_multiplier = 2;
+ }
+
if (intel_hdmi->color_range)
pipe_config->limited_color_range = true;
--
1.7.9.5
[PATCH] video: fix composite video connector compatible string
The quite-recently-added analog-tv-connector bindings say that the
compatible string for composite video connector is
"composite-connector". That string is also used in the omap3-n900.dts
file. However, the connector driver uses "composite-video-connector", so
this has never worked.
While changing the driver's compatible string to "composite-connector"
would be safer, as published DT bindings should not be changed, I'd
rather fix the bindings in this case for two reasons:
* composite-connector is a bit too generic name, as it doesn't even hint
at video.
* it's clear that this has never worked, which means no one has used
those bindings, which should make it safe to change this.
Signed-off-by: Tomi Valkeinen
Reported-by: Laurent Pinchart
---
Documentation/devicetree/bindings/video/analog-tv-connector.txt | 4 ++--
arch/arm/boot/dts/omap3-n900.dts| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
index 0218fcdc1299..0c0970c210ab 100644
--- a/Documentation/devicetree/bindings/video/analog-tv-connector.txt
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -2,7 +2,7 @@ Analog TV Connector
===
Required properties:
-- compatible: "composite-connector" or "svideo-connector"
+- compatible: "composite-video-connector" or "svideo-connector"
Optional properties:
- label: a symbolic name for the connector
@@ -14,7 +14,7 @@ Example
---
tv: connector {
- compatible = "composite-connector";
+ compatible = "composite-video-connector";
label = "tv";
port {
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1fe45d1f75ec..4361777a08d8 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -93,7 +93,7 @@
};
tv: connector {
- compatible = "composite-connector";
+ compatible = "composite-video-connector";
label = "tv";
port {
--
1.9.1
[BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"
Michel D?nzer writes:
> On 30.08.2014 22:59, Mikael Pettersson wrote:
> > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
> > after a while in X + firefox. This still occurs with yesterday's HEAD
> > of Linus' repo. 3.16 and ealier kernels are fine.
> >
> > I ran a bisect, which identified:
> >
> > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
> > Author: Michel D??nzer
> > Date: Thu Jul 31 18:43:49 2014 +0900
> >
> > drm/radeon: Always flush the HDP cache before submitting a CS to the
> > GPU
> >
> > as the cause of my screen corruption. Reverting this from 3.17-rc2
> > (which requires manual intervention due to subsequent changes in
> > radeon_ring_commit()) eliminates the screen corruption.
>
> Does the patch below help?
Thanks for the patch, I'll test it on Friday evening when I'm
back home and have access to the affected machine.
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 4c5ec44..3ff9c53 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -1070,6 +1070,20 @@ void r100_ring_hdp_flush(struct radeon_device *rdev,
> struct radeon_ring *ring)
> radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
> }
>
> +/**
> + * r100_mmio_hdp_flush - flush Host Data Path via MMIO
> + * rdev: radeon device structure
> + */
> +void r100_mmio_hdp_flush(struct radeon_device *rdev)
> +{
> +WREG32(RADEON_HOST_PATH_CNTL,
> + rdev->config.r100.hdp_cntl | RADEON_HDP_READ_BUFFER_INVALIDATE);
> +(void)RREG32(RADEON_HOST_PATH_CNTL);
> +WREG32(RADEON_HOST_PATH_CNTL,
> + rdev->config.r100.hdp_cntl);
> +(void)RREG32(RADEON_HOST_PATH_CNTL);
> +}
> +
> static void r100_cp_load_microcode(struct radeon_device *rdev)
> {
> const __be32 *fw_data;
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index abe..c23a123 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -408,7 +408,7 @@ static struct radeon_asic r300_asic_pcie = {
> .resume = &r300_resume,
> .vga_set_state = &r100_vga_set_state,
> .asic_reset = &r300_asic_reset,
> -.mmio_hdp_flush = NULL,
> +.mmio_hdp_flush = r100_mmio_hdp_flush,
> .gui_idle = &r100_gui_idle,
> .mc_wait_for_idle = &r300_mc_wait_for_idle,
> .gart = {
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index 275a5dc..e9b1c35 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -150,6 +150,8 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
> struct radeon_ring *ring);
> void r100_ring_hdp_flush(struct radeon_device *rdev,
> struct radeon_ring *ring);
> +void r100_mmio_hdp_flush(struct radeon_device *rdev);
> +
> /*
> * r200,rv250,rs300,rv280
> */
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index bfd7e1b..3d0f564 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -368,6 +368,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
> void *data,
> r = radeon_bo_wait(robj, &cur_placement, false);
> /* Flush HDP cache via MMIO if necessary */
> if (rdev->asic->mmio_hdp_flush &&
> +!rdev->asic->ring[RADEON_RING_TYPE_GFX_INDEX]->hdp_flush &&
> radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
> robj->rdev->asic->mmio_hdp_flush(rdev);
> drm_gem_object_unreference_unlocked(gobj);
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index d656079..b82843b 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -188,7 +188,8 @@ void radeon_ring_commit(struct radeon_device *rdev,
> struct radeon_ring *ring,
> /* If we are emitting the HDP flush via the ring buffer, we need to
> * do it before padding.
> */
> -if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush)
> +if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush &&
> +!rdev->asic->mmio_hdp_flush)
> rdev->asic->ring[ring->idx]->hdp_flush(rdev, ring);
> /* We pad to match fetch size */
> while (ring->wptr & ring->align_mask) {
>
>
>
> --
> Earthling Michel D?nzer| http://www.amd.com
> Libre software enthusiast |Mesa and X developer
--
[PATCH] gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig
SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry. Signed-off-by: Fabio Estevam --- drivers/gpu/ipu-v3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig index 2f228a2..8696d20 100644 --- a/drivers/gpu/ipu-v3/Kconfig +++ b/drivers/gpu/ipu-v3/Kconfig @@ -1,6 +1,6 @@ config IMX_IPUV3_CORE tristate "IPUv3 core support" - depends on SOC_IMX5 || SOC_IMX6Q || SOC_IMX6SL || ARCH_MULTIPLATFORM + depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM depends on RESET_CONTROLLER help Choose this if you have a i.MX5/6 system and want to use the Image -- 1.8.3.2
[PATCH] gpu: ipu-v3: ipu-di: Print the generated pixelclock error
For debug purposes it is useful to know how far away the generated pixelclock is
from the desired rate, so print the amount of error.
After adding this patch and with debug enabled we have:
imx-ipuv3 240.ipu: disp 0: panel size = 1920 x 1080
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 2400Hz Needed 13850Hz
imx-ipuv3 240.ipu: IPU clock can give 13200 with divider 2, error
-4.3%
imx-ipuv3 240.ipu: Want 13850Hz IPU 26400Hz DI 13850Hz using
DI, 13850Hz, error 0.0%
imx-ipuv3 240.ipu: disp 1: panel size = 1024 x 768
imx-ipuv3 240.ipu: Clocks: IPU 26400Hz DI 6499Hz Needed 6500Hz
imx-ipuv3 240.ipu: Want 6500Hz IPU 26400Hz DI 6499Hz using DI,
6499Hz, error 0.9%
Signed-off-by: Fabio Estevam
---
drivers/gpu/ipu-v3/ipu-di.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index c490ba4..148ef6e 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -402,7 +402,7 @@ static void ipu_di_config_clock(struct ipu_di *di,
const struct ipu_di_signal_cfg *sig)
{
struct clk *clk;
- unsigned clkgen0;
+ unsigned clkgen0, error;
uint32_t val;
if (sig->clkflags & IPU_DI_CLKMODE_EXT) {
@@ -451,7 +451,7 @@ static void ipu_di_config_clock(struct ipu_di *di,
* otherwise we use the DI clock.
*/
unsigned long rate, clkrate;
- unsigned div, error;
+ unsigned div;
clkrate = clk_get_rate(di->clk_ipu);
div = (clkrate + sig->pixelclock / 2) / sig->pixelclock;
@@ -503,12 +503,15 @@ static void ipu_di_config_clock(struct ipu_di *di,
val |= DI_GEN_DI_CLK_EXT;
ipu_di_write(di, val, DI_GENERAL);
- dev_dbg(di->ipu->dev, "Want %luHz IPU %luHz DI %luHz using %s, %luHz\n",
+ error = (clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4)) /
(sig->pixelclock / 1000);
+
+ dev_dbg(di->ipu->dev, "Want %luHz IPU %luHz DI %luHz using %s, %luHz,
error %d.%u%%\n",
sig->pixelclock,
clk_get_rate(di->clk_ipu),
clk_get_rate(di->clk_di),
clk == di->clk_di ? "DI" : "IPU",
- clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4));
+ clk_get_rate(di->clk_di_pixel) / (clkgen0 >> 4),
+ (signed)(error - 1000) / 10, error % 10);
}
int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig)
--
1.8.3.2
