[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #17 from Hamish Wilson --- (In reply to Michel Dänzer from comment #16) > Can you try a 64-bit kernel? Does it happen with that as well? Booting into the exact same kernel for 64-bit does indeed make the problems go away for me. Gentleman, I think we have a suspect... -- 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/20141028/b5ee59ba/attachment.html>
[Bug 84977] r300/compiler: register allocation pass generate invalid swizzle for r300/r400
https://bugs.freedesktop.org/show_bug.cgi?id=84977 --- Comment #11 from David Heidelberger (okias) --- Created attachment 108592 --> https://bugs.freedesktop.org/attachment.cgi?id=108592&action=edit r300_regalloc-separated_workaround.txt I made separeted workaround with line if (writemask == 12) can_change_writemask = 0; $ diff -Naur r300_regalloc.txt r300_regalloc-separated_workaround.txt --- r300_regalloc.txt 2014-10-28 22:54:13.673516366 +0100 +++ r300_regalloc-separated_workaround.txt 2014-10-28 22:54:05.065450759 +0100 @@ -64,10 +64,10 @@ 25: src0.w = temp[5] LG2 temp[5].w, src0.w 26: src0.xyz = temp[5], src0.w = temp[6], src1.xyz = temp[3] - MAD temp[6].x, src0.y__, src1.x__, -src0.H__ + MAD temp[6].z, src0.__y, src1.__x, -src0.__H MAD temp[6].w, src0.x, src0.w, -src0.H 27: src0.xyz = temp[5], src0.w = temp[5], src1.xyz = temp[6], src1.w = temp[6], src2.xyz = const[4] - MAD temp[3].xy, src0.xy_, src1.wx_, src0.11_ + MAD temp[3].xy, src0.xy_, src1.wz_, src0.11_ MAD temp[5].w, src0.w, src2.x, src0.0 28: src0.xyz = temp[3], src0.w = temp[4] MAD temp[3].x, -src0.x__, src0.1__, src0.y__ -- 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/20141028/071f9b89/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding wrote: > On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote: >> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote: >> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote: > [...] >> >> Hm, if you do this can you pls also update drm_panel accordingly? It >> >> shouldn't be a lot of fuzz and would make things around drm+dt more >> >> consistent. >> > Are you talking about using struct device_node instead of struct device? >> > I guess you have misplaced the comment under the wrong section! >> >> Yeah, that should have been one up ;-) > > Like I said earlier, I don't think dropping struct device * in favour of > struct device_node * is a good idea. I am not sure about drm_panel. But, I am not really doing anything with the struct device pointer in case of bridge. So, just wondering if it is really needed? Ajay
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #190 from Daniel Kozak --- (In reply to agapito from comment #189) > This is strange because 5 days ago i was starting to use intel graphic card > because i had a lot of lock-ups with 3.17.1 and 3.18 rc1 kernels. When 3.18 > rc2 was launched i returned to radeon driver and this bug disappeared under > 3.18 rc2, but now i am using 3.17.1 and it seems stable... Maybe this bug is > a mesa problem, and not a kernel problem. Mesa 10.3.2 arrived to archlinux 3 > days ago. > > Changes from 10.3.1 to 10.3.2: > > Brian Paul (3): > mesa: fix spurious wglGetProcAddress / GL_INVALID_OPERATION error > st/wgl: add WINAPI qualifiers on wgl function typedefs > glsl: fix several use-after-free bugs > > Daniel Manjarres (1): > glx: Fix glxUseXFont for glxWindow and glxPixmaps > > Dave Airlie (1): > mesa: fix GetTexImage for 1D array depth textures > > Emil Velikov (3): > docs: Add sha256 sums for the 10.3.1 release > Update VERSION to 10.3.2 > Add release notes for the 10.3.2 release > > Ilia Mirkin (4): > gm107/ir: add dnz emission for fmul > gk110/ir: add dnz flag emission for fmul/fmad > nouveau: 3d textures are unsupported, limit 3d levels to 1 > st/gbm: fix order of arguments passed to is_format_supported > > Kenneth Graunke (3): > i965: Add a BRW_MOCS_PTE #define. > i965: Use BDW_MOCS_PTE for renderbuffers. > i965: Fix register write checks. > > Marek Olšák (2): > st/mesa: use pipe_sampler_view_release for releasing sampler views > glsl_to_tgsi: fix the value of gl_FrontFacing with native integers > > Michel Dänzer (4): > radeonsi: Clear sampler view flags when binding a buffer > r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers > winsys/radeon: Use separate caching buffer manager for each set of > flags > r600g: Drop references to destroyed blend state I don't think so. I try tio downgrade mesa, linux-firmware and lots of other packages, but even with vdpau vlc, html5 youtube videos or flash videos I am unable to frozen my system again (I really try it hard all day). It must be some HW problem or some wierd HW state or something completly different. -- 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/20141028/5fe07e5a/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #189 from agapito --- This is strange because 5 days ago i was starting to use intel graphic card because i had a lot of lock-ups with 3.17.1 and 3.18 rc1 kernels. When 3.18 rc2 was launched i returned to radeon driver and this bug disappeared under 3.18 rc2, but now i am using 3.17.1 and it seems stable... Maybe this bug is a mesa problem, and not a kernel problem. Mesa 10.3.2 arrived to archlinux 3 days ago. Changes from 10.3.1 to 10.3.2: Brian Paul (3): mesa: fix spurious wglGetProcAddress / GL_INVALID_OPERATION error st/wgl: add WINAPI qualifiers on wgl function typedefs glsl: fix several use-after-free bugs Daniel Manjarres (1): glx: Fix glxUseXFont for glxWindow and glxPixmaps Dave Airlie (1): mesa: fix GetTexImage for 1D array depth textures Emil Velikov (3): docs: Add sha256 sums for the 10.3.1 release Update VERSION to 10.3.2 Add release notes for the 10.3.2 release Ilia Mirkin (4): gm107/ir: add dnz emission for fmul gk110/ir: add dnz flag emission for fmul/fmad nouveau: 3d textures are unsupported, limit 3d levels to 1 st/gbm: fix order of arguments passed to is_format_supported Kenneth Graunke (3): i965: Add a BRW_MOCS_PTE #define. i965: Use BDW_MOCS_PTE for renderbuffers. i965: Fix register write checks. Marek Olšák (2): st/mesa: use pipe_sampler_view_release for releasing sampler views glsl_to_tgsi: fix the value of gl_FrontFacing with native integers Michel Dänzer (4): radeonsi: Clear sampler view flags when binding a buffer r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers winsys/radeon: Use separate caching buffer manager for each set of flags r600g: Drop references to destroyed blend state -- 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/20141028/f33ddebe/attachment.html>
[PATCH 5/5] drm/radeon: Use TTM_PL_FLAG_BOTTOMUP
From: Michel Dänzer
We want to allocate small BOs strictly from the bottom up, just as large
BOs are allocated strictly from the top down.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d23b0dd..d9f7a02 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -180,9 +180,11 @@ void radeon_ttm_placement_from_domain(struct radeon_bo
*rbo, u32 domain)
* 512kb was measured as the most optimal number.
*/
if (rbo->tbo.mem.size > 512 * 1024) {
- for (i = 0; i < c; i++) {
+ for (i = 0; i < c; i++)
rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
- }
+ } else {
+ for (i = 0; i < c; i++)
+ rbo->placements[i].flags |= TTM_PL_FLAG_BOTTOMUP;
}
}
--
2.1.1
[PATCH 4/5] drm/ttm: Add TTM_PL_FLAG_BOTTOMUP
From: Michel Dänzer
For placing a BO strictly from the bottom up, i.e. in the lowest hole which
can hold it.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/ttm/ttm_bo_manager.c | 5 +
include/drm/ttm/ttm_placement.h | 5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index aa0bd05..a64397b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -73,6 +73,11 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
*man,
aflags = DRM_MM_CREATE_TOP;
}
+ if (place->flags & TTM_PL_FLAG_BOTTOMUP) {
+ sflags = DRM_MM_SEARCH_DEFAULT;
+ aflags = DRM_MM_CREATE_DEFAULT;
+ }
+
spin_lock(&rman->lock);
ret = drm_mm_insert_node_in_range_generic(mm, node, mem->num_pages,
mem->page_alignment, 0,
diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
index 8ed44f9..c9ae86a 100644
--- a/include/drm/ttm/ttm_placement.h
+++ b/include/drm/ttm/ttm_placement.h
@@ -66,7 +66,9 @@
* TTM_PL_FLAG_NO_EVICT means that the buffer may never
* be evicted to make room for other buffers.
* TTM_PL_FLAG_TOPDOWN requests to be placed from the
- * top of the memory area, instead of the bottom.
+ * top of the memory area.
+ * TTM_PL_FLAG_BOTTOMUP requests to be placed from the
+ * bottom of the memory area.
*/
#define TTM_PL_FLAG_CACHED (1 << 16)
@@ -75,6 +77,7 @@
#define TTM_PL_FLAG_SHARED (1 << 20)
#define TTM_PL_FLAG_NO_EVICT(1 << 21)
#define TTM_PL_FLAG_TOPDOWN (1 << 22)
+#define TTM_PL_FLAG_BOTTOMUP(1 << 23)
#define TTM_PL_MASK_CACHING (TTM_PL_FLAG_CACHED | \
TTM_PL_FLAG_UNCACHED | \
--
2.1.1
[PATCH 3/5] drm/ttm: Use only DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN
From: Michel Dänzer
DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
against the idea of TTM_PL_FLAG_TOPDOWN:
* The smallest hole may be in the overall bottom of the area
* If the hole isn't much larger than the BO, it doesn't make much
difference whether the BO is placed at the bottom or at the top of the
hole
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 1e93f6c..aa0bd05 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -69,7 +69,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
*man,
return -ENOMEM;
if (place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags |= DRM_MM_SEARCH_BELOW;
+ sflags = DRM_MM_SEARCH_BELOW;
aflags = DRM_MM_CREATE_TOP;
}
--
2.1.1
[PATCH 2/5] drm/ttm: Add DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN
From: Michel Dänzer
If the BO should be placed at the top of the area, we should start looking
for holes from the top.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/ttm/ttm_bo_manager.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 964387f..1e93f6c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -55,6 +55,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
*man,
struct ttm_range_manager *rman = (struct ttm_range_manager *) man->priv;
struct drm_mm *mm = &rman->mm;
struct drm_mm_node *node = NULL;
+ enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
unsigned long lpfn;
int ret;
@@ -67,15 +68,16 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
*man,
if (!node)
return -ENOMEM;
- if (place->flags & TTM_PL_FLAG_TOPDOWN)
+ if (place->flags & TTM_PL_FLAG_TOPDOWN) {
+ sflags |= DRM_MM_SEARCH_BELOW;
aflags = DRM_MM_CREATE_TOP;
+ }
spin_lock(&rman->lock);
ret = drm_mm_insert_node_in_range_generic(mm, node, mem->num_pages,
mem->page_alignment, 0,
place->fpfn, lpfn,
- DRM_MM_SEARCH_BEST,
- aflags);
+ sflags, aflags);
spin_unlock(&rman->lock);
if (unlikely(ret)) {
--
2.1.1
[PATCH 1/5] drm/radeon: Set TTM_PL_FLAG_TOPDOWN also for RADEON_GEM_CPU_ACCESS BOs
From: Michel Dänzer
I wasn't sure if TTM_PL_FLAG_TOPDOWN works correctly with non-0 lpfn, but
AFAICT it does.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_object.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 9c92976..d23b0dd 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -179,9 +179,7 @@ void radeon_ttm_placement_from_domain(struct radeon_bo
*rbo, u32 domain)
* improve fragmentation quality.
* 512kb was measured as the most optimal number.
*/
- if (!((rbo->flags & RADEON_GEM_CPU_ACCESS) &&
- (rbo->placements[i].flags & TTM_PL_FLAG_VRAM)) &&
- rbo->tbo.mem.size > 512 * 1024) {
+ if (rbo->tbo.mem.size > 512 * 1024) {
for (i = 0; i < c; i++) {
rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
}
--
2.1.1
[PATCH] drm/radeon: Clean up radeon_uvd_force_into_uvd_segment
From: Michel Dänzer
It was adding a second placement for the second 256MB segment of VRAM,
which is not a good idea for several reasons:
* It fills up the first 256MB segment (which is also typically the CPU
accessible part) of VRAM first, even for BOs which could go into the
second 256MB segment. Only once there is no space in the first segment
does it fall back to the second segment.
* It doesn't work with RADEON_GEM_NO_CPU_ACCESS BOs, which already use
two VRAM placements.
Change it to instead restrict the range for each VRAM placement. If the
BO can go into the second 256MB segment, set up the range to include
both segments, and set the TTM_PL_FLAG_TOPDOWN flag. That should result
in preferring the second segment for those BOs, falling back to the
first segment.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_uvd.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 11b6624..eca0ea96 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -259,27 +259,26 @@ int radeon_uvd_resume(struct radeon_device *rdev)
void radeon_uvd_force_into_uvd_segment(struct radeon_bo *rbo,
uint32_t allowed_domains)
{
+ unsigned lpfn;
int i;
- for (i = 0; i < rbo->placement.num_placement; ++i) {
- rbo->placements[i].fpfn = 0 >> PAGE_SHIFT;
- rbo->placements[i].lpfn = (256 * 1024 * 1024) >> PAGE_SHIFT;
- }
-
- /* If it must be in VRAM it must be in the first segment as well */
if (allowed_domains == RADEON_GEM_DOMAIN_VRAM)
- return;
+ /* If it must be in VRAM, it must be in the first 256MB segment
*/
+ lpfn = (256 * 1024 * 1024) >> PAGE_SHIFT;
+ else
+ /* Allow second 256MB segment as well */
+ lpfn = (2 * 256 * 1024 * 1024) >> PAGE_SHIFT;
- /* abort if we already have more than one placement */
- if (rbo->placement.num_placement > 1)
- return;
+ for (i = 0; i < rbo->placement.num_placement; ++i) {
+ if (!(rbo->placements[i].flags & TTM_PL_FLAG_VRAM))
+ continue;
- /* add another 256MB segment */
- rbo->placements[1] = rbo->placements[0];
- rbo->placements[1].fpfn += (256 * 1024 * 1024) >> PAGE_SHIFT;
- rbo->placements[1].lpfn += (256 * 1024 * 1024) >> PAGE_SHIFT;
- rbo->placement.num_placement++;
- rbo->placement.num_busy_placement++;
+ if (allowed_domains != RADEON_GEM_DOMAIN_VRAM)
+ rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
+
+ if (!rbo->placements[i].lpfn || rbo->placements[i].lpfn > lpfn)
+ rbo->placements[i].lpfn = lpfn;
+ }
}
void radeon_uvd_free_handles(struct radeon_device *rdev, struct drm_file *filp)
--
2.1.1
[Bug 85564] Dead Island rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=85564 --- Comment #4 from Laurent carlier --- Here is a trace grabbed with apitrace-5.0 with the following commandline "apitrace32 trace %command%" with radeonsi from git: https://drive.google.com/file/d/0B1WCo3k21FK3Y0Fnc0dQZElneDA/view?usp=sharing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/49e1226a/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
>> Hi Daniel and Sean,
>>
>> Thanks for the comments!
>>
>> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
>>> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
So don't ask why but I accidentally ended up in a branch looking at this
patch and didn't like it. So very quick&grumpy review.
First, please make the patch subject more descriptive: I'd expect a helper
function scaffolding like the various crtc/probe/dp ... helpers we already
have. You instead add code to untangle the probe ordering. Please say so.
>> Sure. I will reword it properly.
>>
More comments below.
On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
>
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add".
>
> The parent encoder driver waits till the bridge is available
> in the lookup table(by calling "of_drm_find_bridge") and then
> continues with its initialization.
>
> The encoder driver should also call "drm_bridge_attach" to pass
> on the drm_device, encoder pointers to the bridge object.
>
> drm_bridge_attach inturn calls drm_bridge_init to register itself
> with the drm core. Later, it calls "bridge->funcs->attach" so that
> bridge can continue with other initializations.
>
> Signed-off-by: Ajay Kumar
[snip]
> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> * @driver_private: pointer to the bridge driver's internal context
> */
> struct drm_bridge {
> - struct drm_device *dev;
> + struct device *dev;
Please don't rename the ->dev pointer into drm. Because _all_ the other
drm structures still call it ->dev. Also, can't we use struct device_node
here like we do in the of helpers Russell added? See 7e435aad38083
>>>
>>> I think this is modeled after the naming in drm_panel,
>> Right, The entire rework is based on how drm_panel framework is structured.
>>
>>> FWIW. However,
>>> seems reasonable to keep the device_node instead.
>> Yes, its visible that just device_node would be sufficient.
>> This will save us from renaming drm_device as well.
>>
> + struct drm_device *drm;
> + struct drm_encoder *encoder;
This breaks bridge->bridge chaining (if we ever get there). It seems
pretty much unused anyway except for an EBUSY check. Can't you use
bridge->dev for that?
>>>
>>> Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
>>> and leave it up to the caller to establish the proper chain.
>> Ok. I will use drm_device pointer directly instead of passing encoder
>> pointer.
>
> Hm, if you do this can you pls also update drm_panel accordingly? It
> shouldn't be a lot of fuzz and would make things around drm+dt more
> consistent.
Are you talking about using struct device_node instead of struct device?
I guess you have misplaced the comment under the wrong section!
>>
> struct list_head head;
> + struct list_head list;
These lists need better names. I know that the "head" is really awful,
especially since it's actually not the head of the list but just an
element.
>>>
>>> I think we can just rip bridge_list out of mode_config if we're going
>>> to keep track of bridges elsewhere. So we can nuke "head" and keep
>>> "list". This also means that bridge->destroy() goes away, but that's
>>> probably Ok if everything converts to the standalone driver model
>>> where we have driver->remove()
>>>
>>> Sean
>> Great! Thierry actually mentioned about this once, and we have the
>> confirmation now.
>>
>
> struct drm_mode_object base;
Aside: I've noticed all this trying to update the kerneldoc for struct
drm_bridge, which just showed that this patch makes inconsistent changes.
Trying to write kerneldoc is a really great way to come up with better
interfaces imo.
Cheers, Daniel
>> I din't get this actually. You want me to create Doc../drm_bridge.txt
>> or something similar?
>
> If you want to document drm_bridge then I recomment to sprinkle proper
> kerneldoc over drm_bridge.c and pull it all into the drm DocBook
> template. That way all the drm documentation is in one place. I've
> done that for drm_crtc.h in an unrelated patch series (but based upon
> a branch with your patch here included) and there's struct drm_bridge*
> in there. Hence why I've noticed.
Can you send a link for that?
And, is there any problem if the doc comes later?
Ajay
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #188 from Aaron B --- It's random for a reason, it acts like a buffer over run or leak or something that isn't easily produced, as it changes how often it happens every installed package. But I've had worse luck on 3.18-rc2, it's just my install is more prone to it this build where it seems others haven't crashed yet, but give it time. Make sure you run HTML5 youtube for an hour or so. ;) :) -- 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/20141028/06e9499e/attachment.html>
[Bug 85564] Dead Island rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=85564 --- Comment #3 from Thomas Rohloff --- Created attachment 108578 --> https://bugs.freedesktop.org/attachment.cgi?id=108578&action=edit dmesg > dmesg.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/20141028/3a6ec20b/attachment.html>
[Bug 85564] Dead Island rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=85564 --- Comment #2 from Thomas Rohloff --- Created attachment 108577 --> https://bugs.freedesktop.org/attachment.cgi?id=108577&action=edit Xorg.0.log -- 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/20141028/063f0881/attachment.html>
[Bug 84021] [game][the cave] not rendered properly
https://bugs.freedesktop.org/show_bug.cgi?id=84021 --- Comment #3 from Sylvain BERTRAND --- Created attachment 108576 --> https://bugs.freedesktop.org/attachment.cgi?id=108576&action=edit blue overlay -- 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/20141028/c03481de/attachment-0001.html>
[Bug 84021] [game][the cave] not rendered properly
https://bugs.freedesktop.org/show_bug.cgi?id=84021 --- Comment #2 from Sylvain BERTRAND --- I went back to fedora 20. The rendering is mostly ok. The "bloom" visual effects is adding a blue veil on the screen (see screenshot). The character name display while selection is not rendered properly. The anti-aliasing visual effect is killing performance. -- 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/20141028/ed150bd4/attachment.html>
NULL derefs after failed suspend (i915, pm, ext4, slub)
On Tue, 28 Oct 2014, Johan Hovold wrote: > Hi, > > I have had some problems with crashes involving suspend-to-disk after > updating to v3.16. > > Below is a log with 3.16.6 from a failed suspend attempt after which I > get a NULL deref in ext4 code. > > A couple of weeks ago I got something similar, with backtraces from > ext4 (ext4_alloc_inode) and NULL-derefs in vfs (vfs_get_attr_nosec) when > trying to do IO after resuming from suspend. That was with 3.16.3 and I > was hoping that whatever it was would have been fixed in 3.16.6 (there > were some ext4 error handling patches in there). I only got photos of > those oopses but it involved kmem_cache_alloc (slub) and a NULL-deref in > vfs_get_attr_nosec. I can put the photos up somewhere. That time I also > got back to X and could issue a dmesg in an xterm, but any process trying > to do IO died. > > Something similar happened with 3.16.1 but unfortunately I do not have > any logs from that. > > I also have experienced occasional hangs during suspend, but I believe I > have seen this with older kernels as well so not sure if related. Seems > to be more frequent with 3.16. > > This is my main machine so not keen on trying to bisect this on it. > > It's an i7-4770 on an Intel DH87MC using the integrated HD Graphics 4600. > > I'm CCing the Intel graphics guys due to some errors drm errors in the > logs, and reports of other people having problems involving suspend and > this driver. My first suggestion would be to try to reproduce the NULL deref without i915 loaded, and track the issues you have independently. Please file any i915 issues against DRM/Intel at [1]. Thanks, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI > > Note that there was nothing obviously i915 related in the 3.16.3 oops > but I see now that it occurred soon after > > video LNXVIDEO:00: Restoring backlight state > > just like it does below. > > [137452.181187] [drm:intel_dp_start_link_train] *ERROR* failed to enable link > training > [137452.183960] [drm:intel_dp_complete_link_train] *ERROR* failed to start > channel equalization > [138715.329101] [drm:intel_dp_start_link_train] *ERROR* failed to enable link > training > [138715.331798] [drm:intel_dp_complete_link_train] *ERROR* failed to start > channel equalization > > I get the above occasionally when coming out of dpms-off and my > secondary monitor fails to power up. But here's the suspend attempt: > > [148288.654477] s2disk.sh (24636): drop_caches: 3 > [148288.654667] PM: Syncing filesystems ... done. > [148288.836275] Freezing user space processes ... (elapsed 0.000 seconds) > done. > [148288.837641] PM: Preallocating image memory... done (allocated 1668895 > pages) > [148289.299805] PM: Allocated 6675580 kbytes in 0.46 seconds (14512.13 MB/s) > [148289.299806] Freezing remaining freezable tasks ... (elapsed 0.001 > seconds) done. > [148289.301127] Suspending console(s) (use no_console_suspend to debug) > [148289.331656] PM: freeze of devices complete after 30.513 msecs > [148289.331925] PM: late freeze of devices complete after 0.267 msecs > [148289.332470] PM: noirq freeze of devices complete after 0.544 msecs > [148289.332471] Disabling non-boot CPUs ... > [148289.332488] intel_pstate CPU 1 exiting > [148289.333592] kvm: disabling virtualization on CPU1 > [148289.333598] smpboot: CPU 1 is now offline > [148289.333979] intel_pstate CPU 2 exiting > [148289.335092] kvm: disabling virtualization on CPU2 > [148289.335099] smpboot: CPU 2 is now offline > [148289.335370] intel_pstate CPU 3 exiting > [148289.336487] kvm: disabling virtualization on CPU3 > [148289.336492] smpboot: CPU 3 is now offline > [148289.336757] intel_pstate CPU 4 exiting > [148289.337871] kvm: disabling virtualization on CPU4 > [148289.338128] smpboot: CPU 4 is now offline > [148289.338344] intel_pstate CPU 5 exiting > [148289.339436] kvm: disabling virtualization on CPU5 > [148289.339441] smpboot: CPU 5 is now offline > [148289.339608] intel_pstate CPU 6 exiting > [148289.340828] kvm: disabling virtualization on CPU6 > [148289.340853] smpboot: CPU 6 is now offline > [148289.341407] intel_pstate CPU 7 exiting > [148289.342605] kvm: disabling virtualization on CPU7 > [148289.342651] smpboot: CPU 7 is now offline > [148289.342943] PM: Creating hibernation image: > [148289.644672] PM: Need to copy 1665588 pages > > Suspend has failed, resuming: > > [148289.343968] Enabling non-boot CPUs ... > [148289.343991] x86: Booting SMP configuration: > [148289.343992] smpboot: Booting Node 0 Processor 1 APIC 0x2 > [148289.355895] kvm: enabling virtualization on CPU1 > [148289.357989] Intel pstate controlling: cpu 1 > [148289.358014] CPU1 is up > [148289.358025] smpboot: Booting Node 0 Processor 2 APIC 0x4 > [148289.369916] kvm: enabling virtualization on CPU2 > [148289.371995] Intel pstate controlling: cpu 2 > [148289.372016] CPU2 is up > [148289.372025] smpboot: Booting Node 0 Processor 3 APIC 0x6 > [148289.383905] kvm: enabling virtualiz
[PATCH] allow 32bpp framebuffers for cirrus drm
> > revision bump would be needed when adding a new interface (not present > in real hardware) to allow for larger pitches, so you could use 32bpp > with the default (1024x768) resolution. > I did not change the pitch mechanism. The hardware is limited to less than a 4KB pitch because of the registers, so I kept that limitation in the driver. That means no revision bump is necessary. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/727754b0/attachment.html>
[Bug 85564] Dead Island rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=85564 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. -- 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/20141028/deae2d1e/attachment.html>
Standard VGA console with DRI/DRM under X?
> Is this possible and if not, why not? Long story short on modern hardware the VGA console is just an emulation working on top of the real hardware. When the driver wants to talk to the real hardware it must simply disable the VGA emulation first. But to me all points why you don't like the fbcon are just a matter of configuring it correctly, so you might want to look into that direction as well. Regards, Christian. Am 28.10.2014 um 16:48 schrieb Bjorn Helgaas: > [+cc David, Alex, Christian, dri-devel] > > On Tue, Oct 28, 2014 at 12:32 AM, Michael Shell > wrote: >> >>Greetings, >> >> Well, I want to be able to have my cake and eat it too. I want to be able to >> have the standard VGA/"hardware" classic console (not the framebuffer) but >> I still want the /dev/dri/cardX devices so that I can use DRI under Xorg. >> >> Is this possible and if not, why not? >> >> >> (I do hope I'm not bring up an issue with an obvious fix, but my searching >> has not yielded an answer yet. For the record, I'm running modern kernel >> (3.16.3) with much older x86 hardware [r100 Radeon video card].) >> >> >> If I boot with the kernel nomodeset option I can get the classic >> VGA/"hardware" console, but then I lose support for DRI/DRM: >> >> Oct 27 15:11:09 X kernel: [drm] Initialized drm 1.1.0 20060810 >> Oct 27 15:11:09 X kernel: [drm] VGACON disable radeon kernel modesetting. >> Oct 27 15:11:09 X kernel: [drm:radeon_init] *ERROR* No UMS support in radeon >> module >> >> and glxgears et al. turns slow. In more modern Xorg releases, DRI is >> required for all hardware acceleration, so having /dev/dri/cardX is very >> important: >> >> http://askubuntu.com/questions/463142/why-x-is-relying-on-software-instead-of-hardware-with-nomodeset-kernel-paramet >> >> >> One reason I do not wish to use the framebuffer console is because of the >> small font. 160 columns makes it difficult to tell which [OK] belongs with >> which service. The selection of console fonts should always include a >> set that gives us an 80 column screen and the docs should point this out. >> >> And I dislike any blanking or video mode changes during boot. >> >> Can't the kernel just declare that it is capable of setting the video mode, >> provide the /dev/dri/cardX devices and leave the console alone, but still >> allow Xorg to call for a new mode and use /dev/dri/cardX if/when it sees fit? >> >> In an ideal world, there would be some kernel option such as fbcon=no. >> >> In the kernel Documentation fbcon.txt it mentions "fbcon=map:1 tells fbcon >> not >> to take over the console." But, IIRC, from my tests I wasn't able to use this >> to get a VGA/"hardware" console and still be able to have /dev/dri/cardX >> devices. >> >> >> >> Cheers and thank you, >> >> Mike Shell >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 3/3] libdrm: user mode helper for ipvr drm driver
Hi, On 17 October 2014 01:36, Jiang, Fei wrote: > Thanks for Emil's suggestion. You are right, we need make sure structure > size aligned on 8 bytes, which is important for 32bit-64bit compatible case. While you're at it, please don't use enum as a type inside ioctls, since the size can vary by compiler. Please use a uint32_t or whatever instead, assigning enum values to that. Cheers, Daniel Fei > -Original Message- > From: Emil Velikov [mailto:emil.l.velikov at gmail.com] > Sent: Thursday, October 16, 2014 11:20 PM > To: Cheng, Yao; intel-gfx at lists.freedesktop.org > Cc: emil.l.velikov at gmail.com; Jiang, Fei; dri-devel at > lists.freedesktop.org; > Vetter, Daniel > Subject: Re: [RFC PATCH 3/3] libdrm: user mode helper for ipvr drm driver > > On 16/10/14 15:33, Cheng, Yao wrote: > > Hi Emil, > > Sorry, what do you mean by "correctly aligned"? does it mean the > paddings in this data structure? > > > Afaict for compatibility reasons the struct size have to be "aligned" > (multiple of 8 bytes), or if you prefer - the struct is missing the > required padding :) I've only skimmed through the patch so it may be that > other structs are having this issue. > > Cheers, > Emil > > >> -Original Message- > >> From: Emil Velikov [mailto:emil.l.velikov at gmail.com] > >> Sent: Wednesday, October 15, 2014 5:24 PM > >> To: Cheng, Yao; intel-gfx at lists.freedesktop.org > >> Cc: emil.l.velikov at gmail.com; Jiang, Fei; > >> dri-devel at lists.freedesktop.org; Vetter, Daniel > >> Subject: Re: [RFC PATCH 3/3] libdrm: user mode helper for ipvr drm > >> driver > >> > >> Hi Yao, > >> > >> struct drm_ipvr_gem_userptr does not seem to be correctly aligned - > >> is that intentional ? Might be worth checking if anything else in > >> ipvr_drm.h and ipvr_bufmgr.h is in the same boat. > >> > >> Cheers, > >> Emil > >> > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/59aeb816/attachment.html>
[PATCH 2/6] drm: add tile_group support. (v2)
> @@ -5156,3 +5158,100 @@ struct drm_property
> *drm_mode_create_rotation_property(struct drm_device *dev,
>supported_rotations);
> }
> EXPORT_SYMBOL(drm_mode_create_rotation_property);
> +
> +/**
> + * DOC: Tile group
> + *
> + * Tile groups are used to represent tiled monitors with a unique
> + * integer identifier. Tiled monitors using DisplayID v1.3 have
> + * a unique 8-byte handle, we store this in a tile group, so we
> + * have a common identifier for all tiles in a monitor group.
> + */
> +static void drm_tile_group_free(struct kref *kref)
> +{
> + struct drm_tile_group *tg = container_of(kref, struct drm_tile_group,
> refcount);
> + struct drm_device *dev = tg->dev;
> + mutex_lock(&dev->mode_config.idr_mutex);
> + idr_remove(&dev->mode_config.tile_idr, tg->id);
> + mutex_lock(&dev->mode_config.idr_mutex);
Review not to self:
*un*lock.
Dave.
[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
On Tue, Oct 28, 2014 at 2:42 PM, Javier Martinez Canillas wrote: > Hello Ajay, > > On Thu, Oct 16, 2014 at 11:04 AM, Laurent Pinchart > wrote: >>> >>> Right. It would be great if you guys come to agreement ASAP! >> >> I don't think we'll agree any time soon, so I believe it's up to you to >> decide >> which option is best based on all arguments that have been presented. >> > > Did you decide what's the correct approach? I don't have a strong > opinion, I'm just asking because it would be a pity if your series > miss another kernel release... I will be using graphs instead of phandles, and would send a series ASAP. Ajay
[Bug 85564] New: Dead Island rendering issues
https://bugs.freedesktop.org/show_bug.cgi?id=85564 Bug ID: 85564 Summary: Dead Island rendering issues Product: Mesa Version: git Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: v10lator at myway.de This was tested with a AMD Radeon HD 6950. Good image (random screenshot taken from youtube) : http://picload.org/image/carrior/good.png Bad image (rendered with r600g) : http://img5.picload.org/image/carrpgi/2014-10-28_1.jpg I'm not the only one with this problem, people are talking about it at phoronix ( http://www.phoronix.com/forums/showthread.php?108025-Dead-Island-GOTY-Now-Available-On-Linux-SteamOS ), in the steam forums ( http://steamcommunity.com/app/91310/discussions/0/613940109818649734/ ) and at other places. Playing around with SB, HyperZ and LLVM didn't change anything (except LLVM which freezes the game before anything is painted to the screen). If there's anything I can do to help tracking this down feel free to ask for 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/20141028/3e13020a/attachment.html>
[PATCH 2/2] drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()
The Baseline_ELD_Len field does not include ELD Header Block size.
>From High Definition Audio Specification, Revision 1.0a:
The header block is a fixed size of 4 bytes. The baseline block
is variable size in multiple of 4 bytes, and its size is defined
in the header block Baseline_ELD_Len field (in number of
DWords).
Do not include the header size in Baseline_ELD_Len field. Fix all known
users of eld[2].
While at it, switch to DIV_ROUND_UP instead of open coding it.
Signed-off-by: Jani Nikula
---
This is based on an audio rework series which is mid-way being merged to
i915. I don't think this should be cc: stable worthy, as, AFAICT, we
don't use the vendor block, and anyone reading SADs respecting SAD_Count
should stop at the same offset regardless of this patch. So I propose
this gets eventually merged via i915 without a rush.
---
drivers/gpu/drm/drm_edid.c | 7 +--
drivers/gpu/drm/i915/intel_audio.c | 16
drivers/gpu/drm/nouveau/nv50_display.c | 3 ++-
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3bf999134bcc..45aaa6f5ef36 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3128,9 +3128,12 @@ void drm_edid_to_eld(struct drm_connector *connector,
struct edid *edid)
}
}
eld[5] |= sad_count << 4;
- eld[2] = (20 + mnl + sad_count * 3 + 3) / 4;
- DRM_DEBUG_KMS("ELD size %d, SAD count %d\n", (int)eld[2], sad_count);
+ eld[DRM_ELD_BASELINE_ELD_LEN] =
+ DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
+
+ DRM_DEBUG_KMS("ELD size %d, SAD count %d\n",
+ drm_eld_size(eld), sad_count);
}
EXPORT_SYMBOL(drm_edid_to_eld);
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 20af973d7cba..439fa4afa18b 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -107,7 +107,7 @@ static bool intel_eld_uptodate(struct drm_connector
*connector,
tmp &= ~bits_elda;
I915_WRITE(reg_elda, tmp);
- for (i = 0; i < eld[2]; i++)
+ for (i = 0; i < drm_eld_size(eld) / 4; i++)
if (I915_READ(reg_edid) != *((uint32_t *)eld + i))
return false;
@@ -162,7 +162,7 @@ static void g4x_audio_codec_enable(struct drm_connector
*connector,
len = (tmp >> 9) & 0x1f;/* ELD buffer size */
I915_WRITE(G4X_AUD_CNTL_ST, tmp);
- len = min_t(int, eld[2], len);
+ len = min(drm_eld_size(eld) / 4, len);
DRM_DEBUG_DRIVER("ELD size %d\n", len);
for (i = 0; i < len; i++)
I915_WRITE(G4X_HDMIW_HDMIEDID, *((uint32_t *)eld + i));
@@ -209,7 +209,7 @@ static void hsw_audio_codec_enable(struct drm_connector
*connector,
int len, i;
DRM_DEBUG_KMS("Enable audio codec on pipe %c, %u bytes ELD\n",
- pipe_name(pipe), eld[2]);
+ pipe_name(pipe), drm_eld_size(eld));
/* Enable audio presence detect, invalidate ELD */
tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
@@ -225,8 +225,8 @@ static void hsw_audio_codec_enable(struct drm_connector
*connector,
I915_WRITE(HSW_AUD_DIP_ELD_CTRL(pipe), tmp);
/* Up to 84 bytes of hw ELD buffer */
- len = min_t(int, eld[2], 21);
- for (i = 0; i < len; i++)
+ len = min(drm_eld_size(eld), 84);
+ for (i = 0; i < len / 4; i++)
I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((uint32_t *)eld + i));
/* ELD valid */
@@ -315,7 +315,7 @@ static void ilk_audio_codec_enable(struct drm_connector
*connector,
int aud_cntrl_st2;
DRM_DEBUG_KMS("Enable audio codec on port %c, pipe %c, %u bytes ELD\n",
- port_name(port), pipe_name(pipe), eld[2]);
+ port_name(port), pipe_name(pipe), drm_eld_size(eld));
/* XXX: vblank wait here */
@@ -354,8 +354,8 @@ static void ilk_audio_codec_enable(struct drm_connector
*connector,
I915_WRITE(aud_cntl_st, tmp);
/* Up to 84 bytes of hw ELD buffer */
- len = min_t(int, eld[2], 21);
- for (i = 0; i < len; i++)
+ len = min(drm_eld_size(eld), 84);
+ for (i = 0; i < len / 4; i++)
I915_WRITE(hdmiw_hdmiedid, *((uint32_t *)eld + i));
/* ELD valid */
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index ae873d1a8d46..d92c11484bd9 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -1680,7 +1680,8 @@ nv50_audio_mode_set(struct drm_encoder *encoder, struct
drm_display_mode *mode)
drm_edid_to_eld(&nv_connector->base, nv_connector->edid);
memcpy(args.data, nv_connector->base.eld, sizeof(args.data));
- nvif_mthd(disp->disp, 0, &args, sizeof(args.base) + args.data[2] * 4);
+
[PATCH 1/2] drm/edid: add #defines and helpers for ELD
In the interest of reducing magic numbers and having to cross check with
the specs all the time.
Signed-off-by: Jani Nikula
---
include/drm/drm_edid.h | 102 +
1 file changed, 102 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b96031d947a0..c2f1bfa22010 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -207,6 +207,61 @@ struct detailed_timing {
#define DRM_EDID_HDMI_DC_30 (1 << 4)
#define DRM_EDID_HDMI_DC_Y444 (1 << 3)
+/* ELD Header Block */
+#define DRM_ELD_HEADER_BLOCK_SIZE 4
+
+#define DRM_ELD_VER0
+# define DRM_ELD_VER_SHIFT 3
+# define DRM_ELD_VER_MASK (0x1f << 3)
+
+#define DRM_ELD_BASELINE_ELD_LEN 2 /* in dwords! */
+
+/* ELD Baseline Block for ELD_Ver == 2 */
+#define DRM_ELD_CEA_EDID_VER_MNL 4
+# define DRM_ELD_CEA_EDID_VER_SHIFT5
+# define DRM_ELD_CEA_EDID_VER_MASK (7 << 5)
+# define DRM_ELD_CEA_EDID_VER_NONE (0 << 5)
+# define DRM_ELD_CEA_EDID_VER_CEA861 (1 << 5)
+# define DRM_ELD_CEA_EDID_VER_CEA861A (2 << 5)
+# define DRM_ELD_CEA_EDID_VER_CEA861BCD(3 << 5)
+# define DRM_ELD_MNL_SHIFT 0
+# define DRM_ELD_MNL_MASK (0x1f << 0)
+
+#define DRM_ELD_SAD_COUNT_CONN_TYPE5
+# define DRM_ELD_SAD_COUNT_SHIFT 4
+# define DRM_ELD_SAD_COUNT_MASK(0xf << 4)
+# define DRM_ELD_CONN_TYPE_SHIFT 2
+# define DRM_ELD_CONN_TYPE_MASK(3 << 2)
+# define DRM_ELD_CONN_TYPE_HDMI(0 << 2)
+# define DRM_ELD_CONN_TYPE_DP (1 << 2)
+# define DRM_ELD_SUPPORTS_AI (1 << 1)
+# define DRM_ELD_SUPPORTS_HDCP (1 << 0)
+
+#define DRM_ELD_AUD_SYNCH_DELAY6 /* in units of 2 ms */
+# define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa/* 500 ms */
+
+#define DRM_ELD_SPEAKER7
+# define DRM_ELD_SPEAKER_RLRC (1 << 6)
+# define DRM_ELD_SPEAKER_FLRC (1 << 5)
+# define DRM_ELD_SPEAKER_RC(1 << 4)
+# define DRM_ELD_SPEAKER_RLR (1 << 3)
+# define DRM_ELD_SPEAKER_FC(1 << 2)
+# define DRM_ELD_SPEAKER_LFE (1 << 1)
+# define DRM_ELD_SPEAKER_FLR (1 << 0)
+
+#define DRM_ELD_PORT_ID8 /* offsets 8..15
inclusive */
+# define DRM_ELD_PORT_ID_LEN 8
+
+#define DRM_ELD_MANUFACTURER_NAME0 16
+#define DRM_ELD_MANUFACTURER_NAME1 17
+
+#define DRM_ELD_PRODUCT_CODE0 18
+#define DRM_ELD_PRODUCT_CODE1 19
+
+#define DRM_ELD_MONITOR_NAME_STRING20 /* offsets 20..(20+mnl-1)
inclusive */
+
+#define DRM_ELD_CEA_SAD(mnl, sad) (20 + (mnl) + 3 * (sad))
+
struct edid {
u8 header[8];
/* Vendor & product info */
@@ -279,4 +334,51 @@ int
drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
*frame,
const struct drm_display_mode
*mode);
+/**
+ * drm_eld_mnl - Get ELD monitor name length in bytes.
+ * @eld: pointer to an eld memory structure with mnl set
+ */
+static inline int drm_eld_mnl(const uint8_t *eld)
+{
+ return (eld[DRM_ELD_CEA_EDID_VER_MNL] & DRM_ELD_MNL_MASK) >>
DRM_ELD_MNL_SHIFT;
+}
+
+/**
+ * drm_eld_sad_count - Get ELD SAD count.
+ * @eld: pointer to an eld memory structure with sad_count set
+ */
+static inline int drm_eld_sad_count(const uint8_t *eld)
+{
+ return (eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_SAD_COUNT_MASK) >>
+ DRM_ELD_SAD_COUNT_SHIFT;
+}
+
+/**
+ * drm_eld_calc_baseline_block_size - Calculate baseline block size in bytes
+ * @eld: pointer to an eld memory structure with mnl and sad_count set
+ *
+ * This is a helper for determining the payload size of the baseline block, in
+ * bytes, for e.g. setting the Baseline_ELD_Len field in the ELD header block.
+ */
+static inline int drm_eld_calc_baseline_block_size(const uint8_t *eld)
+{
+ return DRM_ELD_MONITOR_NAME_STRING - DRM_ELD_HEADER_BLOCK_SIZE +
+ drm_eld_mnl(eld) + drm_eld_sad_count(eld) * 3;
+}
+
+/**
+ * drm_eld_size - Get ELD size in bytes
+ * @eld: pointer to a complete eld memory structure
+ *
+ * The returned value does not include the vendor block. It's vendor specific,
+ * and comprises of the remaining bytes in the ELD memory buffer after
+ * drm_eld_size() bytes of header and baseline block.
+ *
+ * The returned value is guaranteed to be a multiple of 4.
+ */
+static inline int drm_eld_size(const uint8_t *eld)
+{
+ return DRM_ELD_HEADER_BLOCK_SIZE + eld[DRM_ELD_BASELINE_ELD_LEN] * 4;
+}
+
#endif /* __DRM_EDID_H__ */
--
2.1.1
Standard VGA console with DRI/DRM under X?
> -Original Message- > From: Bjorn Helgaas [mailto:bhelgaas at google.com] > Sent: Tuesday, October 28, 2014 11:48 AM > To: Michael Shell > Cc: linux-kernel at vger.kernel.org; David Airlie; DRI mailing list; Deucher, > Alexander; Koenig, Christian > Subject: Re: Standard VGA console with DRI/DRM under X? > > [+cc David, Alex, Christian, dri-devel] > > On Tue, Oct 28, 2014 at 12:32 AM, Michael Shell > wrote: > > > > > > Greetings, > > > > Well, I want to be able to have my cake and eat it too. I want to be able to > > have the standard VGA/"hardware" classic console (not the framebuffer) > but > > I still want the /dev/dri/cardX devices so that I can use DRI under Xorg. > > > > Is this possible and if not, why not? > > > > It's not currently possible. When the driver loads it needs to reprogram the GPU memory controller which requires disabling (or at least blanking the displays). Additionally there is currently no code in the driver to setup the vga text mode emulation. Moreover, there is no legacy vga text mode on UEFI systems when the GPU has a GOP driver. > > (I do hope I'm not bring up an issue with an obvious fix, but my searching > > has not yielded an answer yet. For the record, I'm running modern kernel > > (3.16.3) with much older x86 hardware [r100 Radeon video card].) > > > > > > If I boot with the kernel nomodeset option I can get the classic > > VGA/"hardware" console, but then I lose support for DRI/DRM: > > > > Oct 27 15:11:09 X kernel: [drm] Initialized drm 1.1.0 20060810 > > Oct 27 15:11:09 X kernel: [drm] VGACON disable radeon kernel > modesetting. > > Oct 27 15:11:09 X kernel: [drm:radeon_init] *ERROR* No UMS support in > radeon module > > > > and glxgears et al. turns slow. In more modern Xorg releases, DRI is > > required for all hardware acceleration, so having /dev/dri/cardX is very > > important: > > > > http://askubuntu.com/questions/463142/why-x-is-relying-on-software- > instead-of-hardware-with-nomodeset-kernel-paramet > > UMS is deprecated in the kernel and support for UMS has been dropped from the X ddx and the mesa drivers. Moreover, UMS had a lot of limitations that make it much less useful for modern desktops (no DRI2 support, no display hotplug support, etc.). > > > > One reason I do not wish to use the framebuffer console is because of the > > small font. 160 columns makes it difficult to tell which [OK] belongs with > > which service. The selection of console fonts should always include a > > set that gives us an 80 column screen and the docs should point this out. > > > > And I dislike any blanking or video mode changes during boot. > > > > Can't the kernel just declare that it is capable of setting the video mode, > > provide the /dev/dri/cardX devices and leave the console alone, but still > > allow Xorg to call for a new mode and use /dev/dri/cardX if/when it sees > fit? > > > > In an ideal world, there would be some kernel option such as fbcon=no. > > > > In the kernel Documentation fbcon.txt it mentions "fbcon=map:1 tells > fbcon not > > to take over the console." But, IIRC, from my tests I wasn't able to use > > this > > to get a VGA/"hardware" console and still be able to have /dev/dri/cardX > devices. > > The driver disables the legacy vga text mode hardware when it loads. I think configuring a different mode or font for the fb console would probably get you what you want. See the Forcing Modes section of this page (http://nouveau.freedesktop.org/wiki/KernelModeSetting/) for how to select a custom mode for your display with KMS Alex > > > > > > Cheers and thank you, > > > > Mike Shell > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo at vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote: > On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding > wrote: > > On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote: > >> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote: > >> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter > >> > wrote: > > [...] > >> >> Hm, if you do this can you pls also update drm_panel accordingly? It > >> >> shouldn't be a lot of fuzz and would make things around drm+dt more > >> >> consistent. > >> > Are you talking about using struct device_node instead of struct device? > >> > I guess you have misplaced the comment under the wrong section! > >> > >> Yeah, that should have been one up ;-) > > > > Like I said earlier, I don't think dropping struct device * in favour of > > struct device_node * is a good idea. > I am not sure about drm_panel. > But, I am not really doing anything with the struct device pointer in > case of bridge. > So, just wondering if it is really needed? I think it's useful to have it just to send the right message. DRM panel and DRM bridge aren't specific to device tree. They are completely generic and can work with any type of device, whether it was instantiated from the device tree or some other infrastructure. Dropping struct device * will make it effectively useless on anything but DT. I don't think we should strive for that, even if only DT-enabled platforms currently use them. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/66fd1f77/attachment-0001.sig>
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #14 from Christian König --- Created attachment 155721 --> https://bugzilla.kernel.org/attachment.cgi?id=155721&action=edit Add more debugging output. Please apply the attached patch and provide new dmesg created with drm.debug=0xE It should now show a bit more debugging output about your hardware. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote: > On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote: > > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote: [...] > >> Hm, if you do this can you pls also update drm_panel accordingly? It > >> shouldn't be a lot of fuzz and would make things around drm+dt more > >> consistent. > > Are you talking about using struct device_node instead of struct device? > > I guess you have misplaced the comment under the wrong section! > > Yeah, that should have been one up ;-) Like I said earlier, I don't think dropping struct device * in favour of struct device_node * is a good idea. > >> If you want to document drm_bridge then I recomment to sprinkle proper > >> kerneldoc over drm_bridge.c and pull it all into the drm DocBook > >> template. That way all the drm documentation is in one place. I've > >> done that for drm_crtc.h in an unrelated patch series (but based upon > >> a branch with your patch here included) and there's struct drm_bridge* > >> in there. Hence why I've noticed. > > Can you send a link for that? > > And, is there any problem if the doc comes later? > > Since quite a while we've asked for the kerneldoc polish as part of > each drm core patch series. It's just that drm_bridge/panel kinda have > flown under the radar of the people usually asking for docs ;-) FWIW, there's some kerneldoc in include/drm/drm_panel.h but I guess I could write up something more complete and integrate it into DocBook. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/cea53b8f/attachment.sig>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter wrote:
> > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
> >>>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> >>>> * @driver_private: pointer to the bridge driver's internal context
> >>>> */
> >>>> struct drm_bridge {
> >>>> - struct drm_device *dev;
> >>>> + struct device *dev;
> >>>
> >>> Please don't rename the ->dev pointer into drm. Because _all_ the other
> >>> drm structures still call it ->dev. Also, can't we use struct device_node
> >>> here like we do in the of helpers Russell added? See 7e435aad38083
> >>>
> >>
> >> I think this is modeled after the naming in drm_panel, FWIW. However,
> >> seems reasonable to keep the device_node instead.
> >
> > Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> > drm_crtc drop the struct device and go directly to a struct
> > device_node. Since we don't really need the sturct device, the only
> > thing we care about is the of_node. For added bonus wrap an #ifdef
> > CONFIG_OF around all the various struct device_node in drm_foo.h.
> > Should be all fairly simple to pull off with cocci.
> >
> > Thierry?
>
> Looking at the of_drm_find_panel function I actually wonder how that
> works - the drm_panel doesn't really need to stick around afaics.
> After all panel_list is global so some other driver can unload.
> Russell's of support for possible_crtcs code works differently since
> it only looks at per-drm_device lists.
I don't understand. Panels are global resources that get registered by
some driver that isn't tied to the DRM device until attached. It can't
be in a per-DRM device list, because it's external to the device.
And yes, they can go away when a driver is unloaded, though it's not the
typical use-case.
> This bridge code here though suffers from the same. So to me this
> looks rather fishy.
Well, this version of the DRM bridge support was written to be close to
DRM panel, so it isn't really surprising that it's similar =), but like
I said, I don't really understand what you think is wrong with it.
> It doesn't help that we have drm_of.[hc] around but not all the of
> code is in there. Adding Russell too.
DRM panel and DRM bridge aren't just OF helpers. They can be used with
whatever type of device you want.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/c55c18b0/attachment.sig>
[PATCH v3 0/9] Renesas R-Car DU HDMI support
> > The last patch instantiates the HDMI encoder in the Koelsch board DT file and > connects it to the DU output. > > The patch series depends on Koelsch DU DT enablement (scheduled for merge in > v3.19-rc1). Dave, I'd like to get this merged in v3.19-rc1, how would you like > to proceed ? Could it go through Simon's Renesas tree ? There's a small risk > of conflict in drivers/gpu/drm/drm_edid.c, include/drm/drm_edid.h, > drivers/gpu/drm/i2c/Kconfig and drivers/gpu/drm/i2c/Makefile. Simon, could you > alternatively provide a stable branch with the required dependencies ? I'd probably like to take the drm patches into drm-next first, then maybe get a stable branch from Simon I could use to base the rest on. Dave. > > Changes since v2: > > - Name arguments to get_edid_block() > > Changes since v1: > > - Dropped Philipp Zabel's OF graph patches (the rcar-du-drm driver will be > udpated to use for_each_endpoint_of_node when the implementation hits > upstream) > - adv7511: Clarify the adi,input-format DT property documentation > - adv7511: Use map array to convert input style to hardware value > - adv7511: Fixed typos > > For ease of testing and review I've pushed this series and its dependencies to > a git branch on > > git://linuxtv.org/pinchartl/fbdev.git drm/du/adv7511 > > Cc: devicetree at vger.kernel.org > Cc: Dave Airlie > Cc: Lars-Peter Clausen > Cc: Simon > > Lars-Peter Clausen (2): > drm: Decouple EDID parsing from I2C adapter > drm: Add adv7511 encoder driver > > Laurent Pinchart (7): > drm: rcar-du: Remove platform data support > drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init() > drm: rcar-du: Replace direct DRM encoder access with cast macro > drm: rcar-du: Replace drm_encoder with drm_slave_encoder > drm: rcar-du: Add HDMI encoder and connector support > video: Add ADV751[13] DT bindings documentation > ARM: shmobile: koelsch: Add DU HDMI output support > > .../devicetree/bindings/video/adi,adv7511.txt | 88 ++ > arch/arm/boot/dts/r8a7791-koelsch.dts | 50 +- > drivers/gpu/drm/drm_edid.c | 27 +- > drivers/gpu/drm/i2c/Kconfig|6 + > drivers/gpu/drm/i2c/Makefile |2 + > drivers/gpu/drm/i2c/adv7511.c | 1010 > > drivers/gpu/drm/i2c/adv7511.h | 289 ++ > drivers/gpu/drm/rcar-du/Kconfig| 11 +- > drivers/gpu/drm/rcar-du/Makefile |2 + > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c |4 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.h |2 - > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 45 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 23 +- > drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 118 +++ > drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 + > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 151 +++ > drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h | 35 + > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 53 +- > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 31 +- > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |2 - > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |1 - > drivers/gpu/drm/rcar-du/rcar_du_vgacon.c |5 +- > include/drm/drm_edid.h |5 + > include/linux/platform_data/rcar-du.h | 74 -- > 25 files changed, 1894 insertions(+), 181 deletions(-) > create mode 100644 Documentation/devicetree/bindings/video/adi,adv7511.txt > create mode 100644 drivers/gpu/drm/i2c/adv7511.c > create mode 100644 drivers/gpu/drm/i2c/adv7511.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h > delete mode 100644 include/linux/platform_data/rcar-du.h > > -- > Regards, > > Laurent Pinchart >
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
> >>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> >>> * @driver_private: pointer to the bridge driver's internal context
> >>> */
> >>> struct drm_bridge {
> >>> - struct drm_device *dev;
> >>> + struct device *dev;
> >>
> >> Please don't rename the ->dev pointer into drm. Because _all_ the other
> >> drm structures still call it ->dev. Also, can't we use struct device_node
> >> here like we do in the of helpers Russell added? See 7e435aad38083
> >>
> >
> > I think this is modeled after the naming in drm_panel, FWIW. However,
> > seems reasonable to keep the device_node instead.
>
> Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> drm_crtc drop the struct device and go directly to a struct
> device_node. Since we don't really need the sturct device, the only
> thing we care about is the of_node. For added bonus wrap an #ifdef
> CONFIG_OF around all the various struct device_node in drm_foo.h.
> Should be all fairly simple to pull off with cocci.
>
> Thierry?
The struct device * is in DRM panel because there's nothing device tree
specific about the concept. Having a struct device_node * instead would
indicate that it can only be used with a device tree, whereas the
framework doesn't care the tiniest bit what type of device we have.
While the trend clearly is to use more device tree, I don't think we
should make it impossible for anybody else to use these frameworks.
There are other advantages to keeping a struct device *, like having
access to the proper device and its name. Also you get access to the
device_node * via dev->of_node anyway. I don't see any advantage in
switching to just a struct device_node *, only disadvantages.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/4208db32/attachment.sig>
NULL derefs after failed suspend (i915, pm, ext4, slub)
Hi, I have had some problems with crashes involving suspend-to-disk after updating to v3.16. Below is a log with 3.16.6 from a failed suspend attempt after which I get a NULL deref in ext4 code. A couple of weeks ago I got something similar, with backtraces from ext4 (ext4_alloc_inode) and NULL-derefs in vfs (vfs_get_attr_nosec) when trying to do IO after resuming from suspend. That was with 3.16.3 and I was hoping that whatever it was would have been fixed in 3.16.6 (there were some ext4 error handling patches in there). I only got photos of those oopses but it involved kmem_cache_alloc (slub) and a NULL-deref in vfs_get_attr_nosec. I can put the photos up somewhere. That time I also got back to X and could issue a dmesg in an xterm, but any process trying to do IO died. Something similar happened with 3.16.1 but unfortunately I do not have any logs from that. I also have experienced occasional hangs during suspend, but I believe I have seen this with older kernels as well so not sure if related. Seems to be more frequent with 3.16. This is my main machine so not keen on trying to bisect this on it. It's an i7-4770 on an Intel DH87MC using the integrated HD Graphics 4600. I'm CCing the Intel graphics guys due to some errors drm errors in the logs, and reports of other people having problems involving suspend and this driver. Note that there was nothing obviously i915 related in the 3.16.3 oops but I see now that it occurred soon after video LNXVIDEO:00: Restoring backlight state just like it does below. [137452.181187] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training [137452.183960] [drm:intel_dp_complete_link_train] *ERROR* failed to start channel equalization [138715.329101] [drm:intel_dp_start_link_train] *ERROR* failed to enable link training [138715.331798] [drm:intel_dp_complete_link_train] *ERROR* failed to start channel equalization I get the above occasionally when coming out of dpms-off and my secondary monitor fails to power up. But here's the suspend attempt: [148288.654477] s2disk.sh (24636): drop_caches: 3 [148288.654667] PM: Syncing filesystems ... done. [148288.836275] Freezing user space processes ... (elapsed 0.000 seconds) done. [148288.837641] PM: Preallocating image memory... done (allocated 1668895 pages) [148289.299805] PM: Allocated 6675580 kbytes in 0.46 seconds (14512.13 MB/s) [148289.299806] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [148289.301127] Suspending console(s) (use no_console_suspend to debug) [148289.331656] PM: freeze of devices complete after 30.513 msecs [148289.331925] PM: late freeze of devices complete after 0.267 msecs [148289.332470] PM: noirq freeze of devices complete after 0.544 msecs [148289.332471] Disabling non-boot CPUs ... [148289.332488] intel_pstate CPU 1 exiting [148289.333592] kvm: disabling virtualization on CPU1 [148289.333598] smpboot: CPU 1 is now offline [148289.333979] intel_pstate CPU 2 exiting [148289.335092] kvm: disabling virtualization on CPU2 [148289.335099] smpboot: CPU 2 is now offline [148289.335370] intel_pstate CPU 3 exiting [148289.336487] kvm: disabling virtualization on CPU3 [148289.336492] smpboot: CPU 3 is now offline [148289.336757] intel_pstate CPU 4 exiting [148289.337871] kvm: disabling virtualization on CPU4 [148289.338128] smpboot: CPU 4 is now offline [148289.338344] intel_pstate CPU 5 exiting [148289.339436] kvm: disabling virtualization on CPU5 [148289.339441] smpboot: CPU 5 is now offline [148289.339608] intel_pstate CPU 6 exiting [148289.340828] kvm: disabling virtualization on CPU6 [148289.340853] smpboot: CPU 6 is now offline [148289.341407] intel_pstate CPU 7 exiting [148289.342605] kvm: disabling virtualization on CPU7 [148289.342651] smpboot: CPU 7 is now offline [148289.342943] PM: Creating hibernation image: [148289.644672] PM: Need to copy 1665588 pages Suspend has failed, resuming: [148289.343968] Enabling non-boot CPUs ... [148289.343991] x86: Booting SMP configuration: [148289.343992] smpboot: Booting Node 0 Processor 1 APIC 0x2 [148289.355895] kvm: enabling virtualization on CPU1 [148289.357989] Intel pstate controlling: cpu 1 [148289.358014] CPU1 is up [148289.358025] smpboot: Booting Node 0 Processor 2 APIC 0x4 [148289.369916] kvm: enabling virtualization on CPU2 [148289.371995] Intel pstate controlling: cpu 2 [148289.372016] CPU2 is up [148289.372025] smpboot: Booting Node 0 Processor 3 APIC 0x6 [148289.383905] kvm: enabling virtualization on CPU3 [148289.385993] Intel pstate controlling: cpu 3 [148289.386013] CPU3 is up [148289.386023] smpboot: Booting Node 0 Processor 4 APIC 0x1 [148289.397882] kvm: enabling virtualization on CPU4 [148289.39] Intel pstate controlling: cpu 4 [148289.400021] CPU4 is up [148289.400031] smpboot: Booting Node 0 Processor 5 APIC 0x3 [148289.411884] kvm: enabling virtualization on CPU5 [148289.414003] Intel pstate controlling: cpu 5 [148289.414025] CPU5 is up [148289.414034] smpboot: Bootin
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
> On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
>> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
>>> Hi Daniel and Sean,
>>>
>>> Thanks for the comments!
>>>
>>> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
> So don't ask why but I accidentally ended up in a branch looking at this
> patch and didn't like it. So very quick&grumpy review.
>
> First, please make the patch subject more descriptive: I'd expect a helper
> function scaffolding like the various crtc/probe/dp ... helpers we already
> have. You instead add code to untangle the probe ordering. Please say so.
>>> Sure. I will reword it properly.
>>>
> More comments below.
>
> On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they get probed by calling "drm_bridge_add".
>>
>> The parent encoder driver waits till the bridge is available
>> in the lookup table(by calling "of_drm_find_bridge") and then
>> continues with its initialization.
>>
>> The encoder driver should also call "drm_bridge_attach" to pass
>> on the drm_device, encoder pointers to the bridge object.
>>
>> drm_bridge_attach inturn calls drm_bridge_init to register itself
>> with the drm core. Later, it calls "bridge->funcs->attach" so that
>> bridge can continue with other initializations.
>>
>> Signed-off-by: Ajay Kumar
>
> [snip]
>
>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
>> * @driver_private: pointer to the bridge driver's internal context
>> */
>> struct drm_bridge {
>> - struct drm_device *dev;
>> + struct device *dev;
>
> Please don't rename the ->dev pointer into drm. Because _all_ the other
> drm structures still call it ->dev. Also, can't we use struct device_node
> here like we do in the of helpers Russell added? See 7e435aad38083
>
I think this is modeled after the naming in drm_panel,
>>> Right, The entire rework is based on how drm_panel framework is structured.
>>>
FWIW. However,
seems reasonable to keep the device_node instead.
>>> Yes, its visible that just device_node would be sufficient.
>>> This will save us from renaming drm_device as well.
>>>
>> + struct drm_device *drm;
>> + struct drm_encoder *encoder;
>
> This breaks bridge->bridge chaining (if we ever get there). It seems
> pretty much unused anyway except for an EBUSY check. Can't you use
> bridge->dev for that?
>
Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
and leave it up to the caller to establish the proper chain.
>>> Ok. I will use drm_device pointer directly instead of passing encoder
>>> pointer.
>>
>> Hm, if you do this can you pls also update drm_panel accordingly? It
>> shouldn't be a lot of fuzz and would make things around drm+dt more
>> consistent.
> Are you talking about using struct device_node instead of struct device?
> I guess you have misplaced the comment under the wrong section!
Yeah, that should have been one up ;-)
>> struct list_head head;
>> + struct list_head list;
>
> These lists need better names. I know that the "head" is really awful,
> especially since it's actually not the head of the list but just an
> element.
I think we can just rip bridge_list out of mode_config if we're going
to keep track of bridges elsewhere. So we can nuke "head" and keep
"list". This also means that bridge->destroy() goes away, but that's
probably Ok if everything converts to the standalone driver model
where we have driver->remove()
Sean
>>> Great! Thierry actually mentioned about this once, and we have the
>>> confirmation now.
>>>
>>
>> struct drm_mode_object base;
>
>
> Aside: I've noticed all this trying to update the kerneldoc for struct
> drm_bridge, which just showed that this patch makes inconsistent changes.
> Trying to write kerneldoc is a really great way to come up with better
> interfaces imo.
>
> Cheers, Daniel
>>> I din't get this actually. You want me to create Doc../drm_bridge.txt
>>> or something similar?
>>
>> If you want to document drm_bridge then I recomment to sprinkle proper
>> kerneldoc over drm_bridge.c and pull it all into the drm DocBook
>> template. That way all the drm documentation is in one place. I've
>> done that for drm_crtc.h in an unrelated patch series (but based upon
>> a branch with your patch here included) and there's struct drm_bridge*
>> in there. Hence why I've noticed.
> Can you send a link for that?
> And, is there any problem if the doc
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul wrote: > On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar > wrote: >> A set of helper functions are defined in this patch to make >> bridge driver probe independent of the drm flow. >> >> The bridge devices register themselves on a lookup table >> when they get probed by calling "drm_bridge_add". >> >> The parent encoder driver waits till the bridge is available >> in the lookup table(by calling "of_drm_find_bridge") and then >> continues with its initialization. >> >> The encoder driver should also call "drm_bridge_attach" to pass >> on the drm_device, encoder pointers to the bridge object. >> >> drm_bridge_attach inturn calls drm_bridge_init to register itself >> with the drm core. Later, it calls "bridge->funcs->attach" so that >> bridge can continue with other initializations. >> >> Signed-off-by: Ajay Kumar >> --- >> drivers/gpu/drm/Makefile |1 + >> drivers/gpu/drm/bridge/Kconfig | 15 - >> drivers/gpu/drm/drm_bridge.c | 102 >> >> drivers/gpu/drm/drm_crtc.c |4 +- >> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |4 +- >> include/drm/drm_crtc.h | 12 +++- >> 6 files changed, 131 insertions(+), 7 deletions(-) >> create mode 100644 drivers/gpu/drm/drm_bridge.c >> >> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >> index 4a55d59..bdbfb6f 100644 >> --- a/drivers/gpu/drm/Makefile >> +++ b/drivers/gpu/drm/Makefile >> @@ -19,6 +19,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o >> drm_cache.o \ >> drm-$(CONFIG_COMPAT) += drm_ioc32.o >> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o >> drm-$(CONFIG_PCI) += ati_pcigart.o >> +drm-$(CONFIG_DRM_BRIDGE) += drm_bridge.o >> drm-$(CONFIG_DRM_PANEL) += drm_panel.o >> drm-$(CONFIG_OF) += drm_of.o >> >> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig >> index 884923f..5a8e907 100644 >> --- a/drivers/gpu/drm/bridge/Kconfig >> +++ b/drivers/gpu/drm/bridge/Kconfig >> @@ -1,5 +1,16 @@ >> -config DRM_PTN3460 >> - tristate "PTN3460 DP/LVDS bridge" >> +config DRM_BRIDGE > > I'm not convinced this adds any value, to be honest. Hmm, then how to compile drm_bridge.c? > In addition to > whether or not it's useful, it seems like you'd need to stub the > drm_bridge_* functions that are declared in drm_crtc.h or break them > out into drm_bridge.h. Well, Thierry mentioned about this long back. Again, we have the confirmation now! Ajay [snip]
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 --- Comment #7 from sarnex --- (In reply to Michel Dänzer from comment #6) > Created attachment 108567 [details] [review] > radeon/llvm: Dynamically allocate branch/loop stack arrays > > This should be an even better fix, does it work as well? Hi Michel, That patch works for me also. Thanks 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/20141028/56d1f1d6/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 1:41 AM, Sean Paul wrote:
> On Wed, Aug 27, 2014 at 10:29 AM, Ajay Kumar
> wrote:
>> A set of helper functions are defined in this patch to make
>> bridge driver probe independent of the drm flow.
>>
>> The bridge devices register themselves on a lookup table
>> when they get probed by calling "drm_bridge_add".
>>
>> The parent encoder driver waits till the bridge is available
>> in the lookup table(by calling "of_drm_find_bridge") and then
>> continues with its initialization.
>>
>> The encoder driver should also call "drm_bridge_attach" to pass
>> on the drm_device, encoder pointers to the bridge object.
>>
>> drm_bridge_attach inturn calls drm_bridge_init to register itself
>> with the drm core. Later, it calls "bridge->funcs->attach" so that
>> bridge can continue with other initializations.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> drivers/gpu/drm/Makefile |1 +
>> drivers/gpu/drm/bridge/Kconfig | 15 -
>> drivers/gpu/drm/drm_bridge.c | 102
>>
>> drivers/gpu/drm/drm_crtc.c |4 +-
>> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |4 +-
>> include/drm/drm_crtc.h | 12 +++-
>> 6 files changed, 131 insertions(+), 7 deletions(-)
>> create mode 100644 drivers/gpu/drm/drm_bridge.c
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 4a55d59..bdbfb6f 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -19,6 +19,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
>> drm_cache.o \
>> drm-$(CONFIG_COMPAT) += drm_ioc32.o
>> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>> drm-$(CONFIG_PCI) += ati_pcigart.o
>> +drm-$(CONFIG_DRM_BRIDGE) += drm_bridge.o
>> drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>> drm-$(CONFIG_OF) += drm_of.o
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index 884923f..5a8e907 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -1,5 +1,16 @@
>> -config DRM_PTN3460
>> - tristate "PTN3460 DP/LVDS bridge"
>> +config DRM_BRIDGE
>
> I'm not convinced this adds any value, to be honest. In addition to
> whether or not it's useful, it seems like you'd need to stub the
> drm_bridge_* functions that are declared in drm_crtc.h or break them
> out into drm_bridge.h.
>
> Sean
>
>> + tristate
>> depends on DRM
>> select DRM_KMS_HELPER
>> + help
>> + Bridge registration and lookup framework.
>> +
>> +menu "bridge chips"
>> + depends on DRM_BRIDGE
>> +
>> +config DRM_PTN3460
>> + tristate "PTN3460 DP/LVDS bridge"
>> + depends on DRM_BRIDGE
>> ---help---
>> +
>> +endmenu
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> new file mode 100644
>> index 000..b2d43fd
>> --- /dev/null
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -0,0 +1,102 @@
>> +/*
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd
>> + *
>> + * 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, sub license,
>> + * 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 NON-INFRINGEMENT. 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.
>> + */
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#include "drm/drmP.h"
>> +
>> +static DEFINE_MUTEX(bridge_lock);
>> +static LIST_HEAD(bridge_list);
>> +
>> +int drm_bridge_add(struct drm_bridge *bridge)
>> +{
>> + mutex_lock(&bridge_lock);
>> + list_add_tail(&bridge->list, &bridge_list);
>> + mutex_unlock(&bridge_lock);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_add);
>> +
>> +void drm_bridge_remove(struct drm_bridge *bridge)
>> +{
>> + mutex_lock(&bridge_lock);
>> + list_del_init(&bridge->list);
>> + mutex_unlock(&bridge_lock);
>> +}
>> +EXPORT_SYMBOL(drm_bridge_remove);
>> +
>> +int drm_bridge_attach(struct drm_bridge *bridge,
>> + struct drm_enc
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
>> So don't ask why but I accidentally ended up in a branch looking at this
>> patch and didn't like it. So very quick&grumpy review.
>>
>> First, please make the patch subject more descriptive: I'd expect a helper
>> function scaffolding like the various crtc/probe/dp ... helpers we already
>> have. You instead add code to untangle the probe ordering. Please say so.
Sure. I will reword it properly.
>> More comments below.
>>
>> On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
>>> A set of helper functions are defined in this patch to make
>>> bridge driver probe independent of the drm flow.
>>>
>>> The bridge devices register themselves on a lookup table
>>> when they get probed by calling "drm_bridge_add".
>>>
>>> The parent encoder driver waits till the bridge is available
>>> in the lookup table(by calling "of_drm_find_bridge") and then
>>> continues with its initialization.
>>>
>>> The encoder driver should also call "drm_bridge_attach" to pass
>>> on the drm_device, encoder pointers to the bridge object.
>>>
>>> drm_bridge_attach inturn calls drm_bridge_init to register itself
>>> with the drm core. Later, it calls "bridge->funcs->attach" so that
>>> bridge can continue with other initializations.
>>>
>>> Signed-off-by: Ajay Kumar
>>
>> [snip]
>>
>>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
>>> * @driver_private: pointer to the bridge driver's internal context
>>> */
>>> struct drm_bridge {
>>> - struct drm_device *dev;
>>> + struct device *dev;
>>
>> Please don't rename the ->dev pointer into drm. Because _all_ the other
>> drm structures still call it ->dev. Also, can't we use struct device_node
>> here like we do in the of helpers Russell added? See 7e435aad38083
>>
>
> I think this is modeled after the naming in drm_panel,
Right, The entire rework is based on how drm_panel framework is structured.
> FWIW. However,
> seems reasonable to keep the device_node instead.
Yes, its visible that just device_node would be sufficient.
This will save us from renaming drm_device as well.
>>> + struct drm_device *drm;
>>> + struct drm_encoder *encoder;
>>
>> This breaks bridge->bridge chaining (if we ever get there). It seems
>> pretty much unused anyway except for an EBUSY check. Can't you use
>> bridge->dev for that?
>>
>
> Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
> and leave it up to the caller to establish the proper chain.
Ok. I will use drm_device pointer directly instead of passing encoder pointer.
>>> struct list_head head;
>>> + struct list_head list;
>>
>> These lists need better names. I know that the "head" is really awful,
>> especially since it's actually not the head of the list but just an
>> element.
>
> I think we can just rip bridge_list out of mode_config if we're going
> to keep track of bridges elsewhere. So we can nuke "head" and keep
> "list". This also means that bridge->destroy() goes away, but that's
> probably Ok if everything converts to the standalone driver model
> where we have driver->remove()
>
> Sean
Great! Thierry actually mentioned about this once, and we have the
confirmation now.
>>>
>>> struct drm_mode_object base;
>>
>>
>> Aside: I've noticed all this trying to update the kerneldoc for struct
>> drm_bridge, which just showed that this patch makes inconsistent changes.
>> Trying to write kerneldoc is a really great way to come up with better
>> interfaces imo.
>>
>> Cheers, Daniel
I din't get this actually. You want me to create Doc../drm_bridge.txt
or something similar?
Ajay
[Intel-gfx] [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj()
On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Merge it into the plane update_plane() callback and make other
> users use the update_plane() functions instead.
>
> The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
> so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
> and merge both paths into one.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_display.c | 215
> ---
> 1 file changed, 100 insertions(+), 115 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9a913f5..60ec165 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev,
> return true;
> }
>
> -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
> - struct drm_i915_gem_object *obj,
> - uint32_t width, uint32_t height)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe;
> - unsigned old_width;
> - uint32_t addr;
> - int ret;
> -
> - /* if we want to turn off the cursor ignore width and height */
> - if (!obj) {
> - DRM_DEBUG_KMS("cursor off\n");
> - addr = 0;
> - mutex_lock(&dev->struct_mutex);
> - goto finish;
> - }
> -
> - /* we only need to pin inside GTT if cursor is non-phy */
> - mutex_lock(&dev->struct_mutex);
> - if (!INTEL_INFO(dev)->cursor_needs_physical) {
> - unsigned alignment;
> -
> - /*
> - * Global gtt pte registers are special registers which actually
> - * forward writes to a chunk of system memory. Which means that
> - * there is no risk that the register values disappear as soon
> - * as we call intel_runtime_pm_put(), so it is correct to wrap
> - * only the pin/unpin/fence and not more.
> - */
> - intel_runtime_pm_get(dev_priv);
> -
> - /* Note that the w/a also requires 2 PTE of padding following
> - * the bo. We currently fill all unused PTE with the shadow
> - * page and so we should always have valid PTE following the
> - * cursor preventing the VT-d warning.
> - */
> - alignment = 0;
> - if (need_vtd_wa(dev))
> - alignment = 64*1024;
> -
> - ret = i915_gem_object_pin_to_display_plane(obj, alignment,
> NULL);
> - if (ret) {
> - DRM_DEBUG_KMS("failed to move cursor bo into the
> GTT\n");
> - intel_runtime_pm_put(dev_priv);
> - goto fail_locked;
> - }
> -
> - ret = i915_gem_object_put_fence(obj);
> - if (ret) {
> - DRM_DEBUG_KMS("failed to release fence for cursor");
> - intel_runtime_pm_put(dev_priv);
> - goto fail_unpin;
> - }
> -
> - addr = i915_gem_obj_ggtt_offset(obj);
> -
> - intel_runtime_pm_put(dev_priv);
> - } else {
> - int align = IS_I830(dev) ? 16 * 1024 : 256;
> - ret = i915_gem_object_attach_phys(obj, align);
> - if (ret) {
> - DRM_DEBUG_KMS("failed to attach phys object\n");
> - goto fail_locked;
> - }
> - addr = obj->phys_handle->busaddr;
> - }
> -
> - finish:
> - if (intel_crtc->cursor_bo) {
> - if (!INTEL_INFO(dev)->cursor_needs_physical)
> -
> i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
> - }
> -
> - i915_gem_track_fb(intel_crtc->cursor_bo, obj,
> - INTEL_FRONTBUFFER_CURSOR(pipe));
> - mutex_unlock(&dev->struct_mutex);
> -
> - old_width = intel_crtc->cursor_width;
> -
> - intel_crtc->cursor_addr = addr;
> - intel_crtc->cursor_bo = obj;
> - intel_crtc->cursor_width = width;
> - intel_crtc->cursor_height = height;
> -
> - if (intel_crtc->active) {
> - if (old_width != width)
> - intel_update_watermarks(crtc);
> - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
> -
> - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
> - }
> -
> - return 0;
> -fail_unpin:
> - i915_gem_object_unpin_from_display_plane(obj);
> -fail_locked:
> - mutex_unlock(&dev->struct_mutex);
> - return ret;
> -}
> -
> static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
>u16 *bl
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Hello, i have an issue with Skype lately (i compile mesa, kernel, drm, xserver from git periodically and i use a A8-6500 with its IGP with r600g and glamor). It crashes the x server if i use bi directional video call. It seems to work in one-way video. The x server restarts, but skype continues to work for about half a minute more, including sending video. One problem is that i dont see any errors in any logs, not dmesg or xorg log so i cant say which component is the culprit. Now it seems that a similar issue existed in the past and it was related to some drivers that couldnt handle multiple xv instances (one for the received video, the other for the local video thumbnail). And there was a workaround of disabling the local video thumbnail which cant be done on the current Skype (4.3). The glamor xv reports 16 available ports though. Is there any other way of diagnosing this error? Maybe i have some issue with the 32 bit driver installation? Although i had no problems whatsoever (gaming on Steam, vdpau etc works well for example) other than this.
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On 10/27/14 06:13, Tomi Valkeinen wrote: > On 27/10/14 13:59, Jani Nikula wrote: > >>> While doing 'depends on' instead of 'select' is an "easy" fix for this, >>> I do dislike it quite a bit. It's a major pain to go around the kernel >>> config, trying to find all the dependencies that a particular driver >>> wants. If I need fb-foobar, I should just be able to enable it, instead >>> of first searching and selecting its minor dependencies individually. >> >> Agreed, but I don't think that's specific to this patch. > > Well, no, the generic problem is not specific to this patch, but we can > avoid the issue with proper use of 'select' (at least in some cases), > which is specific to this patch. > >>> So, not a NACK, but a "isn't there an another way to fix this?". >> >> I think the real answer would be to fix kconfig to also show menu items >> whose dependencies are not met, and then recursively enabling the >> dependencies when the item is enabled. Beyond my scope. >> >>> Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta" >>> option, it only enables a Kconfig submenu. >>> >>> So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option. >>> But if we do that, all the items in drivers/video/backlight/Kconfig with >>> default 'y' or 'm' would get enabled by default, so I think we should >>> remove the 'default's from that file. That makes sense in any case, as I >>> don't see why "HP Jornada 700 series LCD Driver" should be "default y". >>> >>> BACKLIGHT_CLASS_DEVICE doesn't depend on anything except >>> BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should >>> be safe to 'select' BACKLIGHT_CLASS_DEVICE. >>> >>> BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in >>> drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE >>> could be made to select BACKLIGHT_CLASS_DEVICE instead. >> >> I think it should be possible to choose between y and m when it's > > If I'm not mistaken, if CONFIG_FOO is 'm', and it 'select's CONFIG_BAR, > and CONFIG_BAR is tristate, then CONFIG_BAR will be set to 'm'. > >> selected, and it should be possible to enable it when it's not selected >> by any drivers. I'm not sure a hidden option is good for that. > > Why would you want to enable it if no one uses it? Does > BACKLIGHT_CLASS_DEVICE enable something even if no driver uses it? > >>> That doesn't exactly fix anything, but I think it makes sense as >>> BACKLIGHT_CLASS_DEVICE is something that's selected from all around the >>> kernel, so it should be a selectable "library" instead of a Kconfig menu >>> option. >> >> At least for drm/i915 BACKLIGHT_CLASS_DEVICE is "an option". We use it >> if it's enabled, but we are just fine if it's not. I've learned the way >> to express that is >> >> depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n >> >> but I don't think there's a way to express that in terms of select, is >> there? The dependency above guarantees there's no DRM_I915=y and >> BACKLIGHT_CLASS_DEVICE=m combo which would fail. And this, btw, is where >> this whole patch got started, as select didn't handle that properly. > > If backlight support is considered an option for drm/i915, then I think > there should be a Kconfig option for i915 to enable backlight support, > which in turn selects BACKLIGHT_CLASS_DEVICE. And that select will force > BACKLIGHT_CLASS_DEVICE to be built-in if drm/i915 is built-in. > > Oh, but it doesn't work optimally with modules. The new option needed > for that would be boolean, so BACKLIGHT_CLASS_DEVICE would always be > either y or n. Sigh... > >>> I didn't look at the ACPI_VIDEO side, so no idea how messy that is. >> >> Basically it's another dependency on BACKLIGHT_CLASS_DEVICE. I can only >> imagine trying to solve this problem with select is going to end up in >> recursive dependencies that spread out and need changing about as wide >> as this patch. > > If ACPI_VIDEO uses select to enable BACKLIGHT_CLASS_DEVICE, then, I > think, selecting ACPI_VIDEO will also select BACKLIGHT_CLASS_DEVICE. So > I don't right away see any recursive dependencies. Or what did you have > in mind? > >> In the end, I agree with the problem you have with this patch, but yet I >> think it's the right thing to do in terms of expressing the >> dependencies. > > Well, dri/i915 doesn't exactly depend on backlight, if I understood you > correctly. Instead, backlight is an option for dri/i915, and you kind of > hack it to be implemented with that 'depends on BACKLIGHT_CLASS_DEVICE > || BACKLIGHT_CLASS_DEVICE=n'. > > I guess it's debatable whether drivers should automatically use features > in the kernel if they happen to be enabled in the Kconfig, or should > they be individually enabled for that driver. I personally like the > latter option, as it allows more precise control, but it probably also > depends on the feature in question. > > I also think the 'depends on BACKLIGHT_CLASS_DEVICE || > BACKLIGHT_CLASS_DEV
[libdrm]: drmOpen failed issue
Hello,
I find a drmOpen failed issue in our system as below description:
platform: ivy-bridge
OS: Ubuntu12.04 LTS
kernel: 3.13.0-32-generic
libdrm: libdrm-2.4.46
root at tchen37-ivb:/home/tchen37/ws/lib3app/utests# ./test_osd
DRM_IOCTL_I915_GEM_APERTURE failed: Bad file descriptor
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [9]
param: 4, val: 0
Segmentation fault (core dumped)
by debugging libdrm code, I find following changes resolve the problem
diff --git a/xf86drm.c b/xf86drm.c
index 4791a05..3c7c362 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -562,7 +562,7 @@ static int drmOpenByName(const char *name)
drmFreeVersion(version);
id = drmGetBusid(fd);
drmMsg("drmGetBusid returned '%s'\n", id ? id : "NULL");
- if (!id || !*id) {
+ if (id || *id) {
if (id)
drmFreeBusid(id);
return fd;
I know I'm not using the latest version of libdrm, but I confirm that latest
code remains same for this scenario.
Is it possible a bug of libdrm?
Thanks,
-Jet
[PATCH 1/5] drm/radeon: Set TTM_PL_FLAG_TOPDOWN also for RADEON_GEM_CPU_ACCESS BOs
On Tue, 28 Oct 2014 18:35:02 +0900 Michel Dänzer wrote: > From: Michel Dänzer > > I wasn't sure if TTM_PL_FLAG_TOPDOWN works correctly with non-0 lpfn, but > AFAICT it does. > > Signed-off-by: Michel Dänzer This series is Reviewed-by: Lauri Kasanen - Lauri
[PATCH 02/11 V2] radeon: evergreen: Fix probable mask then right shift defect
On 27.10.2014 23:14, Joe Perches wrote:
> Precedence of & and >> is not the same and is not left to right.
> shift has higher precedence and should be done after the mask.
>
> Add parentheses around the mask.
>
> Use the already #defined values instead of hardcoding.
>
> Signed-off-by: Joe Perches
> ---
>> I think this should be NUM_SHADER_ENGINES_SHIFT?
>
> (Joe can't type)
>
> exactly right, thanks Michel
>
> drivers/gpu/drm/radeon/evergreen.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index a31f1ca..a97a685 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3303,7 +3303,8 @@ static void evergreen_gpu_init(struct radeon_device
> *rdev)
> rdev->config.evergreen.tile_config |=
> ((gb_addr_config & 0x3000) >> 28) << 12;
>
> - num_shader_engines = (gb_addr_config & NUM_SHADER_ENGINES(3) >> 12) + 1;
> + num_shader_engines = ((gb_addr_config & NUM_SHADER_ENGINES_MASK)
> + >> NUM_SHADER_ENGINES_SHIFT) + 1;
>
> if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= CHIP_HEMLOCK)) {
> u32 efuse_straps_4;
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
[PATCH 3/5] drm/ttm: Use only DRM_MM_SEARCH_BELOW for TTM_PL_FLAG_TOPDOWN
On Tue, Oct 28, 2014 at 06:35:04PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> DRM_MM_SEARCH_BEST gets the smallest hole which can fit the BO. That seems
> against the idea of TTM_PL_FLAG_TOPDOWN:
>
> * The smallest hole may be in the overall bottom of the area
> * If the hole isn't much larger than the BO, it doesn't make much
> difference whether the BO is placed at the bottom or at the top of the
> hole
>
> Signed-off-by: Michel Dänzer
tbh I think SEARCH_BEST is pretty much always a bad idea - it rips apart
allocations from the same execbuf, and usually those get recycled around
the same time. Which means you'll just fragment your mm even more if you
try to find the best hole instead of just picking one and the stuffing the
entire execbuf into it. So imo we might as well just kill it.
Another one that I've advertised a bunch of times already is the scan
roaster in drm_mm.c: Currently ttm just evicts until there's a big enough
hole, which is fairly awful if you have quasi-segmented memory like with
top-down/bottom-up schemes and different ranges for different units. With
the roaster you just walk the lru and build up potential holes until
there's a suitable one, and then only evict those buffers. Which means if
you have a certain range of memory under very high pressure (e.g. the 256M
which uvd can use or whatever it is), then you wont thrash all the other
vram too.
Cheers, Daniel
> ---
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> index 1e93f6c..aa0bd05 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
> @@ -69,7 +69,7 @@ static int ttm_bo_man_get_node(struct ttm_mem_type_manager
> *man,
> return -ENOMEM;
>
> if (place->flags & TTM_PL_FLAG_TOPDOWN) {
> - sflags |= DRM_MM_SEARCH_BELOW;
> + sflags = DRM_MM_SEARCH_BELOW;
> aflags = DRM_MM_CREATE_TOP;
> }
>
> --
> 2.1.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj()
Hi Ville,
2014-10-24 Ville Syrjälä :
> On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Merge it into the plane update_plane() callback and make other
> > users use the update_plane() functions instead.
> >
> > The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
> > so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
> > and merge both paths into one.
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 215
> > ---
> > 1 file changed, 100 insertions(+), 115 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9a913f5..60ec165 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev,
> > return true;
> > }
> >
> > -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
> > -struct drm_i915_gem_object *obj,
> > -uint32_t width, uint32_t height)
> > -{
> > - struct drm_device *dev = crtc->dev;
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > - enum pipe pipe = intel_crtc->pipe;
> > - unsigned old_width;
> > - uint32_t addr;
> > - int ret;
> > -
> > - /* if we want to turn off the cursor ignore width and height */
> > - if (!obj) {
> > - DRM_DEBUG_KMS("cursor off\n");
> > - addr = 0;
> > - mutex_lock(&dev->struct_mutex);
> > - goto finish;
> > - }
> > -
> > - /* we only need to pin inside GTT if cursor is non-phy */
> > - mutex_lock(&dev->struct_mutex);
> > - if (!INTEL_INFO(dev)->cursor_needs_physical) {
> > - unsigned alignment;
> > -
> > - /*
> > -* Global gtt pte registers are special registers which actually
> > -* forward writes to a chunk of system memory. Which means that
> > -* there is no risk that the register values disappear as soon
> > -* as we call intel_runtime_pm_put(), so it is correct to wrap
> > -* only the pin/unpin/fence and not more.
> > -*/
> > - intel_runtime_pm_get(dev_priv);
> > -
> > - /* Note that the w/a also requires 2 PTE of padding following
> > -* the bo. We currently fill all unused PTE with the shadow
> > -* page and so we should always have valid PTE following the
> > -* cursor preventing the VT-d warning.
> > -*/
> > - alignment = 0;
> > - if (need_vtd_wa(dev))
> > - alignment = 64*1024;
> > -
> > - ret = i915_gem_object_pin_to_display_plane(obj, alignment,
> > NULL);
> > - if (ret) {
> > - DRM_DEBUG_KMS("failed to move cursor bo into the
> > GTT\n");
> > - intel_runtime_pm_put(dev_priv);
> > - goto fail_locked;
> > - }
> > -
> > - ret = i915_gem_object_put_fence(obj);
> > - if (ret) {
> > - DRM_DEBUG_KMS("failed to release fence for cursor");
> > - intel_runtime_pm_put(dev_priv);
> > - goto fail_unpin;
> > - }
> > -
> > - addr = i915_gem_obj_ggtt_offset(obj);
> > -
> > - intel_runtime_pm_put(dev_priv);
> > - } else {
> > - int align = IS_I830(dev) ? 16 * 1024 : 256;
> > - ret = i915_gem_object_attach_phys(obj, align);
> > - if (ret) {
> > - DRM_DEBUG_KMS("failed to attach phys object\n");
> > - goto fail_locked;
> > - }
> > - addr = obj->phys_handle->busaddr;
> > - }
> > -
> > - finish:
> > - if (intel_crtc->cursor_bo) {
> > - if (!INTEL_INFO(dev)->cursor_needs_physical)
> > -
> > i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
> > - }
> > -
> > - i915_gem_track_fb(intel_crtc->cursor_bo, obj,
> > - INTEL_FRONTBUFFER_CURSOR(pipe));
> > - mutex_unlock(&dev->struct_mutex);
> > -
> > - old_width = intel_crtc->cursor_width;
> > -
> > - intel_crtc->cursor_addr = addr;
> > - intel_crtc->cursor_bo = obj;
> > - intel_crtc->cursor_width = width;
> > - intel_crtc->cursor_height = height;
> > -
> > - if (intel_crtc->active) {
> > - if (old_width != width)
> > - intel_update_watermarks(crtc);
> > - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
> > -
> > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
> > - }
> > -
> > - return 0;
> > -fail_unpin:
> > - i915_gem_object_unpin_from_display_plane(obj);
> > -fail_locked:
> > - mutex_unlock(&dev->struct_mutex);
> > - return
[Bulk] Re: [3.16-rcX][pciehp][radeon] PCIe HotPlug conflicts with radeon GPU
On Mon, Oct 27, 2014 at 12:44 PM, Bjorn Helgaas wrote:
> On Sun, Oct 26, 2014 at 11:31 AM, Alex Deucher
> wrote:
>> On Mon, Oct 13, 2014 at 12:11 PM, Bjorn Helgaas
>> wrote:
>>> [+cc Alex, Christian, dri-devel]
>>>
>>> On Sat, Oct 11, 2014 at 1:37 PM, Shawn Starr
>>> wrote:
On September 11, 2014 04:26:21 PM Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> On Sat, Aug 2, 2014 at 10:02 AM, Shawn Starr
> wrote:
> > Hello devs,
> >
> > There are two issues I am encountering with the PCIe Hotplug driver on
> > my
> > Lenovo Laptop (W500). I note this goes back further than 3.15.
> >
> > It is noted here:
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> > f244d8b623dae7a7bc695b0336f67729b95a9736
> > https://bugzilla.kernel.org/show_bug.cgi?id=79701
> >
> > And my open bug here:
> > https://bugzilla.kernel.org/show_bug.cgi?id=77261
> >
> > 1) If I enable the device to use both the integrated and discrete GPU,
> > pciehp will decide to force unload radeon because it puts itself into a
> > power saving state, fails back to the Intel integrated GPU in this case
> > unless I tell radeon.ko to runpm=0 (no power management, then pciehp
> > wont
> > touch it).
> >
> > 2) If the Radeon GPU resets and you use pci_reset=1 for kernel module
> > option, pciehp decides to force unload radeon even though the GPU is
> > trying to setup after failing.
> >
> > Kernel I am using right now: 3.16.0-0.rc7.git3.1.fc21.x86_64 (about to
> > boot into snapshot kernel-core-3.16.0-0.rc7.git4.1.fc21.x86_64)
> Hi Shawn,
>
> Thanks for the report and sorry that it got dropped. But I see you're
> cc'd on https://bugzilla.kernel.org/show_bug.cgi?id=79701, so you've
> probably seen the work there. If you can try out the patches I just
> posted, that would be great.
>
> Bjorn
Hi Bjorn,
For #1) This is fixed in linux-next (tracking
3.18.0-0.rc0.git1.2.fc22.1.x86_64
nondebug kernel for Fedora). PCIe HotPlug no longer unloads radeon. For
this
bugzilla report we can close it.
#2) This still has weird results however, radeon.hard_reset=1 is
experimental
and while it attempts to reset GPU, PCIe HotPlug seems to interact in this.
This can be tested by adding to grub command line radeon.hard_reset=1.
When X has started up, trigger a reset by cat
/sys/kernel/debug/dri/#/radeon_gpu_reset. It will output 0, cat it again
will
show 1.
Attempt to drag a window. The this will trigger a GPU reset, but fail to
recover, its unknown if PCIe HotPlug is preventing a proper reset or not
but
there is pciehp calls in the stack trace.
>>>
>>> A PCIe device reset usually looks like a hotplug event because the
>>> PCIe link goes down and comes back up. As far as the PCI core is
>>> concerned, it can't tell the difference between (1) a simple reset
>>> where the link bounces and (2) removal of one device followed by
>>> addition of another.
>>>
>>> b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events
>>> for a device") addressed this for some similar cases, but it looks
>>> like we probably need some more calls to pci_ignore_hotplug() in the
>>> radeon driver reset methods.
>>>
>>> Can you please open a bugzilla and attach the complete dmesg log,
>>> including the GPU reset and recovery failure?
>>
>> Is there a way we could temporarily disable pci hotplug around a GPU reset?
>
> There is pci_ignore_hotplug(). Do you mean something more? Oh, I
> guess you mean a way to disable, then *re*-enable hotplug. We can
> easily add that if that would help.
Exactly. I was thinking I could disable hotplug, do the gpu hard
reset, then re-enable hotplug.
Alex
[PATCH] drm/radeon: Clean up radeon_uvd_force_into_uvd_segment
Am 28.10.2014 um 10:28 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> It was adding a second placement for the second 256MB segment of VRAM,
> which is not a good idea for several reasons:
>
> * It fills up the first 256MB segment (which is also typically the CPU
>accessible part) of VRAM first, even for BOs which could go into the
>second 256MB segment. Only once there is no space in the first segment
>does it fall back to the second segment.
> * It doesn't work with RADEON_GEM_NO_CPU_ACCESS BOs, which already use
>two VRAM placements.
>
> Change it to instead restrict the range for each VRAM placement. If the
> BO can go into the second 256MB segment, set up the range to include
> both segments, and set the TTM_PL_FLAG_TOPDOWN flag. That should result
> in preferring the second segment for those BOs, falling back to the
> first segment.
>
> Signed-off-by: Michel Dänzer
I'm not sure if this will work correctly. Please keep in mind that even
if BOs can be in the second segment they are not allowed to cross
segment borders.
E.g. if you just set lpfn = (2 * 256 * 1024 * 1024) >> PAGE_SHIFT it
might happen that the first halve of a BO lands in the first 256MB
segment and the second halve of a BO in the second 256MB segment.
Have you considered that as well?
Regards,
Christian.
> ---
> drivers/gpu/drm/radeon/radeon_uvd.c | 31 +++
> 1 file changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 11b6624..eca0ea96 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -259,27 +259,26 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> void radeon_uvd_force_into_uvd_segment(struct radeon_bo *rbo,
> uint32_t allowed_domains)
> {
> + unsigned lpfn;
> int i;
>
> - for (i = 0; i < rbo->placement.num_placement; ++i) {
> - rbo->placements[i].fpfn = 0 >> PAGE_SHIFT;
> - rbo->placements[i].lpfn = (256 * 1024 * 1024) >> PAGE_SHIFT;
> - }
> -
> - /* If it must be in VRAM it must be in the first segment as well */
> if (allowed_domains == RADEON_GEM_DOMAIN_VRAM)
> - return;
> + /* If it must be in VRAM, it must be in the first 256MB segment
> */
> + lpfn = (256 * 1024 * 1024) >> PAGE_SHIFT;
> + else
> + /* Allow second 256MB segment as well */
> + lpfn = (2 * 256 * 1024 * 1024) >> PAGE_SHIFT;
>
> - /* abort if we already have more than one placement */
> - if (rbo->placement.num_placement > 1)
> - return;
> + for (i = 0; i < rbo->placement.num_placement; ++i) {
> + if (!(rbo->placements[i].flags & TTM_PL_FLAG_VRAM))
> + continue;
>
> - /* add another 256MB segment */
> - rbo->placements[1] = rbo->placements[0];
> - rbo->placements[1].fpfn += (256 * 1024 * 1024) >> PAGE_SHIFT;
> - rbo->placements[1].lpfn += (256 * 1024 * 1024) >> PAGE_SHIFT;
> - rbo->placement.num_placement++;
> - rbo->placement.num_busy_placement++;
> + if (allowed_domains != RADEON_GEM_DOMAIN_VRAM)
> + rbo->placements[i].flags |= TTM_PL_FLAG_TOPDOWN;
> +
> + if (!rbo->placements[i].lpfn || rbo->placements[i].lpfn > lpfn)
> + rbo->placements[i].lpfn = lpfn;
> + }
> }
>
> void radeon_uvd_free_handles(struct radeon_device *rdev, struct drm_file
> *filp)
[PATCH 2/2] drm/qxl: use suggested x/y offset properties to pass guest prefs
From: Dave Airlie
This passes the guest preferences for a where to place the
outputs through to userspace. Userspace would need to be updated
to take note of this information, X server and GNOME.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 0d13962..2b90b53 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -100,14 +100,37 @@ static int
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
return 0;
}
+static void qxl_update_offset_props(struct qxl_device *qdev)
+{
+ struct drm_device *dev = qdev->ddev;
+ struct drm_connector *connector;
+ struct qxl_output *output;
+ struct qxl_head *head;
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ output = drm_connector_to_qxl_output(connector);
+
+ head = &qdev->client_monitors_config->heads[output->index];
+
+ drm_object_property_set_value(&connector->base,
+ dev->mode_config.suggested_x_property, head->x);
+ drm_object_property_set_value(&connector->base,
+ dev->mode_config.suggested_y_property, head->y);
+ }
+}
+
void qxl_display_read_client_monitors_config(struct qxl_device *qdev)
{
+ struct drm_device *dev = qdev->ddev;
while (qxl_display_copy_rom_client_monitors_config(qdev)) {
qxl_io_log(qdev, "failed crc check for client_monitors_config,"
" retrying\n");
}
+ drm_modeset_lock_all(dev);
+ qxl_update_offset_props(qdev);
+ drm_modeset_unlock_all(dev);
if (!drm_helper_hpd_irq_event(qdev->ddev)) {
/* notify that the monitor configuration changed, to
adjust at the arbitrary resolution */
@@ -951,6 +974,10 @@ static int qdev_output_init(struct drm_device *dev, int
num_output)
drm_object_attach_property(&connector->base,
qdev->hotplug_mode_update_property, 0);
+ drm_object_attach_property(&connector->base,
+ dev->mode_config.suggested_x_property, 0);
+ drm_object_attach_property(&connector->base,
+ dev->mode_config.suggested_y_property, 0);
drm_connector_register(connector);
return 0;
}
@@ -1064,6 +1091,7 @@ int qxl_modeset_init(struct qxl_device *qdev)
qdev->ddev->mode_config.fb_base = qdev->vram_base;
+ drm_mode_create_suggested_offset_properties(qdev->ddev);
qxl_mode_create_hotplug_mode_update_property(qdev);
for (i = 0 ; i < qxl_num_crtc; ++i) {
--
1.9.3
[PATCH 1/2] drm: add properties for suggested x/y offset for connectors.
From: Dave Airlie
Virtual GPUs would like to give the guest some indication where on the screen
the outputs are layed out. So far we only provide modes, these
properties could be exposed to userspace so the desktop environment
could use them as hints to set the correct offsets.
Signed-off-by: Dave Airlie
---
Documentation/DocBook/drm.tmpl | 17 -
drivers/gpu/drm/drm_crtc.c | 24
include/drm/drm_crtc.h | 5 +
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index be35bc3..a434040 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2507,7 +2507,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions
- DRM
+ DRM
Generic
âEDIDâ
BLOB | IMMUTABLE
@@ -2638,6 +2638,21 @@ void intel_crt_init(struct drm_device *dev)
TBD
+ Virtual GPU
+ âsuggested Xâ
+ RANGE
+ Min=0, Max=0x
+ Connector
+ property to suggest an X offset for a connector
+
+
+ âsuggested Yâ
+ RANGE
+ Min=0, Max=0x
+ Connector
+ property to suggest an Y offset for a connector
+
+
Optional
âscaling modeâ
ENUM
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..15679a7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1535,6 +1535,30 @@ int drm_mode_create_dirty_info_property(struct
drm_device *dev)
}
EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
+/**
+ * drm_mode_create_suggested_offset_properties - create suggests offset
properties
+ * @dev: DRM device
+ *
+ * Create the the suggested x/y offset property for connectors.
+ */
+int drm_mode_create_suggested_offset_properties(struct drm_device *dev)
+{
+ if (dev->mode_config.suggested_x_property &&
dev->mode_config.suggested_y_property)
+ return 0;
+
+ dev->mode_config.suggested_x_property =
+ drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
"suggested_x", 0, 0x);
+
+ dev->mode_config.suggested_y_property =
+ drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
"suggested_y", 0, 0x);
+
+ if (dev->mode_config.suggested_x_property == NULL ||
+ dev->mode_config.suggested_y_property == NULL)
+ return -ENOMEM;
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_suggested_offset_properties);
+
static int drm_mode_group_init(struct drm_device *dev, struct drm_mode_group
*group)
{
uint32_t total_objects = 0;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..01da16a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -851,6 +851,10 @@ struct drm_mode_config {
struct drm_property *aspect_ratio_property;
struct drm_property *dirty_info_property;
+ /* properties for virtual machine layout */
+ struct drm_property *suggested_x_property;
+ struct drm_property *suggested_y_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
@@ -1046,6 +1050,7 @@ extern int drm_mode_create_tv_properties(struct
drm_device *dev, int num_formats
extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
+extern int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
extern int drm_mode_connector_attach_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
--
1.9.3
[rfc] suggested offset properties + qxl support
There was some discussion on spice irc channel somewhere last week about how best to take note of the x/y offsets that were suggested by the hosts into the guests, so that the guest can configured the monitors in the same layout as they are on the host side. I think initially the kernel needs to just propogate the values to userspace, so I've created two properties. The X server and desktop environments should start to use these properties to set things correctly. Dave.
[Bug 84977] r300/compiler: register allocation pass generate invalid swizzle for r300/r400
https://bugs.freedesktop.org/show_bug.cgi?id=84977 --- Comment #10 from David Heidelberger (okias) --- class_index: 1, dstindex: 8, writemask: 3, can_change: 0 class_index: 0, dstindex: 35, writemask: 1, can_change: 1 class_index: 0, dstindex: 41, writemask: 1, can_change: 1 class_index: 0, dstindex: 20, writemask: 1, can_change: 1 class_index: 1, dstindex: 9, writemask: 3, can_change: 0 class_index: 1, dstindex: 10, writemask: 3, can_change: 0 class_index: 0, dstindex: 45, writemask: 1, can_change: 1 class_index: 0, dstindex: 38, writemask: 1, can_change: 1 class_index: 1, dstindex: 11, writemask: 3, can_change: 0 class_index: 1, dstindex: 12, writemask: 3, can_change: 0 class_index: 0, dstindex: 13, writemask: 4, can_change: 1 class_index: 0, dstindex: 14, writemask: 4, can_change: 1 class_index: 0, dstindex: 15, writemask: 4, can_change: 1 class_index: 4, dstindex: 16, writemask: 12, can_change: 0 class_index: 1, dstindex: 17, writemask: 3, can_change: 0 class_index: 0, dstindex: 18, writemask: 2, can_change: 1 class_index: 0, dstindex: 30, writemask: 1, can_change: 1 output with additional code: if (writemask == 12) can_change_writemask = 0; // which is WZ later converted to WX -- 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/20141028/a5897ebc/attachment.html>
[Bug 84977] r300/compiler: register allocation pass generate invalid swizzle for r300/r400
https://bugs.freedesktop.org/show_bug.cgi?id=84977 --- Comment #9 from David Heidelberger (okias) --- class_index: 1, dstindex: 8, writemask: 3, can_change: 0 class_index: 0, dstindex: 35, writemask: 1, can_change: 1 class_index: 0, dstindex: 41, writemask: 1, can_change: 1 class_index: 0, dstindex: 20, writemask: 1, can_change: 1 class_index: 1, dstindex: 9, writemask: 3, can_change: 0 class_index: 1, dstindex: 10, writemask: 3, can_change: 0 class_index: 0, dstindex: 45, writemask: 1, can_change: 1 class_index: 0, dstindex: 38, writemask: 1, can_change: 1 class_index: 1, dstindex: 11, writemask: 3, can_change: 0 class_index: 1, dstindex: 12, writemask: 3, can_change: 0 class_index: 0, dstindex: 13, writemask: 4, can_change: 1 class_index: 0, dstindex: 14, writemask: 4, can_change: 1 class_index: 0, dstindex: 15, writemask: 4, can_change: 1 class_index: 4, dstindex: 16, writemask: 12, can_change: 1 class_index: 1, dstindex: 17, writemask: 3, can_change: 0 class_index: 0, dstindex: 18, writemask: 2, can_change: 1 class_index: 0, dstindex: 30, writemask: 1, can_change: 1 Not a native swizzle: 0fc3 Not sure, if I fully get it. It has only INST up to 43. Why is there dstindex 45? -- 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/20141028/c8db0ff6/attachment-0001.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
> Hi Daniel and Sean,
>
> Thanks for the comments!
>
> On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul wrote:
>> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
>>> So don't ask why but I accidentally ended up in a branch looking at this
>>> patch and didn't like it. So very quick&grumpy review.
>>>
>>> First, please make the patch subject more descriptive: I'd expect a helper
>>> function scaffolding like the various crtc/probe/dp ... helpers we already
>>> have. You instead add code to untangle the probe ordering. Please say so.
> Sure. I will reword it properly.
>
>>> More comments below.
>>>
>>> On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
A set of helper functions are defined in this patch to make
bridge driver probe independent of the drm flow.
The bridge devices register themselves on a lookup table
when they get probed by calling "drm_bridge_add".
The parent encoder driver waits till the bridge is available
in the lookup table(by calling "of_drm_find_bridge") and then
continues with its initialization.
The encoder driver should also call "drm_bridge_attach" to pass
on the drm_device, encoder pointers to the bridge object.
drm_bridge_attach inturn calls drm_bridge_init to register itself
with the drm core. Later, it calls "bridge->funcs->attach" so that
bridge can continue with other initializations.
Signed-off-by: Ajay Kumar
>>>
>>> [snip]
>>>
@@ -660,8 +662,11 @@ struct drm_bridge_funcs {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
- struct drm_device *dev;
+ struct device *dev;
>>>
>>> Please don't rename the ->dev pointer into drm. Because _all_ the other
>>> drm structures still call it ->dev. Also, can't we use struct device_node
>>> here like we do in the of helpers Russell added? See 7e435aad38083
>>>
>>
>> I think this is modeled after the naming in drm_panel,
> Right, The entire rework is based on how drm_panel framework is structured.
>
>> FWIW. However,
>> seems reasonable to keep the device_node instead.
> Yes, its visible that just device_node would be sufficient.
> This will save us from renaming drm_device as well.
>
+ struct drm_device *drm;
+ struct drm_encoder *encoder;
>>>
>>> This breaks bridge->bridge chaining (if we ever get there). It seems
>>> pretty much unused anyway except for an EBUSY check. Can't you use
>>> bridge->dev for that?
>>>
>>
>> Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
>> and leave it up to the caller to establish the proper chain.
> Ok. I will use drm_device pointer directly instead of passing encoder pointer.
Hm, if you do this can you pls also update drm_panel accordingly? It
shouldn't be a lot of fuzz and would make things around drm+dt more
consistent.
>
struct list_head head;
+ struct list_head list;
>>>
>>> These lists need better names. I know that the "head" is really awful,
>>> especially since it's actually not the head of the list but just an
>>> element.
>>
>> I think we can just rip bridge_list out of mode_config if we're going
>> to keep track of bridges elsewhere. So we can nuke "head" and keep
>> "list". This also means that bridge->destroy() goes away, but that's
>> probably Ok if everything converts to the standalone driver model
>> where we have driver->remove()
>>
>> Sean
> Great! Thierry actually mentioned about this once, and we have the
> confirmation now.
>
struct drm_mode_object base;
>>>
>>>
>>> Aside: I've noticed all this trying to update the kerneldoc for struct
>>> drm_bridge, which just showed that this patch makes inconsistent changes.
>>> Trying to write kerneldoc is a really great way to come up with better
>>> interfaces imo.
>>>
>>> Cheers, Daniel
> I din't get this actually. You want me to create Doc../drm_bridge.txt
> or something similar?
If you want to document drm_bridge then I recomment to sprinkle proper
kerneldoc over drm_bridge.c and pull it all into the drm DocBook
template. That way all the drm documentation is in one place. I've
done that for drm_crtc.h in an unrelated patch series (but based upon
a branch with your patch here included) and there's struct drm_bridge*
in there. Hence why I've noticed.
If you do kerneldoc/DocBook integration for drm_bridge it's probably
best to also do it for drm_panel and use the opportunity to
review/rework the interfaces a bit for consistency. E.g. move dt
related stuff into drm_of.c and have that in a separate section in the
docs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #187 from Daniel Kozak --- After reinstall my arch workstation, I am unable to reproduce this issue anymore. Even with same mesa, linux, and linux-firmware versions as before. -- 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/20141028/c86d781d/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 10:19 AM, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote:
>> On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter wrote:
>>> On Tue, Oct 28, 2014 at 10:21 AM, Ajay kumar wrote:
Hi Daniel and Sean,
Thanks for the comments!
On Tue, Oct 28, 2014 at 1:28 AM, Sean Paul
wrote:
> On Mon, Oct 27, 2014 at 3:01 PM, Daniel Vetter wrote:
>> So don't ask why but I accidentally ended up in a branch looking at this
>> patch and didn't like it. So very quick&grumpy review.
>>
>> First, please make the patch subject more descriptive: I'd expect a
>> helper
>> function scaffolding like the various crtc/probe/dp ... helpers we
>> already
>> have. You instead add code to untangle the probe ordering. Please say so.
Sure. I will reword it properly.
>> More comments below.
>>
>> On Wed, Aug 27, 2014 at 07:59:37PM +0530, Ajay Kumar wrote:
>>> A set of helper functions are defined in this patch to make
>>> bridge driver probe independent of the drm flow.
>>>
>>> The bridge devices register themselves on a lookup table
>>> when they get probed by calling "drm_bridge_add".
>>>
>>> The parent encoder driver waits till the bridge is available
>>> in the lookup table(by calling "of_drm_find_bridge") and then
>>> continues with its initialization.
>>>
>>> The encoder driver should also call "drm_bridge_attach" to pass
>>> on the drm_device, encoder pointers to the bridge object.
>>>
>>> drm_bridge_attach inturn calls drm_bridge_init to register itself
>>> with the drm core. Later, it calls "bridge->funcs->attach" so that
>>> bridge can continue with other initializations.
>>>
>>> Signed-off-by: Ajay Kumar
>>
>> [snip]
>>
>>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
>>> * @driver_private: pointer to the bridge driver's internal context
>>> */
>>> struct drm_bridge {
>>> - struct drm_device *dev;
>>> + struct device *dev;
>>
>> Please don't rename the ->dev pointer into drm. Because _all_ the other
>> drm structures still call it ->dev. Also, can't we use struct device_node
>> here like we do in the of helpers Russell added? See 7e435aad38083
>>
>
> I think this is modeled after the naming in drm_panel,
Right, The entire rework is based on how drm_panel framework is structured.
> FWIW. However,
> seems reasonable to keep the device_node instead.
Yes, its visible that just device_node would be sufficient.
This will save us from renaming drm_device as well.
>>> + struct drm_device *drm;
>>> + struct drm_encoder *encoder;
>>
>> This breaks bridge->bridge chaining (if we ever get there). It seems
>> pretty much unused anyway except for an EBUSY check. Can't you use
>> bridge->dev for that?
>>
>
> Yeah, I'd prefer to pass drm_device directly into drm_bridge_attach
> and leave it up to the caller to establish the proper chain.
Ok. I will use drm_device pointer directly instead of passing encoder
pointer.
>>>
>>> Hm, if you do this can you pls also update drm_panel accordingly? It
>>> shouldn't be a lot of fuzz and would make things around drm+dt more
>>> consistent.
>> Are you talking about using struct device_node instead of struct device?
>> I guess you have misplaced the comment under the wrong section!
>
> Yeah, that should have been one up ;-)
>
>>> struct list_head head;
>>> + struct list_head list;
>>
>> These lists need better names. I know that the "head" is really awful,
>> especially since it's actually not the head of the list but just an
>> element.
>
> I think we can just rip bridge_list out of mode_config if we're going
> to keep track of bridges elsewhere. So we can nuke "head" and keep
> "list". This also means that bridge->destroy() goes away, but that's
> probably Ok if everything converts to the standalone driver model
> where we have driver->remove()
>
> Sean
Great! Thierry actually mentioned about this once, and we have the
confirmation now.
>>>
>>> struct drm_mode_object base;
>>
>>
>> Aside: I've noticed all this trying to update the kerneldoc for struct
>> drm_bridge, which just showed that this patch makes inconsistent changes.
>> Trying to write kerneldoc is a really great way to come up with better
>> interfaces imo.
>>
>> Cheers, Daniel
I din't get this actually. You want me to create Doc../drm_bridge.txt
or something similar?
>>>
>>> If you want to document drm_bridge then I recomment to sprinkle proper
>>> kerneldoc over drm_bridge.c and pull it all into the drm DocBook
>>> template. That way all the drm documentation is in one place. I've
>>> done that for drm_crtc.h in an unrelated patch series (
[Bulk] Re: [3.16-rcX][pciehp][radeon] PCIe HotPlug conflicts with radeon GPU
[+cc Alex Williamson, Rajat]
On Tue, Oct 28, 2014 at 9:45 AM, Alex Deucher wrote:
> On Mon, Oct 27, 2014 at 12:44 PM, Bjorn Helgaas
> wrote:
>> On Sun, Oct 26, 2014 at 11:31 AM, Alex Deucher
>> wrote:
>>> On Mon, Oct 13, 2014 at 12:11 PM, Bjorn Helgaas
>>> wrote:
[+cc Alex, Christian, dri-devel]
On Sat, Oct 11, 2014 at 1:37 PM, Shawn Starr
wrote:
> On September 11, 2014 04:26:21 PM Bjorn Helgaas wrote:
>> [+cc linux-pci]
>>
>> On Sat, Aug 2, 2014 at 10:02 AM, Shawn Starr
>> wrote:
>> > Hello devs,
>> >
>> > There are two issues I am encountering with the PCIe Hotplug driver on
>> > my
>> > Lenovo Laptop (W500). I note this goes back further than 3.15.
>> >
>> > It is noted here:
>> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
>> > f244d8b623dae7a7bc695b0336f67729b95a9736
>> > https://bugzilla.kernel.org/show_bug.cgi?id=79701
>> >
>> > And my open bug here:
>> > https://bugzilla.kernel.org/show_bug.cgi?id=77261
>> >
>> > 1) If I enable the device to use both the integrated and discrete GPU,
>> > pciehp will decide to force unload radeon because it puts itself into a
>> > power saving state, fails back to the Intel integrated GPU in this case
>> > unless I tell radeon.ko to runpm=0 (no power management, then pciehp
>> > wont
>> > touch it).
>> >
>> > 2) If the Radeon GPU resets and you use pci_reset=1 for kernel module
>> > option, pciehp decides to force unload radeon even though the GPU is
>> > trying to setup after failing.
>> >
>> > Kernel I am using right now: 3.16.0-0.rc7.git3.1.fc21.x86_64 (about to
>> > boot into snapshot kernel-core-3.16.0-0.rc7.git4.1.fc21.x86_64)
>> Hi Shawn,
>>
>> Thanks for the report and sorry that it got dropped. But I see you're
>> cc'd on https://bugzilla.kernel.org/show_bug.cgi?id=79701, so you've
>> probably seen the work there. If you can try out the patches I just
>> posted, that would be great.
>>
>> Bjorn
>
> Hi Bjorn,
>
> For #1) This is fixed in linux-next (tracking
> 3.18.0-0.rc0.git1.2.fc22.1.x86_64
> nondebug kernel for Fedora). PCIe HotPlug no longer unloads radeon. For
> this
> bugzilla report we can close it.
>
> #2) This still has weird results however, radeon.hard_reset=1 is
> experimental
> and while it attempts to reset GPU, PCIe HotPlug seems to interact in
> this.
>
> This can be tested by adding to grub command line radeon.hard_reset=1.
> When X has started up, trigger a reset by cat
> /sys/kernel/debug/dri/#/radeon_gpu_reset. It will output 0, cat it again
> will
> show 1.
>
> Attempt to drag a window. The this will trigger a GPU reset, but fail to
> recover, its unknown if PCIe HotPlug is preventing a proper reset or not
> but
> there is pciehp calls in the stack trace.
A PCIe device reset usually looks like a hotplug event because the
PCIe link goes down and comes back up. As far as the PCI core is
concerned, it can't tell the difference between (1) a simple reset
where the link bounces and (2) removal of one device followed by
addition of another.
b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events
for a device") addressed this for some similar cases, but it looks
like we probably need some more calls to pci_ignore_hotplug() in the
radeon driver reset methods.
Can you please open a bugzilla and attach the complete dmesg log,
including the GPU reset and recovery failure?
>>>
>>> Is there a way we could temporarily disable pci hotplug around a GPU reset?
>>
>> There is pci_ignore_hotplug(). Do you mean something more? Oh, I
>> guess you mean a way to disable, then *re*-enable hotplug. We can
>> easily add that if that would help.
>
> Exactly. I was thinking I could disable hotplug, do the gpu hard
> reset, then re-enable hotplug.
That approach sounds fine to me.
We're accumulating ways to deal with this issue, and I wonder if they
could be unified a bit. At least the following are related:
b440bde74f04 PCI: Add pci_ignore_hotplug() to ignore hotplug events
for a device
06a8d89af551 PCI: pciehp: Disable link notification across slot reset
2e35afaefe64 PCI: pciehp: Add reset_slot() method
2e35afaefe64 adds a pciehp reset method that disables presence detect
notification and stops any pciehp polling for events.
06a8d89af551 extends that pciehp reset method to also disable link
status notifications.
b440bde74f04 adds an explicit interface for drivers
(pci_ignore_hotplug()), since some drivers reset devices in
device-specific ways rather than using the pci_reset_function() path.
This leaves notifications enabled but ignores them if they arrive.
And of course, this didn't add a way to *enable* hotplug again, which
is what we need
[Bug 84944] tearing on radeonsi vdpau deinterlacer
https://bugs.freedesktop.org/show_bug.cgi?id=84944 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #26 from Michel Dänzer --- (In reply to Christian König from comment #24) > (In reply to Andy Furniss from comment #23) > > My normal use case, however, is to have 2 screens - TV below monitor + > > different refresh rates. Like this I don't get flips, but I also don't have > > any tearing issues with deint. I always set cpus to perf - so I guess that > > my system is fast enough to handle copy. > > For your case it for some reason don't page flip because of the two screens > setup. DRI2 can only flip if the application window covers the whole X11 desktop, which is probably not the case with several monitors. > And it then indeed most likely tears because the deint shader needs to much > time. De-interlacing happens before the DRI2 buffer swap, so the tearing probably isn't directly related to that. > My best guess is that MythTV is trying to crop the first and last line of > the video to avoid flickering with BOB deinterlacing. But instead of > providing a proper video_source_rect while calling VdpVideoMixerRender they > resize their X window to be two lines less in height which is a really > really bad idea. Sounds like this needs to be fixed in MythTV. Resolving as not our bug. (In reply to warpme from comment #22) > It looks however that only glamor starts to have tearing by this. With EXA, the mechanism controlled by Option "SwapbuffersWait" prevents tearing, but presumably at the cost of one (additional) frame of delay. That mechanism is not available with glamor. -- 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/20141028/d43144a4/attachment.html>
[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties
Hello Ajay, On Thu, Oct 16, 2014 at 11:04 AM, Laurent Pinchart wrote: >> >> Right. It would be great if you guys come to agreement ASAP! > > I don't think we'll agree any time soon, so I believe it's up to you to decide > which option is best based on all arguments that have been presented. > Did you decide what's the correct approach? I don't have a strong opinion, I'm just asking because it would be a pity if your series miss another kernel release... Best regards, Javier
[PATCH] allow 32bpp framebuffers for cirrus drm
On Mo, 2014-10-27 at 22:09 +, Zachary Reizner wrote: > ajax, > What do you mean by a pci revision id bump? Do you want it in qemu or > the kernel? Why is a revision bump needed when none of the behavior of > the cirrus device has changed? revision bump would be needed when adding a new interface (not present in real hardware) to allow for larger pitches, so you could use 32bpp with the default (1024x768) resolution. > I heartily agree, people should stop using cirrus. And qemu > should stop > defaulting to it. Since neither has happened yet, enhancing > the > emulation holds the promise of making the future better... I'll try flip the default. That is more sane than pimping up the cirrus emulation. cheers, Gerd
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 Michel Dänzer changed: What|Removed |Added Attachment #108544|0 |1 is obsolete|| --- Comment #6 from Michel Dänzer --- Created attachment 108567 --> https://bugs.freedesktop.org/attachment.cgi?id=108567&action=edit radeon/llvm: Dynamically allocate branch/loop stack arrays This should be an even better fix, does it work 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/20141028/32d43d30/attachment.html>
[PATCH 02/11 V2] radeon: evergreen: Fix probable mask then right shift defect
On Mon, Oct 27, 2014 at 10:14 AM, Joe Perches wrote:
> Precedence of & and >> is not the same and is not left to right.
> shift has higher precedence and should be done after the mask.
>
> Add parentheses around the mask.
>
> Use the already #defined values instead of hardcoding.
>
> Signed-off-by: Joe Perches
> ---
>> I think this should be NUM_SHADER_ENGINES_SHIFT?
>
> (Joe can't type)
>
> exactly right, thanks Michel
Applied with a compile fix.
Thanks,
Alex
>
> drivers/gpu/drm/radeon/evergreen.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index a31f1ca..a97a685 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3303,7 +3303,8 @@ static void evergreen_gpu_init(struct radeon_device
> *rdev)
> rdev->config.evergreen.tile_config |=
> ((gb_addr_config & 0x3000) >> 28) << 12;
>
> - num_shader_engines = (gb_addr_config & NUM_SHADER_ENGINES(3) >> 12) +
> 1;
> + num_shader_engines = ((gb_addr_config & NUM_SHADER_ENGINES_MASK)
> + >> NUM_SHADER_ENGINES_SHIFT) + 1;
>
> if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= CHIP_HEMLOCK)) {
> u32 efuse_straps_4;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH qxl] qxl: don't create too large primary surface
It's been in Linus tree for a few days now .
c572aaf46f71f63ae5914d4e194a955e0ba1b519
Dave.
On 27 October 2014 23:35, Marc-André Lureau
wrote:
> ping
>
> On Thu, Oct 16, 2014 at 11:39 AM, Marc-André Lureau
> wrote:
>>
>> Limit primary to qemu vgamem size, to avoid reaching
>> qemu guest bug "requested primary larger than framebuffer"
>> on resizing screen too large to fit.
>>
>> Remove unneeded and misleading variables.
>>
>> Related to:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1127552
>>
>> Signed-off-by: Marc-André Lureau
>> ---
>> drivers/gpu/drm/qxl/qxl_display.c | 16
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
>> b/drivers/gpu/drm/qxl/qxl_display.c
>> index 5d7ea24..98a344c 100644
>> --- a/drivers/gpu/drm/qxl/qxl_display.c
>> +++ b/drivers/gpu/drm/qxl/qxl_display.c
>> @@ -523,7 +523,6 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
>> struct qxl_framebuffer *qfb;
>> struct qxl_bo *bo, *old_bo = NULL;
>> struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
>> - uint32_t width, height, base_offset;
>> bool recreate_primary = false;
>> int ret;
>> int surf_id;
>> @@ -553,9 +552,10 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
>> if (qcrtc->index == 0)
>> recreate_primary = true;
>>
>> - width = mode->hdisplay;
>> - height = mode->vdisplay;
>> - base_offset = 0;
>> + if (bo->surf.stride * bo->surf.height > qdev->vram_size) {
>> + DRM_ERROR("Mode doesn't fit in vram size (vgamem)");
>> + return -EINVAL;
>> +}
>>
>> ret = qxl_bo_reserve(bo, false);
>> if (ret != 0)
>> @@ -569,10 +569,10 @@ static int qxl_crtc_mode_set(struct drm_crtc *crtc,
>> if (recreate_primary) {
>> qxl_io_destroy_primary(qdev);
>> qxl_io_log(qdev,
>> - "recreate primary: %dx%d (was %dx%d,%d,%d)\n",
>> - width, height, bo->surf.width,
>> - bo->surf.height, bo->surf.stride,
>> bo->surf.format);
>> - qxl_io_create_primary(qdev, base_offset, bo);
>> + "recreate primary: %dx%d,%d,%d\n",
>> + bo->surf.width, bo->surf.height,
>> + bo->surf.stride, bo->surf.format);
>> + qxl_io_create_primary(qdev, 0, bo);
>> bo->is_primary = true;
>> }
>>
>> --
>> 1.9.3
>>
>
>
>
> --
> Marc-André Lureau
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
https://bugzilla.kernel.org/show_bug.cgi?id=85421 --- Comment #8 from Michel Dänzer --- (In reply to Alan from comment #7) > Reproducable case seems to be using firefox to review/edit an object you've > uploaded to Shapeways. Another one is to load a fairly curved shape into > OpenScad and hit F5 to view then rotate it. Those seem sufficiently different from the scenario described in this report that they should be tracked separately. -- You are receiving this mail because: You are watching the assignee of the bug.
Standard VGA console with DRI/DRM under X?
[+cc David, Alex, Christian, dri-devel] On Tue, Oct 28, 2014 at 12:32 AM, Michael Shell wrote: > > > Greetings, > > Well, I want to be able to have my cake and eat it too. I want to be able to > have the standard VGA/"hardware" classic console (not the framebuffer) but > I still want the /dev/dri/cardX devices so that I can use DRI under Xorg. > > Is this possible and if not, why not? > > > (I do hope I'm not bring up an issue with an obvious fix, but my searching > has not yielded an answer yet. For the record, I'm running modern kernel > (3.16.3) with much older x86 hardware [r100 Radeon video card].) > > > If I boot with the kernel nomodeset option I can get the classic > VGA/"hardware" console, but then I lose support for DRI/DRM: > > Oct 27 15:11:09 X kernel: [drm] Initialized drm 1.1.0 20060810 > Oct 27 15:11:09 X kernel: [drm] VGACON disable radeon kernel modesetting. > Oct 27 15:11:09 X kernel: [drm:radeon_init] *ERROR* No UMS support in radeon > module > > and glxgears et al. turns slow. In more modern Xorg releases, DRI is > required for all hardware acceleration, so having /dev/dri/cardX is very > important: > > http://askubuntu.com/questions/463142/why-x-is-relying-on-software-instead-of-hardware-with-nomodeset-kernel-paramet > > > One reason I do not wish to use the framebuffer console is because of the > small font. 160 columns makes it difficult to tell which [OK] belongs with > which service. The selection of console fonts should always include a > set that gives us an 80 column screen and the docs should point this out. > > And I dislike any blanking or video mode changes during boot. > > Can't the kernel just declare that it is capable of setting the video mode, > provide the /dev/dri/cardX devices and leave the console alone, but still > allow Xorg to call for a new mode and use /dev/dri/cardX if/when it sees fit? > > In an ideal world, there would be some kernel option such as fbcon=no. > > In the kernel Documentation fbcon.txt it mentions "fbcon=map:1 tells fbcon not > to take over the console." But, IIRC, from my tests I wasn't able to use this > to get a VGA/"hardware" console and still be able to have /dev/dri/cardX > devices. > > > > Cheers and thank you, > > Mike Shell > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
On Tue, Oct 28, 2014 at 8:13 AM, Laszlo Kertesz wrote: > Hello, > i have an issue with Skype lately (i compile mesa, kernel, drm, xserver from > git periodically and i use a A8-6500 with its IGP with r600g and glamor). > It crashes the x server if i use bi directional video call. It seems to work > in one-way video. > The x server restarts, but skype continues to work for about half a minute > more, including sending video. > One problem is that i dont see any errors in any logs, not dmesg or xorg log > so i cant say which component is the culprit. > > Now it seems that a similar issue existed in the past and it was related to > some drivers that couldnt handle multiple xv instances (one for the received > video, the other for the local video thumbnail). And there was a workaround > of disabling the local video thumbnail which cant be done on the current > Skype (4.3). The glamor xv reports 16 available ports though. > > Is there any other way of diagnosing this error? Maybe i have some issue > with the 32 bit driver installation? > Although i had no problems whatsoever (gaming on Steam, vdpau etc works well > for example) other than this. > Attach gdb to the xserver and get a backtrace when it crashes. Make sure you install the debug symbols for the xserver, etc. http://www.x.org/wiki/Development/Documentation/ServerDebugging/ Alex
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #186 from Jacob --- (In reply to agapito from comment #184) > (In reply to Michel Dänzer from comment #182) > > Can you bisect which commit in 3.18-rc2 fixed it for you? > > Sorry, I do not know how to do it. But these are the changes between RC1 > (still crashing) and RC2 (stable): > > drm/radeon: reduce sparse false positive warnings > Revert "drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table" > Revert "drm/radeon/dpm: drop clk/voltage dependency filters for SI" > drm/radeon: initialize sadb to NULL in the audio code > drm/radeon: fix speaker allocation setup > drm/radeon: use gart memory for DMA ring tests > drm/radeon: fix vm page table block size calculation > > I am not an expert, but probably: drm/radeon: use gart memory for DMA ring > tests; could be the good commit. > > (In reply to Aaron B from comment #183) > > 3.18 is still crashing for me, I doubt it is fixed. > > rc2 crashed for you? After 24 hours I am still stable. https://wiki.ubuntu.com/Kernel/KernelBisection This guide helped me. Might help you too. In short, you just have to clone the Linux repository, run "git bisect start ", then compile the kernel and test it. If it crashes, then run "git bisect bad", and recompile. If you think you've tested it long enough and the version is stable, then run "git bisect good", and recompile. Continue to do so until no revisions are left to be tested -- 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/20141028/23f715e3/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #185 from Michel Dänzer --- (In reply to agapito from comment #184) > > Can you bisect which commit in 3.18-rc2 fixed it for you? > > Sorry, I do not know how to do it. Search the web for 'git bisect howto'. One gotcha is that you'll need to run 'git bisect good' for bad kernels and vice versa, because git bisect can only isolate good -> bad transitions. > I am not an expert, but probably: drm/radeon: use gart memory for DMA ring > tests; could be the good commit. That should have no effect once the driver is initialized. None of the changes between rc1 and rc2 seem like obvious candidates. -- 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/20141028/644fc20e/attachment-0001.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #184 from agapito --- (In reply to Michel Dänzer from comment #182) > Can you bisect which commit in 3.18-rc2 fixed it for you? Sorry, I do not know how to do it. But these are the changes between RC1 (still crashing) and RC2 (stable): drm/radeon: reduce sparse false positive warnings Revert "drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table" Revert "drm/radeon/dpm: drop clk/voltage dependency filters for SI" drm/radeon: initialize sadb to NULL in the audio code drm/radeon: fix speaker allocation setup drm/radeon: use gart memory for DMA ring tests drm/radeon: fix vm page table block size calculation I am not an expert, but probably: drm/radeon: use gart memory for DMA ring tests; could be the good commit. (In reply to Aaron B from comment #183) > 3.18 is still crashing for me, I doubt it is fixed. rc2 crashed for you? After 24 hours I am still stable. -- 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/20141028/2d76186e/attachment.html>
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #6 from Michael Mair-Keimberger --- (In reply to Dieter Nützel from comment #5) > Can you please test with one of kernel git | 3.18-rc2 | drm-next together > with > git revert 59bc1d8? I've tried it with kernel git 3.18rc2 with a pull a few minutes ago and with `git revert 59bc1d8`. The result looks promising. I've made two benchmarks: 1st 2nd FPS: 18.318.1 Score: 765 757 Min FPS: 5.9 6.3 Max FPS: 32.431.9 I didn't include drm-next simply because i don't know how todo that. :) If you want me to test drm-next as well please point me to some documentation how to include it. :) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #183 from Aaron B --- 3.18 is still crashing for me, I doubt it is fixed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/b2284f67/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #16 from Michel Dänzer --- Can you try a 64-bit kernel? Does it happen with that 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/20141028/32b70806/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #15 from Hamish Wilson --- Created attachment 108548 --> https://bugs.freedesktop.org/attachment.cgi?id=108548&action=edit dmesg output for Hamish Wilson -- 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/20141028/99f3f2bd/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #14 from Hamish Wilson --- Created attachment 108547 --> https://bugs.freedesktop.org/attachment.cgi?id=108547&action=edit Xorg.0.log file for Hamish Wilson -- 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/20141028/b5979822/attachment.html>
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 --- Comment #5 from sarnex --- (In reply to Michel Dänzer from comment #4) > Created attachment 108544 [details] [review] > radeon/llvm: Increase maximum branch depth > > Does this patch fix the problem? Wow, that did it. Great job and thanks. If you need this, Tested-by: Nick Sarnie Thanks 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/20141028/46cabde6/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #13 from Michel Dänzer --- This may be the same or at least related to bug 84627, which seems caused by something subtle in the kernel. -- 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/20141028/28ecbe7b/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #12 from Michel Dänzer --- Hamish, please attach the /var/log/Xorg.0.log file and the output of dmesg. -- 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/20141028/2d565f1e/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #11 from John --- (In reply to Aaron B from comment #7) > I don't have bad rendering during normal renders like you guys, but when > mousing over the bookmarks bar in chromium the overlayed boxes are usually > corrupt for me now. R9 270X. I've had the same issue in chromium with a 280x. (well I haven't tried on bookmarks, but on any other overlay) I found a way to get around it, just move the cursor away, and move it back on, then your overlay should be fine. I *felt* that this issue came from chromium's new ui library, but truly I never tested it so maybe it came from gallium3d. I'll subscribe to this and maybe I'll try building mesa without that commit later this week. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141028/87d5725e/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #10 from Hamish Wilson --- (In reply to Michel Dänzer from comment #9) > Does running the affected apps with the environment variable RADEON_THREAD=0 > work around the problem? Running "RADEON_THREAD=0 quake3" from the terminal still produces image corruptions for me with 10.3.2. -- 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/20141028/ad3d9417/attachment-0001.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #9 from Michel Dänzer --- Does running the affected apps with the environment variable RADEON_THREAD=0 work around the problem? (In reply to Aaron B from comment #7) > I don't have bad rendering during normal renders like you guys, but when > mousing over the bookmarks bar in chromium the overlayed boxes are usually > corrupt for me now. R9 270X. And that's caused by the same Git commit? I.e. if you revert that commit, the problem goes away? -- 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/20141028/4251cd0c/attachment.html>
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 --- Comment #4 from Michel Dänzer --- Created attachment 108544 --> https://bugs.freedesktop.org/attachment.cgi?id=108544&action=edit radeon/llvm: Increase maximum branch depth Does this patch fix 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/20141028/e42ff2a4/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #8 from Emil Velikov --- (In reply to Hamish Wilson from comment #0) > While the bug itself is of course distressing, the main thing that is > confusing me is that I am even having trouble finding mention of Mesa 10.3.2 > release as the website does not mention it and I can not even find an entry > for Mesa 10.3 in the Version field of this very submission form. > Sometime the website takes a bit of time to update as I don't the have access to it atm. Similar story for bugzilla. I'll take a look into getting those resolved. Announcements can bee seen in the mesa-announce ML archive [1], which includes mesa 10.3.2. If you're interest in testing mesa just before it's released, keep an eye open for "New stable branch X candidate" style messages on the mesa-stable ML [2] Pardon for the off topic gents. -Emil [1] http://lists.freedesktop.org/archives/mesa-announce/ [2] http://lists.freedesktop.org/archives/mesa-stable/ -- 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/20141028/3baa7dd4/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #7 from Aaron B --- I don't have bad rendering during normal renders like you guys, but when mousing over the bookmarks bar in chromium the overlayed boxes are usually corrupt for me now. R9 270X. -- 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/20141028/6434c482/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #6 from Hamish Wilson --- [hamish at Griffindor mesa]$ git bisect bad 64c2bdc334ba472603b1e7cd2c3046cfbce285b6 is the first bad commit commit 64c2bdc334ba472603b1e7cd2c3046cfbce285b6 Author: Michel Dänzer Date: Tue Aug 26 18:21:50 2014 +0900 r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers Putting those in VRAM can cause long pauses due to buffers being moved into / out of VRAM. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84662 Cc: mesa-stable at lists.freedesktop.org Reviewed-by: Alex Deucher (cherry picked from commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786) :04 04 3d09f050c7cf6907d82aebab6bd1d4f719729712 290288e425b6751de0c5f8e02f9d50f566a8d2f3 Msrc [hamish at Griffindor mesa]$ -- 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/20141028/904f1c1e/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #5 from Hamish Wilson --- So it looks like "r600g,radeonsi: Always use GTT again" is the culprit. Sorry for doing it is as two posts; this my first time bisecting and I did not realize at first I needed to do one more step. -- 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/20141028/73bcbd16/attachment.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #4 from Hamish Wilson --- [hamish at Griffindor mesa]$ git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [64c2bdc334ba472603b1e7cd2c3046cfbce285b6] r600g,radeonsi: Always use GTT again for PIPE_USAGE_STREAM buffers [hamish at Griffindor mesa]$ -- 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/20141028/27385151/attachment-0001.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 --- Comment #3 from Hamish Wilson --- (In reply to Alex Deucher from comment #2) > Can you bisect mesa to indentify the problematic commit between 10.3.1 and > 10.3.2? there are only a few changes between the two versions: > http://cgit.freedesktop.org/mesa/mesa/log/?h=10.3 [hamish at Griffindor mesa]$ git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [85d7eb730a1cbfbd4c9b2ecd017f6b8dab40b20d] i965: Add a BRW_MOCS_PTE #define. [hamish at Griffindor mesa]$ -- 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/20141028/acd2581f/attachment.html>
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #10 from Michel Dänzer --- (In reply to Rafael Pereira from comment #9) > I performed the bisection and that is result: [...] > # first bad commit: [920f946428b70494eb1c64e0de260da0d8bde040] Merge branch > 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next Still same answer as in comment #6, I'm afraid. That commit doesn't directly affect the radeon driver AFAICT, so it can't be the cause of your problem. Please try bisecting again, but make sure you test several (at least three, but the more the better) times before running git bisect good. -- 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/20141028/55b38fb3/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #182 from Michel Dänzer --- (In reply to Maximilian Böhm from comment #179) > Just want to remind you that there is a Mesa connection somehow. I've seen that mentioned before, but the answer is always the same: Please bisect Mesa. (In reply to agapito from comment #180) > I know it's early to say this but 3.18 rc2 solved this bug for me. Can you bisect which commit in 3.18-rc2 fixed it for you? -- 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/20141028/1158b1ca/attachment.html>
