from:"Paul Menzel"

Re: [Intel-gfx] [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

2022-04-07 Thread Paul Menzel


Dear Arunpravin,


Thank you for your patch.

Am 07.04.22 um 07:46 schrieb Arunpravin Paneer Selvam:

- Switch to drm buddy allocator
- Add resource cursor support for drm buddy


I though after the last long discussion, you would actually act on the 
review comments. Daniel wrote a good summary, you could more or less 
copy and past. So why didn’t you?


So, I really wish to not have the patch commit as is.

The summary should also say something about using mutex over spinlocks. 
For me the version change summaries below are just for reviewers of 
earlier iterations to see what changed, and not something to be read easily.



Kind regards,

Paul



v2(Matthew Auld):
   - replace spinlock with mutex as we call kmem_cache_zalloc
 (..., GFP_KERNEL) in drm_buddy_alloc() function

   - lock drm_buddy_block_trim() function as it calls
 mark_free/mark_split are all globally visible

v3(Matthew Auld):
   - remove trim method error handling as we address the failure case
 at drm_buddy_block_trim() function

v4:
   - fix warnings reported by kernel test robot 

v5:
   - fix merge conflict issue

v6:
   - fix warnings reported by kernel test robot 

v7:
   - remove DRM_BUDDY_RANGE_ALLOCATION flag usage

v8:
   - keep DRM_BUDDY_RANGE_ALLOCATION flag usage
   - resolve conflicts created by drm/amdgpu: remove VRAM accounting v2

v9(Christian):
   - merged the below patch
  - drm/amdgpu: move vram inline functions into a header
   - rename label name as fallback
   - move struct amdgpu_vram_mgr to amdgpu_vram_mgr.h
   - remove unnecessary flags from struct amdgpu_vram_reservation
   - rewrite block NULL check condition
   - change else style as per coding standard
   - rewrite the node max size
   - add a helper function to fetch the first entry from the list

v10(Christian):
- rename amdgpu_get_node() function name as amdgpu_vram_mgr_first_block

v11:
- if size is not aligned with min_page_size, enable is_contiguous flag,
  therefore, the size round up to the power of two and trimmed to the
  original size.
v12:
- rename the function names having prefix as amdgpu_vram_mgr_*()
- modify the round_up() logic conforming to contiguous flag enablement
  or if size is not aligned to min_block_size
- modify the trim logic
- rename node as block wherever applicable

Signed-off-by: Arunpravin Paneer Selvam 
---
  drivers/gpu/drm/Kconfig   |   1 +
  .../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h|  97 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |  10 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  | 359 ++
  4 files changed, 291 insertions(+), 176 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f1422bee3dcc..5133c3f028ab 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -280,6 +280,7 @@ config DRM_AMDGPU
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+   select DRM_BUDDY
help
  Choose this option if you have a recent AMD Radeon graphics card.
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h

index acfa207cf970..6546552e596c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -30,12 +30,15 @@
  #include 
  #include 
  
+#include "amdgpu_vram_mgr.h"

+
  /* state back for walking over vram_mgr and gtt_mgr allocations */
  struct amdgpu_res_cursor {
uint64_tstart;
uint64_tsize;
uint64_tremaining;
-   struct drm_mm_node  *node;
+   void*node;
+   uint32_tmem_type;
  };
  
  /**

@@ -52,27 +55,63 @@ static inline void amdgpu_res_first(struct ttm_resource 
*res,
uint64_t start, uint64_t size,
struct amdgpu_res_cursor *cur)
  {
+   struct drm_buddy_block *block;
+   struct list_head *head, *next;
struct drm_mm_node *node;
  
-	if (!res || res->mem_type == TTM_PL_SYSTEM) {

-   cur->start = start;
-   cur->size = size;
-   cur->remaining = size;
-   cur->node = NULL;
-   WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
-   return;
-   }
+   if (!res)
+   goto fallback;
  
  	BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
  
-	node = to_ttm_range_mgr_node(res)->mm_nodes;

-   while (start >= node->size << PAGE_SHIFT)
-   start -= node++->size << PAGE_SHIFT;
+   cur->mem_type = res->mem_type;
+
+   switch (cur->mem_type) {
+   case TTM_PL_VRAM:
+   head = _amdgpu_vram_mgr_resource(res)->blocks;
+
+   block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+

Re: [Intel-gfx] Commit messages

2022-03-25 Thread Paul Menzel

Dear Christian, dear Daniel, dear Alex,

Am 23.03.22 um 16:32 schrieb Christian König:

Am 23.03.22 um 16:24 schrieb Daniel Stone:

On Wed, 23 Mar 2022 at 15:14, Alex Deucher wrote:
On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone
wrote:

That's not what anyone's saying here ...

No-one's demanding AMD publish RTL, or internal design docs, or
hardware specs, or URLs to JIRA tickets no-one can access.

This is a large and invasive commit with pretty big ramifications;
containing exactly two lines of commit message, one of which just
duplicates the subject.

It cannot be the case that it's completely impossible to provide any
justification, background, or details, about this commit being made.
Unless, of course, it's to fix a non-public security issue, that is
reasonable justification for eliding some of the details. But then
again, 'huge change which is very deliberately opaque' is a really
good way to draw a lot of attention to the commit, and it would be
better to provide more detail about the change to help it slip under
the radar.

If dri-devel@ isn't allowed to inquire about patches which are posted,
then CCing the list is just a façade; might as well just do it all
internally and periodically dump out pull requests.

I think we are in agreement. I think the withheld information
Christian was referring to was on another thread with Christian and
Paul discussing a workaround for a hardware bug:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Famd-gfx%2Fmsg75908.htmldata=04%7C01%7Cchristian.koenig%40amd.com%7C6a3f2815d83b4872577008da0ce1347a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637836458652370599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=QtNB0XHMhTgH%2FNHMwF23Qn%2BgSdYyHJSenbpP%2FHG%2BkxE%3Dreserved=0

(Thank you Microsoft for keeping us safe.)

I guess it proves, how assuming what other people should know/have read,
especially when crossing message threads, is causing confusion and
misunderstandings.

Right, that definitely seems like some crossed wires. I don't see
anything wrong with that commit at all: the commit message and a
comment notes that there is a hardware issue preventing Raven from
being able to do TMZ+GTT, and the code does the very straightforward
and obvious thing to ensure that on VCN 1.0, any TMZ buffer must be
VRAM-placed.

My questions were:

Where is that documented, and how can this be reproduced?

Shouldn’t these be answered by the commit message? In five(?) years,
somebody, maybe even with access to the currently non-public documents,
finds a fault in the commit, and would be helped by having an
document/errata number where to look at. To verify the fix, the
developer would need a method to produce the error, so why not just
share it?

Also, I assume that workarounds often come with downsides, as otherwise
it would have been programmed like this from the beginning, or instead
of “workaround” it would be called “improvement”. Shouldn’t that also be
answered?

So totally made-up example:

Currently, there is a graphics corruption running X on system Y. This is
caused by a hardware bug in Raven ASIC (details internal document
#/AMD-Jira #N), and can be worked around by [what is in the commit
message].

The workaround does not affect the performance, and testing X shows the
error is fixed.

This one, on the other hand, is much less clear ...

Yes, completely agree. I mean a good bunch of comments on commit
messages are certainly valid and we could improve them.

That’d be great.

But this patch here was worked on by both AMD and Intel developers.
Where both sides and I think even people from other companies perfectly
understands why, what, how etc...

When now somebody comes along and asks for a whole explanation of the
context why we do it then that sounds really strange to me.

The motivation should be part of the commit message. I didn’t mean
anyone to rewrite buddy memory allocator Wikipedia article [1]. But the
commit message at hand for switching the allocator is definitely too terse.

Kind regards,

Paul

[1]: https://en.wikipedia.org/wiki/Buddy_memory_allocation

[Intel-gfx] Commit messages (was: [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu)

2022-03-23 Thread Paul Menzel


Dear Christian,


Am 23.03.22 um 08:42 schrieb Christian König:


Am 23.03.22 um 07:42 schrieb Paul Menzel:



Am 23.03.22 um 07:25 schrieb Arunpravin Paneer Selvam:

- Remove drm_mm references and replace with drm buddy functionalities


The commit message summary to me suggested, you can somehow use both 
allocators now. Two suggestions below:


1.  Switch to drm buddy allocator
2.  Use drm buddy alllocator


- Add res cursor support for drm buddy


As an allocator switch sounds invasive, could you please extend the 
commit message, briefly describing the current situation, saying what 
the downsides are, and why the buddy allocator is “better”.


Well, Paul please stop bothering developers with those requests.

It's my job as maintainer to supervise the commit messages and it is 
certainly NOT require to explain all the details of the current 
situation in a commit message. That is just overkill.


I did not request all the details, and I think my requests are totally 
reasonable. But let’s change the perspective. If there were not any AMD 
graphics drivers bug, I would have never needed to look at the code and 
deal with it. Unfortunately the AMD graphics driver situation – which 
improved a lot in recent years – with no public documentation, 
proprietary firmware and complex devices is still not optimal, and a lot 
of bugs get reported, and I am also hit by bugs, taking time to deal 
with them, and maybe reporting and helping to analyze them. So to keep 
your wording, if you would stop bothering users with bugs and requesting 
their help in fixing them – asking the user to bisect the issue is often 
the first thing. Actually it should not be unreasonable for customers 
buying an AMD device to expect get bug free drivers. It’s strange and a 
sad fact, that the software industry succeeded to sway that valid 
expectation and customers now except they need to regularly install 
software updates, and do not get, for example, a price reduction when 
there are bugs.


Also, as stated everywhere, reviewer time is scarce, so commit authors 
should make it easy to attract new folks.


A simple note that we are switching from the drm_mm backend to the buddy 
backend is sufficient, and that is exactly what the commit message is 
saying here.


Sorry, I disagree. The motivation needs to be part of the commit 
message. For example see recent discussion on the LWN article 
*Donenfeld: Random number generator enhancements for Linux 5.17 and 
5.18* [1].


How much the commit message should be extended, I do not know, but the 
current state is insufficient (too terse).



Kind regards,

Paul


[1]: https://lwn.net/Articles/888413/
 "Donenfeld: Random number generator enhancements for Linux 5.17 
and 5.18"

Re: [Intel-gfx] [PATCH v11] drm/amdgpu: add drm buddy support to amdgpu

2022-03-23 Thread Paul Menzel


Dear Arunprivin,


Thank you for your patch.

Am 23.03.22 um 07:25 schrieb Arunpravin Paneer Selvam:

- Remove drm_mm references and replace with drm buddy functionalities


The commit message summary to me suggested, you can somehow use both 
allocators now. Two suggestions below:


1.  Switch to drm buddy allocator
2.  Use drm buddy alllocator


- Add res cursor support for drm buddy


As an allocator switch sounds invasive, could you please extend the 
commit message, briefly describing the current situation, saying what 
the downsides are, and why the buddy allocator is “better”.


How did you test it? How can it be tested, that there are no regressions?


v2(Matthew Auld):


Nit: I’d add a space before (.


Kind regards,

Paul



   - replace spinlock with mutex as we call kmem_cache_zalloc
 (..., GFP_KERNEL) in drm_buddy_alloc() function

   - lock drm_buddy_block_trim() function as it calls
 mark_free/mark_split are all globally visible

v3(Matthew Auld):
   - remove trim method error handling as we address the failure case
 at drm_buddy_block_trim() function

v4:
   - fix warnings reported by kernel test robot 

v5:
   - fix merge conflict issue

v6:
   - fix warnings reported by kernel test robot 

v7:
   - remove DRM_BUDDY_RANGE_ALLOCATION flag usage

v8:
   - keep DRM_BUDDY_RANGE_ALLOCATION flag usage
   - resolve conflicts created by drm/amdgpu: remove VRAM accounting v2

v9(Christian):
   - merged the below patch
  - drm/amdgpu: move vram inline functions into a header
   - rename label name as fallback
   - move struct amdgpu_vram_mgr to amdgpu_vram_mgr.h
   - remove unnecessary flags from struct amdgpu_vram_reservation
   - rewrite block NULL check condition
   - change else style as per coding standard
   - rewrite the node max size
   - add a helper function to fetch the first entry from the list

v10(Christian):
- rename amdgpu_get_node() function name as amdgpu_vram_mgr_first_block

v11:
- if size is not aligned with min_page_size, enable is_contiguous flag,
  therefore, the size round up to the power of two and trimmed to the
  original size.

Signed-off-by: Arunpravin Paneer Selvam 
---
  drivers/gpu/drm/Kconfig   |   1 +
  .../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h|  97 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |  10 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  | 263 ++
  4 files changed, 234 insertions(+), 137 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f1422bee3dcc..5133c3f028ab 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -280,6 +280,7 @@ config DRM_AMDGPU
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+   select DRM_BUDDY
help
  Choose this option if you have a recent AMD Radeon graphics card.
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h

index acfa207cf970..864c609ba00b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -30,12 +30,15 @@
  #include 
  #include 
  
+#include "amdgpu_vram_mgr.h"

+
  /* state back for walking over vram_mgr and gtt_mgr allocations */
  struct amdgpu_res_cursor {
uint64_tstart;
uint64_tsize;
uint64_tremaining;
-   struct drm_mm_node  *node;
+   void*node;
+   uint32_tmem_type;
  };
  
  /**

@@ -52,27 +55,63 @@ static inline void amdgpu_res_first(struct ttm_resource 
*res,
uint64_t start, uint64_t size,
struct amdgpu_res_cursor *cur)
  {
+   struct drm_buddy_block *block;
+   struct list_head *head, *next;
struct drm_mm_node *node;
  
-	if (!res || res->mem_type == TTM_PL_SYSTEM) {

-   cur->start = start;
-   cur->size = size;
-   cur->remaining = size;
-   cur->node = NULL;
-   WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
-   return;
-   }
+   if (!res)
+   goto fallback;
  
  	BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
  
-	node = to_ttm_range_mgr_node(res)->mm_nodes;

-   while (start >= node->size << PAGE_SHIFT)
-   start -= node++->size << PAGE_SHIFT;
+   cur->mem_type = res->mem_type;
+
+   switch (cur->mem_type) {
+   case TTM_PL_VRAM:
+   head = _amdgpu_vram_mgr_node(res)->blocks;
+
+   block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+link);
+   if (!block)
+   goto fallback;
+
+   while (start >= amdgpu_node_size(block)) {
+   start -=

Re: [Intel-gfx] [PATCH] drm: add a check to verify the size alignment

2022-03-21 Thread Paul Menzel


Dear Arunpravin,


Am 21.03.22 um 06:59 schrieb Arunpravin Paneer Selvam:

add a simple check to reject any size not aligned to the
min_page_size.


Nit: I’d start sentences with a capital letter.

Could you please add a summary of the discussion to the commit message, 
so the question “Why?” is answered?



Kind regards,

Paul



Signed-off-by: Arunpravin Paneer Selvam 
---
  drivers/gpu/drm/drm_buddy.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..b503c88786b0 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -661,6 +661,9 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (range_overflows(start, size, mm->size))
return -EINVAL;
  
+	if (WARN_ON(!IS_ALIGNED(size, min_page_size)))

+   return -EINVAL;
+
/* Actual range allocation */
if (start + size == end)
return __drm_buddy_alloc_range(mm, start, size, blocks);

Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0

2022-03-16 Thread Paul Menzel


Dear Arunprivin,


Am 16.03.22 um 07:49 schrieb Arunpravin Paneer Selvam:


On 15/03/22 9:14 pm, Paul Menzel wrote:



Am 15.03.22 um 16:42 schrieb Arunpravin:


On 15/03/22 2:35 pm, Paul Menzel wrote:



Am 15.03.22 um 10:01 schrieb Arunpravin:


On 15/03/22 1:49 pm, Paul Menzel wrote:



Am 14.03.22 um 20:40 schrieb Arunpravin:

handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC

Signed-off-by: Arunpravin 


Please use your full name.

okay


You might also configure that in your email program.

yes


Not done yet though. ;-)


done in v2 :)

---
 drivers/gpu/drm/drm_buddy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c


In what tree is that file?


drm-tip - 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2Fdata=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GM3iXiDQCx%2BM4pD1nmivRFRvkehwTNd2Jtd713cF51g%3Dreserved=0
drm-misc-next - 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2Fdata=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7C3610aafe216d421c715c08da069ac1d7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829559006306914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=i7pvmDJu310XRX7h3cQ344j5RYHq7fBZ520l%2F%2Br1%2BQU%3Dreserved=0


Thank Outlook. Now everybody feels safe.


@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
 
-			if (order-- == min_order) {

+   if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}


Thank you for the hint. So the whole function is:

do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);

do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);

if (!IS_ERR(block))
break;

if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);

mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(>link, );

pages -= BIT(order);

if (!pages)
break;
} while (1);

Was the BUG_ON triggered for your case?

BUG_ON(order < min_order);

no, this BUG_ON is not triggered for this bug


Please give more details.


there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.


Sorry, I do not see it. How can that be with order ≥ min_order and the
check `order-- == min_order`? Is min_order 0? Please explain that in the
next commit message.


please check v2, yes when min_order is 0, the above said situation may
occur.And, since the order is unsigned int, I think it will not trigger
the BUG_ON(order < min_order) when order becomes -1. Hence I think we
needed a check !order to exit the loop.


Thank you for clarifying this. I still do not understand it though. With

order = fls(pages) - 1;
min_order = ilog2(min_page_size) - ilog2(mm->chunk_size);

