[Bug 90042] Age of Wonders III gpu lockup
https://bugs.freedesktop.org/show_bug.cgi?id=90042 --- Comment #2 from dawide2211 at gmail.com --- I tried to launch the game with R600_DEBUG=nohyperz but it still crashes the gpu so I guess it's not an hyperz issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150418/bab5f89b/attachment.html>
[PATCH 2/5] drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.
Unfortunately, the DRM EDID reading and parsing functions are actually too good
in this case; the header is fixed before the checksum is computed and thus the
test never sees the invalid checksum. This results in a failure to pass the
compliance test.
To correct this issue, when the EDID code detects that the header is invalid,
a flag is set to indicate that the EDID is corrupted. In this case, it sets
edid_corrupt flag and continues with its fix-up code. In the case of a more
seriously damaged header (fixup score less than the threshold) the code does
not generate the checksum but does set the edid_corrupt flag.
V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
- Maintained blank lines / spacing so as to not contaminate the patch
V6:
- Removed extra debug messages
- Added documentation to for the added parameter on drm_edid_block_valid
- Fixed more whitespace issues in check_link_status
- Added a clear of the header_corrupt flag to the end of the test handler
in intel_dp.c
- Changed the usage of the new function prototype in several places to use
NULL where it is not needed by compliance testing
V7:
- Updated to account for long_pulse flag propagation
V8:
- Removed clearing of header_corrupt flag from the test handler in intel_dp.c
- Added clearing of header_corrupt flag in the drm_edid_block_valid function
V9:
- Renamed header_corrupt flag to edid_corrupt to more accurately reflect its
value and purpose
- Updated commit message
V10:
- Updated for versioning and patch swizzle
- Revised the title to more accurately reflect the nature and contents of
the patch
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 30 --
drivers/gpu/drm/drm_edid_load.c | 7 +--
include/drm/drm_crtc.h | 8 +++-
3 files changed, 36 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..69a5a09 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
* @raw_edid: pointer to raw EDID block
* @block: type of block to validate (0 for base, extension otherwise)
* @print_bad_edid: if true, dump bad EDID blocks to the console
+ * @edid_corrupt: if true, the header or checksum is invalid
*
* Validate a base or extension EDID block and optionally dump bad blocks to
* the console.
*
* Return: True if the block is valid, false otherwise.
*/
-bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
+bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
+ bool *edid_corrupt)
{
u8 csum;
struct edid *edid = (struct edid *)raw_edid;
@@ -1060,11 +1062,23 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid)
if (block == 0) {
int score = drm_edid_header_is_valid(raw_edid);
- if (score == 8) ;
- else if (score >= edid_fixup) {
+ if (score == 8) {
+ if (edid_corrupt)
+ *edid_corrupt = 0;
+ } else if (score >= edid_fixup) {
+ /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
+* The corrupt flag needs to be set here otherwise, the
+* fix-up code here will correct the problem, the
+* checksum is correct and the test fails
+*/
+ if (edid_corrupt)
+ *edid_corrupt = 1;
DRM_DEBUG("Fixing EDID header, your hardware may be
failing\n");
memcpy(raw_edid, edid_hea
[PATCH 4/5] drm: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.
The solution is to add the numer of defers to the retry counter when an I2C
DEFER is returned such that another read attempt will be made. This situation
should normally only occur in compliance testing, however, as a worse case
real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C
defers) for a single transaction to complete. The net result is a slightly
slower response to an EDID read that shouldn't significantly impact overall
performance.
V2:
- Added a check on the number of I2C Defers to limit the number
of times that the retries variable will be decremented. This
is to address review feedback regarding possible infinite loops
from misbehaving sink devices.
V3:
- Fixed the limit value to 7 instead of 8 to get the correct retry
count.
- Combined the increment of the defer count into the if-statement
V4:
- Removed i915 tag from subject as the patch is not i915-specific
V5:
- Updated the for-loop to add the number of i2c defers to the retry
counter such that the correct number of retry attempts will be
made
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/drm_dp_helper.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 575172e..80a02a4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -432,7 +432,7 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter
*adapter)
*/
static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg
*msg)
{
- unsigned int retry;
+ unsigned int retry, defer_i2c;
int ret;
/*
@@ -440,7 +440,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
* is required to retry at least seven times upon receiving AUX_DEFER
* before giving up the AUX transaction.
*/
- for (retry = 0; retry < 7; retry++) {
+ for (retry = 0, defer_i2c = 0; retry < (7 + defer_i2c); retry++) {
mutex_lock(&aux->hw_mutex);
ret = aux->transfer(aux, msg);
mutex_unlock(&aux->hw_mutex);
@@ -499,7 +499,13 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
+ /* DP Compliance Test 4.2.2.5 Requirement:
+* Must have at least 7 retries for I2C defers on the
+* transaction to pass this test
+*/
aux->i2c_defer_count++;
+ if (defer_i2c < 7)
+ defer_i2c++;
usleep_range(400, 500);
continue;
--
1.9.1
[PATCH 1/2] MAINTAINERS: add entry for Rockchip drm drivers
Mark Yao looks after the Rockchip drm drivers and should thus also get patches touching these. Signed-off-by: Heiko Stuebner --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7687fc6..7e4d386 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3410,6 +3410,13 @@ F: drivers/gpu/drm/rcar-du/ F: drivers/gpu/drm/shmobile/ F: include/linux/platform_data/shmob_drm.h +DRM DRIVERS FOR ROCKCHIP +M: Mark Yao +L: dri-devel at lists.freedesktop.org +S: Maintained +F: drivers/gpu/drm/rockchip/ +F: Documentation/devicetree/bindings/video/rockchip* + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-media at vger.kernel.org -- 2.1.4
[PATCH 2/2] drm/rockchip: make irq variable signed
platform_get_irq() can return negative error values and we already test for
these. Therefore the variable holding this value should be signed to not
loose error values.
Reported-by: David Binderman
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ccb0ce0..bde1c1e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -104,7 +104,7 @@ struct vop {
/* lock vop irq reg */
spinlock_t irq_lock;
- unsigned int irq;
+ int irq;
/* vop AHP clk */
struct clk *hclk;
--
2.1.4
[PATCH 1/2] drm: rockchip: Don't pass DRM fake offset to dma-api
Am Donnerstag, 16. April 2015, 16:41:51 schrieb Ãrjan Eide: > Set vm_pgoff to 0 after using it to look up the GEM node, before passing > it on rockchip_gem_mmap_buf() where the offset must be from the start of > the buffer. > > Passing in the fake offset currently works because the > dma_mmap_attrs implementation that is used for this device, > arm_iommu_mmap_attrs, ignores the offset completely. > > Signed-off-by: Ãrjan Eide both patches on a rk3288-veyron-pinky Tested-by: Heiko Stuebner Through which tree do you want to take these patches? I guess the rockchip-drm related patch should go through the tree that will take the dma-mapping patch, so you'll probably need an "Ack" from Mark Yao (Cc'ed). Heiko > --- > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c index 7ca8799e..69f01c3 > 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > @@ -94,6 +94,11 @@ int rockchip_gem_mmap(struct file *filp, struct > vm_area_struct *vma) return -EACCES; > } > > + /* Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the > + * whole buffer from the start. > + */ > + vma->vm_pgoff = 0; > + > obj = container_of(node, struct drm_gem_object, vma_node); > ret = rockchip_gem_mmap_buf(obj, vma);
[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)
https://bugs.freedesktop.org/show_bug.cgi?id=89980 --- Comment #10 from falaca at gmail.com --- I wanted to add that I built Mesa 10.1 from git and installed it on Ubuntu 15.04. Along with Xorg 1.17.1 and the latest DDX compiled from git, I can't observe the bug. Is there anything else that I can do to help this along? I tried cloning the master branch and just reverting Marek's commit (the one that I narrowed the bug down to with my git bisect), but of course that didn't work since there is other newer code which now depends on that. I also tried disabling hyperz (since I believe 10.2 turned hyperz on by default), and that had no effect. -- 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/20150418/fbc76a01/attachment.html>
[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)
https://bugs.freedesktop.org/show_bug.cgi?id=89980 --- Comment #11 from Marek Olšák --- (In reply to Michel Dänzer from comment #6) > (In reply to falaca from comment #4) > > 4a5519f1e019dbf1103e4f3abe0a695637a87518 is the first bad commit > > commit 4a5519f1e019dbf1103e4f3abe0a695637a87518 > > Author: Marek Olšák > > Date: Mon Feb 10 01:25:54 2014 +0100 > > > > r600g,radeonsi: set correct initial domain for shared resources > > Weird. Marek, any ideas? Sorry, no. The commit just obtains the initial domain from the kernel, so that it can use it for command submission. The idea of the commit is that the driver shouldn't move imported buffers to a domain that is different from the domain where the buffer was originally created. -- 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/20150418/80596ac5/attachment.html>
access "Display Port Helper Functions" trough userspace
An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150418/e1965988/attachment-0001.html>
