[Bug 90219] Half as many compute cores reported as when running with 'fglrx'
https://bugs.freedesktop.org/show_bug.cgi?id=90219 Bug ID: 90219 Summary: Half as many compute cores reported as when running with 'fglrx' Product: Mesa Version: 10.4 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: benjiwiebe14 at gmail.com QA Contact: dri-devel at lists.freedesktop.org When using 'fglrx', this program (https://gist.github.com/BenjiWiebe/52a01924009d3534a5d6) reports 24 compute cores. When running with r600, it reports only 12. I have only one GPU, a Radeon HD6970. -- 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/20150428/03d2a5c9/attachment-0001.html>
[Bug 90218] Kerbal Space Program crashes with Souther Islands
https://bugs.freedesktop.org/show_bug.cgi?id=90218 Lucas changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) Version|unspecified |git OS|All |Linux (All) -- 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/20150428/c4e297be/attachment.html>
[Bug 90218] Kerbal Space Program crashes with Souther Islands
https://bugs.freedesktop.org/show_bug.cgi?id=90218 Bug ID: 90218 Summary: Kerbal Space Program crashes with Souther Islands Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: lvella at gmail.com QA Contact: dri-devel at lists.freedesktop.org I had no problem playing the game (aside from low FPS) with i965 on the same machine, stock drivers from Ubuntu 14.10. Now, with a new GFX r9 280X, the game runs OK, but may randomly crash the entire system and I must hard reset the computer. I could not find anything relevant on the dmesg log from the last crashed session, the last message was from boot procedure. Last time it crashed I was on the Mission Center screen, from Carrer Mode. I also remember it crashed when I switched workspace with the game running (XFce, no composition, I pressed ctrl + alt + leftarrow, it swiched, displayed Chrome window running there, and crashed). The driver is no longer Ubuntu stock, and I am using from this PPA: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers with the following env var: R600_DEBUG=sb It crashed with Ubuntu 14.10, and crashed yesterday again, after updating to Ubuntu 15.04. The relevant part from glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD TAHITI OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.6.0-devel (git-7f5a8ac 2015-04-25 utopic-oibaf-ppa) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile It fares better than fglrx, that crashes the game just past main menu. -- 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/20150428/a5befc6a/attachment.html>
Build regressions/improvements in v4.1-rc1
Geert Uytterhoeven writes: >> Can't see that one with a simple grep: can you post warning? > > /home/kisskb/slave/src/arch/tile/kernel/setup.c: In function > 'zone_sizes_init': > /home/kisskb/slave/src/arch/tile/kernel/setup.c:777:3: warning: > passing argument 2 of 'cpumask_test_cpu' from incompatible pointer > type [enabled by default] > /home/kisskb/slave/src/include/linux/cpumask.h:294:19: note: expected > 'const struct cpumask *' but argument is of type 'struct nodemask_t *' Um, I turned the cpu_isset() into cpumask_test_cpu(), but that just showed this bug up. The tile maintainers need to fix this one. Thanks, Rusty.
[Bug 90176] [bisected] All 3D applications crash on LLVM git
https://bugs.freedesktop.org/show_bug.cgi?id=90176 sarnex changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from sarnex --- Fixed by LLVM commit R600: Fix up for AsmPrinter's OutStreamer being a unique_ptr Thanks guys, sarnex -- 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/20150428/1cbb2b95/attachment.html>
[PATCH/RFC] i915: fix screen flickering
Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
always on for wm calculation (v4)") fixes a null pointer dereference.
Setting the primary and cursor panes to false in
ilk_compute_wm_parameters to false does however give the following
errors in the kernel log and causes the screen to flicker.
[ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
*ERROR* uncleared fifo underrun on pipe A
[ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun
Always setting the panes to enabled fixes this error.
Signed-off-by: Thomas Gummerer
---
Hi,
I've noticed the regression in v4.1-rc1. I'm not sure this is the best
solution, but it's the best I could come up with in the time I had
available.
drivers/gpu/drm/i915/intel_pm.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fa4ccb3..377df60 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2045,22 +2045,20 @@ static void ilk_compute_wm_parameters(struct drm_crtc
*crtc,
p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
- if (crtc->primary->state->fb) {
- p->pri.enabled = true;
+ if (crtc->primary->state->fb)
p->pri.bytes_per_pixel =
crtc->primary->state->fb->bits_per_pixel / 8;
- } else {
- p->pri.enabled = false;
+ else
p->pri.bytes_per_pixel = 0;
- }
- if (crtc->cursor->state->fb) {
- p->cur.enabled = true;
- p->cur.bytes_per_pixel = 4;
- } else {
- p->cur.enabled = false;
- p->cur.bytes_per_pixel = 0;
- }
+ p->cur.bytes_per_pixel = 4;
+ /*
+* TODO: for now, assume primary and cursor planes are always enabled.
+* Setting them to false makes the screen flicker.
+*/
+ p->pri.enabled = true;
+ p->cur.enabled = true;
+
p->pri.horiz_pixels = intel_crtc->config->pipe_src_w;
p->cur.horiz_pixels = intel_crtc->base.cursor->state->crtc_w;
--
2.1.0.264.g0463184.dirty
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207
José Fonseca changed:
What|Removed |Added
CC||jfonseca at vmware.com
Component|Drivers/Gallium/r600|Mesa core
Assignee|dri-devel at lists.freedesktop |mesa-dev at
lists.freedesktop.
|.org|org
QA Contact|dri-devel at lists.freedesktop |mesa-dev at
lists.freedesktop.
|.org|org
--- Comment #11 from José Fonseca ---
(In reply to Dieter Nützel from comment #0)
[...]
> a563689a408b7a28c710fb0e382272a0d823f38a is the first bad commit
> commit a563689a408b7a28c710fb0e382272a0d823f38a
> Author: Tapani Pälli
> Date: Thu Apr 23 11:13:17 2015 +0300
>
> mesa: refactor active attrib queries for glGetProgramiv
>
> Main motivation here is to get rid of iterating IR and
> encapsulate queries within program resources.
> No functional changes.
>
> Piglit tests calling the modified functionality:
>
>- gl-get-active-attrib-returns-all-inputs
>- glsl-1.50-get-active-attrib-array
>- getactiveattrib
>
> [...]
Piglit `getactiveattrib 110` test started to randomly fail on llvmpipe:
$ for i in `seq 1 100`; do .../piglit/bin/getactiveattrib 110 -auto -fbo; done
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
Mesa: User error: GL_INVALID_VALUE in glGetActiveAttrib(index)
Failing shader:
attribute vec4 vertex;
attribute vec2 alternate;
uniform bool use_alternate;
void main() {
gl_Position = vertex;
if (use_alternate) gl_Position = alternate.xyxy;
}
Attribute `alternate' listed multiple times in active list.
PIGLIT: {"result": "fail" }
PIGLIT: {"result": "pass" }
PIGLIT: {"result": "pass" }
> When I revert 'a563689' all is smooth, again.
And likewise, if I revert a563689 it passes consistently.
--
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/20150428/209eda31/attachment.html>
[PATCH v2 2/2] drm/msm/mdp5: Wait for PP_DONE irq for command mode CRTC atomic commit
CRTCs in DSI command mode data path should wait for pingpong done,
instead of vblank, to finish atomic commit.
This change is to enable PP_DONE irq on command mode CRTCs and wait for
this irq happens before atomic commit completion.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 4 --
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 82 -
2 files changed, 66 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
index e4e8956..5f87357 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
@@ -216,16 +216,12 @@ static void mdp5_cmd_encoder_mode_set(struct drm_encoder
*encoder,
static void mdp5_cmd_encoder_disable(struct drm_encoder *encoder)
{
struct mdp5_cmd_encoder *mdp5_cmd_enc = to_mdp5_cmd_encoder(encoder);
- struct mdp5_kms *mdp5_kms = get_kms(encoder);
struct mdp5_ctl *ctl = mdp5_crtc_get_ctl(encoder->crtc);
struct mdp5_interface *intf = _cmd_enc->intf;
- int lm = mdp5_crtc_get_lm(encoder->crtc);
if (WARN_ON(!mdp5_cmd_enc->enabled))
return;
- /* Wait for the last frame done */
- mdp_irq_wait(_kms->base, lm2ppdone(lm));
pingpong_tearcheck_disable(encoder);
mdp5_ctl_set_encoder_state(ctl, false);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index aa0b0c5..8d9d67a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2015 The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
*
@@ -60,6 +60,11 @@ struct mdp5_crtc {
struct mdp_irq vblank;
struct mdp_irq err;
+ struct mdp_irq pp_done;
+
+ struct completion pp_completion;
+
+ bool cmd_mode;
struct {
/* protect REG_MDP5_LM_CURSOR* registers and cursor scanout_bo*/
@@ -87,6 +92,12 @@ static void request_pending(struct drm_crtc *crtc, uint32_t
pending)
mdp_irq_register(_kms(crtc)->base, _crtc->vblank);
}
+static void request_pp_done_pending(struct drm_crtc *crtc)
+{
+ struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
+ reinit_completion(_crtc->pp_completion);
+}
+
static u32 crtc_flush(struct drm_crtc *crtc, u32 flush_mask)
{
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
@@ -282,6 +293,9 @@ static void mdp5_crtc_disable(struct drm_crtc *crtc)
/* set STAGE_UNUSED for all layers */
mdp5_ctl_blend(mdp5_crtc->ctl, mdp5_crtc->lm, 0x);
+ if (mdp5_crtc->cmd_mode)
+ mdp_irq_unregister(_kms->base, _crtc->pp_done);
+
mdp_irq_unregister(_kms->base, _crtc->err);
mdp5_disable(mdp5_kms);
@@ -301,6 +315,9 @@ static void mdp5_crtc_enable(struct drm_crtc *crtc)
mdp5_enable(mdp5_kms);
mdp_irq_register(_kms->base, _crtc->err);
+ if (mdp5_crtc->cmd_mode)
+ mdp_irq_register(_kms->base, _crtc->pp_done);
+
mdp5_crtc->enabled = true;
}
@@ -402,6 +419,15 @@ static void mdp5_crtc_atomic_flush(struct drm_crtc *crtc)
blend_setup(crtc);
+ /* PP_DONE irq is only used by command mode for now.
+* It is better to request pending before FLUSH and START trigger
+* to make sure no pp_done irq missed.
+* This is safe because no pp_done will happen before SW trigger
+* in command mode.
+*/
+ if (mdp5_crtc->cmd_mode)
+ request_pp_done_pending(crtc);
+
mdp5_crtc->flushed_mask = crtc_flush_all(crtc);
request_pending(crtc, PENDING_FLIP);
@@ -612,6 +638,26 @@ static void mdp5_crtc_err_irq(struct mdp_irq *irq,
uint32_t irqstatus)
DBG("%s: error: %08x", mdp5_crtc->name, irqstatus);
}
+static void mdp5_crtc_pp_done_irq(struct mdp_irq *irq, uint32_t irqstatus)
+{
+ struct mdp5_crtc *mdp5_crtc = container_of(irq, struct mdp5_crtc,
+ pp_done);
+
+ complete(_crtc->pp_completion);
+}
+
+static void mdp5_crtc_wait_for_pp_done(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
+ int ret;
+
+ ret = wait_for_completion_timeout(_crtc->pp_completion,
+ msecs_to_jiffies(50));
+ if (ret == 0)
+ dev_warn(dev->dev, "pp done time out, lm=%d\n", mdp5_crtc->lm);
+}
+
static void mdp5_crtc_wait_for_flush_done(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@ -659,16 +705,18 @@ void mdp5_crtc_set_intf(struct drm_crtc *crtc, struct
mdp5_interface *intf)
/* now that we know what irq's we want: */
[PATCH v2 1/2] drm/msm: Use customized function to wait for atomic commit done
MDP FLUSH registers could indicate if the previous flush updates
has taken effect at vsync boundary. Making use of this H/W feature
can catch the vsync that happened between CRTC atomic_flush and
*_wait_for_vblanks, to avoid unnecessary wait.
This change allows kms CRTCs to use their own *_wait_for_commit_done
functions to wait for FLUSH register cleared at vsync, before commit
completion.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 39 ++
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 7
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 55
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 11 +--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 3 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 7
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
drivers/gpu/drm/msm/msm_atomic.c | 30 +++--
drivers/gpu/drm/msm/msm_kms.h| 3 ++
10 files changed, 146 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
index 73afa21..c4bb9d9 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
@@ -51,6 +51,11 @@ struct mdp4_crtc {
/* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
+ /* Bits have been flushed at the last commit,
+* used to decide if a vsync has happened since last commit.
+*/
+ u32 flushed_mask;
+
#define PENDING_CURSOR 0x1
#define PENDING_FLIP 0x2
atomic_t pending;
@@ -93,6 +98,8 @@ static void crtc_flush(struct drm_crtc *crtc)
DBG("%s: flush=%08x", mdp4_crtc->name, flush);
+ mdp4_crtc->flushed_mask = flush;
+
mdp4_write(mdp4_kms, REG_MDP4_OVERLAY_FLUSH, flush);
}
@@ -537,6 +544,29 @@ static void mdp4_crtc_err_irq(struct mdp_irq *irq,
uint32_t irqstatus)
crtc_flush(crtc);
}
+static void mdp4_crtc_wait_for_flush_done(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
+ struct mdp4_kms *mdp4_kms = get_kms(crtc);
+ int ret;
+
+ ret = drm_crtc_vblank_get(crtc);
+ if (ret)
+ return;
+
+ ret = wait_event_timeout(dev->vblank[drm_crtc_index(crtc)].queue,
+ !(mdp4_read(mdp4_kms, REG_MDP4_OVERLAY_FLUSH) &
+ mdp4_crtc->flushed_mask),
+ msecs_to_jiffies(50));
+ if (ret <= 0)
+ dev_warn(dev->dev, "vblank time out, crtc=%d\n", mdp4_crtc->id);
+
+ mdp4_crtc->flushed_mask = 0;
+
+ drm_crtc_vblank_put(crtc);
+}
+
uint32_t mdp4_crtc_vblank(struct drm_crtc *crtc)
{
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
@@ -600,6 +630,15 @@ void mdp4_crtc_set_intf(struct drm_crtc *crtc, enum
mdp4_intf intf, int mixer)
mdp4_write(mdp4_kms, REG_MDP4_DISP_INTF_SEL, intf_sel);
}
+void mdp4_crtc_wait_for_commit_done(struct drm_crtc *crtc)
+{
+ /* wait_for_flush_done is the only case for now.
+* Later we will have command mode CRTC to wait for
+* other event.
+*/
+ mdp4_crtc_wait_for_flush_done(crtc);
+}
+
static const char *dma_names[] = {
"DMA_P", "DMA_S", "DMA_E",
};
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index d81e19d..f0b6c4b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -157,6 +157,12 @@ static void mdp4_complete_commit(struct msm_kms *kms,
struct drm_atomic_state *s
mdp4_disable(mdp4_kms);
}
+static void mdp4_wait_for_crtc_commit_done(struct msm_kms *kms,
+ struct drm_crtc *crtc)
+{
+ mdp4_crtc_wait_for_commit_done(crtc);
+}
+
static long mdp4_round_pixclk(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder)
{
@@ -195,6 +201,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.disable_vblank = mdp4_disable_vblank,
.prepare_commit = mdp4_prepare_commit,
.complete_commit = mdp4_complete_commit,
+ .wait_for_crtc_commit_done = mdp4_wait_for_crtc_commit_done,
.get_format = mdp_get_format,
.round_pixclk= mdp4_round_pixclk,
.preclose= mdp4_preclose,
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index 0a5c58b..5b1a412 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -206,6 +206,7 @@ uint32_t mdp4_crtc_vblank(struct drm_crtc *crtc);
void mdp4_crtc_cancel_pending_flip(struct drm_crtc *crtc, struct drm_file
*file);
void mdp4_crtc_set_config(struct drm_crtc *crtc, uint32_t config);
void mdp4_crtc_set_intf(struct
[PATCH v2 0/2] drm/msm: Customize wait for atomic commit done function
The current way to wait for atomic commit done may cause unnecessary wait for another vsync for video mode path. Also, for command mode path, we need to wait for PP_DONE event other than vsync before finish. This patch series is to fix these issues. v2: Replace function pointer with a cmd mode flag to differentiate cmd mode wait function from video mode. (From Rob Clark) Hai Li (2): drm/msm: Use customized function to wait for atomic commit done drm/msm/mdp5: Wait for PP_DONE irq for command mode CRTC atomic commit drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 39 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 7 ++ drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 4 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 125 +--- drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 11 ++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 3 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 7 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 + drivers/gpu/drm/msm/msm_atomic.c| 30 +- drivers/gpu/drm/msm/msm_kms.h | 3 + 11 files changed, 206 insertions(+), 25 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/2] clk: change clk_ops' ->round_rate() prototype
The series Tested-by: Mikko Perttunen on Jetson-TK1. I rebased my cpufreq series on top of this and everything's working well now. :) Thanks, Mikko. On 04/17/2015 10:29 AM, Boris Brezillon wrote: > ...
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #10 from Andy Furniss --- (In reply to Grigori Goronzy from comment #9) > Created attachment 115409 [details] [review] > Full shader > > That does not help either. Seems to break the SSA somehow. Full shader that > triggers the bug attached. > > The patch I posted earlier help with the the reduced testcase, but not with > the full shader. Both undef incoming values in phi nodes and undef branch > conditions cause problems in different ways. With the second patch + valley I get - valley_x64: LiveVariables.cpp:114: void llvm::LiveVariables::MarkVirtRegAliveInBlock(llvm::LiveVariables::VarInfo &, llvm::MachineBasicBlock *, llvm::MachineBasicBlock *, std::vector &): Assertion `MBB != >front() && "Can't find reaching def for virtreg"' failed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/223a0154/attachment-0001.html>
Using EGLImage textures imported via dma-buf with E3845 baytrail
I'm still fighting with the zero copy rendering of graphics data sent by an FPGA to my system memory. Basically what I've done so far is writing a kernel module based on TI's CMEM only simpler, reserving memory for that module during boot up using kernel command line parameter memmap=256M$0x6000 and provide a DMA-BUF implementation for accessing those buffers. After allocation of a region within that area I created an EGLImage by using the DMA-BUF file descriptor I got from my module. So far rendering of that EGLImage as a texture within OpenGL seems to work OK. But of course one buffer is not enough as we have to get FPGA writes and GPU reads in sync. Unfortunately here's where trouble starts. I stripped down a test case as much as I could that allocates three textures bound to an EGLImage Those textures are filled with a pattern in different colors. When I start rendering everything is ok. By pressing 'R' key the next texture will be rendered. First also the second texture is rendered ok and finally the third. But after switching from the third back to the first, it seems like it's rendering always the third. In another test scenario in-house we had the effect that the GPU seemed to read from the wrong address after one buffer cycle. But in that case only for the first texture. So the effect might not directly relate to the root cause for that problem. Using the same code with GPU allocated textures works as expected (switchable in the example using preprocessor define EGL_TEXTURE) Additionally if we bind an EGLImage from an DMA-BUF fd to a render buffer and want to render into that buffer we got GPU hang errors. Changing the FBO to be bound to a normal texture allocated by the GPU driver everything is OK. So something weird is going on for all access to DMA-BUF based EGLImages. We're currently using linux-stable 4.0 (but also tested that with 3.17 and 3.19 with the same effects) and mesa master rev 9143940da2c4f0deb07d01c1b48d16bb16022997. We first had used mesa 10.4.4 with a patch to allow writing into a EGLImage based on a DMA-BUF but this has been officially enabled now in current master (see http://comments.gmane.org/gmane.comp.video.mesa3d.devel/100090). But the problems seem to be unrelated to all those changes. Attached is the demo code (including the kernel module and some CMake build files). Not in production state but should be usable. In case binary file attachments are stripped from the mailing list I also uploaded it under http://expirebox.com/download/f618275a39ee118bf2f9d01645d23336.html but this link expires in 48 hours. I would be very grateful for any hint, what's going wrong. Regards, Volker -- next part -- A non-text attachment was scrubbed... Name: DRMTest.tar.gz Type: application/gzip Size: 28468 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/e78e7d14/attachment-0001.bin>
[PATCH 2/2] Fix one warning (v2)
On 28 April 2015 at 15:43, Jan Vesely wrote: > On Mon, 2015-04-27 at 10:29 +0800, Jammy Zhou wrote: >> xf86drm.c:356:2: warning: comparison of unsigned expression >= 0 is always >> true [-Wtype-limits] >> group = (serv_group >= 0) ? serv_group : DRM_DEV_GID; >> ^ >> >> v2: do 'int' cast to fix the warning >> >> Signed-off-by: Jammy Zhou > > FWIW > Reviewed-by: Jan Vesely > > Emil, are you OK with this approach? > Ideally one of the old school devs will chip in, but this looks good imho. Lets give it a week or so for other interested parties to chip-in. -Emil
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #9 from Grigori Goronzy --- Created attachment 115409 --> https://bugs.freedesktop.org/attachment.cgi?id=115409=edit Full shader That does not help either. Seems to break the SSA somehow. Full shader that triggers the bug attached. The patch I posted earlier help with the the reduced testcase, but not with the full shader. Both undef incoming values in phi nodes and undef branch conditions cause problems in different ways. -- 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/20150428/f6d9ca28/attachment.html>
[PATCH 1/2] Add device enumeration interface (v2)
On 28 April 2015 at 04:26, Zhou, Jammy wrote: > Hi Emil, > > This interface is intended for multiple GPU support. For example, we need to > know how many GPU devices are available on the system (and for some specific > vendor) in the client drivers, and then we can select proper devices for > rendering/compute/etc. For current mesa and Xserver implementations, the > device enumeration is done separately. I think it will be helpful if we can > have such kind of function in libdrm core, which can also be leveraged by > other new APIs requiring multi GPU support. > Hmm I'm not sure how the proposed interface will ease either mesa or xserver's implementation. The former is used only for clover(opencl) and already handles platform devices. While for the server I believe (haven't checked) that it just "throws" the PCI device information to the ddx and lets the latter do its thing. >> Any particular reason why "3D controller" (0x32000) is omitted ? > No. For AMD cards, we currently have 0x3 and 0x38000. Is 0x32000 used by > Nvidia cards? If so, I think we should add it as well. > What I am thinking is that using heuristics such as these will either 1) work for vendor A but not for B or 2) will be OK for B but will produce false positives for A. >> Using libpciaccess, will give you the number of PCI devices available on the >> system rather than the ones accessible - think about platform devices and/or >> devices without a drm driver. > This interface is just to enumerate the PCIE GPU devices on the system. With > regard to which ones are accessible, we can use drmOpen/drmOpenWithType to > check, and I don't want to have duplicated functionalities for these > interfaces. And for those non-PCIE platform devices (mostly on ARM > platforms), this interface shouldn't be used, and instead the client drivers > should handle it by themselves. > I am against duplication, to the point that I may have alienated a person or two :-\ Although this function as-is won't bring much benefit to mesa/xserver afaict. Plus it would be nice to keep an open mind for platform world, so that things will just work when AMD decides to go that road. Not to mention that iterating through all the devices in drmOpen* just to find that the device at pci:X:Y provides only a primary/render node seems a bit wasteful. A trivial lookup in sysfs will be able to provide all the required information, won't you agree ? Cheers, Emil
[Bug 90194] Fix Valgrind error in drmPrimeHandleToFD
https://bugs.freedesktop.org/show_bug.cgi?id=90194 --- Comment #4 from Pekka Paalanen --- If you initialize an fd, at least initialize it to the invalid file descriptor -1. Zero is a valid file descriptor and very often already an open one. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/a9b6abb1/attachment.html>
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #8 from Tom Stellard --- Does this patch help: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150202/257738.html -- 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/20150428/8195f823/attachment.html>
[PATCH] drmPrime*: initialize output args to 0
Fix Valgrind errors because those memory was uninitialized. https://bugs.freedesktop.org/show_bug.cgi?id=90194 Signed-off-by: Guillaume Desmottes --- xf86drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xf86drm.c b/xf86drm.c index f7c45f8..f3f84df 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -2724,6 +2724,7 @@ int drmPrimeHandleToFD(int fd, uint32_t handle, uint32_t flags, int *prime_fd) struct drm_prime_handle args; int ret; + args.fd = 0; args.handle = handle; args.flags = flags; ret = drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, ); @@ -2739,6 +2740,7 @@ int drmPrimeFDToHandle(int fd, int prime_fd, uint32_t *handle) struct drm_prime_handle args; int ret; + args.handle = 0; args.fd = prime_fd; args.flags = 0; ret = drmIoctl(fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, ); -- 2.1.0
[Bug 90217] Counter Strike Global Offensive: GPU fault after a while
https://bugs.freedesktop.org/show_bug.cgi?id=90217 Bug ID: 90217 Summary: Counter Strike Global Offensive: GPU fault after a while Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: haagch at frickel.club QA Contact: dri-devel at lists.freedesktop.org Created attachment 115406 --> https://bugs.freedesktop.org/attachment.cgi?id=115406=edit dmesg 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff) mesa git, llvm recent revision, with PRIME. linux 4.1rc1, but with 4.0 it was the same. Counter Strike GO seems to be problematic anyway. Even with 1366x768 and settings on low I get bad performance drops, see video: https://www.youtube.com/watch?v=HVDZowUGlSc There is flickering all over the place. At the end of the video there is one of the GPU hangs: perf interrupt took too long (4996 > 4960), lowering kernel.perf_event_max_sample_rate to 25200 radeon :01:00.0: GPU fault detected: 146 0x08e2c804 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0xEBC7 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x020C8004 VM fault (0x04, vmid 1) at page 60359, read from TC (200) radeon :01:00.0: ring 0 stalled for more than 10490msec radeon :01:00.0: GPU lockup (current fence id 0x008a0d3c last fence id 0x008a0d57 on ring 0) radeon :01:00.0: ring 0 stalled for more than 10990msec radeon :01:00.0: GPU lockup (current fence id 0x008a0d3c last fence id 0x008a0d57 on ring 0) radeon :01:00.0: ring 0 stalled for more than 11490msec radeon :01:00.0: GPU lockup (current fence id 0x008a0d3c last fence id 0x008a0d57 on ring 0) and then only further stalled messages It happens after 15-60 minutes or something like that. -- 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/20150428/22140843/attachment.html>
[Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions optional.
On Tue, Apr 28, 2015 at 11:29:06AM +, Antoine, Peter wrote:
> > > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h index
> > > > 62c40777..367e42f 100644
> > > > --- a/include/drm/drmP.h
> > > > +++ b/include/drm/drmP.h
> > > > @@ -137,17 +137,18 @@ void drm_err(const char *format, ...); /*@{*/
> > > >
> > > > /* driver capabilities and requirements mask */
> > > > -#define DRIVER_USE_AGP 0x1
> > > > -#define DRIVER_PCI_DMA 0x8
> > > > -#define DRIVER_SG 0x10
> > > > -#define DRIVER_HAVE_DMA0x20
> > > > -#define DRIVER_HAVE_IRQ0x40
> > > > -#define DRIVER_IRQ_SHARED 0x80
> > > > -#define DRIVER_GEM 0x1000
> > > > -#define DRIVER_MODESET 0x2000
> > > > -#define DRIVER_PRIME 0x4000
> > > > -#define DRIVER_RENDER 0x8000
> > > > -#define DRIVER_ATOMIC 0x1
> > > > +#define DRIVER_USE_AGP 0x1
> > > > +#define DRIVER_PCI_DMA 0x8
> > > > +#define DRIVER_SG 0x10
> > > > +#define DRIVER_HAVE_DMA0x20
> > > > +#define DRIVER_HAVE_IRQ0x40
> > > > +#define DRIVER_IRQ_SHARED 0x80
> > > > +#define DRIVER_GEM 0x1000
> > > > +#define DRIVER_MODESET 0x2000
> > > > +#define DRIVER_PRIME 0x4000
> > > > +#define DRIVER_RENDER 0x8000
> > > > +#define DRIVER_ATOMIC 0x1
> > > > +#define DRIVER_KMS_LEGACY_CONTEXT 0x2
> > >
> > > Why is there KMS in the name?
> > >
> > > By suggestion of Daniel.
> > >
> > > I was thinking just checking for GEM, but I think there was some
> > > gem+dri1 userland for i915 at some point in time. ums and dri1 are
> > > now dead as far as i915 is concerned, so in theory it should be fine.
> > > But I'm not sure if some other driver might have the same baggage.
> > >
> > > Other drivers have the same baggage.
> > >
> > > I suppose one option would be to check for MODESET instead. kms+dri1
> > > doesn't sound like an entirely sane combination to me.
> > >
> > > Can't use the MODESET as this was how it was turned off in the previous
> > > incarnation and was reverted by Dave Airle.
> >
> > Reference?
>
> From the next commit [5/5] as it is the one that actually turns off the
> functions that were turned off before.
>
> These changes are based on the two patches:
> commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
> Author: Dave Airlie
>
> And the commit that the above patch reverts:
> commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
> Author: Daniel Vetter
Looking at ancient libdrm sources makes me think nouveau just used to
create and destroy the context, but not actually use it for anything.
So nopping out the ioctls should be good enough AFAICS. Or am I missing
something?
--
Ville Syrjälä
Intel OTC
[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock
On 28/04/15 10:21, Dave Gordon wrote: > On 24/04/15 06:52, Antoine, Peter wrote: >> I picked up this work due to the following Jira ticket created by the >> security team (on Android) and was asked to give it a second look and >> found a few more issues with the hw lock code. >> >> https://jira01.devtools.intel.com/browse/GMINL-5388 >> I/O control on /dev/dri/card0 crashes the kernel (0x4008642b) >> >> It also stops Linux as it kills the driver, I guess it might be possible >> to reload the gfx driver. On a unpatched system the test that is >> included in the issue or the igt test that has been posted for the issue >> will show the problem. >> >> I ran the test on an unpatched system here and the gui stopped and the >> keyboard stopped responding, so I rebooted. With the patched system I >> did not need to reboot. >> >> Should I change the SIGTERM to SIGSEGV, not quite the same thing but >> tooling is better at handling a segfault than a SIGTERM and the >> application that calls this IOCTL is using an uninitialised hw lock so >> it is kind of the same as differencing an uninitialised pointer (kind >> of). Or, I could just remove it, but the bug has been in the code for at >> least two years (and known about), and I would guess that any code that >> is calling this is fuzzing the IOCTLs (as this is how the security team >> found it) and we should reward them with a application exit. >> >> Peter. > > SIGSEGV would be a better choice. [snip] Nope, I've changed my mind about this. I thought the problematic case was just a process releasing the lock without having acquired it, but on further examination it's really that the DRM master process has gone away or otherwise deleted (or never created?) the lock. And THEN the (non-master?) process tries to release the (now) non-existent lock. But more importantly, there's existing code in the acquire-lock path that sends SIGTERM for this case, so obviously the release-lock code should be as similar as possible. .Dave.
[PATCH 1/2] amdgpu: cleanup public interface
Haven't I CCed the list as well? If not then sorry that was my fault, Christian. On 28.04.2015 15:41, Marek Olšák wrote: > Hi Alex, > > He sent them to me. I've applied them to my tree: > > http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu > > Marek > > On Fri, Apr 24, 2015 at 5:38 PM, Alex Deucher > wrote: >> On Thu, Apr 23, 2015 at 11:53 AM, Christian König >> wrote: >>> From: Christian König >>> >>> Remove the mostly unused device parameter, for the few cases >>> where we really need it keep a copy in the context structure. >> Are you going to send out the mesa patches as well? >> >> Alex >> >>> Signed-off-by: Christian König >>> Reviewed-by: Jammy Zhou >>> Reviewed-by: Alex Deucher >>> --- >>> amdgpu/amdgpu.h| 24 +++--- >>> amdgpu/amdgpu_cs.c | 115 >>> +++-- >>> amdgpu/amdgpu_internal.h | 2 + >>> tests/amdgpu/basic_tests.c | 33 +++-- >>> tests/amdgpu/cs_tests.c| 14 +++--- >>> 5 files changed, 78 insertions(+), 110 deletions(-) >>> >>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h >>> index 90dc33c..7a85982 100644 >>> --- a/amdgpu/amdgpu.h >>> +++ b/amdgpu/amdgpu.h >>> @@ -882,7 +882,6 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev, >>>* >>>* Destroy GPU execution context when not needed any more >>>* >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>>* \param context - \c [in] GPU Context handle >>>* >>>* \return 0 on success\n >>> @@ -892,13 +891,11 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev, >>>* \sa amdgpu_cs_ctx_create() >>>* >>> */ >>> -int amdgpu_cs_ctx_free(amdgpu_device_handle dev, >>> - amdgpu_context_handle context); >>> +int amdgpu_cs_ctx_free(amdgpu_context_handle context); >>> >>> /** >>>* Query reset state for the specific GPU Context >>>* >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>>* \param context - \c [in] GPU Context handle >>>* \param state - \c [out] Reset state status >>>* >>> @@ -909,8 +906,7 @@ int amdgpu_cs_ctx_free(amdgpu_device_handle dev, >>>* \sa amdgpu_cs_ctx_create() >>>* >>> */ >>> -int amdgpu_cs_query_reset_state(amdgpu_device_handle dev, >>> - amdgpu_context_handle context, >>> +int amdgpu_cs_query_reset_state(amdgpu_context_handle context, >>> enum amdgpu_cs_ctx_reset_state *state); >>> >>> >>> @@ -924,7 +920,6 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle >>> dev, >>>* Allocate memory to be filled with PM4 packets and be served as the >>> first >>>* entry point of execution (a.k.a. Indirect Buffer) >>>* >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>>* \param context - \c [in] GPU Context which will use IB >>>* \param ib_size - \c [in] Size of allocation >>>* \param output - \c [out] Pointer to structure to get information >>> about >>> @@ -937,8 +932,7 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle >>> dev, >>>* \sa amdgpu_cs_free_ib() >>>* >>> */ >>> -int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >>> - amdgpu_context_handle context, >>> +int amdgpu_cs_alloc_ib(amdgpu_context_handle context, >>> enum amdgpu_cs_ib_size ib_size, >>> struct amdgpu_cs_ib_alloc_result *output); >>> >>> @@ -946,8 +940,6 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >>>* If UMD has allocates IBs which doesnât need any more than those IBs >>> must >>>* be explicitly freed >>>* >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>> - * \param context - \c [in] GPU Context containing IB >>>* \param handle - \c [in] IB handle >>>* >>>* \return 0 on success\n >>> @@ -960,9 +952,7 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >>>* \sa amdgpu_cs_alloc_ib() >>>* >>> */ >>> -int amdgpu_cs_free_ib(amdgpu_device_handle dev, >>> - amdgpu_context_handle context, >>> - amdgpu_ib_handle handle); >>> +int amdgpu_cs_free_ib(amdgpu_ib_handle handle); >>> >>> /** >>>* Send request to submit command buffers to hardware. >>> @@ -1011,8 +1001,7 @@ int amdgpu_cs_free_ib(amdgpu_device_handle dev, >>>* amdgpu_cs_query_fence_status() >>>* >>> */ >>> -int amdgpu_cs_submit(amdgpu_device_handle dev, >>> -amdgpu_context_handle context, >>> +int amdgpu_cs_submit(amdgpu_context_handle context, >>> uint64_t flags, >>> struct amdgpu_cs_request *ibs_request, >>> uint32_t number_of_requests, >>> @@ -1038,8 +1027,7 @@ int amdgpu_cs_submit(amdgpu_device_handle dev, >>>* >>>* \sa amdgpu_cs_submit() >>> */
[PATCH v3] drm/exynos: mixer: cleanup pixelformat handling
Hi Tobias,
On 04/28/2015 06:11 AM, Tobias Jakobi wrote:
> Move the defines for the pixelformats that the mixer supports out
> of mixer_graph_buffer() to the top of the source.
> Then select the mixer pixelformat (pf) in mixer_graph_buffer() based on
> the plane's pf (and not bpp).
> Also add handling of RGB565 and XRGB1555 to the switch statement and
> exit early if the plane has an unsupported pf.
>
> Partially based on 'drm/exynos: enable/disable blend based on pixel
> format' by Gustavo Padovan .
>
> v2: Use the shorter MXR_FORMAT as prefix.
> v3: Re-add ARGB because of compatibility reasons
> (suggested by Joonyoung Shim).
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 33 +++--
> 1 file changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index fbec750..0474fd3 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -44,6 +44,12 @@
> #define MIXER_WIN_NR 3
> #define MIXER_DEFAULT_WIN0
>
> +/* The pixelformats that are natively supported by the mixer. */
> +#define MXR_FORMAT_RGB5654
> +#define MXR_FORMAT_ARGB1555 5
> +#define MXR_FORMAT_ARGB 6
> +#define MXR_FORMAT_ARGB 7
> +
> struct mixer_resources {
> int irq;
> void __iomem*mixer_regs;
> @@ -531,20 +537,27 @@ static void mixer_graph_buffer(struct mixer_context
> *ctx, int win)
>
> plane = >planes[win];
>
> - #define RGB565 4
> - #define ARGB1555 5
> - #define ARGB 6
> - #define ARGB 7
> + switch (plane->pixel_format) {
> + case DRM_FORMAT_XRGB:
> + fmt = MXR_FORMAT_ARGB;
> + break;
> +
Actually i don't prefer that use new blank line like above on switch
case statement.
> + case DRM_FORMAT_XRGB1555:
> + fmt = MXR_FORMAT_ARGB1555;
> + break;
>
> - switch (plane->bpp) {
> - case 16:
> - fmt = ARGB;
> + case DRM_FORMAT_RGB565:
> + fmt = MXR_FORMAT_RGB565;
> break;
> - case 32:
> - fmt = ARGB;
> +
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + fmt = MXR_FORMAT_ARGB;
> break;
> +
> default:
> - fmt = ARGB;
> + DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
> + return;
> }
>
> /* check if mixer supports requested scaling setup */
>
If except minor comment,
Acked-by: Joonyoung Shim
Thanks.
[PATCH 1/2] amdgpu: cleanup public interface
Hi Alex, He sent them to me. I've applied them to my tree: http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu Marek On Fri, Apr 24, 2015 at 5:38 PM, Alex Deucher wrote: > On Thu, Apr 23, 2015 at 11:53 AM, Christian König > wrote: >> From: Christian König >> >> Remove the mostly unused device parameter, for the few cases >> where we really need it keep a copy in the context structure. > > Are you going to send out the mesa patches as well? > > Alex > >> >> Signed-off-by: Christian König >> Reviewed-by: Jammy Zhou >> Reviewed-by: Alex Deucher >> --- >> amdgpu/amdgpu.h| 24 +++--- >> amdgpu/amdgpu_cs.c | 115 >> +++-- >> amdgpu/amdgpu_internal.h | 2 + >> tests/amdgpu/basic_tests.c | 33 +++-- >> tests/amdgpu/cs_tests.c| 14 +++--- >> 5 files changed, 78 insertions(+), 110 deletions(-) >> >> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h >> index 90dc33c..7a85982 100644 >> --- a/amdgpu/amdgpu.h >> +++ b/amdgpu/amdgpu.h >> @@ -882,7 +882,6 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev, >> * >> * Destroy GPU execution context when not needed any more >> * >> - * \param dev- \c [in] Device handle. See >> #amdgpu_device_initialize() >> * \param context - \c [in] GPU Context handle >> * >> * \return 0 on success\n >> @@ -892,13 +891,11 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev, >> * \sa amdgpu_cs_ctx_create() >> * >> */ >> -int amdgpu_cs_ctx_free(amdgpu_device_handle dev, >> - amdgpu_context_handle context); >> +int amdgpu_cs_ctx_free(amdgpu_context_handle context); >> >> /** >> * Query reset state for the specific GPU Context >> * >> - * \param dev- \c [in] Device handle. See >> #amdgpu_device_initialize() >> * \param context - \c [in] GPU Context handle >> * \param state - \c [out] Reset state status >> * >> @@ -909,8 +906,7 @@ int amdgpu_cs_ctx_free(amdgpu_device_handle dev, >> * \sa amdgpu_cs_ctx_create() >> * >> */ >> -int amdgpu_cs_query_reset_state(amdgpu_device_handle dev, >> - amdgpu_context_handle context, >> +int amdgpu_cs_query_reset_state(amdgpu_context_handle context, >> enum amdgpu_cs_ctx_reset_state *state); >> >> >> @@ -924,7 +920,6 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle dev, >> * Allocate memory to be filled with PM4 packets and be served as the first >> * entry point of execution (a.k.a. Indirect Buffer) >> * >> - * \param dev- \c [in] Device handle. See >> #amdgpu_device_initialize() >> * \param context - \c [in] GPU Context which will use IB >> * \param ib_size - \c [in] Size of allocation >> * \param output - \c [out] Pointer to structure to get information about >> @@ -937,8 +932,7 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle dev, >> * \sa amdgpu_cs_free_ib() >> * >> */ >> -int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >> - amdgpu_context_handle context, >> +int amdgpu_cs_alloc_ib(amdgpu_context_handle context, >>enum amdgpu_cs_ib_size ib_size, >>struct amdgpu_cs_ib_alloc_result *output); >> >> @@ -946,8 +940,6 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >> * If UMD has allocates IBs which doesnât need any more than those IBs >> must >> * be explicitly freed >> * >> - * \param dev- \c [in] Device handle. See >> #amdgpu_device_initialize() >> - * \param context - \c [in] GPU Context containing IB >> * \param handle - \c [in] IB handle >> * >> * \return 0 on success\n >> @@ -960,9 +952,7 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >> * \sa amdgpu_cs_alloc_ib() >> * >> */ >> -int amdgpu_cs_free_ib(amdgpu_device_handle dev, >> - amdgpu_context_handle context, >> - amdgpu_ib_handle handle); >> +int amdgpu_cs_free_ib(amdgpu_ib_handle handle); >> >> /** >> * Send request to submit command buffers to hardware. >> @@ -1011,8 +1001,7 @@ int amdgpu_cs_free_ib(amdgpu_device_handle dev, >> * amdgpu_cs_query_fence_status() >> * >> */ >> -int amdgpu_cs_submit(amdgpu_device_handle dev, >> -amdgpu_context_handle context, >> +int amdgpu_cs_submit(amdgpu_context_handle context, >> uint64_t flags, >> struct amdgpu_cs_request *ibs_request, >> uint32_t number_of_requests, >> @@ -1038,8 +1027,7 @@ int amdgpu_cs_submit(amdgpu_device_handle dev, >> * >> * \sa amdgpu_cs_submit() >> */ >> -int amdgpu_cs_query_fence_status(amdgpu_device_handle dev, >> -struct amdgpu_cs_query_fence *fence, >> +int amdgpu_cs_query_fence_status(struct amdgpu_cs_query_fence *fence, >> uint32_t *expired); >> >> >> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c >>
[PATCH v2 1/4] drm/exynos: fb: use drm_format_num_planes to get buffer count
Hi Tobias,
On 04/28/2015 06:10 AM, Tobias Jakobi wrote:
> The previous code had some special case handling for the buffer
> count in exynos_drm_format_num_buffers().
>
> This code was incorrect though, since this special case doesn't
> exist for DRM. It stemmed from the existence of the special NV12M
> V4L2 format. NV12 is a bi-planar format (separate planes for luma
> and chroma) and V4L2 differentiates between a NV12 buffer where
> luma and chroma is contiguous in memory (so no data between
> luma/chroma), and a NV12 buffer where luma and chroma have two
> explicit memory locations (which is then called NV12M).
>
> This distinction doesn't exist for DRM. A bi-planar format always
> explicitly comes with the information about its two planes (even
> if these planes should be contiguous).
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 39
> +-
> 1 file changed, 1 insertion(+), 38 deletions(-)
>
Looks good to me about this series,
Acked-by: Joonyoung Shim
Thanks.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 929cb03..142eb4e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -171,43 +171,6 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
> return _fb->fb;
> }
>
> -static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
> -{
> - unsigned int cnt = 0;
> -
> - if (mode_cmd->pixel_format != DRM_FORMAT_NV12)
> - return drm_format_num_planes(mode_cmd->pixel_format);
> -
> - while (cnt != MAX_FB_BUFFER) {
> - if (!mode_cmd->handles[cnt])
> - break;
> - cnt++;
> - }
> -
> - /*
> - * check if NV12 or NV12M.
> - *
> - * NV12
> - * handles[0] = base1, offsets[0] = 0
> - * handles[1] = base1, offsets[1] = Y_size
> - *
> - * NV12M
> - * handles[0] = base1, offsets[0] = 0
> - * handles[1] = base2, offsets[1] = 0
> - */
> - if (cnt == 2) {
> - /*
> - * in case of NV12 format, offsets[1] is not 0 and
> - * handles[0] is same as handles[1].
> - */
> - if (mode_cmd->offsets[1] &&
> - mode_cmd->handles[0] == mode_cmd->handles[1])
> - cnt = 1;
> - }
> -
> - return cnt;
> -}
> -
> static struct drm_framebuffer *
> exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> struct drm_mode_fb_cmd2 *mode_cmd)
> @@ -230,7 +193,7 @@ exynos_user_fb_create(struct drm_device *dev, struct
> drm_file *file_priv,
>
> drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
> exynos_fb->exynos_gem_obj[0] = to_exynos_gem_obj(obj);
> - exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
> + exynos_fb->buf_cnt = drm_format_num_planes(mode_cmd->pixel_format);
>
> DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
>
>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #10 from Aaron Watry --- Created attachment 115405 --> https://bugs.freedesktop.org/attachment.cgi?id=115405=edit API Trace of konqueror crash -- 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/20150428/c6f21ee7/attachment.html>
[PATCH libdrm 3/3] xf86drm: simplify drmMalloc/drmFree
Signed-off-by: Emil Velikov
---
xf86drm.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index f7c45f8..9cd0b02 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -140,16 +140,12 @@ void *drmGetHashTable(void)
void *drmMalloc(int size)
{
-void *pt;
-if ((pt = malloc(size)))
- memset(pt, 0, size);
-return pt;
+return calloc(1, size);
}
void drmFree(void *pt)
{
-if (pt)
- free(pt);
+free(pt);
}
/**
--
2.3.5
[PATCH libdrm 2/3] modetest: replace malloc + memset with calloc
Signed-off-by: Emil Velikov
---
tests/modetest/buffers.c | 2 +-
tests/modetest/modetest.c | 27 +--
2 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 878b64e..e887fb2 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -1022,7 +1022,7 @@ bo_create_dumb(int fd, unsigned int width, unsigned int
height, unsigned int bpp
struct bo *bo;
int ret;
- bo = malloc(sizeof(*bo));
+ bo = calloc(1, sizeof(*bo));
if (bo == NULL) {
fprintf(stderr, "failed to allocate buffer object\n");
return NULL;
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index e4a8bbc..57be810 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -561,12 +561,10 @@ static struct resources *get_resources(struct device *dev)
struct resources *res;
int i;
- res = malloc(sizeof *res);
+ res = calloc(1, sizeof(*res));
if (res == 0)
return NULL;
- memset(res, 0, sizeof *res);
-
drmSetClientCap(dev->fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
res->res = drmModeGetResources(dev->fd);
@@ -576,19 +574,14 @@ static struct resources *get_resources(struct device *dev)
goto error;
}
- res->crtcs = malloc(res->res->count_crtcs * sizeof *res->crtcs);
- res->encoders = malloc(res->res->count_encoders * sizeof
*res->encoders);
- res->connectors = malloc(res->res->count_connectors * sizeof
*res->connectors);
- res->fbs = malloc(res->res->count_fbs * sizeof *res->fbs);
+ res->crtcs = calloc(res->res->count_crtcs, sizeof(*res->crtcs));
+ res->encoders = calloc(res->res->count_encoders,
sizeof(*res->encoders));
+ res->connectors = calloc(res->res->count_connectors,
sizeof(*res->connectors));
+ res->fbs = calloc(res->res->count_fbs, sizeof(*res->fbs));
if (!res->crtcs || !res->encoders || !res->connectors || !res->fbs)
goto error;
- memset(res->crtcs , 0, res->res->count_crtcs * sizeof *res->crtcs);
- memset(res->encoders, 0, res->res->count_encoders * sizeof
*res->encoders);
- memset(res->connectors, 0, res->res->count_connectors * sizeof
*res->connectors);
- memset(res->fbs, 0, res->res->count_fbs * sizeof *res->fbs);
-
#define get_resource(_res, __res, type, Type)
\
do {
\
int i;
\
@@ -623,8 +616,8 @@ static struct resources *get_resources(struct device *dev)
strerror(errno));
\
continue;
\
}
\
- obj->props_info = malloc(obj->props->count_props *
\
-sizeof *obj->props_info);
\
+ obj->props_info = calloc(obj->props->count_props,
\
+sizeof(*obj->props_info));
\
if (!obj->props_info)
\
continue;
\
for (j = 0; j < obj->props->count_props; ++j)
\
@@ -646,12 +639,10 @@ static struct resources *get_resources(struct device *dev)
return res;
}
- res->planes = malloc(res->plane_res->count_planes * sizeof
*res->planes);
+ res->planes = calloc(res->plane_res->count_planes,
sizeof(*res->planes));
if (!res->planes)
goto error;
- memset(res->planes, 0, res->plane_res->count_planes * sizeof
*res->planes);
-
get_resource(res, plane_res, plane, Plane);
get_properties(res, plane_res, plane, PLANE);
@@ -1313,7 +1304,7 @@ static int parse_connector(struct pipe_arg *pipe, const
char *arg)
pipe->num_cons++;
}
- pipe->con_ids = malloc(pipe->num_cons * sizeof *pipe->con_ids);
+ pipe->con_ids = calloc(pipe->num_cons, sizeof(*pipe->con_ids));
if (pipe->con_ids == NULL)
return -1;
--
2.3.5
[PATCH libdrm 1/3] modetest: explicitly zero the newly allocated memory
Signed-off-by: Emil Velikov
---
tests/modetest/modetest.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 7f0c1cc..e4a8bbc 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1368,8 +1368,6 @@ static int parse_plane(struct plane_arg *plane, const
char *p)
{
char *end;
- memset(plane, 0, sizeof *plane);
-
plane->crtc_id = strtoul(p, , 10);
if (*end != ':')
return -EINVAL;
@@ -1541,11 +1539,11 @@ int main(int argc, char **argv)
fprintf(stderr, "memory allocation failed\n");
return 1;
}
+ memset(_args[plane_count], 0,
sizeof(*plane_args));
if (parse_plane(_args[plane_count], optarg) < 0)
usage(argv[0]);
- plane_args[plane_count].fb_id = 0;
plane_count++;
break;
case 'p':
@@ -1559,6 +1557,7 @@ int main(int argc, char **argv)
fprintf(stderr, "memory allocation failed\n");
return 1;
}
+ memset(_args[count], 0, sizeof(*pipe_args));
if (parse_connector(_args[count], optarg) < 0)
usage(argv[0]);
@@ -1578,6 +1577,7 @@ int main(int argc, char **argv)
fprintf(stderr, "memory allocation failed\n");
return 1;
}
+ memset(_args[prop_count], 0, sizeof(*prop_args));
if (parse_property(_args[prop_count], optarg) < 0)
usage(argv[0]);
--
2.3.5
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #9 from Aaron Watry --- Note that firefox 37 works fine for me on my CEDAR (Radeon 5400) on r600g on current mesa master. Konqueror 4.14.6 crashes while loading the OpenGL demo. When running konqueror with LIBGL_DEBUG=verbose, I get the following: awatry at ws-awatry:~$ LIBGL_DEBUG=verbose konqueror libGL: OpenDriver: trying /usr/local/lib/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/local/lib/dri/r600_dri.so libGL: OpenDriver: trying /usr/local/lib/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/local/lib/dri/r600_dri.so NOT SANDBOXED Mesa: User error: GL_INVALID_VALUE in glGetActiveAttrib(index) KCrash: Application 'konqueror' crashing... -- 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/20150428/c8a50f01/attachment.html>
[Bug 90194] Fix Valgrind error in drmPrimeHandleToFD
https://bugs.freedesktop.org/show_bug.cgi?id=90194 Guillaume Desmottes changed: What|Removed |Added Attachment #115375|0 |1 is obsolete|| --- Comment #3 from Guillaume Desmottes --- Created attachment 115403 --> https://bugs.freedesktop.org/attachment.cgi?id=115403=edit drmPrime*: initialize output args to 0 Here is a patch for both functions. I agree it's probably a false positive but the fix is simple enough to be worth adding those extra lines and saving people the trouble of debugging those. I'll send the patch to the list as well. -- 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/20150428/a4687cc3/attachment.html>
Build regressions/improvements in v4.1-rc1
cc Chris On Tue, Apr 28, 2015 at 2:24 PM, Rusty Russell wrote: > Geert Uytterhoeven writes: >>> Can't see that one with a simple grep: can you post warning? >> >> /home/kisskb/slave/src/arch/tile/kernel/setup.c: In function >> 'zone_sizes_init': >> /home/kisskb/slave/src/arch/tile/kernel/setup.c:777:3: warning: >> passing argument 2 of 'cpumask_test_cpu' from incompatible pointer >> type [enabled by default] >> /home/kisskb/slave/src/include/linux/cpumask.h:294:19: note: expected >> 'const struct cpumask *' but argument is of type 'struct nodemask_t *' > > Um, I turned the cpu_isset() into cpumask_test_cpu(), but that just > showed this bug up. The tile maintainers need to fix this one. > > Thanks, > Rusty.
Build regressions/improvements in v4.1-rc1
Geert Uytterhoeven writes: > On Mon, Apr 27, 2015 at 11:51 AM, Geert Uytterhoeven > wrote: >> Below is the list of build error/warning regressions/improvements in >> v4.1-rc1[1] compared to v4.0[2]. >> >> Summarized: >> - build errors: +34/-11 >> - build warnings: +135/-163 >> >> As I haven't mastered kup yet, there's no verbose summary at >> http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.1-rc1.summary.gz >> >> Happy fixing! ;-) >> >> Thanks to the linux-next team for providing the build service. >> >> [1] http://kisskb.ellerman.id.au/kisskb/head/8779/ (254 out of 257 configs) >> [2] http://kisskb.ellerman.id.au/kisskb/head/8710/ (254 out of 257 configs) >> >> >> *** ERRORS *** >> >> 34 regressions: > > The quiet days are over... > >> + /home/kisskb/slave/src/arch/mips/cavium-octeon/smp.c: error: passing >> argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier from pointer >> target type [-Werror]: => 242:2 >> + /home/kisskb/slave/src/arch/mips/kernel/process.c: error: passing >> argument 2 of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer >> target type [-Werror]: => 52:2 >> + /home/kisskb/slave/src/arch/mips/kernel/smp.c: error: passing argument 2 >> of 'cpumask_set_cpu' discards 'volatile' qualifier from pointer target type >> [-Werror]: => 149:2, 211:2 >> + /home/kisskb/slave/src/arch/mips/kernel/smp.c: error: passing argument 2 >> of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer target type >> [-Werror]: => 221:2 > > mips/bigsur_defconfig > mips/malta_defconfig > mips/cavium_octeon_defconfig > mips/ip27_defconfig Already fixed in other thread... > and related warnings due to lack of -Werror on > ia64-defconfig That fix is fairly obvious, I'll post separately. > tilegx_defconfig Can't see that one with a simple grep: can you post warning? > m32r/m32700ut.smp_defconfig Will post fix for this too. > cpumask also gives fishy warnings: > > lib/cpumask.c:167:25: warning: the address of 'cpu_all_bits' will > always evaluate as 'true' [-Waddress] > > on sparc (e.g. sparc64/sparc64-allmodconfig) and powerpc (e.g. > powerpc/ppc64_defconfig), which seem to have been reported 6 months > ago... Hmm, this is cpumask_of_node? That's... Oh my, that requires a separate post. > Can we throw some bitcoins at the cpumasks? ;-) I think I should be throwing bitcoins at you, instead! Thanks, Rusty.
[Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions optional.
On Tue, Apr 28, 2015 at 05:52:20AM +, Antoine, Peter wrote:
> Hi,
>
> (replies inline)
>
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Monday, April 27, 2015 6:04 PM
> To: Antoine, Peter
> Cc: intel-gfx at lists.freedesktop.org; airlied at redhat.com; dri-devel at
> lists.freedesktop.org; daniel.vetter at ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions
> optional.
>
> On Thu, Apr 23, 2015 at 03:07:57PM +0100, Peter Antoine wrote:
> > As these functions are only used by one driver and there are security
> > holes in these functions. Make the functions optional.
> >
> > Issue: VIZ-5485
> > Signed-off-by: Peter Antoine
> > ---
> > drivers/gpu/drm/drm_lock.c| 6 ++
> > drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ++-
> > include/drm/drmP.h| 23 ---
> > include/uapi/drm/i915_drm.h | 1 +
> > 5 files changed, 24 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
> > index 94500930..b61d4c7 100644
> > --- a/drivers/gpu/drm/drm_lock.c
> > +++ b/drivers/gpu/drm/drm_lock.c
> > @@ -61,6 +61,9 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
> > struct drm_master *master = file_priv->master;
> > int ret = 0;
> >
> > + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
> > + return -EINVAL;
> > +
> > ++file_priv->lock_count;
> >
> > if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) { @@
> > -153,6 +156,9 @@ int drm_legacy_unlock(struct drm_device *dev, void *data,
> > struct drm_file *file_
> > struct drm_lock *lock = data;
> > struct drm_master *master = file_priv->master;
> >
> > + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
> > + return -EINVAL;
> > +
> > if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
> > DRM_ERROR("Process %d using kernel context %d\n",
> > task_pid_nr(current), lock->context); diff --git
> > a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> > index e44116f..c771ef0 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -163,6 +163,9 @@ static int i915_getparam(struct drm_device *dev, void
> > *data,
> > if (!value)
> > return -ENODEV;
> > break;
> > + case I915_PARAM_HAS_LEGACY_CONTEXT:
> > + value = drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT);
> > + break;
>
> Seems pointless to add a parameter that'll always be false.
>
> There is some history to these changes, the HW_LOCK functions were removed
> previously but causes an issue with the Nouveau drivers. So that the
> functions where put back in. So the parameter has been added to allow for
> that driver to turn the legacy context on as it is needed.
>
> > default:
> > DRM_DEBUG("Unknown parameter %d\n", param->param);
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > index 8763deb..936b423 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -940,7 +940,8 @@ static struct drm_driver driver_stub = {
> > .driver_features =
> > DRIVER_USE_AGP |
> > - DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,
> > + DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER |
> > + DRIVER_KMS_LEGACY_CONTEXT,
>
> Why is this here? AFAICS only the via driver cares about legacy contexts, and
> only dri1 drivers care about the hw lock.
>
> See above.
> >
> > .load = nouveau_drm_load,
> > .unload = nouveau_drm_unload,
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h index
> > 62c40777..367e42f 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -137,17 +137,18 @@ void drm_err(const char *format, ...); /*@{*/
> >
> > /* driver capabilities and requirements mask */
> > -#define DRIVER_USE_AGP 0x1
> > -#define DRIVER_PCI_DMA 0x8
> > -#define DRIVER_SG 0x10
> > -#define DRIVER_HAVE_DMA0x20
> > -#define DRIVER_HAVE_IRQ0x40
> > -#define DRIVER_IRQ_SHARED 0x80
> > -#define DRIVER_GEM 0x1000
> > -#define DRIVER_MODESET 0x2000
> > -#define DRIVER_PRIME 0x4000
> > -#define DRIVER_RENDER 0x8000
> > -#define DRIVER_ATOMIC 0x1
> > +#define DRIVER_USE_AGP 0x1
> > +#define DRIVER_PCI_DMA 0x8
> > +#define DRIVER_SG 0x10
> > +#define DRIVER_HAVE_DMA0x20
> > +#define DRIVER_HAVE_IRQ0x40
> > +#define DRIVER_IRQ_SHARED 0x80
> > +#define DRIVER_GEM 0x1000
> >
[Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions optional.
On Tue, 2015-04-28 at 16:08 +0300, Ville Syrjälä wrote:
> On Tue, Apr 28, 2015 at 11:29:06AM +, Antoine, Peter wrote:
> > > > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h index
> > > > > 62c40777..367e42f 100644
> > > > > --- a/include/drm/drmP.h
> > > > > +++ b/include/drm/drmP.h
> > > > > @@ -137,17 +137,18 @@ void drm_err(const char *format, ...); /*@{*/
> > > > >
> > > > > /* driver capabilities and requirements mask */
> > > > > -#define DRIVER_USE_AGP 0x1
> > > > > -#define DRIVER_PCI_DMA 0x8
> > > > > -#define DRIVER_SG 0x10
> > > > > -#define DRIVER_HAVE_DMA0x20
> > > > > -#define DRIVER_HAVE_IRQ0x40
> > > > > -#define DRIVER_IRQ_SHARED 0x80
> > > > > -#define DRIVER_GEM 0x1000
> > > > > -#define DRIVER_MODESET 0x2000
> > > > > -#define DRIVER_PRIME 0x4000
> > > > > -#define DRIVER_RENDER 0x8000
> > > > > -#define DRIVER_ATOMIC 0x1
> > > > > +#define DRIVER_USE_AGP 0x1
> > > > > +#define DRIVER_PCI_DMA 0x8
> > > > > +#define DRIVER_SG0x10
> > > > > +#define DRIVER_HAVE_DMA 0x20
> > > > > +#define DRIVER_HAVE_IRQ 0x40
> > > > > +#define DRIVER_IRQ_SHARED0x80
> > > > > +#define DRIVER_GEM 0x1000
> > > > > +#define DRIVER_MODESET 0x2000
> > > > > +#define DRIVER_PRIME 0x4000
> > > > > +#define DRIVER_RENDER0x8000
> > > > > +#define DRIVER_ATOMIC0x1
> > > > > +#define DRIVER_KMS_LEGACY_CONTEXT0x2
> > > >
> > > > Why is there KMS in the name?
> > > >
> > > > By suggestion of Daniel.
> > > >
> > > > I was thinking just checking for GEM, but I think there was some
> > > > gem+dri1 userland for i915 at some point in time. ums and dri1 are
> > > > now dead as far as i915 is concerned, so in theory it should be fine.
> > > > But I'm not sure if some other driver might have the same baggage.
> > > >
> > > > Other drivers have the same baggage.
> > > >
> > > > I suppose one option would be to check for MODESET instead. kms+dri1
> > > > doesn't sound like an entirely sane combination to me.
> > > >
> > > > Can't use the MODESET as this was how it was turned off in the previous
> > > > incarnation and was reverted by Dave Airle.
> > >
> > > Reference?
> >
> > From the next commit [5/5] as it is the one that actually turns off the
> > functions that were turned off before.
> >
> > These changes are based on the two patches:
> > commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095
> > Author: Dave Airlie
> >
> > And the commit that the above patch reverts:
> > commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1
> > Author: Daniel Vetter
>
> Looking at ancient libdrm sources makes me think nouveau just used to
> create and destroy the context, but not actually use it for anything.
> So nopping out the ioctls should be good enough AFAICS. Or am I missing
> something?
>
An old version of libdrm that still requires support needs them, it's
the reason that David Airlie reverted the patch that Daniel did to
remove the functions. Do they still need support, I don't know? David
Airlie is on the cc list.
A discussion was had and this was the way that it was suggested it be
done. This seems a good half-way house, the actual security holes that
have been found have been fixed and the functions (that seem to have a
lot more security issues in them) are turned off for the drivers that
don't use them, and if a driver does require them, it will be a one line
change to reintroduce them. Are we carrying code we don't need to
support, probably.
Peter.
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #7 from Andy Furniss --- (In reply to Grigori Goronzy from comment #6) > Created attachment 115401 [details] [review] > Possible fix > > How about this? Not tested yet, I don't have access to a radeon GPU right > now. It doesn't help valley. -- 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/20150428/3a4a8b47/attachment.html>
[PATCH libdrm 3/3] xf86drm: simplify drmMalloc/drmFree
On Tue, Apr 28, 2015 at 10:09 AM, Emil Velikov
wrote:
> Signed-off-by: Emil Velikov
For the series:
Reviewed-by: Alex Deucher
> ---
> xf86drm.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index f7c45f8..9cd0b02 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -140,16 +140,12 @@ void *drmGetHashTable(void)
>
> void *drmMalloc(int size)
> {
> -void *pt;
> -if ((pt = malloc(size)))
> - memset(pt, 0, size);
> -return pt;
> +return calloc(1, size);
> }
>
> void drmFree(void *pt)
> {
> -if (pt)
> - free(pt);
> +free(pt);
> }
>
> /**
> --
> 2.3.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions optional.
reply at end.
On Tue, 2015-04-28 at 13:40 +0300, Ville Syrjälä wrote:
> On Tue, Apr 28, 2015 at 05:52:20AM +, Antoine, Peter wrote:
> > Hi,
> >
> > (replies inline)
> >
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > Sent: Monday, April 27, 2015 6:04 PM
> > To: Antoine, Peter
> > Cc: intel-gfx at lists.freedesktop.org; airlied at redhat.com; dri-devel at
> > lists.freedesktop.org; daniel.vetter at ffwll.ch
> > Subject: Re: [Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions
> > optional.
> >
> > On Thu, Apr 23, 2015 at 03:07:57PM +0100, Peter Antoine wrote:
> > > As these functions are only used by one driver and there are security
> > > holes in these functions. Make the functions optional.
> > >
> > > Issue: VIZ-5485
> > > Signed-off-by: Peter Antoine
> > > ---
> > > drivers/gpu/drm/drm_lock.c| 6 ++
> > > drivers/gpu/drm/i915/i915_dma.c | 3 +++
> > > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ++-
> > > include/drm/drmP.h| 23 ---
> > > include/uapi/drm/i915_drm.h | 1 +
> > > 5 files changed, 24 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
> > > index 94500930..b61d4c7 100644
> > > --- a/drivers/gpu/drm/drm_lock.c
> > > +++ b/drivers/gpu/drm/drm_lock.c
> > > @@ -61,6 +61,9 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
> > > struct drm_master *master = file_priv->master;
> > > int ret = 0;
> > >
> > > + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
> > > + return -EINVAL;
> > > +
> > > ++file_priv->lock_count;
> > >
> > > if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) { @@
> > > -153,6 +156,9 @@ int drm_legacy_unlock(struct drm_device *dev, void
> > > *data, struct drm_file *file_
> > > struct drm_lock *lock = data;
> > > struct drm_master *master = file_priv->master;
> > >
> > > + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
> > > + return -EINVAL;
> > > +
> > > if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
> > > DRM_ERROR("Process %d using kernel context %d\n",
> > > task_pid_nr(current), lock->context); diff --git
> > > a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> > > index e44116f..c771ef0 100644
> > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > @@ -163,6 +163,9 @@ static int i915_getparam(struct drm_device *dev, void
> > > *data,
> > > if (!value)
> > > return -ENODEV;
> > > break;
> > > + case I915_PARAM_HAS_LEGACY_CONTEXT:
> > > + value = drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT);
> > > + break;
> >
> > Seems pointless to add a parameter that'll always be false.
> >
> > There is some history to these changes, the HW_LOCK functions were removed
> > previously but causes an issue with the Nouveau drivers. So that the
> > functions where put back in. So the parameter has been added to allow for
> > that driver to turn the legacy context on as it is needed.
> >
> > > default:
> > > DRM_DEBUG("Unknown parameter %d\n", param->param);
> > > return -EINVAL;
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > > index 8763deb..936b423 100644
> > > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > > @@ -940,7 +940,8 @@ static struct drm_driver driver_stub = {
> > > .driver_features =
> > > DRIVER_USE_AGP |
> > > - DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,
> > > + DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER |
> > > + DRIVER_KMS_LEGACY_CONTEXT,
> >
> > Why is this here? AFAICS only the via driver cares about legacy contexts,
> > and only dri1 drivers care about the hw lock.
> >
> > See above.
> > >
> > > .load = nouveau_drm_load,
> > > .unload = nouveau_drm_unload,
> > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h index
> > > 62c40777..367e42f 100644
> > > --- a/include/drm/drmP.h
> > > +++ b/include/drm/drmP.h
> > > @@ -137,17 +137,18 @@ void drm_err(const char *format, ...); /*@{*/
> > >
> > > /* driver capabilities and requirements mask */
> > > -#define DRIVER_USE_AGP 0x1
> > > -#define DRIVER_PCI_DMA 0x8
> > > -#define DRIVER_SG 0x10
> > > -#define DRIVER_HAVE_DMA0x20
> > > -#define DRIVER_HAVE_IRQ0x40
> > > -#define DRIVER_IRQ_SHARED 0x80
> > > -#define DRIVER_GEM 0x1000
> > > -#define DRIVER_MODESET 0x2000
> > > -#define DRIVER_PRIME 0x4000
> > > -#define DRIVER_RENDER 0x8000
> > > -#define DRIVER_ATOMIC 0x1
> > > +#define DRIVER_USE_AGP 0x1
> > > +#define DRIVER_PCI_DMA 0x8
> > >
[Bug 90194] Fix Valgrind error in drmPrimeHandleToFD
https://bugs.freedesktop.org/show_bug.cgi?id=90194 --- Comment #2 from Emil Velikov --- Hi Guillaume With args.fd used for output this seems like a false positive. Alternative solution would be to make Valgrind aware of this. A similar issue exists for args.handle in drmPrimeFDToHandle. I fear that not many people keep track of bugzilla, so please forward your patch to the dri-devel mailing list [1]. Thanks Emil [1] dri-devel at lists.freedesktop.org -- 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/20150428/b8610ab6/attachment.html>
[PATCH 1/2] amdgpu: cleanup public interface
On Tue, Apr 28, 2015 at 9:41 AM, Marek Olšák wrote: > Hi Alex, > > He sent them to me. I've applied them to my tree: > > http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu I've pushed them to my mesa tree as well. Alex > > Marek > > On Fri, Apr 24, 2015 at 5:38 PM, Alex Deucher > wrote: >> On Thu, Apr 23, 2015 at 11:53 AM, Christian König >> wrote: >>> From: Christian König >>> >>> Remove the mostly unused device parameter, for the few cases >>> where we really need it keep a copy in the context structure. >> >> Are you going to send out the mesa patches as well? >> >> Alex >> >>> >>> Signed-off-by: Christian König >>> Reviewed-by: Jammy Zhou >>> Reviewed-by: Alex Deucher >>> --- >>> amdgpu/amdgpu.h| 24 +++--- >>> amdgpu/amdgpu_cs.c | 115 >>> +++-- >>> amdgpu/amdgpu_internal.h | 2 + >>> tests/amdgpu/basic_tests.c | 33 +++-- >>> tests/amdgpu/cs_tests.c| 14 +++--- >>> 5 files changed, 78 insertions(+), 110 deletions(-) >>> >>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h >>> index 90dc33c..7a85982 100644 >>> --- a/amdgpu/amdgpu.h >>> +++ b/amdgpu/amdgpu.h >>> @@ -882,7 +882,6 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev, >>> * >>> * Destroy GPU execution context when not needed any more >>> * >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>> * \param context - \c [in] GPU Context handle >>> * >>> * \return 0 on success\n >>> @@ -892,13 +891,11 @@ int amdgpu_cs_ctx_create(amdgpu_device_handle dev, >>> * \sa amdgpu_cs_ctx_create() >>> * >>> */ >>> -int amdgpu_cs_ctx_free(amdgpu_device_handle dev, >>> - amdgpu_context_handle context); >>> +int amdgpu_cs_ctx_free(amdgpu_context_handle context); >>> >>> /** >>> * Query reset state for the specific GPU Context >>> * >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>> * \param context - \c [in] GPU Context handle >>> * \param state - \c [out] Reset state status >>> * >>> @@ -909,8 +906,7 @@ int amdgpu_cs_ctx_free(amdgpu_device_handle dev, >>> * \sa amdgpu_cs_ctx_create() >>> * >>> */ >>> -int amdgpu_cs_query_reset_state(amdgpu_device_handle dev, >>> - amdgpu_context_handle context, >>> +int amdgpu_cs_query_reset_state(amdgpu_context_handle context, >>> enum amdgpu_cs_ctx_reset_state *state); >>> >>> >>> @@ -924,7 +920,6 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle >>> dev, >>> * Allocate memory to be filled with PM4 packets and be served as the first >>> * entry point of execution (a.k.a. Indirect Buffer) >>> * >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>> * \param context - \c [in] GPU Context which will use IB >>> * \param ib_size - \c [in] Size of allocation >>> * \param output - \c [out] Pointer to structure to get information >>> about >>> @@ -937,8 +932,7 @@ int amdgpu_cs_query_reset_state(amdgpu_device_handle >>> dev, >>> * \sa amdgpu_cs_free_ib() >>> * >>> */ >>> -int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >>> - amdgpu_context_handle context, >>> +int amdgpu_cs_alloc_ib(amdgpu_context_handle context, >>>enum amdgpu_cs_ib_size ib_size, >>>struct amdgpu_cs_ib_alloc_result *output); >>> >>> @@ -946,8 +940,6 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >>> * If UMD has allocates IBs which doesnât need any more than those IBs >>> must >>> * be explicitly freed >>> * >>> - * \param dev- \c [in] Device handle. See >>> #amdgpu_device_initialize() >>> - * \param context - \c [in] GPU Context containing IB >>> * \param handle - \c [in] IB handle >>> * >>> * \return 0 on success\n >>> @@ -960,9 +952,7 @@ int amdgpu_cs_alloc_ib(amdgpu_device_handle dev, >>> * \sa amdgpu_cs_alloc_ib() >>> * >>> */ >>> -int amdgpu_cs_free_ib(amdgpu_device_handle dev, >>> - amdgpu_context_handle context, >>> - amdgpu_ib_handle handle); >>> +int amdgpu_cs_free_ib(amdgpu_ib_handle handle); >>> >>> /** >>> * Send request to submit command buffers to hardware. >>> @@ -1011,8 +1001,7 @@ int amdgpu_cs_free_ib(amdgpu_device_handle dev, >>> * amdgpu_cs_query_fence_status() >>> * >>> */ >>> -int amdgpu_cs_submit(amdgpu_device_handle dev, >>> -amdgpu_context_handle context, >>> +int amdgpu_cs_submit(amdgpu_context_handle context, >>> uint64_t flags, >>> struct amdgpu_cs_request *ibs_request, >>> uint32_t number_of_requests, >>> @@ -1038,8 +1027,7 @@ int amdgpu_cs_submit(amdgpu_device_handle dev, >>> * >>> * \sa amdgpu_cs_submit() >>> */ >>> -int amdgpu_cs_query_fence_status(amdgpu_device_handle dev, >>> -
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #6 from Grigori Goronzy --- Created attachment 115401 --> https://bugs.freedesktop.org/attachment.cgi?id=115401=edit Possible fix How about this? Not tested yet, I don't have access to a radeon GPU right 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/20150428/f3dcd0e1/attachment.html>
[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock
On Tue, Apr 28, 2015 at 10:21:49AM +0100, Dave Gordon wrote: > On 24/04/15 06:52, Antoine, Peter wrote: > > I picked up this work due to the following Jira ticket created by the > > security team (on Android) and was asked to give it a second look and > > found a few more issues with the hw lock code. > > > > https://jira01.devtools.intel.com/browse/GMINL-5388 > > I/O control on /dev/dri/card0 crashes the kernel (0x4008642b) > > > > It also stops Linux as it kills the driver, I guess it might be possible > > to reload the gfx driver. On a unpatched system the test that is > > included in the issue or the igt test that has been posted for the issue > > will show the problem. > > > > I ran the test on an unpatched system here and the gui stopped and the > > keyboard stopped responding, so I rebooted. With the patched system I > > did not need to reboot. > > > > Should I change the SIGTERM to SIGSEGV, not quite the same thing but > > tooling is better at handling a segfault than a SIGTERM and the > > application that calls this IOCTL is using an uninitialised hw lock so > > it is kind of the same as differencing an uninitialised pointer (kind > > of). Or, I could just remove it, but the bug has been in the code for at > > least two years (and known about), and I would guess that any code that > > is calling this is fuzzing the IOCTLs (as this is how the security team > > found it) and we should reward them with a application exit. > > > > Peter. > > SIGSEGV would be a better choice. > > SIGTERM is normally sent by a user -- it's the default signal sent by > kill(1). It's also commonly used to tell a long-running daemon process > to tidy up and exit cleanly. > > SIGSEGV commonly means "you accessed something that doesn't exist/isn't > mapped/you don't have permissions for". There are specific subcases that > can be indicated via the siginfo data; this is from the sigaction(1) > manpage: > > The following values can be placed in si_code for a SIGSEGV signal: > > SEGV_MAPERRaddress not mapped to object > > SEGV_ACCERRinvalid permissions for mapped object > > SIGBUS would also be a possibility but that's generally taken to mean > that an access got all the way to some physical bus and then faulted, > whereas SIGSEGV suggests the access was rejected during the > virtual-to-physical mapping process. None of the above. Just return -EINVAL, -EPERM, -EACCESS as appropriate. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #37 from Christian König --- Created attachment 115398 --> https://bugs.freedesktop.org/attachment.cgi?id=115398=edit Something to test Just an idea I had recently what this issue could be. Please test the attached patch and see if it works or not. -- 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/20150428/d7baa535/attachment-0001.html>
[Intel-gfx] [PATCH i-g-t] tests/drm_hw_lock: Tests for hw_lock fixes.
On Tue, Apr 28, 2015 at 09:28:51AM +, Antoine, Peter wrote: > Also, the PARAM should give legitimate code the opportunity to avoid the > problems but avoiding these features completely. There are no legitimate users. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 2/2] Fix one warning (v2)
On Mon, 2015-04-27 at 10:29 +0800, Jammy Zhou wrote:
> xf86drm.c:356:2: warning: comparison of unsigned expression >= 0 is always
> true [-Wtype-limits]
> group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> ^
>
> v2: do 'int' cast to fix the warning
>
> Signed-off-by: Jammy Zhou
FWIW
Reviewed-by: Jan Vesely
Emil, are you OK with this approach?
> ---
> xf86drm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 4d67861..4ecb24f 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -353,7 +353,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
> }
>
> if (drm_server_info) {
> - group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> + group = ((int)serv_group >= 0) ? serv_group : DRM_DEV_GID;
> chown_check_return(buf, user, group);
> chmod(buf, devmode);
> }
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/4a23ab1a/attachment-0001.sig>
[PATCH] tile: properly use node_isset() on a nodemask_t
The code accidentally used cpu_isset() previously in one place
(though properly node_isset() elsewhere).
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 6873f006f7d0..d366675e4bf8 100644
--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -774,7 +774,7 @@ static void __init zone_sizes_init(void)
* though, there'll be no lowmem, so we just alloc_bootmem
* the memmap. There will be no percpu memory either.
*/
- if (i != 0 && cpumask_test_cpu(i, )) {
+ if (i != 0 && node_isset(i, isolnodes)) {
node_memmap_pfn[i] =
alloc_bootmem_pfn(0, memmap_size, 0);
BUG_ON(node_percpu[i] != 0);
--
2.1.2
[PATCH 2/2] Fix one warning
On Mon, 2015-04-27 at 01:40 +, Zhou, Jammy wrote:
> Thanks for sharing the background. For [0], you mentioned that
> get_perms may return -1 in some cases for the group, can you help
> indicate which case it is?
The one i found is in xserver:
dri_drm_get_perms (hw/xfree86/dri/dri.c:759) copies values from
xf86ConfigDRI.
xf86configDRI is initialized in
configDRI(hw/xfree86/common/xf86Config.c:2166).
However, the default value if the DRI section is not present or does not
contain group setting is -1.
it looks like it relies on libdrm to fall back to default in that case,
and it looks like that path currently broken
I don't claim to fully understand what that old code is doing/supposed
to do, but scanning through it suggests that negative values are legal
way to report errors/undefined values.
there might be other users as well
jan
>
> Since the drmSetServerInfo is seldom used, maybe we can just do the
> 'int' cast at this moment. I will send v2 for this.
>
> Regards,
> Jammy
>
> -Original Message-
> From: Jan Vesely [mailto:jv356 at scarletmail.rutgers.edu] On Behalf Of Jan
> Vesely
> Sent: Friday, April 24, 2015 10:30 PM
> To: Zhou, Jammy
> Cc: dri-devel at lists.freedesktop.org; Min, Frank
> Subject: Re: [PATCH 2/2] Fix one warning
>
> On Fri, 2015-04-24 at 11:44 +0800, Jammy Zhou wrote:
> > xf86drm.c:356:2: warning: comparison of unsigned expression >= 0 is always
> > true [-Wtype-limits]
> > group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> > ^
> >
> > Signed-off-by: Jammy Zhou
> > ---
> > xf86drm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xf86drm.c b/xf86drm.c
> > index 4d67861..fbda2aa 100644
> > --- a/xf86drm.c
> > +++ b/xf86drm.c
> > @@ -353,7 +353,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
> > }
> >
> > if (drm_server_info) {
> > - group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> > + group = serv_group;
>
> I don't think this change is correct. get_perms can return errors as negative
> values. I found that xserver does, see [0] for my take on fixing this, as
> well as Emil's response [1].
>
> I think changing the condition to:
> ((int)serv_group >= 0)
>
> should be ok(I don't think there are systems with GID_MAX greater than
> 2^31-1), but I never bothered sending v2.
>
> jan
>
>
> [0]http://lists.freedesktop.org/archives/dri-devel/2015-February/077276.html
> [1]http://lists.freedesktop.org/archives/dri-devel/2015-February/078171.html
>
>
>
> > chown_check_return(buf, user, group);
> > chmod(buf, devmode);
> > }
>
>
> --
> Jan Vesely
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/7fae4206/attachment.sig>
[PATCH v2] drm: fix a memleak on mutex failure path
On Mon, 27 Apr 2015, green at linuxhacker.ru wrote:
> From: Oleg Drokin
>
> Need to free just allocated ctx allocation if we cannot
> get our config mutex.
>
> This one has been flagged by kbuild bot all the way back in August,
> but somehow nobody picked it up:
> https://lists.01.org/pipermail/kbuild/2014-August/001691.html
>
> In addition there is another failure path that leaks the same
> ctx reference that is fixed.
>
> Found with smatch.
>
> Signed-off-by: Oleg Drokin
> CC: Daniel Vetter
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 51cc47d..c0a5cd8 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -80,8 +80,10 @@ int __drm_modeset_lock_all(struct drm_device *dev,
> return -ENOMEM;
>
> if (trylock) {
> - if (!mutex_trylock(>mutex))
> - return -EBUSY;
> + if (!mutex_trylock(>mutex)) {
> + ret = -EBUSY;
> + goto out;
> + }
> } else {
> mutex_lock(>mutex);
> }
> @@ -114,6 +116,8 @@ fail:
> goto retry;
> }
>
> +out:
> + kfree(ctx);
> return ret;
> }
> EXPORT_SYMBOL(__drm_modeset_lock_all);
> --
> 2.1.0
>
--
Jani Nikula, Intel Open Source Technology Center
[Intel-gfx] [PATCH 1/5] drm: Kernel Crash in drm_unlock
On 24/04/15 06:52, Antoine, Peter wrote: > I picked up this work due to the following Jira ticket created by the > security team (on Android) and was asked to give it a second look and > found a few more issues with the hw lock code. > > https://jira01.devtools.intel.com/browse/GMINL-5388 > I/O control on /dev/dri/card0 crashes the kernel (0x4008642b) > > It also stops Linux as it kills the driver, I guess it might be possible > to reload the gfx driver. On a unpatched system the test that is > included in the issue or the igt test that has been posted for the issue > will show the problem. > > I ran the test on an unpatched system here and the gui stopped and the > keyboard stopped responding, so I rebooted. With the patched system I > did not need to reboot. > > Should I change the SIGTERM to SIGSEGV, not quite the same thing but > tooling is better at handling a segfault than a SIGTERM and the > application that calls this IOCTL is using an uninitialised hw lock so > it is kind of the same as differencing an uninitialised pointer (kind > of). Or, I could just remove it, but the bug has been in the code for at > least two years (and known about), and I would guess that any code that > is calling this is fuzzing the IOCTLs (as this is how the security team > found it) and we should reward them with a application exit. > > Peter. SIGSEGV would be a better choice. SIGTERM is normally sent by a user -- it's the default signal sent by kill(1). It's also commonly used to tell a long-running daemon process to tidy up and exit cleanly. SIGSEGV commonly means "you accessed something that doesn't exist/isn't mapped/you don't have permissions for". There are specific subcases that can be indicated via the siginfo data; this is from the sigaction(1) manpage: The following values can be placed in si_code for a SIGSEGV signal: SEGV_MAPERRaddress not mapped to object SEGV_ACCERRinvalid permissions for mapped object SIGBUS would also be a possibility but that's generally taken to mean that an access got all the way to some physical bus and then faulted, whereas SIGSEGV suggests the access was rejected during the virtual-to-physical mapping process. .Dave.
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #8 from Tapani Pälli --- I cannot reproduce this bug. I used following page to verify that Konqueror runs against my Mesa: http://renderingpipeline.com/webgl-extension-viewer/ "WebGL version: WebGL 1.0 (3.0 Mesa 10.6.0-devel (git-9143940))" webgl-water and other webgl tests run fine, Konqueror version information: konqueror-14.12.3-1.fc21.x86_64 kwebkitpart-1.3.4-5.fc21.x86_64 this is on Ivybridge laptop, i965 driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/3a4b41a3/attachment.html>
[Intel-gfx] [PATCH i-g-t] tests/drm_hw_lock: Tests for hw_lock fixes.
On Mon, 2015-04-27 at 16:33 +0100, Chris Wilson wrote:
> On Mon, Apr 27, 2015 at 04:24:37PM +0100, Thomas Wood wrote:
> > On 23 April 2015 at 15:07, Peter Antoine wrote:
> > > There are several issues with the hardware locks functions that stretch
> > > from kernel crashes to priority escalations. This new test will test the
> > > the fixes for these features.
> > >
> > > This test will cause a driver/kernel crash on un-patched kernels, the
> > > following patches should be applied to stop the crashes:
> > >
> > > drm: Kernel Crash in drm_unlock
> > > drm: Fixes unsafe deference in locks.
> > >
> > > Issue: VIZ-5485
> > > Signed-off-by: Peter Antoine
> > > ---
> > > lib/ioctl_wrappers.c | 19 +
> > > lib/ioctl_wrappers.h | 1 +
> > > tests/Makefile.sources | 1 +
> > > tests/drm_hw_lock.c| 207
> > > +
> > > 4 files changed, 228 insertions(+)
> > > create mode 100644 tests/drm_hw_lock.c
> > >
> > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> > > index 000d394..ad8b3d3 100644
> > > --- a/lib/ioctl_wrappers.c
> > > +++ b/lib/ioctl_wrappers.c
> > > @@ -964,6 +964,25 @@ bool gem_has_bsd2(int fd)
> > > {
> > > return gem_has_enable_ring(fd,LOCAL_I915_PARAM_HAS_BSD2);
> > > }
> > > +#define I915_PARAM_HAS_LEGACY_CONTEXT 35
> >
> >
> > Please add some API documentation for this new function here.
> >
> > > +bool drm_has_legacy_context(int fd)
> > > +{
> > > + int tmp = 0;
> > > + drm_i915_getparam_t gp;
> > > +
> > > + memset(, 0, sizeof(gp));
> > > + gp.value =
> > > + gp.param = I915_PARAM_HAS_LEGACY_CONTEXT;
> > > +
> > > + /*
> > > +* if legacy context param is not supported, then it's old and we
> > > +* can assume that the HW_LOCKS are supported.
> > > +*/
> > > + if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ) != 0)
> > > + return true;
>
> Would not a simpler test be to try and legally acquire a hwlock?
> If it fails, hwlocks are not supported. No need for a PARAM.
> -Chris
>
The test relies on the hw_lock not being created (f the HW-LOCKs are
supported). If I grab, then delete the lock I might find more problems
with this code. :)
As you have to be root to create and delete the hwlock the security
issues are minimal as you have root already you don't really need to use
these ioctls to harm the system. So as the exposure is minimal, any more
fixes on code that is legacy and being turned off seems to be a bit of a
time waste.
Also, the PARAM should give legitimate code the opportunity to avoid the
problems but avoiding these features completely.
Peter.
Build regressions/improvements in v4.1-rc1
On Tue, Apr 28, 2015 at 6:39 AM, Rusty Russell wrote:
>>> + /home/kisskb/slave/src/arch/mips/cavium-octeon/smp.c: error: passing
>>> argument 2 of 'cpumask_clear_cpu' discards 'volatile' qualifier from
>>> pointer target type [-Werror]: => 242:2
>>> + /home/kisskb/slave/src/arch/mips/kernel/process.c: error: passing
>>> argument 2 of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer
>>> target type [-Werror]: => 52:2
>>> + /home/kisskb/slave/src/arch/mips/kernel/smp.c: error: passing argument
>>> 2 of 'cpumask_set_cpu' discards 'volatile' qualifier from pointer target
>>> type [-Werror]: => 149:2, 211:2
>>> + /home/kisskb/slave/src/arch/mips/kernel/smp.c: error: passing argument
>>> 2 of 'cpumask_test_cpu' discards 'volatile' qualifier from pointer target
>>> type [-Werror]: => 221:2
> and related warnings due to lack of -Werror on
>> tilegx_defconfig
>
> Can't see that one with a simple grep: can you post warning?
/home/kisskb/slave/src/arch/tile/kernel/setup.c: In function 'zone_sizes_init':
/home/kisskb/slave/src/arch/tile/kernel/setup.c:777:3: warning:
passing argument 2 of 'cpumask_test_cpu' from incompatible pointer
type [enabled by default]
/home/kisskb/slave/src/include/linux/cpumask.h:294:19: note: expected
'const struct cpumask *' but argument is of type 'struct nodemask_t *'
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v10 0/9] ASoC: tda998x: add a codec to the HDMI transmitter
On Mon, 27 Apr 2015 20:25:02 +0200 Jean-Francois Moine wrote: > Using i2s and s/pdif at the same time with the simple card asks for a > patch as the one I submitted in february 2014 (ASoC: simple-card: DT > fix and multi DAI links extension). Sorry, the patch was "ASoC: simple-card: Add multi-CODEC support" submitted in january 2015: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/085855.html -- Ken ar c'hentañ| ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[Bug 90182] [radeonsi]Qt Applications won't start on the dedicated GPU (SIGABRT)
https://bugs.freedesktop.org/show_bug.cgi?id=90182 --- Comment #15 from Paul --- Created attachment 115392 --> https://bugs.freedesktop.org/attachment.cgi?id=115392=edit Xorg.0.log after command execution This is my Xorg.log after I executed LANG=C R600_DEBUG=cs DRI_PRIME=1 QSG_INFO=1 gdb '/home/paul/hybrid test/build-openglunderqml-Desktop-Debug/openglunderqml' -- 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/20150428/83a76ffa/attachment.html>
[Intel-gfx] [PATCH i-g-t] tests/drm_hw_lock: Tests for hw_lock fixes.
Thanks for the review, new patch inbound.
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Monday, April 27, 2015 4:25 PM
To: Antoine, Peter
Cc: Intel Graphics Development; airlied at redhat.com; dri-devel at
lists.freedesktop.org; Daniel Vetter
Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/drm_hw_lock: Tests for hw_lock
fixes.
On 23 April 2015 at 15:07, Peter Antoine wrote:
> There are several issues with the hardware locks functions that
> stretch from kernel crashes to priority escalations. This new test
> will test the the fixes for these features.
>
> This test will cause a driver/kernel crash on un-patched kernels, the
> following patches should be applied to stop the crashes:
>
> drm: Kernel Crash in drm_unlock
> drm: Fixes unsafe deference in locks.
>
> Issue: VIZ-5485
> Signed-off-by: Peter Antoine
> ---
> lib/ioctl_wrappers.c | 19 +
> lib/ioctl_wrappers.h | 1 +
> tests/Makefile.sources | 1 +
> tests/drm_hw_lock.c| 207
> +
> 4 files changed, 228 insertions(+)
> create mode 100644 tests/drm_hw_lock.c
>
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c index
> 000d394..ad8b3d3 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -964,6 +964,25 @@ bool gem_has_bsd2(int fd) {
> return gem_has_enable_ring(fd,LOCAL_I915_PARAM_HAS_BSD2);
> }
> +#define I915_PARAM_HAS_LEGACY_CONTEXT 35
Please add some API documentation for this new function here.
> +bool drm_has_legacy_context(int fd)
> +{
> + int tmp = 0;
> + drm_i915_getparam_t gp;
> +
> + memset(, 0, sizeof(gp));
> + gp.value =
> + gp.param = I915_PARAM_HAS_LEGACY_CONTEXT;
> +
> + /*
> +* if legacy context param is not supported, then it's old and we
> +* can assume that the HW_LOCKS are supported.
> +*/
> + if (drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, ) != 0)
> + return true;
> +
> + return tmp == 1;
> +}
> /**
> * gem_available_aperture_size:
> * @fd: open i915 drm file descriptor diff --git
> a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h index ced7ef3..3adc700
> 100644
> --- a/lib/ioctl_wrappers.h
> +++ b/lib/ioctl_wrappers.h
> @@ -120,6 +120,7 @@ bool gem_has_bsd(int fd); bool gem_has_blt(int
> fd); bool gem_has_vebox(int fd); bool gem_has_bsd2(int fd);
> +bool drm_has_legacy_context(int fd);
> bool gem_uses_aliasing_ppgtt(int fd); int gem_available_fences(int
> fd); uint64_t gem_available_aperture_size(int fd); diff --git
> a/tests/Makefile.sources b/tests/Makefile.sources index
> 71de6de..2f69afc 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -84,6 +84,7 @@ TESTS_progs_M = \
> pm_sseu \
> prime_self_import \
> template \
> + drm_hw_lock \
Please also add the binary name to .gitignore.
> $(NULL)
>
> TESTS_progs = \
> diff --git a/tests/drm_hw_lock.c b/tests/drm_hw_lock.c new file mode
> 100644 index 000..aad50ba
> --- /dev/null
> +++ b/tests/drm_hw_lock.c
> @@ -0,0 +1,207 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person
> +obtaining a
> + * copy of this software and associated documentation files (the
> +"Software"),
> + * to deal in the Software without restriction, including without
> +limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> +sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> +the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including
> +the next
> + * paragraph) shall be included in all copies or substantial portions
> +of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> +SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
> +OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> +OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Peter Antoine
> + */
> +
> +/*
> + * Testcase: Test the HW_LOCKs for correct support and non-crashing.
This would be a good sentence to use in the IGT_TEST_DESCRIPTION macro, to add
a description for the test.
> + *
> + * This test will check that he hw_locks are only g_supported for
> +drivers that
> + * require that support. If it is not g_supported then the functions
> +all return
> + * the correct error code.
> + *
> + * If g_supported it will check that the functions do not crash when
> +the crash
> + * tests are used, also that one of the tests is a security
[Bug 90056] Unigine Valley regression since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90056 --- Comment #5 from Michel Dänzer --- If this can't be fixed soon, maybe the bisected change should be reverted for 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/20150428/dce59bd4/attachment-0001.html>
[Bug 90182] [radeonsi]Qt Applications won't start on the dedicated GPU (SIGABRT)
https://bugs.freedesktop.org/show_bug.cgi?id=90182 --- Comment #14 from Michel Dänzer --- Please attach the /var/log/Xorg.0.log file corresponding to the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/4d311495/attachment.html>
[Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions optional.
Hi,
(replies inline)
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Monday, April 27, 2015 6:04 PM
To: Antoine, Peter
Cc: intel-gfx at lists.freedesktop.org; airlied at redhat.com; dri-devel at
lists.freedesktop.org; daniel.vetter at ffwll.ch
Subject: Re: [Intel-gfx] [PATCH 4/5] drm: Make HW_LOCK access functions
optional.
On Thu, Apr 23, 2015 at 03:07:57PM +0100, Peter Antoine wrote:
> As these functions are only used by one driver and there are security
> holes in these functions. Make the functions optional.
>
> Issue: VIZ-5485
> Signed-off-by: Peter Antoine
> ---
> drivers/gpu/drm/drm_lock.c| 6 ++
> drivers/gpu/drm/i915/i915_dma.c | 3 +++
> drivers/gpu/drm/nouveau/nouveau_drm.c | 3 ++-
> include/drm/drmP.h| 23 ---
> include/uapi/drm/i915_drm.h | 1 +
> 5 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
> index 94500930..b61d4c7 100644
> --- a/drivers/gpu/drm/drm_lock.c
> +++ b/drivers/gpu/drm/drm_lock.c
> @@ -61,6 +61,9 @@ int drm_legacy_lock(struct drm_device *dev, void *data,
> struct drm_master *master = file_priv->master;
> int ret = 0;
>
> + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
> + return -EINVAL;
> +
> ++file_priv->lock_count;
>
> if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) { @@
> -153,6 +156,9 @@ int drm_legacy_unlock(struct drm_device *dev, void *data,
> struct drm_file *file_
> struct drm_lock *lock = data;
> struct drm_master *master = file_priv->master;
>
> + if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT))
> + return -EINVAL;
> +
> if (_DRM_LOCKING_CONTEXT(lock->context) == DRM_KERNEL_CONTEXT) {
> DRM_ERROR("Process %d using kernel context %d\n",
> task_pid_nr(current), lock->context); diff --git
> a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index e44116f..c771ef0 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -163,6 +163,9 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
> if (!value)
> return -ENODEV;
> break;
> + case I915_PARAM_HAS_LEGACY_CONTEXT:
> + value = drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT);
> + break;
Seems pointless to add a parameter that'll always be false.
There is some history to these changes, the HW_LOCK functions were removed
previously but causes an issue with the Nouveau drivers. So that the functions
where put back in. So the parameter has been added to allow for that driver to
turn the legacy context on as it is needed.
> default:
> DRM_DEBUG("Unknown parameter %d\n", param->param);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 8763deb..936b423 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -940,7 +940,8 @@ static struct drm_driver driver_stub = {
> .driver_features =
> DRIVER_USE_AGP |
> - DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER,
> + DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_RENDER |
> + DRIVER_KMS_LEGACY_CONTEXT,
Why is this here? AFAICS only the via driver cares about legacy contexts, and
only dri1 drivers care about the hw lock.
See above.
>
> .load = nouveau_drm_load,
> .unload = nouveau_drm_unload,
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h index
> 62c40777..367e42f 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -137,17 +137,18 @@ void drm_err(const char *format, ...); /*@{*/
>
> /* driver capabilities and requirements mask */
> -#define DRIVER_USE_AGP 0x1
> -#define DRIVER_PCI_DMA 0x8
> -#define DRIVER_SG 0x10
> -#define DRIVER_HAVE_DMA0x20
> -#define DRIVER_HAVE_IRQ0x40
> -#define DRIVER_IRQ_SHARED 0x80
> -#define DRIVER_GEM 0x1000
> -#define DRIVER_MODESET 0x2000
> -#define DRIVER_PRIME 0x4000
> -#define DRIVER_RENDER 0x8000
> -#define DRIVER_ATOMIC 0x1
> +#define DRIVER_USE_AGP 0x1
> +#define DRIVER_PCI_DMA 0x8
> +#define DRIVER_SG0x10
> +#define DRIVER_HAVE_DMA 0x20
> +#define DRIVER_HAVE_IRQ 0x40
> +#define DRIVER_IRQ_SHARED0x80
> +#define DRIVER_GEM 0x1000
> +#define DRIVER_MODESET 0x2000
> +#define DRIVER_PRIME 0x4000
> +#define DRIVER_RENDER0x8000
> +#define DRIVER_ATOMIC0x1
> +#define
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #7 from Tapani Pälli --- (In reply to Dieter Nützel from comment #6) > (In reply to Dieter Nützel from comment #5) > > (In reply to Dieter Nützel from comment #4) > > > (In reply to Tapani Pälli from comment #3) > > > > My konqueror does not seems to support webgl (?) is there something > > > > special > > > > I need to do to enable it? > > > > > > Hello Tapani! > > > > [snip] > > > > > Maybe you have to use WebKit not KHTML. > > > http://html5test.com/index.html > > > > It is in since > > > > 11./13.10.2011 > > > > through WebKit. > > kwebkitpart > kwebkitpart-1.3.3-3.1.5.x86_64 Yes, installing this package made it work, demos seem to work for me though .. I will try some more and also investigate possible side-effects caused by my patch. -- 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/20150428/7351cdfe/attachment-0001.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #6 from Dieter Nützel --- (In reply to Dieter Nützel from comment #5) > (In reply to Dieter Nützel from comment #4) > > (In reply to Tapani Pälli from comment #3) > > > My konqueror does not seems to support webgl (?) is there something > > > special > > > I need to do to enable it? > > > > Hello Tapani! > > [snip] > > > Maybe you have to use WebKit not KHTML. > > http://html5test.com/index.html > > It is in since > > 11./13.10.2011 > > through WebKit. kwebkitpart kwebkitpart-1.3.3-3.1.5.x86_64 -- 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/20150428/e7ab2f40/attachment.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #5 from Dieter Nützel --- (In reply to Dieter Nützel from comment #4) > (In reply to Tapani Pälli from comment #3) > > My konqueror does not seems to support webgl (?) is there something special > > I need to do to enable it? > > Hello Tapani! [snip] > Maybe you have to use WebKit not KHTML. > http://html5test.com/index.html It is in since 11./13.10.2011 through WebKit. -- 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/20150428/3a8bd147/attachment.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #4 from Dieter Nützel --- (In reply to Tapani Pälli from comment #3) > My konqueror does not seems to support webgl (?) is there something special > I need to do to enable it? Hello Tapani! My Konqueror 4.14.6 and former versions (on openSUSE x86 and x86-64) support it for some months (years?) out of the box. What's weird that it do NOT run webgl if I go back to repro package Mesa-10.5.4 (from 27 Apr 2015). I can swear it worked with former versions... Have to retest on my poor RV730/x86 system tomorrow. Maybe you have to use WebKit not KHTML. http://html5test.com/index.html -- 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/20150428/780ed7c9/attachment.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #3 from Tapani Pälli --- My konqueror does not seems to support webgl (?) is there something special I need to do to enable it? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150428/e8feda3c/attachment.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #2 from Tapani Pälli --- seems to work with chrome and firefox, will attempt to reproduce with konqueror -- 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/20150428/16496408/attachment.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 Dieter Nützel changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Severity|normal |critical -- 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/20150428/0633520c/attachment.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 --- Comment #1 from Dieter Nützel --- Created attachment 115389 --> https://bugs.freedesktop.org/attachment.cgi?id=115389=edit konqueror-20150428-051127.kcrash.txt -- 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/20150428/a96c4171/attachment-0001.html>
[Bug 90207] [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff)
https://bugs.freedesktop.org/show_bug.cgi?id=90207 Bug ID: 90207 Summary: [r600g, bisected] regression: NI/Turks crash on WebGL Water (most WebGL stuff) Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: Dieter at nuetzel-hh.de QA Contact: dri-devel at lists.freedesktop.org CC: mesa-dev at lists.freedesktop.org Current Mesa git (9143940) crash on WebGL Water demo and most WebGL stuff. http://madebyevan.com/webgl-water/ http://www.ibiblio.org/e-notes/webgl/webgl.htm I've bisected it to: /opt/mesa> git bisect good a563689a408b7a28c710fb0e382272a0d823f38a is the first bad commit commit a563689a408b7a28c710fb0e382272a0d823f38a Author: Tapani Pälli Date: Thu Apr 23 11:13:17 2015 +0300 mesa: refactor active attrib queries for glGetProgramiv Main motivation here is to get rid of iterating IR and encapsulate queries within program resources. No functional changes. Piglit tests calling the modified functionality: - gl-get-active-attrib-returns-all-inputs - glsl-1.50-get-active-attrib-array - getactiveattrib Signed-off-by: Tapani Pälli Reviewed-by: Martin Peres :04 04 8983df05bac6cc3a455b2e5100a2038939e24eaa cd5fa256be39b9b02e9201a9ce6d313c670f2942 M src When I revert 'a563689' all is smooth, 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/20150428/93ad8d9f/attachment.html>
[PATCH 1/2] Add device enumeration interface (v2)
Hi Emil,
This interface is intended for multiple GPU support. For example, we need to
know how many GPU devices are available on the system (and for some specific
vendor) in the client drivers, and then we can select proper devices for
rendering/compute/etc. For current mesa and Xserver implementations, the device
enumeration is done separately. I think it will be helpful if we can have such
kind of function in libdrm core, which can also be leveraged by other new APIs
requiring multi GPU support.
> Any particular reason why "3D controller" (0x32000) is omitted ?
No. For AMD cards, we currently have 0x3 and 0x38000. Is 0x32000 used by
Nvidia cards? If so, I think we should add it as well.
> Using libpciaccess, will give you the number of PCI devices available on the
> system rather than the ones accessible - think about platform devices and/or
> devices without a drm driver.
This interface is just to enumerate the PCIE GPU devices on the system. With
regard to which ones are accessible, we can use drmOpen/drmOpenWithType to
check, and I don't want to have duplicated functionalities for these
interfaces. And for those non-PCIE platform devices (mostly on ARM platforms),
this interface shouldn't be used, and instead the client drivers should handle
it by themselves.
Regards,
Jammy
-Original Message-
From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
Sent: Tuesday, April 28, 2015 3:07 AM
To: Zhou, Jammy; dri-devel at lists.freedesktop.org
Cc: emil.l.velikov at gmail.com; Min, Frank
Subject: Re: [PATCH 1/2] Add device enumeration interface (v2)
Hi Jammy, Frank
As far as I can see you're trying to get a different version of drmGetBusid().
With the DRM_IOCTL_{G,S}ET_UNIQUE ioctl being lovely as it is I do see your
point, but I'm not sure that the current design will be too useful.
Do we have any upcoming users for this new function, can you share a bit about
the usecase ?
On 24/04/15 03:44, Jammy Zhou wrote:
> drmGetDevices interface is added to enumernate GPU devices on the
> system
>
> v2: rebase the code and some improvement for the coding style
>
> Signed-off-by: Frank Min
> Signed-off-by: Jammy Zhou (v2)
> ---
> Makefile.am | 3 ++-
> xf86drm.c | 48
> xf86drm.h | 18 ++
> 3 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am index 42d3d7f..8236ed8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -89,7 +89,8 @@ SUBDIRS = \
> libdrm_la_LTLIBRARIES = libdrm.la
> libdrm_ladir = $(libdir)
> libdrm_la_LDFLAGS = -version-number 2:4:0 -no-undefined
> -libdrm_la_LIBADD = @CLOCK_LIB@
> +libdrm_la_LIBADD = @CLOCK_LIB@ \
> + @PCIACCESS_LIBS@
>
> libdrm_la_CPPFLAGS = -I$(top_srcdir)/include/drm AM_CFLAGS = \ diff
> --git a/xf86drm.c b/xf86drm.c index ffc53b8..4d67861 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -63,6 +63,7 @@
>
> #include "xf86drm.h"
> #include "libdrm.h"
> +#include
>
> #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
> defined(__DragonFly__) #define DRM_MAJOR 145 @@ -2817,3 +2818,50 @@
> char *drmGetRenderDeviceNameFromFd(int fd) {
> return drmGetMinorNameForFD(fd, DRM_NODE_RENDER); }
> +
> +/**
> + * Enumerate the GPU devices on the system
> + *
> + * \param devs device array set to return the device information
> + * (if NULL, the number of device is returned)
> + * \param vendor the vendor ID for GPU devices to list
> + * (optional, if not specified, all GPU devices are returned)
> + *
> + * \return the number of GPU devices
> + */
> +int drmGetDevices(drmDevicePtr devs, uint16_t vendor) {
> + struct pci_device_iterator * iter;
> + struct pci_device * dev;
> + uint32_t count = 0;
> +
> + if (pci_system_init())
> + return -EINVAL;
> +
> + iter = pci_slot_match_iterator_create(NULL);
> + if (!iter)
> + return -EINVAL;
> +
> + while ((dev = pci_device_next(iter))) {
> + if (((dev->device_class == 0x3) ||
> + (dev->device_class == 0x38000)) &&
Any particular reason why "3D controller" (0x32000) is omitted ?
> + ((vendor == 0) || (dev->vendor_id == vendor))){
> + if (devs) {
> + devs[count].domain = dev->domain;
> + devs[count].bus = dev->bus;
> + devs[count].dev = dev->dev;
> + devs[count].func = dev->func;
> + devs[count].vendor_id = dev->vendor_id;
> + devs[count].device_id = dev->device_id;
> + devs[count].subvendor_id = dev->subvendor_id;
> + devs[count].subdevice_id = dev->subdevice_id;
> + devs[count].revision_id = dev->revision;
> + }
> + count++;
> + }
> +
[Bug 90202] Firefox nightly hangs with accelerated layers and latest r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=90202 --- Comment #4 from Michel Dänzer --- Sounds like bug 84252. -- 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/20150428/97ed955c/attachment.html>
[PATCH v3] drm/exynos: mixer: cleanup pixelformat handling
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Then select the mixer pixelformat (pf) in mixer_graph_buffer() based on
the plane's pf (and not bpp).
Also add handling of RGB565 and XRGB1555 to the switch statement and
exit early if the plane has an unsupported pf.
Partially based on 'drm/exynos: enable/disable blend based on pixel
format' by Gustavo Padovan .
v2: Use the shorter MXR_FORMAT as prefix.
v3: Re-add ARGB because of compatibility reasons
(suggested by Joonyoung Shim).
Reviewed-by: Gustavo Padovan
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index fbec750..0474fd3 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -44,6 +44,12 @@
#define MIXER_WIN_NR 3
#define MIXER_DEFAULT_WIN 0
+/* The pixelformats that are natively supported by the mixer. */
+#define MXR_FORMAT_RGB565 4
+#define MXR_FORMAT_ARGB15555
+#define MXR_FORMAT_ARGB6
+#define MXR_FORMAT_ARGB7
+
struct mixer_resources {
int irq;
void __iomem*mixer_regs;
@@ -531,20 +537,27 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
plane = >planes[win];
- #define RGB565 4
- #define ARGB1555 5
- #define ARGB 6
- #define ARGB 7
+ switch (plane->pixel_format) {
+ case DRM_FORMAT_XRGB:
+ fmt = MXR_FORMAT_ARGB;
+ break;
+
+ case DRM_FORMAT_XRGB1555:
+ fmt = MXR_FORMAT_ARGB1555;
+ break;
- switch (plane->bpp) {
- case 16:
- fmt = ARGB;
+ case DRM_FORMAT_RGB565:
+ fmt = MXR_FORMAT_RGB565;
break;
- case 32:
- fmt = ARGB;
+
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ fmt = MXR_FORMAT_ARGB;
break;
+
default:
- fmt = ARGB;
+ DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
+ return;
}
/* check if mixer supports requested scaling setup */
--
2.0.5
[PATCH v2 4/4] drm/exynos: mixer: also allow NV21 for the video processor
All the necessary code is already there, just need to
handle the format in the switch statement.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 970b293..1bcbcfd 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -399,6 +399,9 @@ static void vp_video_buffer(struct mixer_context *ctx, int
win)
case DRM_FORMAT_NV12:
crcb_mode = false;
break;
+ case DRM_FORMAT_NV21:
+ crcb_mode = true;
+ break;
default:
DRM_ERROR("pixel format for vp is wrong [%d].\n",
plane->pixel_format);
--
2.0.5
[PATCH v2 3/4] drm/exynos: mixer: remove buffer count handling in vp_video_buffer()
The video processor (VP) supports four formats: NV12, NV21 and its
tiled variants. All these formats are bi-planar, so the buffer
count in vp_video_buffer() is always 2.
Also properly exit if we're called with an invalid (non-VP) pixelformat.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0474fd3..970b293 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -388,7 +388,6 @@ static void vp_video_buffer(struct mixer_context *ctx, int
win)
struct mixer_resources *res = >mixer_res;
unsigned long flags;
struct exynos_drm_plane *plane;
- unsigned int buf_num = 1;
dma_addr_t luma_addr[2], chroma_addr[2];
bool tiled_mode = false;
bool crcb_mode = false;
@@ -399,27 +398,15 @@ static void vp_video_buffer(struct mixer_context *ctx,
int win)
switch (plane->pixel_format) {
case DRM_FORMAT_NV12:
crcb_mode = false;
- buf_num = 2;
break;
- /* TODO: single buffer format NV12, NV21 */
default:
- /* ignore pixel format at disable time */
- if (!plane->dma_addr[0])
- break;
-
DRM_ERROR("pixel format for vp is wrong [%d].\n",
plane->pixel_format);
return;
}
- if (buf_num == 2) {
- luma_addr[0] = plane->dma_addr[0];
- chroma_addr[0] = plane->dma_addr[1];
- } else {
- luma_addr[0] = plane->dma_addr[0];
- chroma_addr[0] = plane->dma_addr[0]
- + (plane->pitch * plane->fb_height);
- }
+ luma_addr[0] = plane->dma_addr[0];
+ chroma_addr[0] = plane->dma_addr[1];
if (plane->scan_flag & DRM_MODE_FLAG_INTERLACE) {
ctx->interlace = true;
--
2.0.5
[PATCH v2 2/4] drm/exynos: plane: honor buffer offset for dma_addr
Previously we were ignoring the buffer offsets that are
passed through the addfb2 ioctl. This didn't cause any
major issues, since for uni-planar formats (like XRGB)
userspace would most of the time just use offsets[0]=0.
However with NV12 offsets[1] is very likely non-zero.
So properly apply the offsets to our dma addresses.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 13ea334..b1180fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -76,7 +76,7 @@ int exynos_check_plane(struct drm_plane *plane, struct
drm_framebuffer *fb)
return -EFAULT;
}
- exynos_plane->dma_addr[i] = buffer->dma_addr;
+ exynos_plane->dma_addr[i] = buffer->dma_addr + fb->offsets[i];
DRM_DEBUG_KMS("buffer: %d, dma_addr = 0x%lx\n",
i, (unsigned long)exynos_plane->dma_addr[i]);
--
2.0.5
[PATCH v2 1/4] drm/exynos: fb: use drm_format_num_planes to get buffer count
The previous code had some special case handling for the buffer
count in exynos_drm_format_num_buffers().
This code was incorrect though, since this special case doesn't
exist for DRM. It stemmed from the existence of the special NV12M
V4L2 format. NV12 is a bi-planar format (separate planes for luma
and chroma) and V4L2 differentiates between a NV12 buffer where
luma and chroma is contiguous in memory (so no data between
luma/chroma), and a NV12 buffer where luma and chroma have two
explicit memory locations (which is then called NV12M).
This distinction doesn't exist for DRM. A bi-planar format always
explicitly comes with the information about its two planes (even
if these planes should be contiguous).
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 39 +-
1 file changed, 1 insertion(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 929cb03..142eb4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -171,43 +171,6 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return _fb->fb;
}
-static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
-{
- unsigned int cnt = 0;
-
- if (mode_cmd->pixel_format != DRM_FORMAT_NV12)
- return drm_format_num_planes(mode_cmd->pixel_format);
-
- while (cnt != MAX_FB_BUFFER) {
- if (!mode_cmd->handles[cnt])
- break;
- cnt++;
- }
-
- /*
-* check if NV12 or NV12M.
-*
-* NV12
-* handles[0] = base1, offsets[0] = 0
-* handles[1] = base1, offsets[1] = Y_size
-*
-* NV12M
-* handles[0] = base1, offsets[0] = 0
-* handles[1] = base2, offsets[1] = 0
-*/
- if (cnt == 2) {
- /*
-* in case of NV12 format, offsets[1] is not 0 and
-* handles[0] is same as handles[1].
-*/
- if (mode_cmd->offsets[1] &&
- mode_cmd->handles[0] == mode_cmd->handles[1])
- cnt = 1;
- }
-
- return cnt;
-}
-
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -230,7 +193,7 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
drm_helper_mode_fill_fb_struct(_fb->fb, mode_cmd);
exynos_fb->exynos_gem_obj[0] = to_exynos_gem_obj(obj);
- exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+ exynos_fb->buf_cnt = drm_format_num_planes(mode_cmd->pixel_format);
DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
--
2.0.5