is zorder` always non-negative? Let’s assume it is. Also, can min_order 
get “negative” (wraps around)?


I would add BUG_ON statements for these cases?

BUG_ON(fls(pages) - 1 < 1);
BUG_ON(ilog2(min_page_size) - ilog2(mm->chunk_size) < 1);

Assuming “negative” is not possible, your case can only happen if 
`order` and `min_order` are 0, right? If `order` is

Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0

2022-03-15 Thread Paul Menzel


Dear Arunpravin,


Am 15.03.22 um 16:42 schrieb Arunpravin:


On 15/03/22 2:35 pm, Paul Menzel wrote:



Am 15.03.22 um 10:01 schrieb Arunpravin:


On 15/03/22 1:49 pm, Paul Menzel wrote:



Am 14.03.22 um 20:40 schrieb Arunpravin:

handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC

Signed-off-by: Arunpravin 


Please use your full name.

okay


You might also configure that in your email program.

yes


Not done yet though. ;-)


---
drivers/gpu/drm/drm_buddy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c


In what tree is that file?


drm-tip - 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm-tip%2Ftree%2Fdata=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5Bspe5QGjQ0KHfVI8%2F%2BXqxR45q6tOL4FE2fVD3uwL%2FM%3Dreserved=0
drm-misc-next - 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Ftree%2Fdata=04%7C01%7CArunpravin.PaneerSelvam%40amd.com%7Cc456573102c04191cf9708da0662f798%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637829319396954551%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=g2S14TfsHF5ORo9jTZ3uA0l1BH8mnAxk2OWYJeF5i8k%3Dreserved=0


Thank Outlook. Now everybody feels safe.


@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;

-			if (order-- == min_order) {

+   if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}


Thank you for the hint. So the whole function is:

do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);

do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);

if (!IS_ERR(block))
break;

if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);

mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(>link, );

pages -= BIT(order);

if (!pages)
break;
} while (1);

Was the BUG_ON triggered for your case?

BUG_ON(order < min_order);

no, this BUG_ON is not triggered for this bug


Please give more details.


there is a chance when there is no space to allocate, order value
decrements and reaches to 0 at one point, here we should exit the loop,
otherwise, further order value decrements to -1 and do..while loop
doesn't exit. Hence added a check to exit the loop if order value becomes 0.


Sorry, I do not see it. How can that be with order ≥ min_order and the 
check `order-- == min_order`? Is min_order 0? Please explain that in the 
next commit message.



Kind regards,

Paul

Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0

2022-03-15 Thread Paul Menzel


Dear Arunpravin,


Am 15.03.22 um 10:01 schrieb Arunpravin:


On 15/03/22 1:49 pm, Paul Menzel wrote:



Am 14.03.22 um 20:40 schrieb Arunpravin:

handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC

Signed-off-by: Arunpravin 


Please use your full name.

okay


You might also configure that in your email program.


---
   drivers/gpu/drm/drm_buddy.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c


In what tree is that file?


drm-tip - https://cgit.freedesktop.org/drm-tip/tree/
drm-misc-next - https://cgit.freedesktop.org/drm/drm-misc/tree/


@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
   
-			if (order-- == min_order) {

+   if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}


Thank you for the hint. So the whole function is:

do {
order = min(order, (unsigned int)fls(pages) - 1);
BUG_ON(order > mm->max_order);
BUG_ON(order < min_order);

do {
if (flags & DRM_BUDDY_RANGE_ALLOCATION)
/* Allocate traversing within the range */
block = alloc_range_bias(mm, start, end, order);
else
/* Allocate from freelist */
block = alloc_from_freelist(mm, order, flags);

if (!IS_ERR(block))
break;

if (order-- == min_order) {
err = -ENOSPC;
goto err_free;
}
} while (1);

mark_allocated(block);
mm->avail -= drm_buddy_block_size(mm, block);
kmemleak_update_trace(block);
list_add_tail(>link, );

pages -= BIT(order);

if (!pages)
break;
} while (1);

Was the BUG_ON triggered for your case?

BUG_ON(order < min_order);

Please give more details.


Kind regards,

Paul

Re: [Intel-gfx] [PATCH] drm: Fix a infinite loop condition when order becomes 0

2022-03-15 Thread Paul Menzel


Dear Arunpravin,


Am 14.03.22 um 20:40 schrieb Arunpravin:

handle a situation in the condition order-- == min_order,
when order = 0, leading to order = -1, it now won't exit
the loop. To avoid this problem, added a order check in
the same condition, (i.e) when order is 0, we return
-ENOSPC

Signed-off-by: Arunpravin 


Please use your full name.


---
  drivers/gpu/drm/drm_buddy.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 72f52f293249..5ab66aaf2bbd 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c


In what tree is that file?


@@ -685,7 +685,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm,
if (!IS_ERR(block))
break;
  
-			if (order-- == min_order) {

+   if (!order || order-- == min_order) {
err = -ENOSPC;
goto err_free;
}


Kind regards,

Paul

Re: [Intel-gfx] [PATCH v3 2/3] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

2021-10-29 Thread Paul Menzel


Dear Mark,


On 26.10.21 21:21, Mark Yacoub wrote:

From: Mark Yacoub 

[Why]
1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
or Degamma props in the new CRTC state, allowing any invalid size to
be passed on.
2. Each driver has its own LUT size, which could also be different for
legacy users.

[How]
1. Create |degamma_lut_size| and |gamma_lut_size| to save the LUT sizes
assigned by the driver when it's initializing its color and CTM
management.
2. Create drm_atomic_helper_check_crtc which is called by
drm_atomic_helper_check to check the LUT sizes saved in drm_crtc that
they match the sizes in the new CRTC state.
3. As the LUT size check now happens in drm_atomic_helper_check, remove
the lut check in intel_color.c

Resolves: igt@kms_color@pipe-A-invalid-gamma-lut-sizes on MTK
Tested on Zork(amdgpu) and Jacuzzi(mediatek), volteer(TGL)


If you should sent another iteration, only a minor thing, could you 
please add a space before the (.




v2:
1. Remove the rename to a parent commit.
2. Create a drm drm_check_lut_size instead of intel only function.

v1:
1. Fix typos
2. Remove the LUT size check from intel driver
3. Rename old LUT check to indicate it's a channel change

Signed-off-by: Mark Yacoub 
---
  drivers/gpu/drm/drm_atomic_helper.c| 56 ++
  drivers/gpu/drm/drm_color_mgmt.c   |  2 +
  drivers/gpu/drm/i915/display/intel_color.c | 39 ---
  include/drm/drm_atomic_helper.h|  1 +
  include/drm/drm_color_mgmt.h   | 13 +
  include/drm/drm_crtc.h | 11 +
  6 files changed, 102 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index bc3487964fb5e..c565b3516cce9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -929,6 +929,58 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
  }
  EXPORT_SYMBOL(drm_atomic_helper_check_planes);
  
+/**

+ * drm_atomic_helper_check_crtcs - validate state object for CRTC changes
+ * @state: the driver state object
+ *
+ * Check the CRTC state object such as the Gamma/Degamma LUT sizes if the new
+ * state holds them.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_atomic_helper_check_crtcs(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *new_crtc_state;
+   int i;
+
+   for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
+   if (new_crtc_state->color_mgmt_changed &&
+   new_crtc_state->gamma_lut) {
+   if (drm_check_lut_size(new_crtc_state->gamma_lut,
+  crtc->gamma_lut_size) ||
+   drm_check_lut_size(new_crtc_state->gamma_lut,
+  crtc->gamma_size)) {
+   drm_dbg_state(
+   state->dev,
+   "Invalid Gamma LUT size. Should be %u (or %u 
for legacy) but got %u.\n",
+   crtc->gamma_lut_size, crtc->gamma_size,
+   drm_color_lut_size(
+   new_crtc_state->gamma_lut));
+   return -EINVAL;
+   }
+   }
+
+   if (new_crtc_state->color_mgmt_changed &&
+   new_crtc_state->degamma_lut) {
+   if (drm_check_lut_size(new_crtc_state->degamma_lut,
+  crtc->degamma_lut_size)) {
+   drm_dbg_state(
+   state->dev,
+   "Invalid DeGamma LUT size. Should be %u but 
got %u.\n",
+   crtc->degamma_lut_size,
+   drm_color_lut_size(
+   new_crtc_state->degamma_lut));
+   return -EINVAL;
+   }
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_crtcs);
+
  /**
   * drm_atomic_helper_check - validate state object
   * @dev: DRM device
@@ -974,6 +1026,10 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
  
+	ret = drm_atomic_helper_check_crtcs(state);

+   if (ret)
+   return ret;
+
if (state->legacy_cursor_update)
state->async_update = !drm_atomic_helper_async_check(dev, 
state);
  
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c

index 6f4e04746d90f..6bb59645a75bc 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -166,6 +166,7 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
struct drm_mode_config

Re: [Intel-gfx] [PATCH 1/2] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

2021-10-26 Thread Paul Menzel

 int drm_plane_create_color_properties(struct drm_plane 
*plane,
  enum drm_color_range default_range);
  
  /**

- * enum drm_color_lut_tests - hw-specific LUT tests to perform
+ * enum drm_color_lut_channels_tests - hw-specific LUT tests to perform
   *
   * The drm_color_lut_check() function takes a bitmask of the values here to
   * determine which tests to apply to a userspace-provided LUT.
   */
-enum drm_color_lut_tests {
+enum drm_color_lut_channels_tests {
/**
 * @DRM_COLOR_LUT_EQUAL_CHANNELS:
 *
@@ -119,5 +119,6 @@ enum drm_color_lut_tests {
DRM_COLOR_LUT_NON_DECREASING = BIT(1),
  };
  
-int drm_color_lut_check(const struct drm_property_blob *lut, u32 tests);

+int drm_color_lut_channels_check(const struct drm_property_blob *lut,
+u32 tests);
  #endif
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 2deb15d7e1610..cabd3ef1a6e32 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1072,6 +1072,17 @@ struct drm_crtc {
/** @funcs: CRTC control functions */
const struct drm_crtc_funcs *funcs;
  
+	/**

+* @degamma_lut_size: Size of degamma LUT.
+*/
+   uint32_t degamma_lut_size;
+
+   /**
+* @gamma_lut_size: Size of Gamma LUT. Not used by legacy userspace 
such as
+* X, which doesn't support large lut sizes.
+*/
+   uint32_t gamma_lut_size;
+
/**
 * @gamma_size: Size of legacy gamma ramp reported to userspace. Set up
 * by calling drm_mode_crtc_set_gamma_size().



Acked-by: Paul Menzel 


Kind regards,

Paul

Re: [Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=

2019-11-19 Thread Paul Menzel

Dear Tomáš,


On 2019-11-04 18:31, Tomas Janousek wrote:

> On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote:
>> On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7
>> resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews
>> the errors below.
>>
>> ```
>> [0.00] Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) 
>> (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 
>> (2019-10-19)
>> […]
>> [1.596619] pci :00:1f.3: Adding to iommu group 12
>> [   14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
>> [   14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
>> i915_audio_component_bind_ops [i915])
>> [   14.760751] input: HDA Intel PCH Headphone Mic as 
>> /devices/pci:00/:00:1f.3/sound/card0/input16
>> [   14.760790] input: HDA Intel PCH HDMI as 
>> /devices/pci:00/:00:1f.3/sound/card0/input17
>> [  156.614284] snd_hda_intel :00:1f.3: No response from codec, disabling 
>> MSI: last cmd=0x20270503
>> [  157.622232] snd_hda_intel :00:1f.3: No response from codec, resetting 
>> bus: last cmd=0x20270503
>> [  158.626371] snd_hda_intel :00:1f.3: No response from codec, resetting 
>> bus: last cmd=0x20370503
>> [  159.634102] snd_hda_intel :00:1f.3: No response from codec, resetting 
>> bus: last cmd=0x201f0500
>> [  161.678121] snd_hda_intel :00:1f.3: No response from codec, resetting 
>> bus: last cmd=0x20270503
>> [  162.682272] snd_hda_intel :00:1f.3: No response from codec, resetting 
>> bus: last cmd=0x20370503
>> [  163.694234] snd_hda_intel :00:1f.3: No response from codec, resetting 
>> bus: last cmd=0x201f0500
>> [  165.730142] snd_hda_intel :00:1f.3: No response from codec, resetting 
>> bus: last cmd=0x20270503
>> […]
>> ```
> 
> Debian's 5.3.0-1-amd64 has a corrupted signature on the snd-hda-codec-hdmi
> module which prevents the module from loading and causes these errors. Further
> details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881
> 
> Workaround: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881#20

Thank you so much for pointing me to that bug report. The problem is now fixed
in linux-image 5.3.9-1.

Takashi, could a sanity check be added to `snd_hda_intel` to see if the codec
module is loaded?


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=

2019-11-04 Thread Paul Menzel

Dear Linux folks,


On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7
resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews
the errors below.

```
[0.00] Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) 
(gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19)
[…]
[1.596619] pci :00:1f.3: Adding to iommu group 12
[   14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002)
[   14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   14.760751] input: HDA Intel PCH Headphone Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[   14.760790] input: HDA Intel PCH HDMI as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[  156.614284] snd_hda_intel :00:1f.3: No response from codec, disabling 
MSI: last cmd=0x20270503
[  157.622232] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270503
[  158.626371] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370503
[  159.634102] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[  161.678121] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270503
[  162.682272] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20370503
[  163.694234] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x201f0500
[  165.730142] snd_hda_intel :00:1f.3: No response from codec, resetting 
bus: last cmd=0x20270503
[…]
```

In the bug report *[Intel Ice Lake, snd-hda-intel, HDMI] "No
response from codec" (after display hotplug?)* [1], note it’s a
different model, Takashi comments that this is a Thunderbolt or
i915 issue.

Please tell me, how to debug this further.


Kind regards,

Paul


[1]: https://bugzilla.kernel.org/show_bug.cgi?id=205229
 "205229 - [Intel Ice Lake, snd-hda-intel, HDMI] "No response from codec" 
(after display hotplug?)"
[0.463803] pci :3f:00.0: PME# supported from D3cold
[0.464089] pci :3e:01.0: PCI bridge to [bus 3f]
[0.464111] pci :3e:01.0:   bridge window [mem 0xc400-0xc40f]
[0.464220] pci :3e:04.0: PCI bridge to [bus 40-6d]
[0.464241] pci :3e:04.0:   bridge window [mem 0xc410-0xd9ff]
[0.464256] pci :3e:04.0:   bridge window [mem 0x8000-0xa9ff 
64bit pref]
[0.464560] pci :6e:00.0: [1344:5410] type 00 class 0x010802
[0.464583] pci :6e:00.0: reg 0x10: [mem 0xdc30-0xdc303fff 64bit]
[0.464870] pci :00:1d.4: PCI bridge to [bus 6e]
[0.464873] pci :00:1d.4:   bridge window [mem 0xdc30-0xdc3f]
[0.468165] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0
[0.468218] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *1
[0.468269] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0
[0.468320] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0
[0.468371] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0
[0.468422] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0
[0.468473] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0
[0.468524] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 14 15) *0
[0.482170] ACPI: EC: interrupt unblocked
[0.482180] ACPI: EC: event unblocked
[0.482196] ACPI: \_SB_.PCI0.LPCB.ECDV: GPE=0x6e, EC_CMD/EC_SC=0x934, 
EC_DATA=0x930
[0.482197] ACPI: \_SB_.PCI0.LPCB.ECDV: Boot DSDT EC used to handle 
transactions and events
[0.482653] pci :00:02.0: vgaarb: setting as boot VGA device
[0.482653] pci :00:02.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.482653] pci :00:02.0: vgaarb: bridge control possible
[0.482653] vgaarb: loaded
[0.482752] EDAC MC: Ver: 3.0.0
[0.483874] Registered efivars operations
[0.483874] PCI: Using ACPI for IRQ routing
[0.519201] PCI: pci_cache_line_size set to 64 bytes
[0.519918] e820: reserve RAM buffer [mem 0x0009e000-0x0009]
[0.519919] e820: reserve RAM buffer [mem 0x2a059000-0x2bff]
[0.519920] e820: reserve RAM buffer [mem 0x3a927000-0x3bff]
[0.519920] e820: reserve RAM buffer [mem 0x48e0-0x4bff]
[0.519921] e820: reserve RAM buffer [mem 0x4ae80-0x4afff]
[0.520127] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[0.520129] hpet0: 8 comparators, 64-bit 24.00 MHz counter
[0.521960] clocksource: Switched to clocksource tsc-early
[0.528569] VFS: Disk quotas dquot_6.6.0
[0.528579] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[0.528668] AppArmor: AppArmor Filesystem Enabled
[0.528677] pnp: PnP ACPI init
[0.528744] system 00:00: [mem 0x4000-0x403f] could not be reserved
[0.528747] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)

Re: [Intel-gfx] [v2] drm/i915/fbdev: Enable late fbdev initial configuration

2018-04-20 Thread Paul Menzel


Dear Jose,


On 04/19/18 01:41, Souza, Jose wrote:

If the initial fbdev configuration(intel_fbdev_initial_config()) runs and


Nit: Space before (.


there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened(but
internally the return is -EAGAIN).


Nit: Space before (.


Because no framebuffer was allocated, when a sink is connected
intel_fbdev_output_poll_changed() will not execute
drm_fb_helper_hotplug_event() that would trigger another try to do the
initial fbdev configuration.

So here allowing drm_fb_helper_hotplug_event() to be executed when there
is not frambebuffer allocated and fbdev was not setup yet.


s/not/no/
s/setup/set up/


This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if intel_fbdev_initial_config()
is executed before the first sink MST is discovered it will cause this
same issue.

This is a follow up patch of


follow-up


https://patchwork.freedesktop.org/patch/196089/

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: José Roberto de Souza <jose.so...@intel.com>
---

Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.


s/setup/set up/


  drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 7d41d139341b..e9e02b58b7be 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct drm_device *dev)
return;
  
  	intel_fbdev_sync(ifbdev);

-   if (ifbdev->vma)
+   if (ifbdev->vma || ifbdev->helper.deferred_setup)
drm_fb_helper_hotplug_event(>helper);
  }
  


Tested-by: Paul Menzel <pmen...@molgen.mpg.de>


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] OT: Patches for Chromium browser to use VAAPI available

2017-07-31 Thread Paul Menzel

Dear Linux folks,


Just a small note, that Intel pushed patches for the Chromium browser
for review [1] to use VAAPI [2] along with vaapi-driver to run all
supported media use cases with hardware acceleration.

This will hopefully let GNU/Linux systems desktop to catch up further
to Microsoft Windows systems, especially on mobile devices like laptops
where this makes a difference in how long the battery lasts.

Unfortunately, Mozilla Firefox still lacks support for this too. Bug
report #1210727 [3] has been open for several years. Maybe Intel is so
kind to also do that work. ;-)


Thanks,

Paul


[1] https://chromium-review.googlesource.com/c/532294
[2] https://01.org/linuxgraphics/community/vaapi
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1210727

signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix cursor updates on some platforms

2017-07-18 Thread Paul Menzel


Dear Ville,


On 07/14/17 17:52, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.

Even worse, a write to any of the cursor register apart from CURBASE
will cancel an already pending cursor update. So if we have armed a
CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
would cancel that armed update. Thus we're left with a cursor that
doesn't appear to move, or even change shape.

Fix the problem by always performing the CURBASE write after a
CURPOS write. Bspec is somewhat unclear which platforms actually
require this CURBASE write and which don't. So to keep it simple
and to make sure we really fix the problem across all supported
devices, let's just perform the CURBASE write unconditionally.

Cc: Paul Menzel <pmen...@molgen.mpg.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790
Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit")
Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
  drivers/gpu/drm/i915/intel_display.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2144adc5b1d5..460bd942fcb7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9555,7 +9555,16 @@ static void i9xx_update_cursor(struct intel_plane *plane,
 * On some platforms writing CURCNTR first will also
 * cause CURPOS to be armed by the CURBASE write.
 * Without the CURCNTR write the CURPOS write would
-* arm itself.
+* arm itself. Thus we always start the full update
+* with a CURCNTR write.
+*
+* On other platforms CURPOS always requires the
+* CURBASE write to arm the update. Additonally
+* a write to any of the cursor register will cancel
+* an already armed cursor update. Thus leaving out
+* the CURBASE write after CURPOS could lead to a
+* cursor that doesn't appear to move, or even change
+* shape. Thus we always write CURBASE.
 *
 * CURCNTR and CUR_FBC_CTL are always
 * armed by the CURBASE write only.
@@ -9574,6 +9583,7 @@ static void i9xx_update_cursor(struct intel_plane *plane,
plane->cursor.cntl = cntl;
} else {
I915_WRITE_FW(CURPOS(pipe), pos);
+   I915_WRITE_FW(CURBASE(pipe), base);
}
  
  	POSTING_READ_FW(CURBASE(pipe));


Tested-by: Paul Menzel <paulepan...@users.sourceforge.net>

I created two more bugs for an issue with pasting text with the middle 
mouse button [1], and failing *kms_cursor_crc* tests [2].



Kind regards,

Paul Menzel


[1] https://bugs.freedesktop.org/show_bug.cgi?id=101819
[2] https://bugs.freedesktop.org/show_bug.cgi?id=101817
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dim: Switch Link: tags to https://

2017-07-16 Thread Paul Menzel

Dear Daniel,


Am Sonntag, den 16.07.2017, 12:26 +0200 schrieb Daniel Vetter:
> http: gets a "301 moved permanently" reply.
> 
> Reported-by: Paul Menzel <paulepan...@users.sourceforge.net>
> Cc: Paul Menzel <paulepan...@users.sourceforge.net>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>

Reviewed-by: Paul Menzel <paulepan...@users.sourceforge.net>


Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] 01.org: HTTPS: Please fix mixed content loading

2015-05-23 Thread Paul Menzel

Dear Intel folks,


accessing the resources at 01.org over HTTPS, some have mixed content
loading issues. For example [1] loads an image from Gravatar – for
whatever reason – over HTTP.

Google Chromium reports for example the following.

Mixed Content: The page at 
'https://01.org/linuxgraphics/documentation/how-report-bugs' was loaded over 
HTTPS, but requested an insecure image 
'http://www.gravatar.com/avatar/672c5e6b44ca5810141d82f730aad074.jpg?d=mms=50r=G'.
 This content should also be served over HTTPS.


Thanks,

Paul


[1] https://01.org/linuxgraphics/documentation/how-report-bugs


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Lenovo X60 with i945: Setting resolution in GRUB to 1024×768

2015-01-18 Thread Paul Menzel

Dear Intel folks,


on the Lenovo X60 with i945 graphics (and vendor BIOS), for using
fastboot, that means to avoid a modeset, I want to set the desired
resolution in GRUB using the option `GRUB_GFXMODE=1024x768` in
`/etc/default/grub`. Unfortunately that does not have an effect and the
resolution is only 640×480.

The GRUB developer told me that this is likely a Video BIOS issue.

Am I out of luck or do you know of possible solutions or do you have
pointers how to debug this? GRUB’s `vbeinfo` lists the resolution of
1024×768.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Lenovo X60 with i945: Setting resolution in GRUB to 1024×768

2015-01-18 Thread Paul Menzel

Am Sonntag, den 18.01.2015, 16:56 -0500 schrieb Felix Miata:
 Paul Menzel composed on 2015-01-18 12:20 (UTC+0100):
 
  on the Lenovo X60 with i945 graphics (and vendor BIOS), for using
  fastboot, that means to avoid a modeset, I want to set the desired
  resolution in GRUB using the option `GRUB_GFXMODE=1024x768` in
  `/etc/default/grub`.
 
 Making a change in /etc/default/grub does not take effect until the actual
 Grub menu is rebuilt. It's a config file, not a menu file.

I know and ran `sudo update-grub` afterward. Thank you for the hint
though.

  Unfortunately that does not have an effect and the
  resolution is only 640a×480.
 
 IIRC, I've solved this problem in the distant past by in BIOS setup changing
 memory size reserved for video controller from 1M to 8M.

Unfortunately I was unable to find such a configuration option in the
BIOS menu.

  The GRUB developer told me that this is likely a Video BIOS issue.
 
  Am I out of luck or do you know of possible solutions or do you have
  pointers how to debug this? GRUB’s `vbeinfo` lists the resolution of
  1024×768.
 
 GRUB_GFXMODE=1024x768 assumes you are using Grub2. In Grub legacy what you
 need is video=1024x768 or video=1024x768@60 on the kernel cmdline. I have
 multiple i945G systems using both vga=1024x768@60 and Grub Legacy, but none
 Lenovo.

Good to know. Hopefully it can be solved in GRUB 2.

 Which distro are you using?

Debian Jessie/testing


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Mark fastboot as unsafe

2014-11-04 Thread Paul Menzel

Dear Daniel,


thank you for the support in #intel-...@irc.freenode.net and the patch.
As already commented in the bug report #84682, there are some typos.

Am Dienstag, den 04.11.2014, 15:29 +0100 schrieb Daniel Vetter:
 Fastboot in its current incarnation assumes that the pfit isn't
 relevatn for the state and that it can be disabled without restarting

releva*nt*

 the crtc. Unfortunately that's not the case on gen2/3 - it upsets the
 hw and results in a black screen.
 
 Worse, the way the current fastboot hack is structure we can't detect

structure*d*

 and work around this in the code, since the fastboot smashes the
 adjusted mode into crtc-mode. Which means the higher levels can't
 correctly figure out that this is a lie and act accordingly.
 
 Since fastboot is just a tech demo let's mark the module option as
 experimental and close the coresponding reports as wontfix.

cor*r*esponding

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84682
 Signed-off-by: Daniel Vetter daniel.vet...@intel.com
 ---
  drivers/gpu/drm/i915/i915_params.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_params.c 
 b/drivers/gpu/drm/i915/i915_params.c
 index c91cb2033cc5..93d792349668 100644
 --- a/drivers/gpu/drm/i915/i915_params.c
 +++ b/drivers/gpu/drm/i915/i915_params.c
 @@ -138,7 +138,7 @@ MODULE_PARM_DESC(disable_power_well,
  module_param_named(enable_ips, i915.enable_ips, int, 0600);
  MODULE_PARM_DESC(enable_ips, Enable IPS (default: true));
  
 -module_param_named(fastboot, i915.fastboot, bool, 0600);
 +module_param_named_unsafe(fastboot, i915.fastboot, bool, 0600);
  MODULE_PARM_DESC(fastboot,
   Try to skip unnecessary mode sets at boot time (default: false));


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915.fastboot bug report - not working on coreboot

2014-08-27 Thread Paul Menzel

Dear Charles,


thanks a lot for following up on the intel-gfx mailing list.


Am Dienstag, den 26.08.2014, 13:09 -0400 schrieb Charles Devereaux:

 I'm trying to use i915.fastboot on a Thinkpad X60t. The bios has been
 replaced by coreboot, which supports native video init.
 
 The goal is to boot to a console on a debian in less than 2 seconds (kernel
 + systemd), systemd is just fine in 0.6s but the kernel takes a long time,
 with apparently 1 full second spend on the video mode initialization, just
 as if fastboot was ignored.
 
 Coreboot is starting a grub2 payload, which is in the appropriate vesa
 mode, and has option set gfxpayload=keep to pass it to the kernel.
 
 The 3.14.16 kernel start in the appropriate vesa mode, but there is some
 flickering at one time, which indicates the drivers tries to reinitialize
 the video card, before returning to this same mode.

By the way, does it work with the vendor VGA BIOS?

 The kernel arguments are:
 nohz=on nmi_watchdog=0 pcie_aspm=force i915.semaphores=1 i915.fastboot=1
 i915.i915_enable_rc6=7 i915.i915_enable_fbc=1 i915.lvds_downclock=1
 thinkpad_acpi.force_load=1 thinkpad_acpi.brightness_enable=0
 snd-hda-intel.index=0 snd_hda_intel.power_save=10
 snd_hda_intel.model=thinkpad snd-hda-intel.probe_mask=0x103
 snd-pcsp.index=1 btusb.reset=1 quiet root=/dev/sda1
 
 The kernel .config has:
 CONFIG_DRM_I915=y
 CONFIG_DRM_I915_KMS=y
 CONFIG_DRM_I915_FBDEV=y
 # CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT is not set
 # CONFIG_DRM_I915_UMS is not set
 
 Is it possible to enable some kind of debugging of i915.fastboot to see why
 exactly the video is reinitialized?

 I didn't see any module option to do that in drivers/gpu/drm/i915/i915_drv.c

Reading »How to file a good bug report« [1], you should pass
drm.debug=0x06 to get more debug messages.

 Here are the dmesg showing the time spent.
 
 In a 3.14.16 kernel :
 [0.498511] [drm] Initialized drm 1.1.0 20060810
 [0.498967] [drm] Memory usable by graphics device = 256M
 [0.500365] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
 [0.500370] [drm] Driver supports precise vblank timestamp query.
 [0.500377] i915 :00:02.0: Invalid ROM contents
 [0.500384] [drm] failed to find VBIOS tables
 [0.500449] vgaarb: device changed decodes:
 PCI::00:02.0,olddecodes=io+me
 m,decodes=io+mem:owns=io+mem
 [0.532092] [drm] initialized overlay support
 [0.799483] fbcon: inteldrmfb (fb0) is primary device
 [1.452009] Console: switching to colour frame buffer device 128x48
 [1.480975] i915 :00:02.0: fb0: inteldrmfb frame buffer device
 [1.480978] i915 :00:02.0: registered panic notifier
 [1.480990] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
 minor 0
 
 
 In a 3.10.45 kernel: (no fastboot support)
 [0.213937] [drm] Initialized drm 1.1.0 20060810
 [0.214643] [drm] Memory usable by graphics device = 256M
 [0.214650] i915 :00:02.0: setting latency timer to 64
 [0.216252] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
 [0.216284] [drm] Driver supports precise vblank timestamp query.
 [0.216291] i915 :00:02.0: Invalid ROM contents
 [0.216298] [drm] failed to find VBIOS tables
 [0.216351] vgaarb: device changed decodes:
 PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
 [0.226207] ACPI: Deprecated procfs I/F for battery is loaded, please
 retry with CONFIG_ACPI_PROCFS_POWER cleared
 [0.226218] ACPI: Battery Slot [BAT0] (battery present)
 [0.226378] ACPI: Deprecated procfs I/F for battery is loaded, please
 retry with CONFIG_ACPI_PROCFS_POWER cleared
 [0.226386] ACPI: Battery Slot [BAT1] (battery absent)
 [0.267013] [drm] GMBUS [i915 gmbus panel] timed out, falling back to
 bit banging on pin 3
 [0.297928] [drm] initialized overlay support
 [0.360013] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit
 banging on pin 2
 [0.546070] fbcon: inteldrmfb (fb0) is primary device
 [1.198025] Console: switching to colour frame buffer device 128x48
 [1.226996] i915 :00:02.0: fb0: inteldrmfb frame buffer device
 [1.227000] i915 :00:02.0: registered panic notifier
 [1.227015] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
 minor 0
 [1.228648] loop: module loaded
 [1.279013] [drm] GMBUS [i915 gmbus ssc] timed out, falling back to bit
 banging on pin 1
 [1.398013] [drm] GMBUS [i915 gmbus dpc] timed out, falling back to bit
 banging on pin 4
 [1.513013] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit
 banging on pin 5
 [1.586013] [drm] GMBUS [i915 gmbus dpd] timed out, falling back to bit
 banging on pin 6

Are you able to try a newer/the latest Linux kernel?


Thanks,

Paul


[1] https://01.org/linuxgraphics/documentation/how-report-bugs


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list

[Intel-gfx] How to debug GTT/PTE errors?

2014-06-11 Thread Paul Menzel

Dear Linux folks,


although there are no user visible issues, there is still the following
error message in the log.

 [1.235596] i915: render error detected, EIR: 0x0010
 [1.235596] i915: page table error
 [1.235596] i915:   PGTBL_ER: 0x0012
 [1.235596] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 
 0x0010, masking
 [1.235596] i915: render error detected, EIR: 0x0010
 [1.235596] i915: page table error
 [1.235596] i915:   PGTBL_ER: 0x0012
 [1.310633] [drm:intel_modeset_init], 2 display pipes available.
 
 The intel-gpu-tools [6] include the program `intel-error-decode`, which
 give the following.
 
 $ ./intel_error_decode /tmp/5927_7/error
 Time: 1402269737 s 277725 us
 Kernel: 3.14.4-gnuowen
 PCI ID: 0x27a2
 Detected GEN3 chipset
 EIR: 0x0010
 IER: 0x00028053
 PGTBL_ER: 0x0012
 Display A: Invalid GTT PTE
 Host Invalid PTE data
 […]

Is there an option that the GTT is dumped on such an error or the
addresses are shown in the logs to exactly see where in memory the
problem is?


Thanks,

Paul


[1] http://www.coreboot.org/pipermail/coreboot/2014-June/078092.html
[6] http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Intel 945] BSM: How to determine size of DRAM used for internal graphics?

2014-06-09 Thread Paul Menzel

Dear Intel graphics folks,

Am Freitag, den 30.05.2014, 14:47 +0200 schrieb Paul Menzel:

Am Freitag, den 30.05.2014, 13:45 +0200 schrieb Paul Menzel:

since commit 17fec8a0 [1]

drm/i915: Use Graphics Base of Stolen Memory on all gen3+

Linux reads the register BSM (Base of Stolen Memory) directly to get the
base address of graphics stolen memory. With coreboot [2] and native
graphics init – note that everything works with the proprietary VGA
BIOS/Option ROM – this causes a regression [3] as this register is not
programmed at all.

From the datasheet *Mobile Intel® 945 Express Chipset Family* [4] the
register BSM is described on page 290.

Graphics Stolen Memory and TSEG are within DRAM space defined
under TOLUD. From the top of low used DRAM, (G)MCH claims 1 to
64 MBs of DRAM for internal graphics if enabled.

This register contains bits 31 to 20 of the base address of
stolen
DRAM memory. The host interface determines the base of
graphics stolen memory by subtracting the graphics stolen
memory size from TOLUD. See Device 0 TOLUD for more
explanations.

Also see Figure 12 *Main Memory Address Range* in section 9.2 on page
325.

Unfortunately I am unable to find out how the graphics stolen memory
size is determined. I’d have thought it is used for the framebuffer, but
according to page 93 (Graphics Mode select (GMS)) that the framebuffer
size can only be 1 MB or 8 MB, which contradicts that it can be up to 64
MB.

If it is determined implicitly by the value I set the BSM to, where can
I find the recommendations what size to use? I’d guess it is dependent
on the RAM size, that means dependent if the system has 512 MB or 4 GB
for example.

The datasheet documents the bits of the register BSM as Read Only (RO).
So I am even more confused now.

It turned out that the register is indeed read-only and that the
register to look at seems to be PGTBL_CTL/PGETBL_CTL.

Thanks,

Paul

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=17fec8a08698bcab98788e1e89f5b8e7502ababd
[2] http://www.coreboot.org/
[3] https://bugs.freedesktop.org/show_bug.cgi?id=79038
[4]
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobile-945-express-chipset-datasheet.pdf
Document Number: 309219-006

signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [Intel 945] BSM: How to determine size of DRAM used for internal graphics?

2014-05-30 Thread Paul Menzel

Dear Intel graphics folks,

since commit 17fec8a0 [1]

drm/i915: Use Graphics Base of Stolen Memory on all gen3+

From the datasheet *Mobile Intel® 945 Express Chipset Family* [4] the
register BSM is described on page 290.

Graphics Stolen Memory and TSEG are within DRAM space defined
under TOLUD. From the top of low used DRAM, (G)MCH claims 1 to
64 MBs of DRAM for internal graphics if enabled.

Also see Figure 12 *Main Memory Address Range* in section 9.2 on page
325.

Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Intel 945] BSM: How to determine size of DRAM used for internal graphics?

2014-05-30 Thread Paul Menzel

Dear Intel graphics folks,

Am Freitag, den 30.05.2014, 13:45 +0200 schrieb Paul Menzel:

since commit 17fec8a0 [1]

drm/i915: Use Graphics Base of Stolen Memory on all gen3+

From the datasheet *Mobile Intel® 945 Express Chipset Family* [4] the
register BSM is described on page 290.

Graphics Stolen Memory and TSEG are within DRAM space defined
under TOLUD. From the top of low used DRAM, (G)MCH claims 1 to
64 MBs of DRAM for internal graphics if enabled.

Also see Figure 12 *Main Memory Address Range* in section 9.2 on page
325.

The datasheet documents the bits of the register BSM as Read Only (RO).
So I am even more confused now.

Thanks,

Paul

signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] OT: GSoC project idea: Replacement of Video BIOS for native graphics initialization in coreboot

2013-04-11 Thread Paul Menzel

(Sent to dri-devel and intel-gfx lists.)


Dear Linux graphics folks,


coreboot has been accepted to participate in Google Summer of Code 2013
[1]. coreboot is a Free Software project aimed at replacing the
proprietary BIOS (firmware) found in most computers.

Please find more information about GSoC in our Wiki [3], where some
project ideas are already listed [4]. But you can of course propose your
own ideas.

A nice project for you graphics folks might be to work on native
graphics initialization to replace the Video BIOS [5][6]. For example on
the Chromebook Pixel (Google Link) the Video BIOS takes 1.5 s and the
native graphics initialization just 200 ms [7].

So if you are interested, please join the coreboot list and the IRC
channel, ask questions and submit your proposal. We are looking forward
to it!


Thanks and happy coding,

Paul


PS: If you know somebody interested in this, please spread the word.


[1] http://blogs.coreboot.org/blog/2013/03/30/google-summer-of-code-2013/
[2] http://www.coreboot.org/
[3] http://www.coreboot.org/GSoC
[4] http://www.coreboot.org/Project_Ideas
[5] 
https://docs.google.com/document/d/1g8FMob25VZYxbWri2iFB8YiSL8gwF9vKJH3HGxr0xQU/edit?pli=1#
[6] http://www.coreboot.org/pipermail/coreboot/2013-March/075512.html
[7] http://review.coreboot.org/#/c/2531/5//COMMIT_MSG


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fixup pd vs pt confusion in gen6 ppgtt code

2013-03-20 Thread Paul Menzel

Dear Daniel,


Am Dienstag, den 19.03.2013, 23:51 +0100 schrieb Daniel Vetter:
 The index variable points at a page table, not a page directory or a
 pde. Ben Widawsky fix this up correctly in his ppgtt cleanup, but I've

fix*ed*

 botched the job and copypasted the old confusion from the original
 gen6 ppgtt code in
 
 commit def886c3768d24c4e0aa56ff98b5a468c2b5c9bf
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Jan 24 14:44:56 2013 -0800
 
 drm/i915: vfuncs for ppgtt
 
 Cc: Ben Widawsky b...@bwidawsk.net
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_gem_gtt.c |   14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.

2013-03-06 Thread Paul Menzel

Am Montag, den 04.03.2013, 17:17 +0100 schrieb Daniel Vetter:
 On Mon, Mar 04, 2013 at 09:24:38AM -0500, Egbert Eich wrote:
  On G45 some low res modes (800x600 and 1024x768) produce a blank
  screen when the display plane is enabled with with cursor plane
  off.
  Experiments showed that this issue occurred when the following
  conditions were met:
  a. a previous mode had the cursor plane enabled (Xserver).
  b. this mode or the previous one was using self refresh. (Thus
 the problem was only seen with low res modes).
  The screens lit up as soon as the cursor plane got enabled.
  Therefore the blank screen occurred only in console mode, not
  when running an Xserver.
  It also seemed to be necessary to disable self refresh while briefly
  enabling the cursor plane.
  
  Signed-off-by: Egbert Eich e...@suse.com
  Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=61457
  Acked-by: Chris Wilson ch...@chris-wilson.co.uk
 
 This w/a is impressive ;-) Applied to -fixes, thanks for the patch.
 -Daniel
 
  ---
   drivers/gpu/drm/i915/intel_display.c |   28 +++-
   1 files changed, 27 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 6eb3882..689cc3a 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c

[…]

  @@ -6337,7 +6363,7 @@ static int intel_crtc_cursor_set(struct drm_crtc 
  *crtc,
  i915_gem_detach_phys_object(dev, 
  intel_crtc-cursor_bo);
  } else
  i915_gem_object_unpin(intel_crtc-cursor_bo);
  -   drm_gem_object_unreference(intel_crtc-cursor_bo-base);
  +   
  drm_gem_object_unreference(intel_crtc-cursor_bo-base);

As there are no {} around the else branch, this indentation is
incorrect, right?

  }
   
  mutex_unlock(dev-struct_mutex);


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits

2013-03-05 Thread Paul Menzel

Dear Patrik,


Am Dienstag, den 05.03.2013, 19:09 +0100 schrieb Patrik Jakobsson:
 Disable bits for ADPA HSYNC and VSYNC where mixed up resulting in suspend
 becoming standby and vice versa.

nice find. Could you elaborate on the symptoms please as I have never
experienced any issues with suspend and resume on my ASUS Eee PC 701 4G?

 Fixed by swapping their bit position.
 
 Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com

Where did Ville report this? Maybe my questions are already answered
there.

 Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com
 ---
  drivers/gpu/drm/i915/i915_reg.h |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Tabs or spaces? (was: [I-G-T] tools/intel_reg_dumper: add hsw backlight registers)

2013-03-04 Thread Paul Menzel

Dear intel-gfx folks,


Am Montag, den 04.03.2013, 12:22 +0200 schrieb Jani Nikula:
 The more the merrier.
 
 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
  lib/intel_reg.h  |5 +
  tools/intel_reg_dumper.c |5 +
  2 files changed, 10 insertions(+)
 
 diff --git a/lib/intel_reg.h b/lib/intel_reg.h
 index 99d97bb..db07064 100644
 --- a/lib/intel_reg.h
 +++ b/lib/intel_reg.h
 @@ -3465,6 +3465,11 @@ typedef enum {
  #define  PWM_PIPE_B (1  29)
  #define BLC_PWM_CPU_CTL 0x48254
  
 +#define BLC_PWM2_CTL 0x48350
 +#define BLC_PWM2_DATA0x48354
 +#define BLC_MISC_CTL 0x48360
 +#define UTIL_PIN_CTL 0x48400
 +

looking at that change I noticed that tabs and spaces are mixed in that
file? What is preferred?

  #define BLC_PWM_PCH_CTL10xc8250
  #define  PWM_PCH_ENABLE (1  31)
  #define  PWM_POLARITY_ACTIVE_LOW(1  29)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] sna: Initialize variable 'iter' to silence clang

2013-02-28 Thread Paul Menzel

Dear Sedat,


thank you for testing stuff with Clang!


Am Dienstag, den 26.02.2013, 15:15 +0100 schrieb Sedat Dilek:

Please always paste the error/warning messages so reviewers see exactly
what it has find.

 Signed-off-by: Sedat Dilek sedat.di...@gmail.com
 ---
  src/sna/sna_damage.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/src/sna/sna_damage.c b/src/sna/sna_damage.c
 index ab693af..53ed635 100644
 --- a/src/sna/sna_damage.c
 +++ b/src/sna/sna_damage.c
 @@ -410,7 +410,7 @@ static void __sna_damage_reduce(struct sna_damage *damage)
   int n, nboxes;
   BoxPtr boxes, free_boxes = NULL;
   pixman_region16_t *region = damage-region;
 - struct sna_damage_box *iter;
 + struct sna_damage_box *iter = NULL;

Looking at the macro in `src/intel_list.h`

/**
 * Loop through the list given by head and set pos to struct in the 
list.
 *
 * Example:
 * struct foo *iterator;
 * list_for_each_entry(iterator, bar-list_of_foos, entry) {
 *  [modify iterator]
 * }
 *
 * This macro is not safe for node deletion. Use 
list_for_each_entry_safe
 * instead.
 *
 * @param pos Iterator variable of the type of the list elements.
 * @param head List head
 * @param member Member name of the struct list in the list elements.
 *
 */
#define list_for_each_entry(pos, head, member)  
\
for (pos = __container_of((head)-next, pos, member);   
\
 pos-member != (head);
\
 pos = __container_of(pos-member.next, pos, member))

the iterator is definitely initialized in the for loop.

pos = __container_of((head)-next

   assert(damage-mode != DAMAGE_ALL);
   assert(damage-dirty);
 @@ -1671,7 +1671,7 @@ void _sna_damage_debug_get_region(struct sna_damage 
 *damage, RegionRec *r)
  {
   int n, nboxes;
   BoxPtr boxes;
 - struct sna_damage_box *iter;
 + struct sna_damage_box *iter = NULL;
  
   RegionCopy(r, damage-region);
   if (!damage-dirty)

So in my opinion this patch should not be applied as it would prevent
the compiler to warn next time when there is really a code change where
this variable might be uninitialized.

By the way, does `gcc` warn about this?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Warnings in `sna_damage.c` (was: [PATCH] sna: Initialize variable 'iter' to silence clang)

2013-02-28 Thread Paul Menzel

Dear Sedat,


Am Donnerstag, den 28.02.2013, 09:45 +0100 schrieb Paul Menzel:

 thank you for testing stuff with Clang!
 
 
 Am Dienstag, den 26.02.2013, 15:15 +0100 schrieb Sedat Dilek:
 
 Please always paste the error/warning messages so reviewers see exactly
 what it has find.
 
  Signed-off-by: Sedat Dilek sedat.di...@gmail.com
  ---
   src/sna/sna_damage.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
  
  diff --git a/src/sna/sna_damage.c b/src/sna/sna_damage.c
  index ab693af..53ed635 100644
  --- a/src/sna/sna_damage.c
  +++ b/src/sna/sna_damage.c
  @@ -410,7 +410,7 @@ static void __sna_damage_reduce(struct sna_damage 
  *damage)
  int n, nboxes;
  BoxPtr boxes, free_boxes = NULL;
  pixman_region16_t *region = damage-region;
  -   struct sna_damage_box *iter;
  +   struct sna_damage_box *iter = NULL;
 
 Looking at the macro in `src/intel_list.h`
 
 /**
  * Loop through the list given by head and set pos to struct in the 
 list.
  *
  * Example:
  * struct foo *iterator;
  * list_for_each_entry(iterator, bar-list_of_foos, entry) {
  *  [modify iterator]
  * }
  *
  * This macro is not safe for node deletion. Use 
 list_for_each_entry_safe
  * instead.
  *
  * @param pos Iterator variable of the type of the list elements.
  * @param head List head
  * @param member Member name of the struct list in the list elements.
  *
  */
 #define list_for_each_entry(pos, head, member)
 \
 for (pos = __container_of((head)-next, pos, member); 
 \
pos-member != (head);
 \
pos = __container_of(pos-member.next, pos, member))
 
 the iterator is definitely initialized in the for loop.
 
 pos = __container_of((head)-next
 
  assert(damage-mode != DAMAGE_ALL);
  assert(damage-dirty);
  @@ -1671,7 +1671,7 @@ void _sna_damage_debug_get_region(struct sna_damage 
  *damage, RegionRec *r)
   {
  int n, nboxes;
  BoxPtr boxes;
  -   struct sna_damage_box *iter;
  +   struct sna_damage_box *iter = NULL;
   
  RegionCopy(r, damage-region);
  if (!damage-dirty)
 
 So in my opinion this patch should not be applied as it would prevent
 the compiler to warn next time when there is really a code change where
 this variable might be uninitialized.
 
 By the way, does `gcc` warn about this?

Using GCC I only see the following warnings in `sna_damage.c`.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
4.7.2-15' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs 
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.7 --enable-shared --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object 
--enable-plugin --enable-objc-gc --enable-targets=all --enable-multiarch 
--with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --with-tune=generic 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-15)
$ ./autogen.sh # I’d prefer it did not run ./configure
$ make
[…]
sna_damage.c: In function '__sna_damage_add_box':
sna_damage.c:601:11: warning: cast discards '__attribute__((const))' 
qualifier from pointer target type [-Wcast-qual]
sna_damage.c: In function '__sna_damage_contains_box':
sna_damage.c:1292:58: warning: cast discards '__attribute__((const))' 
qualifier from pointer target type [-Wcast-qual]
sna_damage.c:1305:59: warning: cast discards '__attribute__((const))' 
qualifier from pointer target type [-Wcast-qual]
sna_damage.c: In function '_sna_damage_contains_box__no_reduce':
sna_damage.c:1346:42: warning: cast discards '__attribute__((const))' 
qualifier from pointer target type [-Wcast-qual]
sna_damage.c:1347:7: warning: cast discards '__attribute__((const))' 
qualifier from pointer target type [-Wcast-qual]
[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Eliminate race from gen2/3 page flip interrupt handling

2013-02-18 Thread Paul Menzel

Am Montag, den 18.02.2013, 13:57 +0200 schrieb ville.syrj...@linux.intel.com:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 If the interrupt handler were to process a previous vblank interrupt and
 the following flip pending interrupt at the same time, the page flip
 would be complete too soon.

»would complete« or »would be complete*d*«

 To eliminate this race check the live pending flip status from the ISR
 register before finishing the page flip.

Could this be tested somehow? Could a test case be written for this?

 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/i915_irq.c | 21 +++--
  1 file changed, 15 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
 index 9fde49a..3de570c 100644
 --- a/drivers/gpu/drm/i915/i915_irq.c
 +++ b/drivers/gpu/drm/i915/i915_irq.c
 @@ -2284,8 +2284,11 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
   drm_handle_vblank(dev, 0)) {
   if (iir  I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT) {
   intel_prepare_page_flip(dev, 0);
 - intel_finish_page_flip(dev, 0);
 - flip_mask = 
 ~I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT;
 +
 + if ((I915_READ16(ISR)  
 I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT) == 0) {
 + intel_finish_page_flip(dev, 0);
 + flip_mask = 
 ~I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT;
 + }
   }
   }
  
 @@ -2293,8 +2296,11 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
   drm_handle_vblank(dev, 1)) {
   if (iir  I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT) {
   intel_prepare_page_flip(dev, 1);
 - intel_finish_page_flip(dev, 1);
 - flip_mask = 
 ~I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
 +
 + if ((I915_READ16(ISR)  
 I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT) == 0) {
 + intel_finish_page_flip(dev, 1);
 + flip_mask = 
 ~I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
 + }
   }
   }
  
 @@ -2491,8 +2497,11 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
   drm_handle_vblank(dev, pipe)) {
   if (iir  flip[plane]) {
   intel_prepare_page_flip(dev, plane);
 - intel_finish_page_flip(dev, pipe);
 - flip_mask = ~flip[plane];
 +
 + if ((I915_READ(ISR)  flip[plane]) == 
 0) {

Why not `I915_READ16`?

 + intel_finish_page_flip(dev, 
 pipe);
 + flip_mask = ~flip[plane];
 + }
   }
   }


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Read the Base of Stolen Memory for 915gm

2013-02-11 Thread Paul Menzel

Dear Chris,


Am Sonntag, den 10.02.2013, 23:21 + schrieb Chris Wilson:
 On Sun, Feb 10, 2013 at 11:37:03PM +0100, Paul Menzel wrote:
  Am Sonntag, den 10.02.2013, 19:38 + schrieb Chris Wilson:
   Reading the cspec pays dividends once again, as I found the 'Base of
   Stolen Memory' config register so that we can skip the fragile
   computation from Top of Usable Draw and use the real value provided by
   the BIOS.
  
  Nice find. What is the expected functionality change as the code
  beforehand was a no-op due to the `if 0`?
 
 It enables the driver to use stolen memory - memory that is hidden from
 the system and only available, in principal, to the gfx device.

ah, nice. Thank you for the explanation.

Should it be backported to the stable Linux kernel releases then, by
adding the following line to the commit message?

CC: sta...@vger.kernel.org

  If testing is needed, how can this be tested?
 
 Boot a 915g/945g. The driver will utilize stolen memory for its
 ringbuffers and fbcon.

Any messages which will get logged to see if it works correctly?

   - /* Stolen is immediately below Top of Low Usable DRAM */
   - pci_read_config_byte(pdev, 0x9c, val);
   - base = val  3  27;
   - base -= dev_priv-mm.gtt-stolen_size;
   + /* Read D2:F0 Base of Stolen Memory directly */
   + pci_read_config_dword(dev-pdev, 0x5c, base);
  
  Should macros be defined for the register names?
 
 My argument is basically where else are you planning to use this value.
 Each chipset calls it something different and uses a different register,
 so DRY is not violated and instead of hiding the value in a header, we
 can define it locally and clearly. Makes adapting it for the next
 generation much easier as you only have the single location to worry
 about. (The normal argument for the macro, but in reverse.)

Sounds reasonable.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Read the Base of Stolen Memory for 915gm

2013-02-10 Thread Paul Menzel

Am Sonntag, den 10.02.2013, 19:38 + schrieb Chris Wilson:
 Reading the cspec pays dividends once again, as I found the 'Base of
 Stolen Memory' config register so that we can skip the fragile
 computation from Top of Usable Draw and use the real value provided by
 the BIOS.

Nice find. What is the expected functionality change as the code
beforehand was a no-op due to the `if 0`?

If testing is needed, how can this be tested?

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_gem_stolen.c |9 +++--
  1 file changed, 3 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 130d1db..7f1735c 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -72,13 +72,10 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   } else if (INTEL_INFO(dev)-gen  3 || IS_G33(dev)) {
   /* Read Graphics Base of Stolen Memory directly */
   pci_read_config_dword(pdev, 0xA4, base);
 -#if 0
   } else if (IS_GEN3(dev)) {
 - u8 val;
 - /* Stolen is immediately below Top of Low Usable DRAM */
 - pci_read_config_byte(pdev, 0x9c, val);
 - base = val  3  27;
 - base -= dev_priv-mm.gtt-stolen_size;
 + /* Read D2:F0 Base of Stolen Memory directly */
 + pci_read_config_dword(dev-pdev, 0x5c, base);

Should macros be defined for the register names?

 +#if 0
   } else {
   /* Stolen is immediately above Top of Memory */
   base = max_low_pfn_mapped  PAGE_SHIFT;


Thanks,

Paul



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/12] configure.ac: slightly more standard --disable-tests

2013-02-08 Thread Paul Menzel

Dear Ben,


Am Donnerstag, den 07.02.2013, 10:39 -0800 schrieb Ben Widawsky:
 This partially reverts

missing empty line for better legibility.

 commit 7c170724003f42cd4ceea9f6c805292bbe2e81b2
 Author: Rodrigo Vivi rodrigo.v...@gmail.com
 Date:   Tue Feb 5 16:17:54 2013 -0200
 
 Build: Add --disable-tests configure flag to avoid tests build
 
 I was still in the middle of arguing this when Daniel merged it.

Could you please explain your change? Why is it »sligthly more
standard«?

 Cc: Rodrigo Vivi rodrigo.v...@gmail.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Julien Cristau jcris...@debian.org
 Signed-off-by: Ben Widawsky b...@bwidawsk.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/12] configure.ac: Move prime stuff to where it belongs

2013-02-08 Thread Paul Menzel

Am Donnerstag, den 07.02.2013, 10:39 -0800 schrieb Ben Widawsky:

So where does it belong?

 Signed-off-by: Ben Widawsky b...@bwidawsk.net

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/12] README: Add quick_dump info

2013-02-07 Thread Paul Menzel

Am Donnerstag, den 07.02.2013, 10:39 -0800 schrieb Ben Widawsky:

Thank you for updating documentation!

 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  README | 15 +++
  1 file changed, 15 insertions(+)
 
 diff --git a/README b/README
 index 0ec53fb..5ede794 100644
 --- a/README
 +++ b/README
 @@ -75,6 +75,21 @@ tools/
   These tools generally must be run as root, safe for the ones that just
   decode dumps.
  
 +tools/quick_dump
 + Quick dumper is a python tool built with SWIG bindings to
 + important libraries exported by the rest of the tool quite. The tool

*s*uite

 + itself is quite straight forward, and should also be a useful example
 + for others wishing to write python based i915 tools.
 +
 + As of writing, the build is sort of broken in Arch because of

Arch Linux distribution [add URL]

 + the way they package Python. You'll need something like:
 + LDFLAGS=-lpython3.3m
 +
 + Note to package maintainers: It is not recommended to package
 + this directory, as the tool is not yet designed for such usage. If the

*wide* usage?

 + package is installed via make install the user will have to

s,the user/users/

 + set their python library path appropriately.
 +
  debugger/
   This tool is to be used to do shader debugging. It acts like a
   debug server accepting connections from debug clients such as

With the above changes (proofread by a native English speaker)

Reviewed-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/2] configure.ac: Split out XCB libraries from `XVMCLIB` into `XCB`

2013-02-06 Thread Paul Menzel

Date: Sun, 3 Feb 2013 13:33:08 +0100

Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
that `libI810XvMC.so.1.0.0` does not need to be linked against
`libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or
`libxcb.so.1` [1].

$ debuild -b -us -uc
[…]
make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libX11-xcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libxcb-dri2.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libxcb-util.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libxcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
[…]

Moving `x11-xcb`, `xcb-dri2` and `xcb-aux` from `XVMCLIBS` into `XCB`
and adding `XCB_LIBS` only to the `LIBADD` variables of `libIntelXvMC`
makes the warnings go away and the libraries are still built without any
issues.

make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
   dh_installdeb -O--builddirectory=build/
   dh_xsf_substvars -O--builddirectory=build/
   dh_gencontrol -O--builddirectory=build/
dpkg-gencontrol: Warnung: Feld Depends von Paket 
xserver-xorg-video-intel-dbg: unbekannte Substitutionsvariable ${shlibs:Depends}
   dh_md5sums -O--builddirectory=build/
   dh_builddeb -O--builddirectory=build/
dpkg-deb: Paket »xserver-xorg-video-intel« wird in 
»../xserver-xorg-video-intel_2.19.0-6.1_i386.deb« gebaut.
dpkg-deb: Paket »xserver-xorg-video-intel-dbg« wird in 
»../xserver-xorg-video-intel-dbg_2.19.0-6.1_i386.deb« gebaut.
 dpkg-genchanges -b ../xserver-xorg-video-intel_2.19.0-6.1_i386.changes
dpkg-genchanges: rein binärer Upload - es ist kein Quellcode hinzugefügt
 dpkg-source --after-build xserver-xorg-video-intel
dpkg-buildpackage: Binärpaket(e) hochzuladen (keine Quellen enthalten)
Now running lintian...
W: xserver-xorg-video-intel: hardening-no-relro 
usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions 
usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro 
usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions 
usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro 
usr/lib/xorg/modules/drivers/intel_drv.so
W: xserver-xorg-video-intel: hardening-no-fortify-functions 
usr/lib/xorg/modules/drivers/intel_drv.so
N: 1 tag overridden (1 warning)
Finished running lintian.

The modules were originally added with the following commit present
since tag 2.10.0.

commit 3e8f2eae3a586aa29be4858698e666e0ec778cea
Author: Eric Anholt e...@anholt.net
Date:   Thu Oct 15 13:48:56 2009 -0700

XVMC: Use XCB DRI2 instead of cargo-culting our own copy of Xlib 
stuff. (v2)

[1] 
https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intelarch=i386ver=2%3A2.19.0-6stamp=1347825458

Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
 configure.ac |3 ++-
 src/xvmc/Makefile.am |2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index e6ab9d0..5ae4208 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,8 +404,9 @@ AC_MSG_RESULT([$DRI2])
 
 if test $XVMC = yes; then
PKG_CHECK_MODULES(XVMCLIB,
- [xvmc dri2proto x11-xcb xcb-dri2 xcb-aux],
+ [xvmc dri2proto],
  [XVMC=yes], [XVMC=no])
+   PKG_CHECK_MODULES(XCB, [x11-xcb xcb-dri2 xcb-aux])
 fi
 AC_MSG_CHECKING([whether to include XvMC support])
 AC_MSG_RESULT([$XVMC])
diff --git a/src/xvmc/Makefile.am b/src/xvmc/Makefile.am
index 36a939b..85e6a89 100644
--- a/src/xvmc/Makefile.am
+++ b/src/xvmc/Makefile.am
@@ -20,4 +20,4 @@ AM_CFLAGS = @XORG_CFLAGS@ @DRM_CFLAGS@ @DRI_CFLAGS@ \
@XVMCLIB_CFLAGS@ -I$(top_srcdir)/src -DTRUE=1 -DFALSE=0
 
 libIntelXvMC_la_LDFLAGS = -version-number 1:0:0
-libIntelXvMC_la_LIBADD = @DRI_LIBS@ @DRM_LIBS@ @XVMCLIB_LIBS@ @DRMINTEL_LIBS@ 
-lpthread
+libIntelXvMC_la_LIBADD = @DRI_LIBS@ @DRM_LIBS@ @XVMCLIB_LIBS@ @XCB_LIBS@ 
@DRMINTEL_LIBS@ -lpthread
-- 
1.7.10.4


signature.asc
Description: This is a digitally signed

[Intel-gfx] [PATCH] NEWS: Fix a typo: an inadvertent

2013-02-06 Thread Paul Menzel

Date: Tue, 22 Jan 2013 10:47:22 +0100

---
 NEWS |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index a1fcf66..bc384e7 100644
--- a/NEWS
+++ b/NEWS
@@ -47,7 +47,7 @@ As usual we have a large number of bug fixes since the last 
release:
 Release 2.20.19 (2013-01-20)
 
 A quick release as the last broke USB DisplayLink slave outputs badly. The
-performance of those displays was unusable due to a inadvertent change that
+performance of those displays was unusable due to an inadvertent change that
 caused us to flush the entire scanout over the USB for every drawing
 operation.
 
-- 
1.7.10.4



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Build: Add --disable-tests configure flag to avoid tests build - v2

2013-02-05 Thread Paul Menzel

Dear Rodrigo,


Am Dienstag, den 05.02.2013, 16:17 -0200 schrieb Rodrigo Vivi:
 Tests are still being built by default. However this request
 came from OSVs in order to allow them to include i-g-t in their

Please do not use abbreviations which do not even show up in the top ten
hits when searching for them in the Google search engine.

 distributions by default avoiding adding more and more dependencies
 since we are improving and adding more and more tests.
 
 v2: wait for Ben's spacin fixes and adjusted for new space rules.

For the subject line from `git help format-pactch`:

$ git format-patch --subject-prefix=PATCH v2

 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 
 Conflicts:
   configure.ac

As it is just locale for you, you can remove this, right?

 ---
  Makefile.am  |  6 +-
  configure.ac | 11 ++-
  2 files changed, 15 insertions(+), 2 deletions(-)

[…]

With the changes above,

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] configure.ac: Do not include `x11-xcb`, `xcb-dri2` and `xcb-aux` in `XVMCLIB`

