dri-devel March 2014

dri-devel@lists.freedesktop.org

144 participants
926 discussions

[Bug 73911] Color Banding on R600 (7660G + 7670M)
by bugzilla-daemon＠freedesktop.org 11 Mar '14

11 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=73911 --- Comment #18 from Bernhardt Mark <wrgcpp(a)gmail.com> --- I have the same problem on my laptop Samsung NP355V4C with 7660G and 7670M. I have tried 3.13 kernel on Kubuntu 14.04 x86-64 and Debian Wheezy x86-64 (with default debian kernel config from /boot), and this problem was observed in both distributions. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 76009] New: r600_streamout.c:108:6: error: conflicting types for 'r600_set_streamout_targets'
by bugzilla-daemon＠freedesktop.org 11 Mar '14

11 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=76009 Priority: medium Bug ID: 76009 Keywords: regression CC: jfonseca(a)vmware.com, maraeo(a)gmail.com, sroland(a)vmware.com, zackr(a)vmware.com Assignee: dri-devel(a)lists.freedesktop.org Summary: r600_streamout.c:108:6: error: conflicting types for 'r600_set_streamout_targets' Severity: blocker Classification: Unclassified OS: Linux (All) Reporter: vlee(a)freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa mesa: dfa25ea5cd19d5a050a1c94bd7370a2259b9f007 (master 10.2.0-devel) CC r600_streamout.lo r600_streamout.c:108:6: error: conflicting types for 'r600_set_streamout_targets' void r600_set_streamout_targets(struct pipe_context *ctx, ^ In file included from r600_streamout.c:27:0: r600_pipe_common.h:413:6: note: previous declaration of 'r600_set_streamout_targets' was here void r600_set_streamout_targets(struct pipe_context *ctx, ^ dfa25ea5cd19d5a050a1c94bd7370a2259b9f007 is the first bad commit commit dfa25ea5cd19d5a050a1c94bd7370a2259b9f007 Author: Zack Rusin <zackr(a)vmware.com> Date: Thu Mar 6 18:43:44 2014 -0500 gallium: allow setting of the internal stream output offset D3D10 allows setting of the internal offset of a buffer, which is in general only incremented via actual stream output writes. By allowing setting of the internal offset draw_auto is capable of rendering from buffers which have not been actually streamed out to. Our interface didn't allow. This change functionally shouldn't make any difference to OpenGL where instead of an append_bitmask you just get a real array where -1 means append (like in D3D) and 0 means do not append. Signed-off-by: Zack Rusin <zackr(a)vmware.com> Reviewed-by: Roland Scheidegger <sroland(a)vmware.com> Reviewed-by: Jose Fonseca <jfonseca(a)vmware.com> Reviewed-by: Marek Olšák <marek.olsak(a)amd.com> :040000 040000 899aff75fb864562d50d09d1b72b728adfa3c9be c1582db45fac19679419c7bcf4152269b630df36 M src -- You are receiving this mail because: You are the assignee for the bug.

1 1

[PATCH 0/7] drm/msm: what's in store for 3.15
by Rob Clark 10 Mar '14

10 Mar '14

An early look at what I have lined up for 3.15. Main highlights are: * HDMI audio support (sans interface to ALSA which needs to be invented) * Basic GPU power management * Add chip-id param, so userspace can know the GPU patch revision level (which gallium driver needs in a couple places) * Convert over to use new componentised device support and get rid of global pdev ptrs Rob Clark (7): drm/msm: hdmi audio support drm/msm: add hang_debug module param drm/msm: spin helper drm/msm: crank down gpu when inactive drm/msm: add chip-id param drm/msm: use componentised device support drm/msm: validate flags, etc drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 104 +++++++++--- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 65 +++++--- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 16 +- drivers/gpu/drm/msm/hdmi/hdmi.c | 49 ++++-- drivers/gpu/drm/msm/hdmi/hdmi.h | 25 +++ drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 273 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 26 ++- drivers/gpu/drm/msm/msm_drv.c | 160 ++++++++++++++++++- drivers/gpu/drm/msm/msm_drv.h | 4 + drivers/gpu/drm/msm/msm_gem_submit.c | 15 +- drivers/gpu/drm/msm/msm_gpu.c | 85 +++++++++- drivers/gpu/drm/msm/msm_gpu.h | 16 +- include/uapi/drm/msm_drm.h | 12 ++ 14 files changed, 759 insertions(+), 92 deletions(-) create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_audio.c -- 1.8.5.3

2 14

Re: [PATCH 0/9] Doc/DT: DT bindings for various display components
by Tomi Valkeinen 10 Mar '14

10 Mar '14

Hi Rob, On 10/03/14 18:05, Rob Herring wrote: >> Russell's point was that these connector bindings are very generic, i.e. >> they are not for any particular chip from a particular vendor, but for >> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we >> shouldn't define such generic bindings without consulting the whole >> device-tree community (i.e including non-linux users). > > So re-work it to be generic and send it out. DT maintainers would > rarely disagree that something shouldn't be made generic. They (in this series) are already designed to be generic. I should perhaps re-word the question: we are concerned whether these bindings are good for all the users, not just us, and whether there already exists something that overlaps. Afaik, there's nothing overlapping. And I don't see why they wouldn't be good for all users (with the few minor modifications that have been discussed in this thread). But, if I gathered right, Russell would like some kind of ack from someone who might know better than us. So is it enough to have posted these, and gotten acks from the people involved, or should we get acks from DT maintainers also? Is there a way to get the attention of, say, BSD people, or should we just presume they'll follow the list? >> So the question is, is there such a community and a forum to bring up >> this kind of things? If yes, should we bring this up there? If yes, what >> kind of things in general should be brought into the attention of >> non-linux users? > > devicetree list is just that. It is not just for Linux. There is the > newly created devicetree-spec(a)vger.kernel.org which is for more > core/common binding discussion. Ok. >> What I wonder here is that while a thing like DVI connector is, of >> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the >> case still the same: we're defining global bindings for hardware that >> should work for everyone, not only Linux users? > > Defining the connectors in DT is a useful thing although mainly when > you have multiple connectors of the same type. Labels for composite, > SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or > printed label (like front vs. rear connections) seem more useful to > me. My point above was that it feels mentally easier to define bindings for one particular IP block or chip, than defining bindings for a more generic thing like "HDMI connector". But, in the end, I believe they both should go through similar review, and there's no such difference. As for the labels, they can be anything that makes sense for that particular board. It can be "HDMI Front", if such makes sense, or "HDMI-2" if the connector has such physical printed label. Or, say, "Main LCD", "Secondary LCD". It's a free form text that is given to the user. Tomi

2 1

[PATCH] drm/edid: Remove part of the HDTV hack
by Stéphane Marchesin 10 Mar '14

10 Mar '14

The part which turns 1360x765 into 1366x768 breaks this mode on a Toshiba TV here. 1360x765 works fine, though. Reviewed-by: Adam Jackson <ajax(a)redhat.com> Signed-off-by: Stéphane Marchesin <marcheu(a)chromium.org> --- drivers/gpu/drm/drm_edid.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index b924306..7527f48 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1628,8 +1628,7 @@ drm_mode_std(struct drm_connector *connector, struct edid *edid, /* HDTV hack, part 1 */ if (vrefresh_rate == 60 && - ((hsize == 1360 && vsize == 765) || - (hsize == 1368 && vsize == 769))) { + (hsize == 1368 && vsize == 769)) { hsize = 1366; vsize = 768; } -- 1.9.0.279.gdc9e3eb

1 0

[Bug 75433] xserver crashes after suspend with radeonsi and glamor, poor 2d performance
by bugzilla-daemon＠freedesktop.org 10 Mar '14

10 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=75433 --- Comment #5 from blaze <blaze(a)jabster.pl> --- Created attachment 95527 --> https://bugs.freedesktop.org/attachment.cgi?id=95527&action=edit dmesg after the crash -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
by bugzilla-daemon＠freedesktop.org 10 Mar '14

10 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #26 from Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> --- Created attachment 95513 --> https://bugs.freedesktop.org/attachment.cgi?id=95513&action=edit 3.14-rc6 suspend/resume log -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
by bugzilla-daemon＠freedesktop.org 10 Mar '14

10 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #25 from Johan Brannlund <freedesktop-bugs(a)nullinfinity.org> --- The bug is still there with kernel 3.14-rc6 - the display doesn't get enabled on resume. But now the logs (attached) don't contain any obvious failures. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 4/4] Documentation: drm: describing plane alpha and color blending property
by sagar.a.kamble＠intel.com 10 Mar '14

10 Mar '14

From: Sagar Kamble <sagar.a.kamble(a)intel.com> Cc: Rob Landley <rob(a)landley.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Cc: David Herrmann <dh.herrmann(a)gmail.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: "Ville Syrjälä" <ville.syrjala(a)linux.intel.com> Cc: Sagar Kamble <sagar.a.kamble(a)intel.com> Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman(a)intel.com> Cc: linux-doc(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Sagar Kamble <sagar.a.kamble(a)intel.com> --- Documentation/DocBook/drm.tmpl | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 5650d13..ba260e8 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2334,7 +2334,7 @@ void intel_crt_init(struct drm_device *dev) </tr> <tr> <td rowspan="19" valign="top" >DRM</td> -<td rowspan="2" valign="top" >Generic</td> +<td rowspan="3" valign="top" >Generic</td> <td valign="top" >“EDID”</td> <td valign="top" >BLOB | IMMUTABLE</td> <td valign="top" >0</td> @@ -2349,6 +2349,17 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >Contains DPMS operation mode value.</td> </tr> <tr> +<td valign="top" >“blend”</td> +<td valign="top" >BITMASK</td> +<td valign="top" >{ {0, "none"}, {1, "zero"}, {2, "one"}, {3, "src-color"}, {4, "one-minus-src-color"} +, {5, "dst-color"}, {6, "one-minus-dst-color"}, {7, "src-alpha"}, {8, "one-minus-src-alpha"}, {9, "dst-alpha"} +, {10, "one-minus-dst-alpha"}, {11, "constant-color"}, {12, "one-minus-constant-color"}, {13, "constant-alpha"} +, {14, "one-minus-constant-alpha"}, {15, "alpha-saturate"}, {16, "src1-color"}, {17, "one-minus-src1-color"} +, {18, "src1-alpha"}, {19, "one-minus-src1-alpha"}, {20, "pre-multiplied-alpha"} }</td> +<td valign="top" >Plane</td> +<td valign="top" >Contains plane alpha/color blending operation value.</td> +</tr> +<tr> <td rowspan="2" valign="top" >DVI-I</td> <td valign="top" >“subconnector”</td> <td valign="top" >ENUM</td> -- 1.8.5

2 1

[RFC PATCH] drm/dp: let drivers specify the name of the I2C-over-AUX adapter
by Jani Nikula 10 Mar '14

10 Mar '14

Let the drivers specify the name of the I2C-over-AUX adapter to maintain backwards compatibility in the sysfs when converting to the new I2C-over-AUX helper infrastructure. The i915 driver currently uses DPDDC-A to DPDDC-D as names for the DP i2c adapters. These names show up in the i2c sysfs name attribute. We'd like to be able to maintain that when switching over to the new helpers. Due to i2c device and connector cleanup ordering issues we also recently made the drm device (instead of connector) the parent of the i2c adapters: commit 80f65de3c9b8101c1613fa82df500ba6a099a11c Author: Imre Deak <imre.deak(a)intel.com> Date: Tue Feb 11 17:12:49 2014 +0200 drm/i915: dp: fix order of dp aux i2c device cleanup With the name picked up from the adapter parent using dev_name(), it would be the same for all i2c adapters with the current I2C-over-AUX helpers. Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- I am not entirely happy with adding an extra name field, but I also didn't like the caller having to set up aux.ddc.name in advance. Ideas welcome. --- drivers/gpu/drm/drm_dp_helper.c | 3 ++- include/drm/drm_dp_helper.h | 4 ++++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 35251af3b14e..17832d048147 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -726,7 +726,8 @@ int drm_dp_aux_register_i2c_bus(struct drm_dp_aux *aux) aux->ddc.dev.parent = aux->dev; aux->ddc.dev.of_node = aux->dev->of_node; - strncpy(aux->ddc.name, dev_name(aux->dev), sizeof(aux->ddc.name)); + strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev), + sizeof(aux->ddc.name)); return i2c_add_adapter(&aux->ddc); } diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 42947566e755..b4f58914bf7d 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -438,6 +438,9 @@ struct drm_dp_aux_msg { * The .dev field should be set to a pointer to the device that implements * the AUX channel. * + * The .name field may be used to specify the name of the I2C adapter. If set to + * NULL, dev_name() of .dev will be used. + * * Drivers provide a hardware-specific implementation of how transactions * are executed via the .transfer() function. A pointer to a drm_dp_aux_msg * structure describing the transaction is passed into this function. Upon @@ -455,6 +458,7 @@ struct drm_dp_aux_msg { * should call drm_dp_aux_unregister_i2c_bus() to remove the I2C adapter. */ struct drm_dp_aux { + const char *name; struct i2c_adapter ddc; struct device *dev; -- 1.7.9.5

2 2

← Newer
1
...
82
83
84
85
86
87
88
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2014