2013-02-05 Thread Paul Menzel

Am Montag, den 04.02.2013, 22:28 +0100 schrieb Julien Cristau:
 On Sun, Feb  3, 2013 at 13:29:04 +0100, Paul Menzel wrote:
 
  I was surprised too that no error was generated. Do you have any idea
  why compilations succeeds?

 Fails to build here with
 ../../../src/xvmc/intel_xvmc.c:29:25: fatal error: xcb/xcb_aux.h: No such 
 file or directory

I wonder where our build environments differ.

 Also, shared libraries, as opposed to executable binaries, are allowed
 to have undefined symbols.

Sorry, as I cannot range in this comment, could you please elaborate.

 Try this:
 
 -libIntelXvMC_la_LDFLAGS = -version-number 1:0:0
 +libIntelXvMC_la_LDFLAGS = -version-number 1:0:0 -Wl,-z,defs

Thanks. With these flags/switches the build indeed fails. (Reading `man
ld` was also helpful to me.)

[…]
CC intel_batchbuffer.lo
CCLD   libIntelXvMC.la
.libs/intel_xvmc.o: In function `XvMCCreateContext':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:282:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `dri2_connect':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:131:
 undefined reference to `XGetXCBConnection'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:137:
 undefined reference to `xcb_aux_get_screen'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:139:
 undefined reference to `xcb_dri2_id'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:139:
 undefined reference to `xcb_get_extension_dat

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:147:
 undefined reference to `xcb_dri2_query_versio

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:148:
 undefined reference to `xcb_dri2_connect'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:150:
 undefined reference to `xcb_dri2_query_versio

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:152:
 undefined reference to `xcb_dri2_connect_repl

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:160:
 undefined reference to `xcb_dri2_connect_devi

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:166:
 undefined reference to `xcb_dri2_connect_devi
.libs/intel_xvmc.o: In function `XvMCCreateContext':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:301:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `dri2_connect':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:181:
 undefined reference to `xcb_dri2_authenticate

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:182:
 undefined reference to `xcb_dri2_authenticate
.libs/intel_xvmc.o: In function `XvMCCreateContext':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:323:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `XvMCCreateSurface':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:407:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `XvMCDestroySurface':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:458:
 undefined reference to `XFree'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:460:
 undefined reference to `XFreeGC'
.libs/intel_xvmc.o: In function `XvMCPutSurface':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:651:
 undefined reference to `XFreeGC'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:652:
 undefined reference to `XCreateGC'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:648:
 undefined reference to `XCreateGC'
.libs/i915_xvmc.o: In function `i915_xvmc_mc_create_context':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/i915_xvmc.c:915: 
undefined reference to `XFree'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/i915_xvmc.c:933: 
undefined reference to `XFree'
collect2: error: ld returned 1 exit status
make[5]: *** [libIntelXvMC.la] Fehler 1
[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] configure.ac: Do not include `x11-xcb`, `xcb-dri2` and `xcb-aux` in `XVMCLIB`

2013-02-03 Thread Paul Menzel

Am Sonntag, den 03.02.2013, 09:32 + schrieb Chris Wilson:
 The first patch looks fine (and I've applied it, thanks),

Thank you for the quick reaction.

 but I'm not convinced this one is safe.
 
 On Sat, Feb 02, 2013 at 11:00:15PM +0100, Paul Menzel wrote:
  Date: Sat, 2 Feb 2013 20:33:36 +0100
  
  Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
  that `libI810XvMC.so.1.0.0` does not need to be linked against
  `libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or
  `libxcb.so.1` [1].
  
  $ debuild -b -us -uc
  […]
  make[1]: Entering directory `/src/xserver-xorg-video-intel'
  dh_shlibdeps -- --warnings=6
  dpkg-shlibdeps: Warnung: 
  debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht 
  gegen libX11-xcb.so.1 gelinkt werden (es verwendet keines der 
  Bibliotheks-Symbole)
  dpkg-shlibdeps: Warnung: 
  debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht 
  gegen libxcb-dri2.so.0 gelinkt werden (es verwendet keines der 
  Bibliotheks-Symbole)
  dpkg-shlibdeps: Warnung: 
  debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht 
  gegen libxcb-util.so.0 gelinkt werden (es verwendet keines der 
  Bibliotheks-Symbole)
  dpkg-shlibdeps: Warnung: 
  debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht 
  gegen libxcb.so.1 gelinkt werden (es verwendet keines der 
  Bibliotheks-Symbole)
  make[1]: Leaving directory `/src/xserver-xorg-video-intel'
  […]
  
  Not populating `XVMCLIB` with `x11-xcb`, `xcb-dri2` and `xcb-aux` makes
  the warnings go away and the libraries are still built without any
  issues.
 
 Notice that the warning is only generated for I810XvMC and not for
 IntelXvMC which does use the DRI2 interface to pass along video objects.

I was surprised too that no error was generated. Do you have any idea
why compilations succeeds?

 Since XVMCLIB is shared between the two we would need to split out the
 I810XvMC dependencies from the IntelXvMC set first.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] configure.ac: Do not include `xext` and `xfixes` in `XVMCLIB`

2013-02-02 Thread Paul Menzel

Date: Sat, 2 Feb 2013 11:44:54 +0100

Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
that `libIntelXvMC.so.1.0.0` does not need to be linked against
`libXext.so.6` or `libXfixes.so.3` [1].

$ debuild -b -us -uc
[…]
make[1]: Entering directory 
`/build/buildd-xserver-xorg-video-intel_2.19.0-6-i386-9thLfo/xserver-xorg-video-intel-2.19.0'
dh_shlibdeps -- --warnings=6
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 should not be 
linked against libXext.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 should not be 
linked against libXfixes.so.3 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be 
linked against libXext.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be 
linked against libXfixes.so.3 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be 
linked against libX11-xcb.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be 
linked against libxcb-dri2.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be 
linked against libxcb-util.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be 
linked against libxcb.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 were not linked 
against libXext.so.6 (they use none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 were not linked 
against libXfixes.so.3 (they use none of the library's symbols)
make[1]: Leaving directory 
`/build/buildd-xserver-xorg-video-intel_2.19.0-6-i386-9thLfo/xserver-xorg-video-intel-2.19.0'
   dh_installdeb -a -O--builddirectory=build/
[…]

Not populating `XVMCLIB` with `xext` and `xfixes` makes the warning go
away and the libraries are still built without any issues.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intelarch=i386ver=2%3A2.19.0-6stamp=1347825458

Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 5135ecc..e6ab9d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,7 +404,7 @@ AC_MSG_RESULT([$DRI2])
 
 if test $XVMC = yes; then
PKG_CHECK_MODULES(XVMCLIB,
- [xvmc xext xfixes dri2proto x11-xcb xcb-dri2 xcb-aux],
+ [xvmc dri2proto x11-xcb xcb-dri2 xcb-aux],
  [XVMC=yes], [XVMC=no])
 fi
 AC_MSG_CHECKING([whether to include XvMC support])
-- 
1.7.10.4


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] configure.ac: Do not include `x11-xcb`, `xcb-dri2` and `xcb-aux` in `XVMCLIB`

2013-02-02 Thread Paul Menzel

Date: Sat, 2 Feb 2013 20:33:36 +0100

Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
that `libI810XvMC.so.1.0.0` does not need to be linked against
`libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or
`libxcb.so.1` [1].

$ debuild -b -us -uc
[…]
make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libX11-xcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libxcb-dri2.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libxcb-util.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: 
debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen 
libxcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
[…]

Not populating `XVMCLIB` with `x11-xcb`, `xcb-dri2` and `xcb-aux` makes
the warnings go away and the libraries are still built without any
issues.

make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
   dh_installdeb -O--builddirectory=build/
   dh_xsf_substvars -O--builddirectory=build/
   dh_gencontrol -O--builddirectory=build/
dpkg-gencontrol: Warnung: Feld Depends von Paket 
xserver-xorg-video-intel-dbg: unbekannte Substitutionsvariable ${shlibs:Depends}
   dh_md5sums -O--builddirectory=build/
   dh_builddeb -O--builddirectory=build/
dpkg-deb: Paket »xserver-xorg-video-intel« wird in 
»../xserver-xorg-video-intel_2.19.0-6.1_i386.deb« gebaut.
dpkg-deb: Paket »xserver-xorg-video-intel-dbg« wird in 
»../xserver-xorg-video-intel-dbg_2.19.0-6.1_i386.deb« gebaut.
 dpkg-genchanges -b ../xserver-xorg-video-intel_2.19.0-6.1_i386.changes
dpkg-genchanges: rein binärer Upload - es ist kein Quellcode hinzugefügt
 dpkg-source --after-build xserver-xorg-video-intel
dpkg-buildpackage: Binärpaket(e) hochzuladen (keine Quellen enthalten)
Now running lintian...
W: xserver-xorg-video-intel: hardening-no-relro 
usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions 
usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro 
usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions 
usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro 
usr/lib/xorg/modules/drivers/intel_drv.so
W: xserver-xorg-video-intel: hardening-no-fortify-functions 
usr/lib/xorg/modules/drivers/intel_drv.so
N: 1 tag overridden (1 warning)
Finished running lintian.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intelarch=i386ver=2%3A2.19.0-6stamp=1347825458

Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
I hope there is not a corner case where applying this patch will result
in built errors.

 configure.ac |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index e6ab9d0..0652822 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,7 +404,7 @@ AC_MSG_RESULT([$DRI2])
 
 if test $XVMC = yes; then
PKG_CHECK_MODULES(XVMCLIB,
- [xvmc dri2proto x11-xcb xcb-dri2 xcb-aux],
+ [xvmc dri2proto],
  [XVMC=yes], [XVMC=no])
 fi
 AC_MSG_CHECKING([whether to include XvMC support])
-- 
1.7.10.4


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Intel Linux display driver sending incompatible signal to one monitor.

2012-12-07 Thread Paul Menzel

Am Donnerstag, den 06.12.2012, 19:03 -0800 schrieb Freddie F. Haddad:
 Gentoo Linux
 - kernel 3.6.8
 - xf86-video-intel 2.20.15
 - xorg-server: 1.13.0-r1

Is your problem a regression?

 grub.conf
 kernel /boot/gentoo_3.6.8 root=/dev/sda3 video=1024x768-24@75 quiet splash
 
 .xinitrc
 xrandr --output HDMI1 --mode 1600x1200 --rate 60 --output HDMI3 --mode
 1600x1200 --rate 60 --right-of HDMI1
 
 Booting the system:
 Generally the displays are fine, however, sometimes (and it appears to
 be completely random) the left monitor will receive a video signal that
 is out of range. Briefly, the monitor will display a scrambled image
 followed by the monitor's on-screen display reporting the signal is out
 of range and then putting the monitor to sleep.
 
 Starting X via startx:
 When X starts, the same scenario as described above occurs.
 
 If I shutdown the x server and return to the console, the monitor that
 isn't displaying anything will come back on and be fine. Then if I start
 X again, it usually displays everything correctly.
 
 Both monitors (Dell Ultrasharp 2007FP) were purchased at the same time
 and are identical. Also, I have tried various configurations with xrandr
 and the kernel line in grub.conf. For example, I tried removing all
 kernel parameters as well as reducing xrandr the minimum options
 (removing mode and rate) without success.

I guess without log files the developers will not be able to help you.
For example you missed what hardware you are using. Please read the page
»How to file a good bug report« [1] for what is needed.


Thanks,

Paul


[1] http://intellinuxgraphics.org/how_to_report_bug.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: don't block resume on fb console resume

2012-11-04 Thread Paul Menzel

Dear Jesse,


unfortunately due to mail problems with SourceForge I did not get the
latest series.

Do you have a public repository with these patches in it?


Am Mittwoch, den 31.10.2012, 15:41 -0700 schrieb Jesse Barnes:
 The console lock can be contended, so rather than prevent other drivers
 after us from being held up, queue the console suspend into the global
 work queue that can happen anytime.  I've measured this to take around
 200ms on my T420.  Combined with the ring freq/turbo change, we should
 save almost 1/2 a second on resume.

In #intel-gfx on irc.freenode.net, Daniel told me that this is mostly
true for Sandybridge. Could you clarify that in the commit message
please.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] scripts: Add a dmesg filter to prettify ioctl traces

2012-11-01 Thread Paul Menzel

Am Donnerstag, den 01.11.2012, 16:42 + schrieb Damien Lespiau:
 From: Damien Lespiau damien.lesp...@intel.com

The content of the cover letter would have been very useful for this
commit message body. ;-)

 Signed-off-by: Damien Lespiau damien.lesp...@intel.com

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer

2012-10-22 Thread Paul Menzel

Am Montag, den 22.10.2012, 12:32 +0100 schrieb Chris Wilson:
 The specs for gen2 say that the watermark values should always be set
 assuming a 32bpp display mode, even though the display mode may be 15 or
 16 bpp.

Does this patch fix an actual bug or is it just preemptively doing so?

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/intel_pm.c |   17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Lockup when switching displays using xrandr since kernel 3.5.x

2012-10-18 Thread Paul Menzel

Am Donnerstag, den 18.10.2012, 09:10 +0200 schrieb Thilo-Alexander Ginkel:
 On Wed, Oct 17, 2012 at 1:26 AM, Thilo-Alexander Ginkel wrote:
  since upgrading from kernel 3.4.10 to 3.5.x or 3.6.2 (on Kubuntu
  12.04) I am getting sporadic (but frequent) lockups when switching
  displays using xrandr:
  [...]
 
 BTW, the lockups also happen with i915.i915_enable_rc6=1 (instead of
 the original i915.i915_enable_rc6=3).

Please follow the instructions on the page »How to file a good bug
report« [1].


Thanks,

Paul


[1] http://intellinuxgraphics.org/how_to_report_bug.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Set guardband clipping workaround bit in the right register.

2012-10-06 Thread Paul Menzel

Dear Kenneth,


thanks for the patch.


Am Freitag, den 05.10.2012, 17:46 -0700 schrieb Kenneth Graunke:
 Commit bf97b276ca04

Could you please paste the date, author and commit summary of this
commit too? At least I cannot memorize hashes that well and having the
summary pasted would give me enough information most of the time about
the other commit. ;-)

 accidentally set bit 5 in 3D_CHICKEN, which has
 nothing to do with clipping.  This patch changes it to be set in
 3D_CHICKEN3, where it belongs.
 
 The game Dante demonstrates random clipping issues when guardband
 clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set.  So the
 workaround actually is necessary.
 
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Oliver McFadden oliver.mcfad...@linux.intel.com
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  drivers/gpu/drm/i915/i915_reg.h | 2 +-
  drivers/gpu/drm/i915/intel_pm.c | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

[…]

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] could you stop this spam

2012-09-28 Thread Paul Menzel

Am Freitag, den 28.09.2012, 18:00 +0100 schrieb Sérgio Basto:
 This spam is making my spam filter get crazy .

Never paste spam!


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fighting tearing

2012-09-09 Thread Paul Menzel

Dear Roberth,


Am Sonntag, den 09.09.2012, 17:48 +0200 schrieb Roberth Sjonøy:

 I run Arch Linux, with it's latest x.org and kernel,

that is xorg-server 1.12.4-1 [1] and linux 3.5.3-1 [2].

 and I have compiled libdrm and the intel driver from git, and I update
 it today.

Please provide the Git commit hashes with the commit summaries to make
life for readers of your message easier.

 But this is issue exists even with the releases.

Since when do you experience these issues?

 With UXA, rendering of the windows in my XFCE4-desktop goes just
 fines, good performance, windows (exspecially GTK+) doesn't hang after
 if I drag them over the screen, but there is lot of small tearing.
 And I want this to go away, I do not use any kind of composition, and
 I am using XFCEs window manager.

Maybe your monitor causes the tearing?

 Here is my xorg.conf
 
 
 Section ServerFlags
 Option AutoAddDevices Off
 EndSection
 
 Section InputDevice
 Identifier Keyboard0
 Driver keyboard
 Option XkbLayout no
 EndSection
 
 Section Device
 Identifier  Card0
 Driver  intel
 Option  AccelMethod UXA
 Option  TearFree true
 Option  MigrationHeuristic greedy
 OptionTripleBuffer true
 EndSection
 
 With SNA, the performance of the applications is muc much worse. If I
 just replace UXA with SNA.

Is the tearing fixed though?

What happens when you test different Window managers or some live
distribution with other versions? You can even test those by saving the
ISO file on your drive and directly boot those using GRUB 2 [3].

 Thanks in advance for any help.

I am sorry for not being more helpful. Maybe the developers have more
ideas.


Thanks,

Paul


[1] http://www.archlinux.org/packages/extra/i686/xorg-server/
[2] http://www.archlinux.org/packages/core/i686/linux/
[3] https://bugs.freedesktop.org/show_bug.cgi?id=26294#c13


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes

2012-08-30 Thread Paul Menzel

Am Donnerstag, den 30.08.2012, 13:26 +0200 schrieb Daniel Vetter:
 We've had and still have too many issues where the gpu turbot doesn't

s,turbot,turbo,

 quite to what it's supposed to do (or what we want it to do).

s,to,do,

 Adding a tracepoint to track when the desired gpu frequence changes

frequenc*y*

 should help a lot in characterizing and understanding problematic
 workloads.
 
 Also, this should be fairly interesting for power tuning (and
 especially noticing when the gpu is stuck in high frequencies, as has
 happened in the past) and hence for integration into powertop and
 similar tools.

If this can be used from user space already, it would be nice to add
some notes to the commit how this can be done.

 Cc: Arjan van de Ven ar...@linux.intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_trace.h |   15 +++
  drivers/gpu/drm/i915/intel_pm.c   |2 ++
  2 files changed, 17 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_trace.h 
 b/drivers/gpu/drm/i915/i915_trace.h
 index 3c4093d..8134421 100644
 --- a/drivers/gpu/drm/i915/i915_trace.h
 +++ b/drivers/gpu/drm/i915/i915_trace.h
 @@ -430,6 +430,21 @@ TRACE_EVENT(i915_reg_rw,
   (u32)(__entry-val  32))
  );
  
 +TRACE_EVENT(intel_gpu_freq_change,
 + TP_PROTO(u32 freq),
 + TP_ARGS(freq),
 +
 + TP_STRUCT__entry(
 +  __field(u32, freq)
 +  ),
 +
 + TP_fast_assign(
 +__entry-freq = freq;
 +),
 +
 + TP_printk(new_freq=%u, __entry-freq)
 +);
 +
  #endif /* _I915_TRACE_H_ */
  
  /* This part must be outside protection */
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index ebe3498..194a72f 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2343,6 +2343,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
   I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
  
   dev_priv-rps.cur_delay = val;
 +
 + trace_intel_gpu_freq_change(val * 50);
  }
  
  static void gen6_disable_rps(struct drm_device *dev)

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Please add last edited date to http://intellinuxgraphics.org/

2012-08-26 Thread Paul Menzel

Dear Intel folks,


it would be nice if you could add a “last edited” field to the Web site
so information like on the teams page [1] can be judged better. (It
seems recent though, which is great and which should be made obvious.)


Thanks,

Paul


[1] http://intellinuxgraphics.org/team.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: differe error message between forcwake timeouts

2012-08-24 Thread Paul Menzel

Am Freitag, den 24.08.2012, 17:26 +0200 schrieb Daniel Vetter:

In the commit summary: s,differe,different,

 ickle danvet: in the force wake, both DRM_ERRORs have the same string.
 ickle useful for .txt shrinkage, horrible for debugging
 
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

 ---
  drivers/gpu/drm/i915/intel_pm.c |   12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

[…]

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fix color order for BGR formats on IVB

2012-08-22 Thread Paul Menzel

Dear Vijay,


Am Mittwoch, den 22.08.2012, 11:47 +0530 schrieb Vijay Purushothaman:
 This is already fixed for ILK and SNB

… in what commits?

 but somehow IVB is missed.
 
 Signed-off-by: Vijay Purushothaman vijay.a.purushotha...@intel.com
 Signed-off-by: Ben Lin ben.y@intel.com
 ---
  drivers/gpu/drm/i915/intel_sprite.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

[…]

Please resend as [PATCH v2] with the updated commit message [1].


Thanks,

Paul


[1] 
http://wireless.kernel.org/en/developers/Documentation/git-guide#Annotating_new_revision


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+

2012-08-15 Thread Paul Menzel

Am Mittwoch, den 15.08.2012, 10:41 +0200 schrieb Daniel Vetter:
 James Bottomley reported [1] a massive power regression, due to the
 enabling of semaphores by default in 3.5. A workaround for him is to
 again disable semaphores. And indeed, his system has a very hard time
 to entre rc6 with semaphores enabled.

s,entre,enter,

 Ben Widawsky run around with a kill-a-watt a lot and noticed:
 - There are indeed a few rare systems that seem to have a hard time
   entering rc6 when desktop-idle.
 - One machine, The Indestructible Toshiba regressed in this behaviour

Never heard that Toshiba name.

   between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
   current setting seems to be highly timing dependent and not robust
   at all.
 - The behaviour James reported wrt semaphores seems to be a freak
   timing thing that only happens on his specific machine, confirming
   that enabling semaphores shouldn't reduce rc6 residency.
 
 Now furthermore the Google ChromeOS guys reported [2] a while ago that
 at least on some machines a simply a blinking cursor can keep the gpu
 turbo at the highest frequency. This is because the current rps limits
 used on snb/ivb are highly asymmetric.
 
 On the theory that gpu turbo and rc6 tuning values are related, we've
 tried whether the much saner looking (since much less asymmetric) rps
 tuning values used for hsw would also help entering rc6 more robustly.
 
 And it seems to work.
 
 Reference[1]: 
 http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
 Reference[2]: 
 http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
 Tested-by: Ben Widawsky b...@bwidawsk.net

Did James already confirm, that this fixes his problem?

 Cc: sta...@vger.kernel.org
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/intel_pm.c |   15 ---
  1 file changed, 4 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index d64dffb..cf10a1d 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2482,17 +2482,10 @@ static void gen6_enable_rps(struct drm_device *dev)
  dev_priv-rps.max_delay  24 |
  dev_priv-rps.min_delay  16);
  
 - if (IS_HASWELL(dev)) {
 - I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
 - I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
 - I915_WRITE(GEN6_RP_UP_EI, 66000);
 - I915_WRITE(GEN6_RP_DOWN_EI, 35);
 - } else {
 - I915_WRITE(GEN6_RP_UP_THRESHOLD, 1);
 - I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100);
 - I915_WRITE(GEN6_RP_UP_EI, 10);
 - I915_WRITE(GEN6_RP_DOWN_EI, 500);
 - }
 + I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
 + I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
 + I915_WRITE(GEN6_RP_UP_EI, 66000);
 + I915_WRITE(GEN6_RP_DOWN_EI, 35);
  
   I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
   I915_WRITE(GEN6_RP_CONTROL,

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Find bugs in i915 driver

2012-08-13 Thread Paul Menzel

Am Montag, den 13.08.2012, 03:08 + schrieb Xu, Anhua:
 Sorry, Deniel/Greg, late response for your email because of a busy work last 
 work. 
 I will response to you guys ASAP :), below is the updated patch: 
 
 
 From 33eb95a3a711b2354985361ff208ea150a5ba235 Mon Sep 17 00:00:00 2001
 From: Xu Anhua anhua...@intel.com

If Anhua is your first name your name is still switched here.

Please do the following.

git commit --amend --author=Anhua Xu anhua...@intel.com

 Date: Tue, 31 Jul 2012 17:16:50 +0800
 Subject: [PATCH] drm/i915: fix wrong order of parameters in port checking 
 functions
 
 Wrong order of parameters passed-in when calling hdmi/adpa
 /lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
 This bug was indroduced by commit
 1519b9956eb4b4180fa3f47c73341463cdcfaa37

Since it is hard to remember commit hashes, you should add the following
summary

commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard kei...@keithp.com
Date:   Sat Aug 6 10:35:34 2011 -0700

drm/i915: Fix PCH port pipe select in CPT disable paths

or just the following.

1519b995 drm/i915: Fix PCH port pipe select in CPT disable paths

 The reachable tag for this commit is v3.1-rc1-3-g1519b99

Then this should be sent to stable [1] too?

Cc: sta...@vger.kernel.org

Does this actually fix a bug you are seeing or did you just spot this
reading the code?

 Signed-off-by: Anhua Xu anhua...@intel.com
 ---
  drivers/gpu/drm/i915/intel_display.c |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index f615976..5fc8c8d 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -1383,7 +1383,7 @@ static void assert_pch_hdmi_disabled(struct 
 drm_i915_private *dev_priv,
enum pipe pipe, int reg)
  {
   u32 val = I915_READ(reg);
 - WARN(hdmi_pipe_enabled(dev_priv, val, pipe),
 + WARN(hdmi_pipe_enabled(dev_priv, pipe, val),
PCH HDMI (0x%08x) enabled on transcoder %c, should be disabled\n,
reg, pipe_name(pipe));
  
 @@ -1403,13 +1403,13 @@ static void assert_pch_ports_disabled(struct 
 drm_i915_private *dev_priv,
  
   reg = PCH_ADPA;
   val = I915_READ(reg);
 - WARN(adpa_pipe_enabled(dev_priv, val, pipe),
 + WARN(adpa_pipe_enabled(dev_priv, pipe, val),
PCH VGA enabled on transcoder %c, should be disabled\n,
pipe_name(pipe));
  
   reg = PCH_LVDS;
   val = I915_READ(reg);
 - WARN(lvds_pipe_enabled(dev_priv, val, pipe),
 + WARN(lvds_pipe_enabled(dev_priv, pipe, val),
PCH LVDS enabled on transcoder %c, should be disabled\n,
pipe_name(pipe));
  
 @@ -1871,7 +1871,7 @@ static void disable_pch_hdmi(struct drm_i915_private 
 *dev_priv,
enum pipe pipe, int reg)
  {
   u32 val = I915_READ(reg);
 - if (hdmi_pipe_enabled(dev_priv, val, pipe)) {
 + if (hdmi_pipe_enabled(dev_priv, pipe, val)) {
   DRM_DEBUG_KMS(Disabling pch HDMI %x on pipe %d\n,
 reg, pipe);
   I915_WRITE(reg, val  ~PORT_ENABLE);
 @@ -1893,12 +1893,12 @@ static void intel_disable_pch_ports(struct 
 drm_i915_private *dev_priv,
  
   reg = PCH_ADPA;
   val = I915_READ(reg);
 - if (adpa_pipe_enabled(dev_priv, val, pipe))
 + if (adpa_pipe_enabled(dev_priv, pipe, val))
   I915_WRITE(reg, val  ~ADPA_DAC_ENABLE);
  
   reg = PCH_LVDS;
   val = I915_READ(reg);
 - if (lvds_pipe_enabled(dev_priv, val, pipe)) {
 + if (lvds_pipe_enabled(dev_priv, pipe, val)) {
   DRM_DEBUG_KMS(disable lvds on pipe %d val 0x%08x\n, pipe, 
 val);
   I915_WRITE(reg, val  ~LVDS_PORT_EN);
   POSTING_READ(reg);

With the changes addressed above, please add

Acked-by: Paul Menzel paulepan...@users.sourceforge.net

when sending [PATCH v3] as documented in [2].


Thanks,

Paul


[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/stable_kernel_rules.txt;h=b0714d8f678ac51d0c280a4f5f2980196052421f;hb=HEAD
[2] 
http://wireless.kernel.org/en/developers/Documentation/git-guide#Annotating_new_revision


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: ingore eDP bpc settings

2012-08-11 Thread Paul Menzel

Am Freitag, den 10.08.2012, 11:10 +0200 schrieb Daniel Vetter:

There is a typo in the commit summary: i*gn*ore.

 This has originally been introduced to not oversubscribe the dp links
 in
 
 commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18
 Author: Zhenyu Wang zhen...@linux.intel.com
 Date:   Tue Jan 12 05:38:31 2010 +0800
 
 drm/i915: fix pixel color depth setting on eDP
 
 Since then we've fixed up the dp link bandwidth calculation code for
 code

`for code` should be removed.

 and should now automatically fall back to 6bpc dithering. So this
 is unnecessary.
 
 Furthermore it seems to break the new MacbookPro with retina display,
 hence let's just rip this out.
 
 Reported-by: Benoit Gschwind gschw...@gnu-log.net
 Cc: Benoit Gschwind gschw...@gnu-log.net
 Cc: Francois Rigaut frig...@gmail.com
 Cc: Greg KH gre...@linuxfoundation.org
 Cc: sta...@vger.kernel.org
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 
 --
 
 Testing feedback highgly welcome, and thanks for Benoit for finding
 out that the bpc computations are busted.
 -Daniel
 ---
  drivers/gpu/drm/i915/intel_display.c |   11 ---
  1 file changed, 11 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index bddb290..ddd4db3 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -3755,17 +3755,6 @@ static bool intel_choose_pipe_bpp_dither(struct 
 drm_crtc *crtc,
   continue;
   }
  
 - if (intel_encoder-type == INTEL_OUTPUT_EDP) {
 - /* Use VBT settings if we have an eDP panel */
 - unsigned int edp_bpc = dev_priv-edp.bpp / 3;
 -
 - if (edp_bpc  display_bpc) {
 - DRM_DEBUG_KMS(clamping display bpc (was %d) to 
 eDP (%d)\n, display_bpc, edp_bpc);
 - display_bpc = edp_bpc;
 - }
 - continue;
 - }
 -
   /* Not one of the known troublemakers, check the EDID */
   list_for_each_entry(connector, dev-mode_config.connector_list,
   head) {

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Netiquette: No HTML messages please. (was: [ANNOUNCE] glamor 0.5.0)

2012-08-11 Thread Paul Menzel

Dear Zhigang,


thank you for the announcement message and congratulations on the
release. But please do not send HTML messages to lists [1]!


Thanks,

Paul


[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Macbook Air 2012

2012-08-11 Thread Paul Menzel

Dear Daniel,


Am Samstag, den 11.08.2012, 16:05 +0200 schrieb Daniel Wagner:

 I installed on my shiny new Macbook Air 2012 Fedora 17. After adding
 
 intremap=off
 
 to the kernel arguments, I was able to install the system. The X server 
 worked out of the box. This was with a 3.3.4 kernel.
 
 Then I started to upgrade the installation and a newer kernel was 
 installed 3.5. After the reboot the screen stayed black. Upgrading to 
 Linus' 3.6-rc1 didn't help either.
 
 After some research I have tried now Daniel's tree danvet branch 
 drm-intel-next. Still no success. I also found 
 https://bugs.freedesktop.org/show_bug.cgi?id=48652 which sounds awfully 
 like what I am seeing as symptoms.
 
 Unfortunately, is my graphic trouble debugging skills rather limited. Is 
 there anything I could provide to resolve this issue?

I think there is a fix already [1].

[…]


Thanks,

Paul


[1] http://lists.freedesktop.org/archives/intel-gfx/2012-August/019545.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 0/4] Haswell HDMI/DP audio enable

2012-08-08 Thread Paul Menzel

Dear Wang,


first is Wang your first name?

Am Mittwoch, den 08.08.2012, 11:03 +0800 schrieb Wang Xingchao:
 This patch series enable HDMI audio on Haswell platform, not DP audio.
 The DP enablement will come after the DP patches are upstream.
 
 I tested this patch on Sharkbay machine and i could hear clear sound from
 HDMI port.

Could you please add if that was a TV or a receiver?

 V2 patches fixed one warning and some type errors.
 
 V3 patches changes:
 - change some registers definitions
 - use macro for IBX/CPT/HSW to get registers
 - remove some unused variable intended to use in TODO list.
 
 v4 patches changes:
 - remove alsa related hack patch
 
 v5 patches changes:
 - change comments stype
 - split IBX/CTP registers patch into seperate one

• sep*a*rate

 - remove unused register definition
 
 Here're some notes useful for you to test the patches on Sharkbay machine:
 I please make sure your branch include below three commits in Takashi's 
 sound tree, othersiwe there's no proper Haswell ID and HDMI ID.  

• White space at the end.
• other*wise*

 For the upstream tree, please refer to sound git tree
 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
 You can just pull for-linus branch.
 The all commits above are found in 3.6-rc1.
 
 e926f2c850c472f813f9bab486c68a3fe0b03ae4
 1c76684d2752b3a24bb7da183cc18e5d126dbcc9
 bdbe34dece4942f4d8df9865dba7785bb813366a
 
 II No sound from HDMI/DP.
 we found it's not stable in current stage, sometimes you may not heard sound
 from HDMI or DP port, but most of the time you can heard clear sound. After
 some investigation, we suspect the HDA verb didnot really make codec 

did not

 change,and we regard the GPU register as the right one. (see III explanation)
 the easy way is to use intel_audio_dump to compare related registers, and make
 sure the port is enabled and unmute, otherwise there's no sound.
 intel_audio_tools has no support on Haswell yet, i wrote patches to make that
 happen, if you need the patches, please feel free to let me know. Here's part
 of the snapshot about port enable and mute status from intel_audio_dump:
 
 AUD_PORT_EN_HD_CFG  Port_B_Out_Enable 1
 AUD_PORT_EN_HD_CFG  Port_C_Out_Enable 1
 AUD_PORT_EN_HD_CFG  Port_D_Out_Enable 1
 AUD_PORT_EN_HD_CFG  Port_B_Amp_Mute_Status1
 AUD_PORT_EN_HD_CFG  Port_C_Amp_Mute_Status0
 AUD_PORT_EN_HD_CFG  Port_D_Amp_Mute_Status1
 
 you can see from above message, the Port C is enabled and unmute, that's what
 we expect.
 
 III HDA Codec dependency. When you found there's no sound from HDMI, please
 use intel_audio_dump to check Port enable/mute status in II and also check
 related Pipe/Transcoder/DDI port status. Sometimes the pipe and transcoder was
 disabled in dpms and will not work anymore, that results in the HDMI port no
 sound. HDA codec's three converters are somehow hardwired to audio Pipes and
 if you choose the pipe, that means the regarding Codec converter should be
 enabled too, and only one digital Pin's HDA verbs could work, that depends on
 whehter your Pin select the converter as input. Here's one example about the

whe*th*er

 Pipe/Transcoder/DDI port(Pipe B, DDI Port C):
 
 DDI_BUF_CTL_A 0x0080  DDI Buffer Controler A
 DDI_BUF_CTL_B 0x  DDI Buffer Controler B
 DDI_BUF_CTL_C 0x8000  DDI Buffer Controler C
 DDI_BUF_CTL_D 0x  DDI Buffer Controler D
 DDI_BUF_CTL_E 0x8002  DDI Buffer Controler E
 PIPE_CONF_A   0xc000  PIPE Configuration A
 PIPE_CONF_B   0xc000  PIPE Configuration B
 PIPE_CONF_C   0x  PIPE Configuration C
 PIPE_CONF_EDP 0x  PIPE Configuration EDP
 PIPE_DDI_FUNC_CTL_A   0xc4034002  PIPE DDI Function Control A
 PIPE_DDI_FUNC_CTL_B   0xa0035000  PIPE DDI Function Control B
 PIPE_DDI_FUNC_CTL_C   0x0003  PIPE DDI Function Control C
 PIPE_DDI_FUNC_CTL_EDP 0x0003  PIPE DDI Function Control EDP
 
 Wang Xingchao (3):

The line above should be removed.

 Wang Xingchao (4):
   drm/i915: HSW audio registers definition
   drm/i915: write eld info for HDMI audio
   drm/i915: Haswell HDMI audio enable
   drm/i915: use _PIPE macro for IBX/CPT register definition
 
  drivers/gpu/drm/i915/i915_reg.h  |   71 
 ++
  drivers/gpu/drm/i915/intel_ddi.c |6 ++-
  drivers/gpu/drm/i915/intel_display.c |   52 -
  3 files changed, 118 insertions(+), 11 deletions(-)


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Find bugs in i915 driver

2012-08-01 Thread Paul Menzel

Dear Anhua,


five additional comments to Greg’s ones.


Am Dienstag, den 31.07.2012, 07:23 -0700 schrieb Greg KH:
 On Tue, Jul 31, 2012 at 09:17:15AM +, Xu, Anhua wrote:
  Thanks Chris. I add this in the the commit description. The updated patch 
  is below: 
  
  commit 71c3ff04834a01c81a5843996b87397273eb538d
  Author: Xu Anhua anhua...@intel.com

1. Looking at your address in the From field of this message there is
Xu, Anhua, so I am not sure which is your first name.

If it is Anhua, please do the following.

git config --global author.name Anhua Xu

  Date:   Tue Jul 31 17:16:50 2012 +0800
  
  i915: make the parameters passed-in coherent with functions'
  definition when calling hdmi/adpa/lvds_pipe_enabled()
  
  This bug is indroduced by commit 
  1519b9956eb4b4180fa3f47c73341463cdcfaa37

1. There is a typo: in*t*roduced. The spell checker of your email
program should mention that. Or you hook up Git to check that [1][2][3].

  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
 
 No signed-off-by?  No tag for inclusion in the stable tree?
 
 This patch isn't going very far :(

2. Please do not just mention the hash of the commit but also the
summary. Only a few people have memorized all hashes. ;-)

commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard kei...@keithp.com
Date:   Sat Aug 6 10:35:34 2011 -0700

drm/i915: Fix PCH port pipe select in CPT disable paths

You can use `git commit --amend --author=Anhua Xu to edit the last
commit.

3. To include the patch you seem to copy the output of `git log` or `git
show`. The recommended way is to use `git format-patch -s -1`. This way
the commit message is indented correctly.

4. Your first message of this thread included a HTML part. Luckily your
reply did not which suggests that your mail program supports writing
just plain text messages. In the future it would be great if you could
write just plain text messages which is the recommended way for mailing
lists [4].


Thanks,

Paul


[1] 
http://blog.mpdaugherty.com/2010/04/06/how-to-include-git-hooks-in-a-repository-and-still-personalize-your-machine/
[2] 
http://stackoverflow.com/questions/1691060/vim-set-spell-in-file-git-commit-editmsg
[3] http://petereisentraut.blogspot.de/2011/01/git-commit-mode.html
[4] http://en.opensuse.org/openSUSE:Mailing_list_netiquette


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] tests/testdisplay.c: Remove an uncomfortable error output.

2012-08-01 Thread Paul Menzel

Am Mittwoch, den 01.08.2012, 14:56 +0800 schrieb Yi Sun:
 Update the image file paas.png with higher correction level.

s,paas.png,pass.png,

Additionally the summary and the commit message seem to be orthogonal,
if I am not mistaken. Should these be two patches?

 Signed-off-by: Yi Sun yi@intel.com
 
 diff --git a/tests/pass.png b/tests/pass.png
 index 
 5928d5ca109b7db33640851ceb352f9da742ff7b..36a5236be785ef4b2c1da634560c42d508d211bb
  100644
 GIT binary patch
 literal 569
 zcmV-90=G`P)h;3K|Lk000e1NJLTq00Gee00Gef09k{+W9a7bBm0017s
 z0017s0dCNBJ^%m#q$gGRCt{2+_8~^Fc5{|^;~eFOKSJ4N7wE`iX2=X8G7YT;5
 zZ-j94zf49S*^a~_ETKJu#bU8oEEbE!?zRu9@|A~|aFZc~pEyjp*E7yoEVj3`p-xtt
 zFQ4q^yIg(71B=BTVYNb6HsecW=F4XEEapT)#0G^t3xan`%xRJ~jr6#eT|K^x)e
 zv#vT!IsbnTjKyM`Y!zQaQ^78l)HzrzwzFNO|=vJOKt^=#rCthXy$^Is)1A8%J#7v
 z^^3(~_gY;;^VQSbM74g-GheJpT_cNiN#{OT21vrf68E3KTF!JuvqLNwyID)W0O;w
 zsN-tWi^XDlSzklrSfm_m8$z|M3Uo@VzJnEn-MWm@BjtYxJGZe?4G#bP^K@7M${
 z*vZbhSvgOq++qyLu~1(%4r_veva6!Z0Ow{EEe0R!@uddku^3a#N~Pa9Aw1qg}=O
 zIYSzhMRUYru?N{wp|Uv99p=gN;8BFcyp5Zx@rjy%WlJPbt+3i^XEQ+j}lvE7=H
 z#zy?AY}GFoi|uMXqZc|{Z~H+i^X=eTEEw2dgR=@4p?!VzEuuvgp|O|3NL@Exz6Z
 zW3kvKTcv!1KbE7X;`N*IsuzUCVjFB*uvjbi^XEG*gf_a_Lf0-E8BSr0NkvXX
 Hu0mjfwks0m
 
 literal 376
 zcmV-;0f+vHP)h;3K|Lk000e1NJLTq007q007r0dK`lq9a7bBm000XT
 z000XT0n*)m`~Uy}DoI2^R9J=Wm(dNwAPht;F#sd6IwLUvl53w0P1CgB_W?SQ){l=E
 z9mWy;GvvSnd7=1dMSE)a|H2CWIhyfM87+gHaEJ$d4q*v9e2X8NH73LkVH2~nh8{db
 z1oH@vt%vi;17nnJKqlmd8Y?m?=SV};d!JC-@c%hEGI?~i|G%bw#%`yn#2zFYS
 z+0-7gg|{O}1!wgq~?C}LtVEqB(o|lRCr`J5x)I`I3=`z)d}Rt{K;Mk`1O)KFXWY
 z!nic_THZ#ZgI00c~fPDf?c;Hvckz~B`9IOHyYm1SA#|bqn!+nJepLch5kgVzT3%I
 zOA6OV+pcX-Uvy+}b(EP0H?%ow8?F4v@mQk8pPG2rCR_!R9VEK^wFvD^r0@l
 W))U}2HxaMNUMnLSTY*+nlZd
 
 diff --git a/tests/testdisplay.c b/tests/testdisplay.c
 index 2d1fdb0..0329a99 100644
 --- a/tests/testdisplay.c
 +++ b/tests/testdisplay.c
 @@ -360,9 +360,6 @@ static void paint_image(cairo_t *cr, const char *file)
  
   cairo_translate(cr, img_x, img_y);
  
 - fprintf(stderr, drew %dx%d image at %d,%d\n, img_w, img_h,
 - img_x, img_y);
 -
   img_w_scale = (double)img_w / (double)img_w_o;
   img_h_scale = (double)img_h / (double)img_h_o;
   cairo_scale(cr, img_w_scale, img_h_scale);


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] NEWS: Correct release version: s/2.12.0/2.20.0/

2012-07-26 Thread Paul Menzel

Date: Thu, 26 Jul 2012 12:51:57 +0200

Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
---
 NEWS |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index a6819d4..08340f8 100644
--- a/NEWS
+++ b/NEWS
@@ -38,7 +38,7 @@ Among the other tweaks this week:
 * Shadow support was dropped from UXA as it was neither complete nor
   correct, use SNA instead.
 
-Release 2.12.0 (2012-07-15)
+Release 2.20.0 (2012-07-15)
 ===
 First the big news, a new acceleration method that aims to be faster and
 consume far less CPU than UXA is now available for selection at runtime.
-- 
1.7.10.4


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] HD 4000: Passthrough for HD audio formats

2012-07-22 Thread Paul Menzel

Dear Frederik,


Am Freitag, den 20.07.2012, 21:03 +0200 schrieb Frederik Vogelsang:

 I am using a Core i5-3475S on a ASUS P8H77-I. The system is connected
 to my amp through HDMI. For some reason I cannot get passthrough of
 DTS-HD MA or Dolby TrueHD to work properly. On my HTPC with an ION2
 chipset I can use
 
 aplay -D hdmi:CARD=NVidia,DEV=2,AES0=6 -c8 -fs16_le -r192000 dtshd_test.spdif
 
 and the receiver recognizes and plays the DTS-HD MA stream. On my
 Intel system I am trying the exact same thing (different card name,
 obviously) and the receiver only plays noise (shows 7.1 PCM instead of
 DTS-HD).
 
 Am I doing anything wrong? Are there any configuration options I am
 missing or kernel module parameters? I am using the latest stable
 xf86-video-intel driver and Linux kernel.

I guess the developers might look at your problem on Monday, but please
note the specific versions. ALSA version might also be interesting. Do
you use PulseAudio? Have you tried some live systems? And lastly is this
a regression?

Anyway, please also provide some log files as documented in [1].


Thanks and good luck,

Paul


[1] http://intellinuxgraphics.org/how_to_report_bug.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix eDP blank screen after S3 resume on HP desktops

2012-06-22 Thread Paul Menzel

Am Donnerstag, den 21.06.2012, 15:30 +0200 schrieb Takashi Iwai:
 This patch fixes the problem on some HP desktop machines with eDP
 which give blank screens after S3 resume.
 
 It turned out that BLC_PWM_CPU_CTL must be written after
 BLC_PWM_CPU_CTL2.  Otherwise it doesn't take effect on these
 SNB machines.
 
 Tested with 3.5-rc3 kernel.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233

Hmm, the bug entry does not contain a link to the discussion on
intel-gfx.

http://lists.freedesktop.org/archives/intel-gfx/2012-June/018418.html

Maybe add it there or to the commit message.

 Cc: sta...@vger.kernel.org
 Signed-off-by: Takashi Iwai ti...@suse.de
 ---
  drivers/gpu/drm/i915/i915_suspend.c |5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
 b/drivers/gpu/drm/i915/i915_suspend.c
 index 0ede02a..a748e5c 100644
 --- a/drivers/gpu/drm/i915/i915_suspend.c
 +++ b/drivers/gpu/drm/i915/i915_suspend.c
 @@ -740,8 +740,11 @@ static void i915_restore_display(struct drm_device *dev)
   if (HAS_PCH_SPLIT(dev)) {
   I915_WRITE(BLC_PWM_PCH_CTL1, dev_priv-saveBLC_PWM_CTL);
   I915_WRITE(BLC_PWM_PCH_CTL2, dev_priv-saveBLC_PWM_CTL2);
 - I915_WRITE(BLC_PWM_CPU_CTL, dev_priv-saveBLC_CPU_PWM_CTL);
 + /* NOTE: BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2;
 +  * otherwise we get blank eDP screen after S3 on some machines

Full stop at the end? Also add a reference to the list discussion or
Bugzilla entry?

 +  */
   I915_WRITE(BLC_PWM_CPU_CTL2, dev_priv-saveBLC_CPU_PWM_CTL2);
 + I915_WRITE(BLC_PWM_CPU_CTL, dev_priv-saveBLC_CPU_PWM_CTL);
   I915_WRITE(PCH_PP_ON_DELAYS, dev_priv-savePP_ON_DELAYS);
   I915_WRITE(PCH_PP_OFF_DELAYS, dev_priv-savePP_OFF_DELAYS);
   I915_WRITE(PCH_PP_DIVISOR, dev_priv-savePP_DIVISOR);

With or without these changes above, this patch is

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Support for the ns2501 dvo

2012-06-17 Thread Paul Menzel

Dear Thomas,


thank you for your patch and patience.


Am Sonntag, den 17.06.2012, 00:22 +0200 schrieb Thomas Richter:

 unfortunately the patch I submitted last week for supporting the ns2501 
 has never been picked up, so I'm trying again.
 
 This version here improves the patch considerably, not only are 
 800x600,1024x768 and 640x480 now supported, it also includes support for 
 DPMS. The previous version just disabled the DVO, leaving some random 
 pattern on the screen. This one also turns the backlight off.

Since this patch is not only a resend but also an improvement please
mark it with »[PATCH vX]« where X is the iteration next time.

Also your patch is not created with the Git tool and therefore (not
necessarily) misses some required things as the Signed-off-by line and a
proper commit message (summary and body).

Using these tools also makes the life for the other developers easier
although it might take you some time in the beginning.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Support for the ns2501 dvo

2012-06-17 Thread Paul Menzel

Am Sonntag, den 17.06.2012, 20:36 +0200 schrieb Daniel Vetter:
 On Sun, Jun 17, 2012 at 08:07:15PM +0200, Thomas Richter wrote:
  On 17.06.2012 14:28, Paul Menzel wrote:

  thank you for your patch and patience.
  
  Since this patch is not only a resend but also an improvement please
  mark it with »[PATCH vX]« where X is the iteration next time.
  
  Also your patch is not created with the Git tool and therefore (not
  necessarily) misses some required things as the Signed-off-by line and a
  proper commit message (summary and body).
  
  Actually, it was created by git diff HEAD. (-; Anyhow, how do I
  need to submit it so it gets accepted (or to make this at least
  easier?)

*Before* creating the patch you have to commit your changes.

git commit -a -s

`-s` adds your Signed-off-by line automatically. You can configure your
data with the following commands.

git config --global user.name Thomas Richter
git config --global user.email t...@math.tu-berlin.de

For the commit message give a summary with less than 72 characters, add
a blank line and give an elaborate explanation.

 git format-patch -1 HEAD

For patch iterations do the following.

git format-patch --subject-prefix=PATCH v2 -1 HEAD

The manual pages are pretty elaborate (`git help format-patch`).

`git send-email` can also send the patch for you.

  Using these tools also makes the life for the other developers easier
  although it might take you some time in the beginning.
  
  All understood - please provide some advice.
 
 Imo you don't need anything else, the only other thing missing is the
 signed-off-by line, see Documentation/SubmittingPatches.

As written above `-s` adds that automatically.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] Support for ns2501 DVO.

2012-06-17 Thread Paul Menzel

Dear Thomas,


you put Daniel address twice into the CC field.


Am Sonntag, den 17.06.2012, 20:59 +0200 schrieb Thomas Richter:
 Includes now proper DPMS support.
   Includes switching between resolutions - from 640x480 to 1024x768.
   Currently assumes that the native display resolution is 1024x768.

Please put that after the next paragraph.

 The ns2501 seems to be rather critical - if the output PLL is not
 running, the chip doesn't seem to be clocked and then doesn't react
 on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO
 is active before submitting any i2c messages to it. This is
 probably to be reviewed.

Such for the commit message unnecessary information goes below the first
`---` below.

 Signed-Off-by: Thomas Richter t...@math.tu-berlin.de
 ---

Here goes email message information.

   drivers/gpu/drm/i915/Makefile|1 +
   drivers/gpu/drm/i915/dvo.h   |1 +
   drivers/gpu/drm/i915/dvo_ns2501.c|  566 
 ++

Unfortunately you have to resend as v4 since your mailer line wrapped
this line and others.

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] Support for ns2501 DVO.

2012-06-17 Thread Paul Menzel

Am Sonntag, den 17.06.2012, 21:42 +0200 schrieb Daniel Vetter:
 On Sun, Jun 17, 2012 at 09:18:56PM +0200, Paul Menzel wrote:

  you put Daniel address twice into the CC field.
  
  
  Am Sonntag, den 17.06.2012, 20:59 +0200 schrieb Thomas Richter:
   Includes now proper DPMS support.
 Includes switching between resolutions - from 640x480 to 1024x768.
 Currently assumes that the native display resolution is 1024x768.
  
  Please put that after the next paragraph.
  
   The ns2501 seems to be rather critical - if the output PLL is not
   running, the chip doesn't seem to be clocked and then doesn't react
   on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO
   is active before submitting any i2c messages to it. This is
   probably to be reviewed.
  
  Such for the commit message unnecessary information goes below the first
  `---` below.
 
 Fully disagree, this explains why the patch exports a function from
 intel_display.c and hence _must_ be part of the commit message.

Of course I meant »This is probably to be reviewed.«.

 While you resend, can you also please add bug links to the s-o-b section
 of your patch?
 
   Signed-Off-by: Thomas Richter t...@math.tu-berlin.de
   ---
  
  Here goes email message information.
  
 drivers/gpu/drm/i915/Makefile|1 +
 drivers/gpu/drm/i915/dvo.h   |1 +
 drivers/gpu/drm/i915/dvo_ns2501.c|  566 
   ++
  
  Unfortunately you have to resend as v4 since your mailer line wrapped
  this line and others.
 
 Yeah, patch is corrupted, I guess the easiest thing is to simply append
 the file generated with format-patch - I can also slurp that one in.

But inline patches are preferred though.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Debian 6 (Squeeze) support for Sandy Bridge

2012-06-12 Thread Paul Menzel

Dear Anthony,


please send just plain text messages to lists and no HTML messages [1].


Am Dienstag, den 12.06.2012, 03:48 + schrieb See, Anthony Chaur Yih:

 From the 2010Q4 released package which is the earliest package that
 support Sandy Bridge platform, the OS requirement look is much more
 newer than Debian 6. Is there any way to enable Sandy Bridge with 3D
 acceleration on Debin 6?

This is Debian Squeeze right?

 Intel 2010Q4 graphics package components
 2D driver: xf86-video-intel 2.14.0 
 releasehttp://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.14.0.tar.bz2
 3D driver: mesa 7.10http://mesa3d.org/relnotes-7.10.html
 Libdrm: libdrm-2.4.23 
 releasehttp://dri.freedesktop.org/libdrm/libdrm-2.4.23.tar.bz2
 Kernel: 2.6.37 
 releasehttp://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.tar.bz2
 Cairo: cairo-1.10.2 releasehttp://cairographics.org/news/cairo-1.10.2/
 Libva: libva-1.0.7 
 releasehttp://cgit.freedesktop.org/libva/snapshot/libva-1.0.7.tar.bz2
 Xorg: X server 1.9.3
 
 This is what debian 6 support
 ※xf86-video-intel 版本為 2.13 
 http://packages.debian.org/squeeze/xserver-xorg-video-intel
 ※Mesa 的版本為 7.7.1 http://packages.debian.org/squeeze/libgl1-mesa-glx 
 http://packages.debian.org/squeeze/libgl1-mesa-dri
 ※libdrm 的版本為 2.4.21 http://packages.debian.org/squeeze/libdrm-intel1
 ※Linux Kernel 的版本為 2.6.32 http://packages.debian.org/squeeze/linux-source-2.6
 ※Cairo 的版本為 1.8.10 http://packages.debian.org/squeeze/libcairo2
 ※VAAPI 的版本為 1.0.1 http://packages.debian.org/squeeze/libva1 
 http://packages.debian.org/squeeze/libva-x11-1
 ※X.org X server 版本為 1.7.7 http://packages.debian.org/squeeze/xserver-xorg-core

I guess the only way is to try the backports repository [2]. For example
`xserver-xorg-video-intel` version 2.15.0-3 is available there [3].

Otherwise your only option is Debian Wheezy which is due to be released
this year as far as I know.


Thanks,

Paul


[1] http://en.opensuse.org/openSUSE:Mailing_list_netiquette
[2] http://backports-master.debian.org/
[3] 
http://packages.debian.org/search?keywords=xserver-xorg-video-intelsearchon=namessection=allsuite=squeeze-backports


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [libva] GPU hung

2012-06-12 Thread Paul Menzel

Am Mittwoch, den 13.06.2012, 00:09 +0200 schrieb Angela:
  For gpu hangs the important thing is the i915_error_state file from 
  sysfs
  (the files you've attached are mainly interesting for modeset issues). 
  I guess the best thing would be to file a bug on bugs.freedesktop.org 
  with that.
  
  # cat /sys/kernel/debug/dri/0/i915_error_state
  no error state collected
  # cat /sys/kernel/debug/dri/64/i915_error_state
  no error state collected
  
  mount:
  sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
 I guess you need to rehang your machine, the error_state doesn't survive a
 reboot.
 
 Hung the system and checked i915_error_state before reboot.
 
 Any other hints ?

I think you have to mount the debug filesystem [1].


Thanks,

Paul


PS: Maybe that and the i915_error_state stuff could be added to the
Intel Web site too [2].

PPS: Angela, you can also join the IRC channel #intel-gfx for live
debugging.

PPPS: Angela, can you use a different mail program which can quote
correctly. Outlook should be able to do it, but I do not know how to
configure it. Thunderbird works under Microsoft Windows.


[1] https://en.wikipedia.org/wiki/Debugfs
[2] http://intellinuxgraphics.org/how_to_report_bug.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] test: Measure performance of copying between tiled and untiled/LLC

2012-06-06 Thread Paul Menzel

Am Mittwoch, den 06.06.2012, 11:04 +0100 schrieb Chris Wilson:
 The goal is compare the speed of copying to and from a LLC bo using
 either the CPU or GPU.

I would prefer an example output of this test in the commit message.

 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  lib/drmtest.c|   14 +++
  lib/drmtest.h|1 +
  tests/.gitignore |1 +
  tests/Makefile.am|1 +
  tests/llc_exec_blt.c |  278 
 ++
  5 files changed, 295 insertions(+)
  create mode 100644 tests/llc_exec_blt.c

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: don't chnage the original mode in dp_mode_fixup

2012-05-30 Thread Paul Menzel

Am Mittwoch, den 30.05.2012, 13:52 +0200 schrieb Daniel Vetter:

Typo in »change« in the commit message.

 We should only frob adjusted_mode. This is in preparation of
 a massive patch by Laurent Pinchart to make the mode argument
 const.
 
 After the prevous prep patch to use adjusted_mode-clock instead of

previous

 mode-clock the only thing left is to clean up things a bit. I've
 opted to pass in an adjust_mode param to dp_adjust_dithering because
 that way we can be sure to avoid duplicating this logic - which was
 the cause behind a dp link bw calculation bug in the past.
 
 Also mark the mode argument of pch_panel_fitting const.
 
 v2: Split up the mode-clock = adjusted_mode-clock change,
 as suggested by Chris Wilson.
 
 Reported-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/intel_dp.c|   12 ++--
  drivers/gpu/drm/i915/intel_drv.h   |2 +-
  drivers/gpu/drm/i915/intel_panel.c |2 +-
  3 files changed, 8 insertions(+), 8 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/6] tools/dpf: Tool to read and write l3 remap registers.

2012-05-28 Thread Paul Menzel

Dear Ben,


Am Freitag, den 25.05.2012, 16:56 -0700 schrieb Ben Widawsky:

an output of a working run of `dpf_test` with some explanation pasted
into the commit message would be nice as there is no manual page.

 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  tests/dpf_test  |8 +++
  tools/Makefile.am   |3 +-
  tools/intel_l3_parity.c |  159 
 +++
  3 files changed, 169 insertions(+), 1 deletion(-)
  create mode 100755 tests/dpf_test
  create mode 100644 tools/intel_l3_parity.c

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Updated -next

2012-04-11 Thread Paul Menzel

Dear Yi¹,


Am Mittwoch, den 11.04.2012, 03:20 + schrieb Sun, Yi:

 We finished a new round of kernel testing. The version of kernel is:
 Kernel: (drm-intel-testing)9d0b5b5468650e0ac72a7786cf6625963f926d4d
 Merge: ec34a01 b4db1e3
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Mon Apr 9 18:12:03 2012 +0200
 
 We covered the platform IvyBridge, SandyBridge, IronLake, G45 and
 Pineview. We haven't any available HasWell machine, so didn't do
 testing on that.

the platform seems to be spelled Haswell [1].

 General, in this circle, 11 bugs are fixed, 4 bugs are still open, and
 2 new bugs about suspending are filed. The detail of bugs are as
 following:
 
 Fixed bugs
 Bug 38138 - [SNB] mplayer -vo fbdev videofile will cause system hang on 
 HuronRiver (https://bugs.freedesktop.org/show_bug.cgi?id=38138)
 Bug 40031 - [Regression] testdisplay can't display correctly with 30 bpp 
 (https://bugs.freedesktop.org/show_bug.cgi?id=40031)
 Bug 42180 - System hang while running gem_linear_blits of Intel-gpu-tools 
 (https://bugs.freedesktop.org/show_bug.cgi?id=42180)
 Bug 47990 - [PNV]I-G-T/gem_tiled_after_untiled_blt fail 
 (https://bugs.freedesktop.org/show_bug.cgi?id=47990)
 Bug 48026 - [Regression]I-G-T/gem_linear_blits fail 
 (https://bugs.freedesktop.org/show_bug.cgi?id=48026)
 Bug 47085 - [ILK]I-G-T/gem_pipe_control_store_loop fail unstablely 
 (https://bugs.freedesktop.org/show_bug.cgi?id=47085)
 Bug 48028 - [Regression ILK]I-G-T/gem_tiled_blits fail 
 (https://bugs.freedesktop.org/show_bug.cgi?id=48028)
 Bug 48030 - [Regression ILK]I-G-T /gem_tiled_fence_blits fail 
 (https://bugs.freedesktop.org/show_bug.cgi?id=48030)
 Bug 42943 - [IVB] Boot with a vga monitor can't light the DP screen while 
 plugin it (https://bugs.freedesktop.org/show_bug.cgi?id=42943)
 Bug 44305 - [IVB]The Edp can't work while booting with a monitor 
 (https://bugs.freedesktop.org/show_bug.cgi?id=44305)
 
 Open bugs:
 Bug 41976 - [IVB] screen turn to be black while switching between console and 
 x-window with 3-pipe active 
 (https://bugs.freedesktop.org/show_bug.cgi?id=41976)
 Bug 47990 - [PNV]I-G-T/gem_tiled_after_untiled_blt fail 
 (https://bugs.freedesktop.org/show_bug.cgi?id=47990)
 Bug 45867 - [IVB 3pipe] 3 Pipe Doesn't Work with Eaglemont Card 
 (https://bugs.freedesktop.org/show_bug.cgi?id=45867)
 Bug 45870 - [IVB PCH eDP] PCH eDP doesn't work 
 (https://bugs.freedesktop.org/show_bug.cgi?id=45870)

so what are the newly submitted/opened problem reports?


Thanks,

Paul


PS: Could you please adapt the subject line next time like

[QA] Testing report for `drm-intel-testing` (was: Updated -next)

for better overview in the inbox and the archive.


¹ I hope Yi is your first name. I am always confused about that. If it
is, no comma goes after it.


[1] https://en.wikipedia.org/wiki/Haswell_(microarchitecture)


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Updated -next

2012-04-11 Thread Paul Menzel

Am Mittwoch, den 11.04.2012, 08:24 + schrieb Sun, Yi:

[…]

 Thank all your comments.

Thank you for your prompt reply and your work on the Intel-gfx driver.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: implement async flush w/a

2012-04-10 Thread Paul Menzel

Am Samstag, den 31.03.2012, 11:52 +0100 schrieb Chris Wilson:
 On Sat, 31 Mar 2012 11:22:02 +0200, Daniel Vetter daniel.vet...@ffwll.ch 
 wrote:
  Note that async flush also means things like VT-d IOTLB invalidation.
  
  See Bspec vol1c.4 Render Engine Command Streamer, Section ECOSKPD -
  Eco Scratch Pad.
  
  It doesn't seem to help in for any of our VT-d related bugs thoug.

While we are at it: thoug*h*.

  Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
  ---
   drivers/gpu/drm/i915/i915_reg.h  |1 +
   drivers/gpu/drm/i915/intel_display.c |3 +++
   2 files changed, 4 insertions(+), 0 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: implement ColorBlt w/a

2012-04-10 Thread Paul Menzel

Am Samstag, den 31.03.2012, 11:21 +0200 schrieb Daniel Vetter:
 According to an internal workaround master list, we need to set bit 5
 of register 9400 to avoid issues with color blits.
 
 Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
  drivers/gpu/drm/i915/i915_reg.h  |3 +++
  drivers/gpu/drm/i915/intel_display.c |4 
  2 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 3886cf0..233dbd5 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -3727,6 +3727,9 @@
  #define  GT_FIFO_FREE_ENTRIES0x120008
  #defineGT_FIFO_NUM_RESERVED_ENTRIES  20
  
 +#define GEN6_UCGCTL1 0x9400
 +# define GEN6_BLBUNIT_CLOCK_GATE_DISABLE (1  5)
 +
  #define GEN6_UCGCTL2 0x9404
  # define GEN6_RCZUNIT_CLOCK_GATE_DISABLE (1  13)
  # define GEN6_RCPBUNIT_CLOCK_GATE_DISABLE(1  12)
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index d514719..aa0c6df 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -8510,6 +8510,10 @@ static void gen6_init_clock_gating(struct drm_device 
 *dev)
   I915_WRITE(WM2_LP_ILK, 0);
   I915_WRITE(WM1_LP_ILK, 0);
  
 + I915_WRITE(GEN6_UCGCTL1,
 +I915_READ(GEN6_UCGCTL1) |
 +GEN6_BLBUNIT_CLOCK_GATE_DISABLE);
 +

Should a comment be added to the header file or here that this is from
an internal workaround list? (Same for patch 7/7 I think.)

   /* According to the BSpec vol1g, bit 12 (RCPBUNIT) clock
* gating disable must be set.  Failure to set it results in
* flickering pixels due to Z write ordering failures after


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Handle request to map a very large buffer object

2012-02-28 Thread Paul Menzel

Dear Anuj,


thank you for your patch with the great explanation in the commit
message. I found one typo in the code comment and while at it point out
some grammar issue in the commit message.


Am Montag, den 27.02.2012, 12:28 -0800 schrieb Anuj Phogat:
 This patch sets an upper limit on the size of buffer object which can be
 mapped safely. Following bugs reported segmentation fault / assertion

reported *a* segmentation fault / *an* assertion …

 failure with large textures:
 
 https://bugs.freedesktop.org/show_bug.cgi?id=44970
 https://bugs.freedesktop.org/show_bug.cgi?id=46303
 
 This patch along with another patch which I posted on mesa-dev
 (intel: Fix a case when mapping large texture fails) [1] resolve

You could add the URL.

 above mentioned bugs. Recently posted piglit test case (large-textures)

*The* recently …

 also passes with these patches.

[1] http://lists.freedesktop.org/archives/mesa-dev/2012-February/019488.html

 Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
 ---
 This fix doesn't limit developers to create very large texture but it
 restricts them to map it. I am not very confident about this patch and
 setting 128 MB as the upper limit on size of buffer object. So, please
 provide your views.
 
 Chris Wilson's views on this issue:
 http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg08585.html
 
  intel/intel_bufmgr_gem.c |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)
 
 diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
 index 0f33b71..8b05de9 100644
 --- a/intel/intel_bufmgr_gem.c
 +++ b/intel/intel_bufmgr_gem.c
 @@ -1191,6 +1191,17 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
  
   pthread_mutex_lock(bufmgr_gem-lock);
  
 + /* Set am upper limit on the size of buffer which can be mapped
 +safely

s/am/an/
Maybe add full stop ».« at the end of the sentence.

 +  */
 + if (bo-size  128 * 1024 * 1024) {

It seems strange for me that the upper buffer size is always the same
and not dependent on the chipset(?). But I guess you have checked that.

 + DBG(%s:%d: Reached buffer map limit.\n,
 + __FILE__, __LINE__);
 + bo-virtual = NULL;
 + pthread_mutex_unlock(bufmgr_gem-lock);
 + return -1;
 + }
 +
   if (bo_gem-map_count++ == 0)
   drm_intel_gem_bo_open_vma(bufmgr_gem, bo_gem);

Reviewed-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] intel_reg_read: add support for getopt

2012-02-28 Thread Paul Menzel

Dear Eugeni,


Am Dienstag, den 28.02.2012, 17:55 -0300 schrieb Eugeni Dodonov:
 This will allow us to pass more options to it in the future.
 
 Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
 ---
  tools/intel_reg_read.c |   44 +++-
  1 file changed, 35 insertions(+), 9 deletions(-)
 
 diff --git a/tools/intel_reg_read.c b/tools/intel_reg_read.c
 index cad30ff..c3e559b 100644
 --- a/tools/intel_reg_read.c
 +++ b/tools/intel_reg_read.c
 @@ -41,21 +41,45 @@ static void dump_range(uint32_t start, uint32_t end)
  *(volatile uint32_t *)((volatile char*)mmio + i));
  }
  
 +static void usage(char *cmdname)
 +{
 + printf(Usage: %s [-f | addr]\n, cmdname);
 + printf(\t -f : read back full range of registers.\n);
 + printf(\t  WARNING! This could be danger to hang the machine!\n);

I know you just copied this sentence, but could a native English speaker
proof read it? It sounds strange to me.

 + printf(\t addr : in 0x format\n);
 +}
 +
  int main(int argc, char** argv)
  {
 + int ret=0;

Coding style seems to differ, does not it? There are some occurrences
where `=` does have spaces around. Care to send a patch cleaning that up
beforehand?

   uint32_t reg;
 + int ch;
 + char *cmdname = strdup(argv[0]);
 + int full_dump=0;
 +
 + while ((ch = getopt(argc, argv, fh)) != -1) {

I did not check further. But I guess no headers need to be included for
`getopt`.

 + switch(ch) {
 + case 'f':
 + full_dump=1;
 +   break;

Indentation seems to differ in the line `full_dump = 1`.

 + case 'h':
 +   usage(cmdname);
 +   ret=1;
 +   goto out;
 + }
 + }
 + argc -= optind;
 + argv += optind;
  
 - if (argc != 2) {
 - printf(Usage: %s [-f | addr]\n, argv[0]);
 - printf(\t -f : read back full range of registers.\n);
 - printf(\t  WARNING! This could be danger to hang the 
 machine!\n);
 - printf(\t addr : in 0x format\n);
 - exit(1);
 + if (argc != 1) {
 + usage(cmdname);
 + ret=1;
 + goto out;
   }
  
   intel_register_access_init(intel_get_pci_device(), 0);
  
 - if (!strcmp(argv[1], -f)) {
 + if (full_dump) {
   dump_range(0x0, 0x00fff);   /* VGA registers */
   dump_range(0x02000, 0x02fff);   /* instruction, memory, 
 interrupt control registers */
   dump_range(0x03000, 0x031ff);   /* FENCE and PPGTT control 
 registers */
 @@ -71,12 +95,14 @@ int main(int argc, char** argv)
   dump_range(0x7, 0x72fff);   /* display and cursor registers 
 */
   dump_range(0x73000, 0x73fff);   /* performance counters */
   } else {
 - sscanf(argv[1], 0x%x, reg);
 + sscanf(argv[0], 0x%x, reg);
   dump_range(reg, reg + 4);
   }
  
   intel_register_access_fini();
  
 - return 0;
 +out:
 + free(cmdname);
 + return ret;
  }

Otherwise you can add

Reviewed-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel: Add support for (possibly) unsynchronized maps.

2012-02-25 Thread Paul Menzel

Dear Eric,


Am Freitag, den 24.02.2012, 19:53 -0800 schrieb Eric Anholt:

[…]

 +/**
 + * Performs a mapping of the buffer object like the normal GTT
 + * mapping, but avoiding waiting for the GPU to be done reading from

s/avoiding/avoids/?

 + * or rendering to the buffer.
 + *
 + * This is used in the implementation of GL_ARB_map_buffer_range: The
 + * user asks to create a buffer, then does a mapping, fills some
 + * space, runs a drawing command, then asks to map it again without
 + * synchronizing because it guarantees that it won't write over the
 + * data that the GPU is busy using (or, more specifically, that if it
 + * does write over the data, it acknowledges that rendering is
 + * undefined).
 + */
 +
 +int drm_intel_gem_bo_map_unsynchronized(drm_intel_bo *bo)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: error_buffer-ring should be signed

2012-02-16 Thread Paul Menzel

Am Donnerstag, den 16.02.2012, 11:03 +0100 schrieb Daniel Vetter:
 gcc seems to get uber-anal recently about these things.

which was introduced by the following commit.

96154f2faba5: drm/i915: switch ring-id to be a real id

 Reported-by: Dan Carpenter dan.carpen...@oracle.com

The URL of the report is the following.

http://lists.freedesktop.org/archives/dri-devel/2012-February/019183.html

 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Acked-by: Paul Menzel paulepan...@users.sourceforge.net

 ---
  drivers/gpu/drm/i915/i915_drv.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index b839728..35833fc 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -199,7 +199,7 @@ struct drm_i915_error_state {
   u32 tiling:2;
   u32 dirty:1;
   u32 purgeable:1;
 - u32 ring:4;
 + s32 ring:4;
   u32 cache_level:2;
   } *active_bo, *pinned_bo;
   u32 active_bo_count, pinned_bo_count;


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: paper over missed irq issues with force wake voodoo

2012-01-24 Thread Paul Menzel

Dear Daniel,


Am Freitag, den 14.12.2012, 16:01 +0100 schrieb Daniel Vetter:

the (author) date is wrong (December instead of January) unless you sent
it from the future. If you did, please tell us how the Intel driver will
work in eleven months. ;-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] MSI intel video card not detected

2011-11-27 Thread Paul Menzel

Dear Pablo,


Am Sonntag, den 27.11.2011, 16:02 -0300 schrieb Pablo Yaggi:
 Hi, i installed the latest driver from git repo on an msi ae2060 but
 no adapter is detected. lspci reports an intel vga adapter installed
 and xorg automatically loads the i915 module but then it reports no
 driver is found.
 syslog reports the module beign loaded and no fouther info. Im using
 kernel 3.2.1, any ideas ? can i gather any usefull information for you
 ?

you could take a look at the page »How to file a good bug report« [1].


Thanks,

Paul


[1] http://intellinuxgraphics.org/how_to_report_bug.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2 v2] hda - delayed ELD repoll

2011-11-16 Thread Paul Menzel

Dear Fengguang,


Am Mittwoch, den 16.11.2011, 00:57 +0800 schrieb Wu Fengguang:
 The Intel HDMI chips (ironlake at least) are found to have ~250ms delay
 between the ELD_Valid=1 hotplug event is send and the ELD buffer becomes
 actually readable. During the time the ELD buffer is mysteriously all 0.
 
 Fix it by scheduling a delayed work to re-read ELD buffer after 300ms.
 
 Signed-off-by: Wu Fengguang fengguang...@intel.com

other then my comment at the end, please note that it is very confusing
for European (and other folks) what your first name is.

If it is Fengguang then you should use

Fengguang Wu or Wu, Fengguang

where I prefer the first one.

 ---
  sound/pci/hda/hda_local.h  |2 +
  sound/pci/hda/patch_hdmi.c |   49 ++-
  2 files changed, 44 insertions(+), 7 deletions(-)
 
 --- linux.orig/sound/pci/hda/hda_local.h  2011-11-15 21:29:53.0 
 +0800
 +++ linux/sound/pci/hda/hda_local.h   2011-11-15 21:29:54.0 +0800
 @@ -655,6 +655,8 @@ struct hdmi_eld {
  #ifdef CONFIG_PROC_FS
   struct snd_info_entry *proc_entry;
  #endif
 + struct hda_codec *codec;
 + struct delayed_work work;
  };
  
  int snd_hdmi_get_eld_size(struct hda_codec *codec, hda_nid_t nid);
 --- linux.orig/sound/pci/hda/patch_hdmi.c 2011-11-15 21:29:53.0 
 +0800
 +++ linux/sound/pci/hda/patch_hdmi.c  2011-11-16 00:50:50.0 +0800
 @@ -746,7 +746,7 @@ static void hdmi_setup_audio_infoframe(s
   */
  
  static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
 -struct hdmi_eld *eld);
 +struct hdmi_eld *eld, bool retry);
  
  static void hdmi_intrinsic_event(struct hda_codec *codec, unsigned int res)
  {
 @@ -766,7 +766,7 @@ static void hdmi_intrinsic_event(struct 
   return;
   eld = spec-pins[pin_idx].sink_eld;
  
 - hdmi_present_sense(codec, pin_nid, eld);
 + hdmi_present_sense(codec, pin_nid, eld, true);
  
   /*
* HDMI sink's ELD info cannot always be retrieved for now, e.g.
 @@ -969,7 +969,7 @@ static int hdmi_read_pin_conn(struct hda
  }
  
  static void hdmi_present_sense(struct hda_codec *codec, hda_nid_t pin_nid,
 -struct hdmi_eld *eld)
 +struct hdmi_eld *eld, bool retry)
  {
   /*
* Always execute a GetPinSense verb here, even when called from
 @@ -992,13 +992,31 @@ static void hdmi_present_sense(struct hd
   HDMI status: Codec=%d Pin=%d Presence_Detect=%d 
 ELD_Valid=%d\n,
   codec-addr, pin_nid, eld-monitor_present, eld_valid);
  
 - if (eld_valid)
 + if (eld_valid) {
   if (!snd_hdmi_get_eld(eld, codec, pin_nid))
   snd_hdmi_show_eld(eld);
 + else if (retry) {
 + queue_delayed_work(codec-bus-workq,
 +eld-work,
 +msecs_to_jiffies(300));
 + }

Would adding a comment referring to the discussion thread be beneficial
for code readers asking why a delay is needed?

 + }
  
   snd_hda_input_jack_report(codec, pin_nid);
  }

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/18] intel-gpu-tools: intel_audio_dump updates

2011-11-11 Thread Paul Menzel

Am Samstag, den 12.11.2011, 11:12 +0800 schrieb Wu Fengguang:
 A bunch of cleanups, fixes and new fields to intel_audio_dump, tested OK on
 G45, Ironlake and IvyBridge.

Christopher White mentioned some lacks in the documentation like missing
dependencies. Could you update that too, please?


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] intel-gpu-tools: Please release new version (was: [PATCH 00/18] intel-gpu-tools: intel_audio_dump updates)

2011-11-11 Thread Paul Menzel

Am Samstag, den 12.11.2011, 11:12 +0800 schrieb Wu Fengguang:
 A bunch of cleanups, fixes and new fields to intel_audio_dump, tested OK on
 G45, Ironlake and IvyBridge.

Christopher White mentioned the last release or tag happened a long time
ago.

Is a new release planned? Most of the time distributions package those
more easily.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-11-02 Thread Paul Menzel

Dear Sander,


Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen:
 On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang fengguang...@intel.com wrote:

  The log does confirm that the drm_edid_to_eld function is running, and
  that we're not far from a solution:
  [   21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607
  [   21.061421] [drm:drm_edid_to_eld], ELD size 13, SAD count 8
 
  It looks all sane to this point.
 
  As for where I am getting the EDID dump from, I am getting it from
  /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid,
  which provides direct virtual access to the EDID response of the
  connected device.
 
  I'm completely confident that the device doesn't report too small of a
  buffer size, and that it's completely compliant with the spec: If you
 
  Agreed.
 
  have a Windows virtual machine (or if you're masochistic enough - a real
  machine) you should download the excellent, free Monitor Asset Manager
  by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It
  will let you analyze EDID + ELD + extended timings, etc from an EDID
  dump, such as the one taken above. It understands every part of EDID.
 
  I've put together a small archive containing my exact EDID binary dump
  (taken from the above device path), the FULL dmesg log, as well as
  EnTech's interpretation of the EDID dump, showing the full list of
  supported channels, formats, etc.
 
  I'm guessing there is some tiny bug in your interpretation of how to
  read ELD, maybe an incorrect 1 byte offset or something like that.
 
  Here's the pack:
  http://www.pulseforce.com/node/edid_to_eld.zip
 
  Thanks! It's great tool and information!
 
  If you do a hex analysis of my EDID dump and compare it to what the
  edid_to_eld function is trying to do, it will probably show what's
  wrong. I'd love to have a look at that myself but am really busy with a
  project over here so I can't help out other than to recompile and test
  as fast as I can.
 
  Would you install the intel-gpu-tools package and run its
  intel_audio_dump utility? If not shipped with your distribution, the
  source code is also available in
 
  git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools
 
  You'll need to install packages autotools-dev pkg-config
  libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from
  source.
 
  intel_audio_dump will dump the ELD data in the hardware buffer for use
  by the audio driver. By verifying if that data is correct, we are able
  to analyze whether and how the audio driver goes wrong.
 
 
 I think I experience similar issues. In my case the multi-channel pcm
 playback through HDMI doesn't work. Stereo and passthrough seem to
 work fine though !? It's hookedup  to my TV via a yamaha receiver.
 
 I'm currently running Linux 3.1 with a G45 chipset.
 
 libdrm 2.4.27-1
 xf86-video-intel 2.16.0-1

do you have Fengguang’s patch applied? This thread is about testing that
patch.

 The eld seems be incorrectly parsed, though the kernel log didn't give
 much info. The eld info from alsa is rather empty:
 
 cat /proc/asound/Intel/eld#3.0
 monitor_present   1
 eld_valid 0
 
 Using the same Monitor Asset Manager I was able to verify that the edid from
 (/sys/devices/pci\:00/\:00\:02.0/drm/card0/card0-HDMI-A-1/edid
 ) does seem to contain the correct information.
 
 I've attached both the edid and the output of Monitor Asset Manager.In
 addition I also run the intel_audio_dump.
 
 Let me know if you need anymore information.

It would be great if you could test the patch.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] test/testdisplay:add cursor test

2011-10-22 Thread Paul Menzel

Dear Hai,


Am Samstag, den 22.10.2011, 22:03 -0400 schrieb Hai Lan:

what does this test do? For the unknowledgeable user what is supposed to
happen, that means, when is the test successful and when not?

 Signed-off-by: Hai Lan hai@intel.com
 ---
  tests/testdisplay.c |   32 +---
  1 files changed, 25 insertions(+), 7 deletions(-)
 
 diff --git a/tests/testdisplay.c b/tests/testdisplay.c
 index 01f31dc..174d5c7 100644
 --- a/tests/testdisplay.c
 +++ b/tests/testdisplay.c
 @@ -75,7 +75,7 @@ struct udev_monitor *uevent_monitor;
  drmModeRes *resources;
  int fd, modes;
  int dump_info = 0, test_all_modes =0, test_preferred_mode = 0, force_mode = 
 0,
 - test_plane, enable_tiling;
 + test_plane, enable_tiling, test_cursor;
  int sleep_between_modes = 5;
  uint32_t depth = 24;
  
 @@ -823,7 +823,7 @@ set_mode(struct connector *c)
   cairo_surface_t *surface;
   cairo_status_t status;
   cairo_t *cr;
 - uint32_t handle;
 + uint32_t handle,cursor_handle;

Missing space?

   if (test_all_modes)
   c-mode = c-connector-modes[j];
 @@ -872,7 +872,6 @@ set_mode(struct connector *c)
  handle, fb_id);
   cairo_surface_destroy(surface);
   gem_close(fd, handle);
 -
   if (ret) {
   fprintf(stderr, failed to add fb (%dx%d): %s\n,
   width, height, strerror(errno));
 @@ -888,6 +887,21 @@ set_mode(struct connector *c)
   continue;
   }
  
 + if (test_cursor) {
 + cursor_handle = gem_create(fd,64*64*4);
 + char * cursor_buff = gem_mmap(fd, cursor_handle, 
 64*64*4, PROT_READ | PROT_WRITE);
 + for(int i=0;i64*64*4;i++)
 + *(cursor_buff+i)=0xff;
 +
 + drmModeSetCursor(fd,c-crtc,cursor_handle,64,64);
 + for(int i=0;i10;i++) {
 + drmModeMoveCursor(fd,c-crtc,i*100, 0);
 + sleep(1);
 + }
 + drmModeSetCursor(fd,c-crtc,0,64,64);
 + gem_close(fd, cursor_handle);
 + }
 +
   if (test_plane)
   enable_plane(c);
  
 @@ -931,7 +945,7 @@ static int update_display(void)
   dump_planes();
   }
  
 - if (test_preferred_mode || test_all_modes || force_mode) {
 + if (test_preferred_mode || test_all_modes || force_mode || test_cursor) 
 {
   /* Find any connected displays */
   for (c = 0; c  resources-count_connectors; c++) {
   connectors[c].id = resources-connectors[c];
 @@ -944,11 +958,11 @@ static int update_display(void)
  
  extern char *optarg;
  extern int optind, opterr, optopt;
 -static char optstr[] = hiaf:s:d:pmt;
 +static char optstr[] = hiaf:s:d:pmtc;
  
  static void usage(char *name)
  {
 - fprintf(stderr, usage: %s [-hiafs]\n, name);
 + fprintf(stderr, usage: %s [-hiaf:s:d:pmtc]\n, name);
   fprintf(stderr, \t-i\tdump info\n);
   fprintf(stderr, \t-a\ttest all modes\n);
   fprintf(stderr, \t-s\tduration\tsleep between each mode test\n);
 @@ -959,6 +973,7 @@ static void usage(char *name)
   fprintf(stderr, \t-f\tclock 
 MHz,hdisp,hsync-start,hsync-end,htotal,\n);
   fprintf(stderr, \t\tvdisp,vsync-start,vsync-end,vtotal\n);
   fprintf(stderr, \t\ttest force mode\n);
 + fprintf(stderr, \t-c\ttest cursor\n);
   fprintf(stderr, \tDefault is to test all modes.\n);
   exit(0);
  }
 @@ -1048,6 +1063,9 @@ int main(int argc, char **argv)
   case 't':
   enable_tiling = 1;
   break;
 + case 'c':
 + test_cursor = 1;
 + break;
   default:
   fprintf(stderr, unknown option %c\n, c);
   /* fall through */
 @@ -1057,7 +1075,7 @@ int main(int argc, char **argv)
   }
   }
   if (!test_all_modes  !force_mode  !dump_info 
 - !test_preferred_mode)
 + !test_preferred_mode  !test_cursor)
   test_all_modes = 1;
  
   for (i = 0; i  ARRAY_SIZE(modules); i++) {


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: ILK + VT-d workaround

2011-10-18 Thread Paul Menzel

Am Montag, den 17.10.2011, 15:51 -0700 schrieb Ben Widawsky:
 Idle the GPU before doing any unmaps. We know if VT-d is in use through
 an exported variable from iommu code.
 
 This should avoid a known HW issue.

Please describe the issue more in detail or provide a link to more
information.

 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/char/agp/intel-gtt.c|   28 
  drivers/gpu/drm/i915/i915_gem_gtt.c |   30 ++
  include/drm/intel-gtt.h |2 ++
  3 files changed, 60 insertions(+), 0 deletions(-)

[…]


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver

2011-09-04 Thread Paul Menzel

Dear Wu,


I hope that is your first name.

Am Sonntag, den 04.09.2011, 05:15 +0800 schrieb Wu Fengguang:
 Changes from v4: remove a debug call to dump_stack().
 Thanks to Bossart for catching this!

His first name is Pierre-Louis. I do not know how you address people at
Intel though.

 ---

I think your format will confuse `git am`. Please always put that under
the »---« under the Signed-off-by lines.

 Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
 SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
 
 ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
 capabilities of the plugged monitor. It's built and passed to audio
 driver in 2 steps:
 
 (1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
 
 (2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
 ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
 
 ELD selection policy: it's possible for one encoder to be associated
 with multiple connectors (ie. monitors), in which case the first found
 ELD will be used. This policy may not be suitable for all users, but
 let's start it simple first.
 
 The impact of ELD selection policy: assume there are two monitors, one
 supports stereo playback and the other has 8-channel output; cloned
 display mode is used, so that the two monitors are associated with the
 same internal encoder. If only the stereo playback capability is reported,
 the user won't be able to start 8-channel playback; if the 8-channel ELD
 is reported, then user space applications may send 8-channel samples
 down, however the user may actually be listening to the 2-channel
 monitor and not connecting speakers to the 8-channel monitor. Overall,
 it's more safe to report maximum profiles to the user space, so that
 the user can at least be able to do 8-channel playback if he want to.

s'he's/he'

 This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.

What is the correct way to test this patch. Just plug in the HDMI
monitor and it should work out of the box?

 Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always
 reads 0 (reserved). Without knowing the port number, I worked it around
 by setting the ELD_valid bit for ALL the three ports. It's tested to not
 be a problem, because the audio driver will find invalid ELD data and
 hence rightfully abort, even when it sees the ELD_valid indicator.
 
 Thanks to Zhenyu and Bossart for a lot of valuable help and testing.

Again the first name is Pierre-Louis or put Mr in front of it.

 CC: Zhao Yakui yakui.z...@intel.com
 CC: Wang Zhenyu zhenyu.z.w...@intel.com
 CC: Jeremy Bush contractfrombe...@gmail.com
 CC: Christopher White c.wh...@pulseforce.com
 CC: Bossart, Pierre-louis pierre-louis.boss...@intel.com

Pierre-Louis Bossart

 Signed-off-by: Ben Skeggs bske...@redhat.com
 Signed-off-by: Wu Fengguang fengguang...@intel.com
 ---
  drivers/gpu/drm/drm_edid.c   |  171 +
  drivers/gpu/drm/i915/i915_drv.h  |2 
  drivers/gpu/drm/i915/i915_reg.h  |   25 +++
  drivers/gpu/drm/i915/intel_display.c |  131 +++
  drivers/gpu/drm/i915/intel_dp.c  |6 
  drivers/gpu/drm/i915/intel_drv.h |2 
  drivers/gpu/drm/i915/intel_hdmi.c|3 
  drivers/gpu/drm/i915/intel_modes.c   |2 
  include/drm/drm_crtc.h   |9 +
  include/drm/drm_edid.h   |9 +
  10 files changed, 358 insertions(+), 2 deletions(-)

Some more style things follow.

[…]

 +/**
 + * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in milli-seconds
 + * @connector: connector associated with the HDMI/DP sink
 + * @mode: the display mode
 + */
 +int drm_av_sync_delay(struct drm_connector *connector,
 +   struct drm_display_mode *mode)
 +{
 + int i = !!(mode-flags  DRM_MODE_FLAG_INTERLACE);
 + int a, v;
 +
 + if (!connector-latency_present[0])
 + return 0;
 + if (!connector-latency_present[1])
 + i = 0;
 +
 + a = connector-audio_latency[i];
 + v = connector-video_latency[i];
 +
 + /*
 +  * HDMI/DP sink doesn't support audio or video?
 +  */
 + if (a == 255 || v == 255)
 + return 0;
 +
 + /*
 +  * Convert raw edid values to milli-seconds.

s/edid/EDID/ (nitpick)
s/milli-seconds/millisecond/

http://www.merriam-webster.com/dictionary/millisecond

 +  * Treat unknown latency as 0ms.
 +  */
 + if (a)
 + a = min(2 * (a - 1), 500);
 + if (v)
 + v = min(2 * (v - 1), 500);
 +
 + return max(v - a, 0);
 +}
 +EXPORT_SYMBOL(drm_av_sync_delay);

[…]

 --- linux-next.orig/drivers/gpu/drm/i915/i915_reg.h   2011-09-02 
 15:59:31.0 +0800
 +++ linux-next/drivers/gpu/drm/i915/i915_reg.h2011-09-02 
 15:59:40.0 +0800
 @@ -3470,4 +3470,29 @@
  #define GEN6_PCODE_DATA  0x138128
  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
  
 +#define

Re: [Intel-gfx] kernel-3.1.0-0.rc2.git0.1.fc16 and i915GM and DRM

2011-08-18 Thread Paul Menzel

Dear SD,


Am Dienstag, den 16.08.2011, 12:37 -0700 schrieb SD:

 Just updated Fedora 16 to kernel-3.1.0-0.rc2.git0.1.fc16.
 Noticed that DRM (I hope it is DRM) works quite slow. For example if I
 open mc in xterm window 150x50 size this window draws about 1 second,
 noticeably slow, although I can't find any errors nor in xorg log nor
 in dmesg.

was only the Linux kernel upgraded? Could you boot with an older Linux
kernel and try to reproduce the issue?

If it is a Linux kernel issue you could try to bisect it.

 So, if one wants to know any additional details, please tell what to
 check, because everything looks good, but 2D graphics became much
 slower then it was with kernel-3.0.1-5.fc16.

It looks like nobody had time yet to look into your issue. Please either
submit a report to the Fedora bug tracking system or the Freedesktop bug
tracking system and report the bug number back to the list. Please
follow the guide »How to file a good bug report« [1] on what information
to provide.


Thanks,

Paul


[1] http://intellinuxgraphics.org/how_to_report_bug.html


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] xbmc needs to be kill-9ed

2011-08-14 Thread Paul Menzel

Dear Dexter,


Am Sonntag, den 14.08.2011, 15:29 +0200 schrieb Dexter Filmore:
 The XB Media Center here on debian testing (linux 3.0.0, intel v2.15, mesa 
 7.10) doesn't exit cleanly, have to kill -9 the process from a shell.
 As it works ok on any other installation without intel here I suspect 
 intel-video. 
 If you need logs let me know what.

I hope I am wrong, but I guess you provided no useful information for
debugging that problem. Please provide URLs to the programs you are
referring to. XBMC is as far as I know not in the Debian archive. So how
did you install it, what version exactly and what options do you use?

XBMC should tell you why it is not exiting cleanly.

I suggest, that you open a report in the XBMC bug tracker [1] and report
back when the XBMC folks suspect a driver problem and tell you to do so.


Thanks and good luck,

Paul


[1] http://trac.xbmc.org/


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 SSC Patch

2011-07-29 Thread Paul Menzel

Dear Ben,


Am Freitag, den 29.07.2011, 13:55 +0100 schrieb Ben Brewer:
 I've added a global SSC (Spread Spectrum Clock) parameter to the i915 
 driver, since having SSC enabled breaks (distorts) VGA output on some 
 Core i5/i7 chips (see https://bugs.freedesktop.org/show_bug.cgi?id=38750).
 SSC is still enabled by default so the behaviour won't change but 
 setting the global_use_ssc parameter will turn this feature off and 
 allow affected devices to function correctly (notably the Dell Vostro 3300).
 
 Numerous people have tested this and reported it working (as seen in the 
 bug report thread) which isn't surprising considering it's a basic 
 modification of Chris Wilsons work.
 
 Any comments, or anybody willing to include this patch?

You at least need to include your Signed-off-by line [1].

Additionally I do not know if your patch applies against latest master.
So using Git with `git format-patch -s` is recommended.


Thanks,

Paul


[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 915GM: render error detected, EIR: 0x00000010

2011-07-26 Thread Paul Menzel

Dear graphics folks,


Am Montag, den 25.07.2011, 22:33 +0200 schrieb Paul Menzel:

 using `linux-image-3.0.0-1-686-pae` from Debian Sid/unstable I noticed
 the following message in `dmesg`.
 
 [   76.292185] [drm] capturing error event; look for more information 
 in /debug/dri/0/i915_error_state
 [   76.294236] render error detected, EIR: 0x0010
 [   76.294246] page table error
 [   76.294251]   PGTBL_ER: 0x0010
 [   76.294264] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 
 0x0010, masking
 [   76.294298] render error detected, EIR: 0x0010
 [   76.294304] page table error
 [   76.294309]   PGTBL_ER: 0x0010
 
 I just booted, GDM was started, I started the window manager and opened
 a terminal.
 
 I mounted the debug filesystem as documented in [1] (after the message
 had appeared in `dmesg`) and just copied the
 `/debug/dri/0/i915_error_state` to the attached file.
 
 The device is an ASUS EeePC 701 4G [2].
 
 Searching for that error message on the Web gives several hits
 suggesting this error has been there for a long time [3] but is supposed
 to be fixed since 2.6.33 and also 2.6.32 stable. I will try to find out
 if I can find it in the system logs with earlier Linux kernels.

I found such messages also with Linux kernel 2.6.39.

[  114.355954] [drm] capturing error event; look for more information 
in /debug/dri/0/i915_error_state
[  114.356015] render error detected, EIR: 0x0010
[  114.356015] page table error
[  114.356015]   PGTBL_ER: 0x0010
[  114.356015] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 
0x0010, masking
[  114.356015] render error detected, EIR: 0x0010
[  114.356015] page table error
[  114.356015]   PGTBL_ER: 0x0010

 Other information I found on the Web with the same error message are [4–
 7] where some of them suggest that this is an error which got fixed
 again and again.

Please tell me, if that is a know problem and if you want me to submit a
report/ticket to the bug tracker.


Thanks,

Paul


 [1] http://intellinuxgraphics.org/intel-gpu-dump.html
 [2] https://secure.wikimedia.org/wikipedia/en/wiki/ASUS_Eee_PC#Specifications
 [3] https://bugzilla.kernel.org/show_bug.cgi?id=15502
 [4] http://lkml.indiana.edu/hypermail/linux/kernel/1005.1/02637.html
 [5] https://bugs.archlinux.org/task/22781
 [6] 
 http://us.generation-nt.com/answer/2-6-36-rc5-i915-regression-help-200514811.html
 [7] 
 http://www.devheads.net/linux/ubuntu/user/t43-login-render-error-detected-eir-0x0010-page-table-error-pgtbl-er-0x00100-drm915-handle-e.htm


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dri: Do not tile stencil buffer

2011-07-18 Thread Paul Menzel

Am Montag, den 18.07.2011, 00:55 -0700 schrieb Chad Versace:
 Until now, the stencil buffer was allocated as a Y tiled buffer, because
 in several locations the PRM states that it is. However, it is actually
 W tiled. From the PRM, 2011 Sandy Bridge, Volume 1, Part 2, Section
 4.5.2.1 W-Major Format:
 W-Major Tile Format is used for separate stencil.
 
 The GTT is incapable of W fencing, so we allocate the stencil buffer with
 I915_TILING_NONE and decode the tile's layout in software.
 
 This commit mutually depends on the mesa commit:
 intel: Fix stencil buffer to be W tiled
 Author: Chad Versace c...@chad-versace.us
 Date:   Mon Jul 18 00:37:45 2011 -0700
 
 CC: Eric Anholt e...@anholt.net
 CC: Kenneth Graunke kenn...@whitecape.org
 Signed-off-by: Chad Versace c...@chad-versace.us
 ---
  src/intel_dri.c |   16 
  1 files changed, 12 insertions(+), 4 deletions(-)
 
 diff --git a/src/intel_dri.c b/src/intel_dri.c
 index 5ea7c2c..4652dc7 100644
 --- a/src/intel_dri.c
 +++ b/src/intel_dri.c
 @@ -336,7 +336,6 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int 
 attachment,
   switch (attachment) {
   case DRI2BufferDepth:
   case DRI2BufferDepthStencil:
 - case DRI2BufferStencil:
   case DRI2BufferHiz:
   if (SUPPORTS_YTILING(intel)) {
   hint |= INTEL_CREATE_PIXMAP_TILING_Y;
 @@ -351,6 +350,14 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int 
 attachment,
   case DRI2BufferFrontRight:
   hint |= INTEL_CREATE_PIXMAP_TILING_X;
   break;
 + case DRI2BufferStencil:
 + /*
 +  * The stencil buffer is W tiled. However, we
 +  * request from the kernel a non-tiled buffer
 +  * because the GTT is incapable of W fencing.
 +  */
 + hint |= INTEL_CREATE_PIXMAP_TILING_NONE;
 + break;
   default:
   free(privates);
   free(buffer);
 @@ -368,11 +375,12 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int 
 attachment,
* To accomplish this, we resort to the nasty hack of doubling
* the drm region's cpp and halving its height.
*
 -  * If we neglect to double the pitch, then
 -  * drm_intel_gem_bo_map_gtt() maps the memory incorrectly.
 +  * If we neglect to double the pitch, then render corruption
 + * occurs.

The alignment does not seem to match.

*/
   if (attachment == DRI2BufferStencil) {
 - pixmap_height /= 2;
 + pixmap_width = ALIGN(pixmap_width, 64);
 + pixmap_height = ALIGN(pixmap_height / 2, 64);
   pixmap_cpp *= 2;
   }


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

1 2 >

1 - 100 of 122 matches

Mail list logo