[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

--- Comment #7 from Darren Salt  ---
Can't do that (radeon module is built in, and no debug symbols ? should switch
that on), but ksymoops output (below) is clear enough for me to determine that
the marked line is where the bug makes itself known:

 if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
vco_min *= 10;
vco_max *= 10;
}

/* here */  post_div_min = vco_min / target_clock;
if ((target_clock * post_div_min) < vco_min)
++post_div_min;
if (post_div_min < pll->min_post_div)
post_div_min = pll->min_post_div;

Which means that target_clock is zero, which means that freq is 0 or freq/10 is
0.


>>RIP; 812513d0    <=

>>RAX; 000927c0 <__per_cpu_end+804c0/fedd00>
>>RBX; 880236dc8210 
>>RCX; 00124f80 <__per_cpu_end+112c80/fedd00>
>>RSI; 000927c0 <__per_cpu_end+804c0/fedd00>
>>RBP; 8800bd6d2c00 
>>R08; 88021b08fb08 
>>R09; 88021b08fb00 
>>R12; 880236dc8000 
>>R14; 4ff6 

Trace; 81227da9 
Trace; 8123ed95 
Trace; 812d6725 
Trace; 812d68ed 
Trace; 81213ccd 
Trace; 812145a5 
Trace; 81250650 
Trace; 81222183 
Trace; 81224843 
Trace; 81250dac 
Trace; 81219f06 
Trace; 81224470 
Trace; 81468fcc <_raw_spin_unlock_irqrestore+f/21>
Trace; 81234864 
Trace; 810b10a7 
Trace; 810b8747 <__fget+64/6c>
Trace; 810b11a4 
Trace; 81469ca6 

Code;  812513a5 
 <_RIP>:
Code;  812513a5 
   0:   09 8b 6b 08 89 6c or %ecx,0x6c89086b(%rbx)
Code;  812513ab 
   6:   24 20 and$0x20,%al
Code;  812513ad 
   8:   eb 5f jmp69 <_RIP+0x69>
Code;  812513af 
   a:   80 e5 20  and$0x20,%ch
Code;  812513b2 
   d:   74 08 je 17 <_RIP+0x17>
Code;  812513b4 
   f:   8b 73 1c  mov0x1c(%rbx),%esi
Code;  812513b7 
  12:   8b 4b 20  mov0x20(%rbx),%ecx
Code;  812513ba 
  15:   eb 06 jmp1d <_RIP+0x1d>
Code;  812513bc 
  17:   8b 73 14  mov0x14(%rbx),%esi
Code;  812513bf 
  1a:   8b 4b 18  mov0x18(%rbx),%ecx
Code;  812513c2 
  1d:   85 ff test   %edi,%edi
Code;  812513c4 
  1f:   74 06 je 27 <_RIP+0x27>
Code;  812513c6 
  21:   6b f6 0a  imul   $0xa,%esi,%esi
Code;  812513c9 
  24:   6b c9 0a  imul   $0xa,%ecx,%ecx
Code;  812513cc 
  27:   31 d2 xor%edx,%edx
Code;  812513ce 
  29:   89 f0 mov%esi,%eax
Code;  812513d0    <=
  2b:   41 f7 f5  div%r13d   <=
Code;  812513d3 
  2e:   89 c2 mov%eax,%edx
Code;  812513d5 
  30:   8d 68 01  lea0x1(%rax),%ebp
Code;  812513d8 
  33:   41 0f af d5   imul   %r13d,%edx
Code;  812513dc 
  37:   39 f2 cmp%esi,%edx
Code;  812513de 
  39:   8b 53 30  mov0x30(%rbx),%edx

[PATCH] Use signed location for drmModeSetPlane

[Daniel Kurtz]

DRM_IOCTL_MODE_SETPLANE crtc_x, crtc_y are s32.
This is to allow a destination location that is partially off screen.

Make this more obvious to users of libdrm by using signed crtc_x/_y
parameters for drmModeSetPlane() as well.

Signed-off-by: Daniel Kurtz 
---
 xf86drmMode.c | 2 +-
 xf86drmMode.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index a6bb2ee..7ca89b3 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -906,7 +906,7 @@ int drmModePageFlip(int fd, uint32_t crtc_id, uint32_t 
fb_id,

 int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id,
uint32_t fb_id, uint32_t flags,
-   uint32_t crtc_x, uint32_t crtc_y,
+   int32_t crtc_x, int32_t crtc_y,
uint32_t crtc_w, uint32_t crtc_h,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h)
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 9bcb1d1..6eab565 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -445,7 +445,7 @@ extern drmModePlaneResPtr drmModeGetPlaneResources(int fd);
 extern drmModePlanePtr drmModeGetPlane(int fd, uint32_t plane_id);
 extern int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id,
   uint32_t fb_id, uint32_t flags,
-  uint32_t crtc_x, uint32_t crtc_y,
+  int32_t crtc_x, int32_t crtc_y,
   uint32_t crtc_w, uint32_t crtc_h,
   uint32_t src_x, uint32_t src_y,
   uint32_t src_w, uint32_t src_h);
-- 
1.9.1.423.g4596e3a

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #3 from Clemens Ladisch  ---
3.14:
16205, pll dividers - fb: 135.8 ref: 2, post 6

With the patch:
162000 - 161990, pll dividers - fb: 271.5 ref: 4, post 6

And the patch indeed fixes this.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 2/2] drm/radeon: add proper support for RADEON_VM_BLOCK_SIZE

[Christian König]

>   /* defines number of bits in page table versus page directory,
>* a page is 4KB so we have 12 bits offset, 9 bits in the page
>* table and the remaining 19 bits are in the page directory */
> -#define RADEON_VM_BLOCK_SIZE   9
> +#define RADEON_VM_BLOCK_SIZE   12
> I would first do a patch that add all the code to set this bit inside the
> vm context registers and then a patch that change the default current
> value explaining why.
>
> This would allow bisection to either find that the register setting is
> guilty or that the default value change is the one introducing problem
>
> But really i am being picky here.
No, you're right. That change was unintentional, otherwise I would have 
updated the comment above as well.

Christian.

Am 01.05.2014 19:17, schrieb Jerome Glisse:
> On Thu, May 01, 2014 at 06:52:33PM +0200, Christian K?nig wrote:
>> From: Christian K?nig 
>>
>> This patch makes it possible to decide how many address
>> bits are spend on the page directory vs the page tables.
>>
>> Signed-off-by: Christian K?nig 
> NAK on the basis you are modifying default behavior and hardware
> programming in same patch see below.
>
>> ---
>>   drivers/gpu/drm/radeon/cik.c   | 1 +
>>   drivers/gpu/drm/radeon/cikd.h  | 1 +
>>   drivers/gpu/drm/radeon/ni.c| 1 +
>>   drivers/gpu/drm/radeon/nid.h   | 1 +
>>   drivers/gpu/drm/radeon/radeon.h| 2 +-
>>   drivers/gpu/drm/radeon/radeon_vm.c | 4 +++-
>>   drivers/gpu/drm/radeon/si.c| 1 +
>>   drivers/gpu/drm/radeon/sid.h   | 1 +
>>   8 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 38da9f3..f11a9ab 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -5445,6 +5445,7 @@ static int cik_pcie_gart_enable(struct radeon_device 
>> *rdev)
>> (u32)(rdev->dummy_page.addr >> 12));
>>  WREG32(VM_CONTEXT1_CNTL2, 4);
>>  WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
>> +PAGE_TABLE_BLOCK_SIZE(RADEON_VM_BLOCK_SIZE - 9) 
>> |
>>  RANGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
>>  RANGE_PROTECTION_FAULT_ENABLE_DEFAULT |
>>  DUMMY_PAGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
>> diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
>> index dd79263..ae88660 100644
>> --- a/drivers/gpu/drm/radeon/cikd.h
>> +++ b/drivers/gpu/drm/radeon/cikd.h
>> @@ -482,6 +482,7 @@
>>   #defineREAD_PROTECTION_FAULT_ENABLE_DEFAULT(1 << 
>> 16)
>>   #defineWRITE_PROTECTION_FAULT_ENABLE_INTERRUPT (1 << 
>> 18)
>>   #defineWRITE_PROTECTION_FAULT_ENABLE_DEFAULT   (1 << 
>> 19)
>> +#define PAGE_TABLE_BLOCK_SIZE(x)(((x) & 
>> 0xF) << 24)
>>   #define VM_CONTEXT1_CNTL   0x1414
>>   #define VM_CONTEXT0_CNTL2  0x1430
>>   #define VM_CONTEXT1_CNTL2  0x1434
>> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
>> index 5e8db9b..1d3209f 100644
>> --- a/drivers/gpu/drm/radeon/ni.c
>> +++ b/drivers/gpu/drm/radeon/ni.c
>> @@ -1268,6 +1268,7 @@ static int cayman_pcie_gart_enable(struct 
>> radeon_device *rdev)
>> (u32)(rdev->dummy_page.addr >> 12));
>>  WREG32(VM_CONTEXT1_CNTL2, 4);
>>  WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
>> +PAGE_TABLE_BLOCK_SIZE(RADEON_VM_BLOCK_SIZE - 9) 
>> |
>>  RANGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
>>  RANGE_PROTECTION_FAULT_ENABLE_DEFAULT |
>>  DUMMY_PAGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
>> diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
>> index d996033..2e12e4d 100644
>> --- a/drivers/gpu/drm/radeon/nid.h
>> +++ b/drivers/gpu/drm/radeon/nid.h
>> @@ -128,6 +128,7 @@
>>   #defineREAD_PROTECTION_FAULT_ENABLE_DEFAULT(1 << 
>> 16)
>>   #defineWRITE_PROTECTION_FAULT_ENABLE_INTERRUPT (1 << 
>> 18)
>>   #defineWRITE_PROTECTION_FAULT_ENABLE_DEFAULT   (1 << 
>> 19)
>> +#define PAGE_TABLE_BLOCK_SIZE(x)(((x) & 
>> 0xF) << 24)
>>   #define VM_CONTEXT1_CNTL   0x1414
>>   #define VM_CONTEXT0_CNTL2  0x1430
>>   #define VM_CONTEXT1_CNTL2  0x1434
>> diff --git a/drivers/gpu/drm/radeon/radeon.h 
>> b/drivers/gpu/drm/radeon/radeon.h
>> index e3d6be3..2d80cf2 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -838,7 +838,7 @@ struct radeon_mec {
>>   /* defines number of bits in page table versus page directory,
>>* a page is 4KB so we have 12 bits offset, 9 bits in the page
>>* table and the 

[PATCH 2/2] drm/radeon: add proper support for RADEON_VM_BLOCK_SIZE

[Christian König]

From: Christian K?nig 

This patch makes it possible to decide how many address
bits are spend on the page directory vs the page tables.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/cik.c   | 1 +
 drivers/gpu/drm/radeon/cikd.h  | 1 +
 drivers/gpu/drm/radeon/ni.c| 1 +
 drivers/gpu/drm/radeon/nid.h   | 1 +
 drivers/gpu/drm/radeon/radeon.h| 2 +-
 drivers/gpu/drm/radeon/radeon_vm.c | 4 +++-
 drivers/gpu/drm/radeon/si.c| 1 +
 drivers/gpu/drm/radeon/sid.h   | 1 +
 8 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 38da9f3..f11a9ab 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -5445,6 +5445,7 @@ static int cik_pcie_gart_enable(struct radeon_device 
*rdev)
   (u32)(rdev->dummy_page.addr >> 12));
WREG32(VM_CONTEXT1_CNTL2, 4);
WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
+   PAGE_TABLE_BLOCK_SIZE(RADEON_VM_BLOCK_SIZE - 9) 
|
RANGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
RANGE_PROTECTION_FAULT_ENABLE_DEFAULT |
DUMMY_PAGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index dd79263..ae88660 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -482,6 +482,7 @@
 #defineREAD_PROTECTION_FAULT_ENABLE_DEFAULT(1 << 
16)
 #defineWRITE_PROTECTION_FAULT_ENABLE_INTERRUPT (1 << 
18)
 #defineWRITE_PROTECTION_FAULT_ENABLE_DEFAULT   (1 << 
19)
+#definePAGE_TABLE_BLOCK_SIZE(x)(((x) & 
0xF) << 24)
 #define VM_CONTEXT1_CNTL   0x1414
 #define VM_CONTEXT0_CNTL2  0x1430
 #define VM_CONTEXT1_CNTL2  0x1434
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 5e8db9b..1d3209f 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1268,6 +1268,7 @@ static int cayman_pcie_gart_enable(struct radeon_device 
*rdev)
   (u32)(rdev->dummy_page.addr >> 12));
WREG32(VM_CONTEXT1_CNTL2, 4);
WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
+   PAGE_TABLE_BLOCK_SIZE(RADEON_VM_BLOCK_SIZE - 9) 
|
RANGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
RANGE_PROTECTION_FAULT_ENABLE_DEFAULT |
DUMMY_PAGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index d996033..2e12e4d 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -128,6 +128,7 @@
 #defineREAD_PROTECTION_FAULT_ENABLE_DEFAULT(1 << 
16)
 #defineWRITE_PROTECTION_FAULT_ENABLE_INTERRUPT (1 << 
18)
 #defineWRITE_PROTECTION_FAULT_ENABLE_DEFAULT   (1 << 
19)
+#definePAGE_TABLE_BLOCK_SIZE(x)(((x) & 
0xF) << 24)
 #define VM_CONTEXT1_CNTL   0x1414
 #define VM_CONTEXT0_CNTL2  0x1430
 #define VM_CONTEXT1_CNTL2  0x1434
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e3d6be3..2d80cf2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -838,7 +838,7 @@ struct radeon_mec {
 /* defines number of bits in page table versus page directory,
  * a page is 4KB so we have 12 bits offset, 9 bits in the page
  * table and the remaining 19 bits are in the page directory */
-#define RADEON_VM_BLOCK_SIZE   9
+#define RADEON_VM_BLOCK_SIZE   12

 /* number of entries in page table */
 #define RADEON_VM_PTE_COUNT (1 << RADEON_VM_BLOCK_SIZE)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 6bf656e..3900ecf 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -964,6 +964,8 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev,
  */
 int radeon_vm_init(struct radeon_device *rdev, struct radeon_vm *vm)
 {
+   const unsigned align = min(RADEON_VM_PTB_ALIGN_SIZE,
+   RADEON_VM_PTE_COUNT * 8);
unsigned pd_size, pd_entries, pts_size;
int r;

@@ -985,7 +987,7 @@ int radeon_vm_init(struct radeon_device *rdev, struct 
radeon_vm *vm)
return -ENOMEM;
}

-   r = radeon_bo_create(rdev, pd_size, RADEON_VM_PTB_ALIGN_SIZE, false,
+   r = radeon_bo_create(rdev, pd_size, align, false,
 RADEON_GEM_DOMAIN_VRAM, NULL,
 >page_directory);
if (r)
diff --git 

[PATCH 1/2] drm/radeon: add large PTE support for NI, SI and CIK v4

[Christian König]

From: Christian K?nig 

This patch implements support for VRAM page table entry compression.
PTE construction is enhanced to identify physically contiguous page
ranges and mark them in the PTE fragment field. L1 TLB and L2 cache
support is enabled for 64KB (SI/CIK) and 256KB (NI) PTE fragments,
significantly improving TLB utilization for VRAM allocations.

Linear store bandwidth is improved from 60GB/s to 125GB/s on Pitcairn.
Unigine Heaven 3.0 sees an average improvement from 24.7 to 27.7 FPS
on default settings at 1920x1200 resolution with vsync disabled.

See main comment in radeon_gart.c gives a technical description.

v2 (chk): rebased and simplified.
v3 (chk): add missing hw setup
v4 (chk): rebased on current drm-fixes-3.15

Signed-off-by: Jay Cornwall 
Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/cik.c   |  4 +-
 drivers/gpu/drm/radeon/ni.c|  2 +
 drivers/gpu/drm/radeon/radeon.h|  5 +++
 drivers/gpu/drm/radeon/radeon_vm.c | 91 +++---
 drivers/gpu/drm/radeon/si.c|  5 ++-
 5 files changed, 98 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 38f3fcc..38da9f3 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -5395,6 +5395,7 @@ static int cik_pcie_gart_enable(struct radeon_device 
*rdev)
WREG32(MC_VM_MX_L1_TLB_CNTL,
   (0xA << 7) |
   ENABLE_L1_TLB |
+  ENABLE_L1_FRAGMENT_PROCESSING |
   SYSTEM_ACCESS_MODE_NOT_IN_SYS |
   ENABLE_ADVANCED_DRIVER_MODEL |
   SYSTEM_APERTURE_UNMAPPED_ACCESS_PASS_THRU);
@@ -5407,7 +5408,8 @@ static int cik_pcie_gart_enable(struct radeon_device 
*rdev)
   CONTEXT1_IDENTITY_ACCESS_MODE(1));
WREG32(VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS | INVALIDATE_L2_CACHE);
WREG32(VM_L2_CNTL3, L2_CACHE_BIGK_ASSOCIATIVITY |
-  L2_CACHE_BIGK_FRAGMENT_SIZE(6));
+  BANK_SELECT(4) |
+  L2_CACHE_BIGK_FRAGMENT_SIZE(4));
/* setup context0 */
WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR, rdev->mc.gtt_start >> 12);
WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR, rdev->mc.gtt_end >> 12);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index d246e04..5e8db9b 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1228,12 +1228,14 @@ static int cayman_pcie_gart_enable(struct radeon_device 
*rdev)
   SYSTEM_APERTURE_UNMAPPED_ACCESS_PASS_THRU);
/* Setup L2 cache */
WREG32(VM_L2_CNTL, ENABLE_L2_CACHE |
+  ENABLE_L2_FRAGMENT_PROCESSING |
   ENABLE_L2_PTE_CACHE_LRU_UPDATE_BY_WRITE |
   ENABLE_L2_PDE0_CACHE_LRU_UPDATE_BY_WRITE |
   EFFECTIVE_L2_QUEUE_SIZE(7) |
   CONTEXT1_IDENTITY_ACCESS_MODE(1));
WREG32(VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS | INVALIDATE_L2_CACHE);
WREG32(VM_L2_CNTL3, L2_CACHE_BIGK_ASSOCIATIVITY |
+  BANK_SELECT(6) |
   L2_CACHE_BIGK_FRAGMENT_SIZE(6));
/* setup context0 */
WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR, rdev->mc.gtt_start >> 12);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 6852861..e3d6be3 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -854,6 +854,11 @@ struct radeon_mec {
 #define R600_PTE_READABLE  (1 << 5)
 #define R600_PTE_WRITEABLE (1 << 6)

+/* PTE (Page Table Entry) fragment field for different page sizes */
+#define R600_PTE_FRAG_4KB  (0 << 7)
+#define R600_PTE_FRAG_64KB (4 << 7)
+#define R600_PTE_FRAG_256KB(6 << 7)
+
 struct radeon_vm_pt {
struct radeon_bo*bo;
uint64_taddr;
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 2aae6ce..6bf656e 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -658,6 +658,84 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
 }

 /**
+ * radeon_vm_frag_ptes - add fragment information to PTEs
+ *
+ * @rdev: radeon_device pointer
+ * @ib: IB for the update
+ * @pe_start: first PTE to handle
+ * @pe_end: last PTE to handle
+ * @addr: addr those PTEs should point to
+ * @flags: hw mapping flags
+ *
+ * Global and local mutex must be locked!
+ */
+static void radeon_vm_frag_ptes(struct radeon_device *rdev,
+   struct radeon_ib *ib,
+   uint64_t pe_start, uint64_t pe_end,
+   uint64_t addr, uint32_t flags)
+{
+   /**
+* The MC L1 TLB supports variable sized pages, based on a fragment
+* field in the PTE. When this field is set to a non-zero value, page
+* granularity is increased from 4KB to (1 << (12 + frag)). The PTE
+* flags are considered valid for all PTEs 

[Bug 77930] radeon regression after update to kernel 3.13.7 (stable)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77930

--- Comment #5 from AdrianG  ---
*UPDATE*
The problem seems to be solved (partially) by upgrading to the latest unstable
components as found in the oibaf PPA (mesa, libdrm, glamor).

I still get some kernel crash messages, but nonetheless, it boots!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140501/7f05671e/attachment.html>

[Bug 78163] Opencl app with multiprecision math return wrong results

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78163

Alexey Shvetsov  changed:

   What|Removed |Added

   Assignee|dri-devel at lists.freedesktop |tstellar at gmail.com
   |.org|

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140501/964afac5/attachment.html>

[Bug 78163] New: Opencl app with multiprecision math return wrong results

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78163

  Priority: medium
Bug ID: 78163
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Opencl app with multiprecision math return wrong
results
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: alexxy at gentoo.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Opencl app that uses multiprecision math gives wrong results

App is https://github.com/eXtremal-ik7/xpmminer


$ ./xpmclminer -b --opencl-platform Mesa
OpenCL platform available: Mesa
8 warnings generated.
8 warnings generated.
[0] AMD TURKS; 1 compute units
[1] AMD TURKS; 1 compute units
 * GPU 1 benchmark start:
Multiply 256 bits CPU time: 4.868, GPU time: 4.131 (1.178 times faster)
element index: 0
gmp: 79016B22 1C710C4A DF86F5C0 18E693EF D677434D 28B50A0A 4A2F8F5E 6FF1E1A6
C17B67E2 77B8CB65 8BA0DF48 3CD297F7 AD74948C 6B99D76B 8A81F331 DF8A45CB
8869E036 825665FF 9505CD30 543C80C6 96E3B1A5 72CE6A4A CEA9324B 7C37E23C 
gpu:        
       
        
results differ!
Multiply 384 bits CPU time: 9.280, GPU time: 15.885 (0.584 times faster)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140501/d64cc020/attachment-0001.html>

[PATCH v3 0/9] drm/nouveau: support for GK20A, cont'd

[Ben Skeggs]

On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot  
wrote:
> Changes since v2:
> - Enabled software class
> - Removed unneeded changes to nouveau_accel_init()
> - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with
>   the portable page_to_phys()/phys_to_page()
page_to_phys() looks well defined and used everywhere, phys_to_page()
not so much (including on amd64) :(

> - Fixed incorrect comment/commit log talking about bytes instead of words
>
> Hope this looks good! Once this gets merged the next set will be to use this
> driver on Jetson and Venice2 boards.
>
> Cheers,
>
> Alexandre Courbot (9):
>   drm/nouveau/bar: only ioremap BAR3 if it exists
>   drm/nouveau/bar/nvc0: support chips without BAR3
>   drm/nouveau/ibus: add GK20A support
>   drm/nouveau/fb: add GK20A support
>   drm/nouveau/fifo: add GK20A support
>   drm/nouveau/graph: enable when using external firmware
>   drm/nouveau/graph: pad firmware code at load time
>   drm/nouveau/graph: add GK20A support
>   drm/nouveau: support for probing GK20A
>
>  drivers/gpu/drm/nouveau/Makefile   |   6 +
>  drivers/gpu/drm/nouveau/core/engine/device/nve0.c  |  17 +++
>  drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c   |  35 +
>  drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h|   1 +
>  .../gpu/drm/nouveau/core/engine/graph/ctxgk20a.c   |  53 +++
>  .../gpu/drm/nouveau/core/engine/graph/ctxnvc0.h|   9 ++
>  .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c|  14 +-
>  drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c  |  47 ++
>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c   |  13 +-
>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |   2 +
>  drivers/gpu/drm/nouveau/core/engine/graph/nve4.c   |   4 +-
>  drivers/gpu/drm/nouveau/core/include/engine/fifo.h |   1 +
>  .../gpu/drm/nouveau/core/include/engine/graph.h|   1 +
>  drivers/gpu/drm/nouveau/core/include/subdev/fb.h   |   1 +
>  drivers/gpu/drm/nouveau/core/include/subdev/ibus.h |   1 +
>  drivers/gpu/drm/nouveau/core/subdev/bar/base.c |   6 +-
>  drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 114 +++---
>  drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c |  56 +++
>  drivers/gpu/drm/nouveau/core/subdev/fb/priv.h  |   1 +
>  drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c  | 167 
> +
>  drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c   | 103 +
>  21 files changed, 583 insertions(+), 69 deletions(-)
>  create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c
>  create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/ctxgk20a.c
>  create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c
>  create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c
>  create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
>  create mode 100644 drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c
>
> --
> 1.9.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

--- Comment #6 from Christian K?nig  ---
And please provide the output of:

gdb /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/radeon/radeon.ko -ex 'list
*(radeon_compute_pll_avivo+0xb6)' -ex q

Thanks in advance,
Christian.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75241

--- Comment #2 from Christian K?nig  ---
Created attachment 134611
  --> https://bugzilla.kernel.org/attachment.cgi?id=134611=edit
Possible fix.

Please try the attached patch, it might fix the issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

--- Comment #5 from Christian K?nig  ---
(In reply to Darren Salt from comment #4)
> It appears that you do actually need mismatched builds of xserver git and
> xf86-video-ati git, the latter built against (ideally) 1.15.99.902, to
> trigger this kernel bug... I wonder why it's gone apparently unnoticed until
> now. ?

I've reworked that function for 3.15. It's likely that with mismatched DDX and
X you pass some parameters as zero into the kernel and so trigger a divide by
zero error.

Allready digging into this, just give me a day or two to catch up with the
bugs.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3 0/9] drm/nouveau: support for GK20A, cont'd

[Alexandre Courbot]

On 05/01/2014 04:11 PM, Ben Skeggs wrote:
> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot  
> wrote:
>> Changes since v2:
>> - Enabled software class
>> - Removed unneeded changes to nouveau_accel_init()
>> - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with
>>the portable page_to_phys()/phys_to_page()
> page_to_phys() looks well defined and used everywhere, phys_to_page()
> not so much (including on amd64) :(

Argh, dammit. Now I *really* wonder what one is supposed to use in such 
cases...

Let me come with a v4 then. I will address the other issue with external 
firmware at the same time.

Sorry for the inconvenience.

>
>> - Fixed incorrect comment/commit log talking about bytes instead of words
>>
>> Hope this looks good! Once this gets merged the next set will be to use this
>> driver on Jetson and Venice2 boards.
>>
>> Cheers,
>>
>> Alexandre Courbot (9):
>>drm/nouveau/bar: only ioremap BAR3 if it exists
>>drm/nouveau/bar/nvc0: support chips without BAR3
>>drm/nouveau/ibus: add GK20A support
>>drm/nouveau/fb: add GK20A support
>>drm/nouveau/fifo: add GK20A support
>>drm/nouveau/graph: enable when using external firmware
>>drm/nouveau/graph: pad firmware code at load time
>>drm/nouveau/graph: add GK20A support
>>drm/nouveau: support for probing GK20A
>>
>>   drivers/gpu/drm/nouveau/Makefile   |   6 +
>>   drivers/gpu/drm/nouveau/core/engine/device/nve0.c  |  17 +++
>>   drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c   |  35 +
>>   drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h|   1 +
>>   .../gpu/drm/nouveau/core/engine/graph/ctxgk20a.c   |  53 +++
>>   .../gpu/drm/nouveau/core/engine/graph/ctxnvc0.h|   9 ++
>>   .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c|  14 +-
>>   drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c  |  47 ++
>>   drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c   |  13 +-
>>   drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |   2 +
>>   drivers/gpu/drm/nouveau/core/engine/graph/nve4.c   |   4 +-
>>   drivers/gpu/drm/nouveau/core/include/engine/fifo.h |   1 +
>>   .../gpu/drm/nouveau/core/include/engine/graph.h|   1 +
>>   drivers/gpu/drm/nouveau/core/include/subdev/fb.h   |   1 +
>>   drivers/gpu/drm/nouveau/core/include/subdev/ibus.h |   1 +
>>   drivers/gpu/drm/nouveau/core/subdev/bar/base.c |   6 +-
>>   drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 114 +++---
>>   drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c |  56 +++
>>   drivers/gpu/drm/nouveau/core/subdev/fb/priv.h  |   1 +
>>   drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c  | 167 
>> +
>>   drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c   | 103 +
>>   21 files changed, 583 insertions(+), 69 deletions(-)
>>   create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c
>>   create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/ctxgk20a.c
>>   create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c
>>   create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c
>>   create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
>>   create mode 100644 drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c
>>
>> --
>> 1.9.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-3.15

[Christian König]

Hi Dave,

this is the next pull quested for stashed up radeon fixes for 3.15. 
Highlights this time are:
1. Support for Mullins. Handled like Kabini, so only PCI-IDs and a new 
enum that needs to be added on various locations.
2. DPM updates for Kabini.
3. One more patch to better handle PLL limits.
4. Making use of the PFLIP additional to the VBLANK interrupt, otherwise 
we sometimes miss page flip events.
5. Fix for the UVD command stream parser.
6. Fix for bootup UVD clocks on RV7xx systems.

The following changes since commit b8eade24c9891b8f153c40cf310ef4696c873af9:

   drm/exynos: use %pad for dma_addr_t (2014-04-30 09:48:54 +1000)

are available in the git repository at:

   git://people.freedesktop.org/~deathsimple/linux drm-fixes-3.15

for you to fetch changes up to 4404cc95b18e4cacacb7e94fde00b4fc8506ae57:

   drm/radeon: add pci ids for Mullins (2014-05-01 12:29:00 +0200)


Alex Deucher (2):
   drm/radeon/dp: check for errors in dpcd reads
   drm/radeon: dpm updates for KV/KB

Christian K?nig (3):
   drm/radeon/uvd: use lower clocks on old UVD to boot v2
   drm/radeon: use pflip irq on R600+ v2
   drm/radeon: avoid high jitter with small frac divs

Leo Liu (2):
   drm/radeon: check buffer relocation offset
   drm/radeon: add Mullins VCE support

Samuel Li (6):
   drm/radeon: add Mullins chip family
   drm/radeon: update cik init for Mullins.
   drm/radeon: add Mullins UVD support.
   drm/radeon: add Mullins dpm support.
   drm/radeon: modesetting updates for Mullins.
   drm/radeon: add pci ids for Mullins

  drivers/gpu/drm/radeon/atombios_crtc.c  |   5 ++--
  drivers/gpu/drm/radeon/atombios_dp.c|  44 
-
  drivers/gpu/drm/radeon/cik.c| 147 
+
  drivers/gpu/drm/radeon/cikd.h   |   9 ++
  drivers/gpu/drm/radeon/evergreen.c  |  28 ++-
  drivers/gpu/drm/radeon/kv_dpm.c | 135 
++---
  drivers/gpu/drm/radeon/r600.c   |  13 +++--
  drivers/gpu/drm/radeon/radeon.h |   6 
  drivers/gpu/drm/radeon/radeon_asic.c|   1 +
  drivers/gpu/drm/radeon/radeon_device.c  |   1 +
  drivers/gpu/drm/radeon/radeon_display.c |  18 ++--
  drivers/gpu/drm/radeon/radeon_family.h  |   1 +
  drivers/gpu/drm/radeon/radeon_pm.c  |   1 +
  drivers/gpu/drm/radeon/radeon_ucode.h   |   1 +
  drivers/gpu/drm/radeon/radeon_uvd.c |   5 
  drivers/gpu/drm/radeon/radeon_vce.c |   1 +
  drivers/gpu/drm/radeon/si.c |  28 ++-
  drivers/gpu/drm/radeon/uvd_v1_0.c   |  10 +--
  include/drm/drm_pciids.h|  16 +++
  19 files changed, 399 insertions(+), 71 deletions(-)

[PATCH 0/8] Add support for Mullins and Beema

[Christian König]

I've added the patches to my 3.15 queue.

Christian.

Am 01.05.2014 00:40, schrieb Alex Deucher:
> This patch set adds support for the new Mullins and
> Beema APUs.
>
> Alex Deucher (1):
>drm/radeon: dpm updates for KV/KB
>
> Leo Liu (1):
>drm/radeon: add Mullins VCE support
>
> Samuel Li (6):
>drm/radeon: add Mullins chip family
>drm/radeon: update cik init for Mullins.
>drm/radeon: add Mullins UVD support.
>drm/radeon: add Mullins dpm support.
>drm/radeon: modesetting updates for Mullins.
>drm/radeon: add pci ids for Mullins
>
>   drivers/gpu/drm/radeon/atombios_crtc.c |   5 +-
>   drivers/gpu/drm/radeon/cik.c   |  71 +
>   drivers/gpu/drm/radeon/kv_dpm.c| 135 
> ++---
>   drivers/gpu/drm/radeon/radeon_asic.c   |   1 +
>   drivers/gpu/drm/radeon/radeon_device.c |   1 +
>   drivers/gpu/drm/radeon/radeon_family.h |   1 +
>   drivers/gpu/drm/radeon/radeon_pm.c |   1 +
>   drivers/gpu/drm/radeon/radeon_ucode.h  |   1 +
>   drivers/gpu/drm/radeon/radeon_uvd.c|   1 +
>   drivers/gpu/drm/radeon/radeon_vce.c|   1 +
>   include/drm/drm_pciids.h   |  16 
>   11 files changed, 203 insertions(+), 31 deletions(-)
>

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

--- Comment #4 from Darren Salt  ---
It appears that you do actually need mismatched builds of xserver git and
xf86-video-ati git, the latter built against (ideally) 1.15.99.902, to trigger
this kernel bug... I wonder why it's gone apparently unnoticed until now. ?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Nouveau] [PATCH v3 6/9] drm/nouveau/graph: enable when using external firmware

[Ben Skeggs]

On Thu, May 1, 2014 at 2:53 PM, Alexandre Courbot  wrote:
> On Mon, Apr 28, 2014 at 11:10 AM, Ben Skeggs  wrote:
>> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot  
>> wrote:
>>> nvc0_graph_ctor() would only let the graphics engine be enabled if its
>>> oclass has a proper microcode linked to it. This prevents GR from being
>>> enabled at all on chips that rely exclusively on external firmware, even
>>> though such a use-case is valid.
>>>
>>> Relax the conditions enabling the GR engine to also include the case
>>> where an external firmware has also been loaded.
>> I'm happy to take this patch as-is.  I do wonder if we should do
>> something like this though:
>>
>> if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", oclass->fecs.ucode == NULL))
>>
>> Which will automatically switch to external firmware if there's no
>> internal implementation available.
>>
>> Thoughts?  This could be a separate patch even, if preferred.
>
> Sure, that should work. Do you mind if I come with a follow-up patch
> for this so I don't have to re-sent the current patch series? Since
> this is the only comment it received so far.
Yeah that's fine.  I suspect I'll merge this tomorrow, assuming no
further objections are raised.

Ben.

>
> Thanks,
> Alex.

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75241

Christian K?nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #1 from Christian K?nig  ---
Thanks for the info, could you provide the debug output of 3.14 as well? I
especially need the line with radeon_compute_pll_avivo.

The problem isn't really triggered by the patch you bisected, but more an issue
of the new PLL code.

Thanks in advance,
Christian.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip

[Maarten Lankhorst]

op 01-05-14 13:58, Maarten Lankhorst schreef:
> Fixes a regression introduced by 060810d7abaabca "drm/nouveau: fix locking 
> issues in page flipping paths".
> chan->cli->mutex is unlocked a second time in the fail_unreserve path, fix 
> this by moving mutex_unlock down.
>
> Cc: stable at vger.kernel.org # v3.11+
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 24011596af43..5524a3705224 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -762,9 +762,9 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
> drm_framebuffer *fb,
>  }
>
>  ret = nouveau_page_flip_emit(chan, old_bo, new_bo, s, );
> -mutex_unlock(>cli->mutex);
>  if (ret)
>  goto fail_unreserve;
> +mutex_unlock(>cli->mutex);
>
>  /* Update the crtc struct and cleanup */
>  crtc->fb = fb;
>
I had a feeling I missed something here..

Signed-off-by: Maarten Lankhorst 

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

--- Comment #3 from Darren Salt  ---
I didn't rebuild the DDX. (May be worth doing just to see if the kernel bug is
still triggered.)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip

[Maarten Lankhorst]

Fixes a regression introduced by 060810d7abaabca "drm/nouveau: fix locking 
issues in page flipping paths".
chan->cli->mutex is unlocked a second time in the fail_unreserve path, fix this 
by moving mutex_unlock down.

Cc: stable at vger.kernel.org # v3.11+
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 24011596af43..5524a3705224 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -762,9 +762,9 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
}

ret = nouveau_page_flip_emit(chan, old_bo, new_bo, s, );
-   mutex_unlock(>cli->mutex);
if (ret)
goto fail_unreserve;
+   mutex_unlock(>cli->mutex);

/* Update the crtc struct and cleanup */
crtc->fb = fb;

[Nouveau] [PATCH v3 6/9] drm/nouveau/graph: enable when using external firmware

[Alexandre Courbot]

On Mon, Apr 28, 2014 at 11:10 AM, Ben Skeggs  wrote:
> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot  
> wrote:
>> nvc0_graph_ctor() would only let the graphics engine be enabled if its
>> oclass has a proper microcode linked to it. This prevents GR from being
>> enabled at all on chips that rely exclusively on external firmware, even
>> though such a use-case is valid.
>>
>> Relax the conditions enabling the GR engine to also include the case
>> where an external firmware has also been loaded.
> I'm happy to take this patch as-is.  I do wonder if we should do
> something like this though:
>
> if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", oclass->fecs.ucode == NULL))
>
> Which will automatically switch to external firmware if there's no
> internal implementation available.
>
> Thoughts?  This could be a separate patch even, if preferred.

Sure, that should work. Do you mind if I come with a follow-up patch
for this so I don't have to re-sent the current patch series? Since
this is the only comment it received so far.

Thanks,
Alex.

[Bug 75241] New: radeon_compute_pll_avivo broken in 3.15-rc3

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75241

Bug ID: 75241
   Summary: radeon_compute_pll_avivo broken in 3.15-rc3
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15-rc3
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: clemens at ladisch.de
Regression: Yes

After upgrading from rc2 to rc3, my RS880 no longer outputs a signal
that my monitor is able to show.

Bisected to this:

commit c2fb3094669a3205f16a32f4119d0afe40b1a1fd
Author: Christian K?nig 
Date:   Sun Apr 20 13:24:32 2014 +0200

drm/radeon: improve PLL limit handling in post div calculation

This improves the PLL parameters when we work at
the limits of the allowed ranges.


Debug output with black screen:

kernel: [drm:drm_crtc_helper_set_config] attempting to set mode from userspace
kernel: [drm:drm_mode_debug_printmodeline] Modeline 29:"1600x1200" 60 162000
1600 1664 1856 2160 1200 1201 1204 1250 0x48 0x5
kernel: [drm:radeon_encoder_set_active_device] setting active device to
0200 from 0200 0200 for encoder 2
kernel: [drm:drm_crtc_helper_set_mode] [CRTC:14]
kernel: [drm:radeon_atom_encoder_dpms] encoder dpms 21 to mode 3, devices
0001, active_devices 
kernel: [drm:radeon_compute_pll_avivo] 162000 - 161990, pll dividers - fb:
2036.3 ref: 30, post 6

With this commit reverted (and working screen):

kernel: [drm:radeon_compute_pll_avivo] 162000 - 16106, pll dividers - fb:
1023.5 ref: 13, post 7

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2 04/10] drm/nouveau/fb: add GK20A support

[Alexandre Courbot]

On Mon, Apr 28, 2014 at 8:44 PM, Thierry Reding
 wrote:
> On Wed, Apr 23, 2014 at 03:11:01PM +0900, Alexandre Courbot wrote:
>> On Wed, Apr 23, 2014 at 11:07 AM, Alexandre Courbot  
>> wrote:
>> > On 04/22/2014 07:40 PM, Thierry Reding wrote:
>> >>
>> >> * PGP Signed by an unknown key
>> >>
>> >>
>> >> On Mon, Apr 21, 2014 at 03:02:16PM +0900, Alexandre Courbot wrote:
>> >> [...]
>> >>>
>> >>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
>> >>> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
>> >>
>> >> [...]
>> >>>
>> >>> +   pages = dma_alloc_from_contiguous(dev, ncmin, order);
>> >>> +   if (!pages) {
>> >>> +   gk20a_ram_put(pfb, );
>> >>> +   return -ENOMEM;
>> >>> +   }
>> >>> +
>> >>> +   dma_addr = pfn_to_dma(nv_device_base(nv_device(pfb)),
>> >>> + page_to_pfn(pages));
>> >>
>> >>
>> >> This breaks compilation on x86 because neither pfn_to_dma() nor
>> >> dma_to_pfn() are available. Is there some other way this can be
>> >> allocated so that these functions don't need to be called?
>> >
>> >
>> > Mmm, this is bad. There is probably another more portable way to do this.
>> > Let me look for it.
>>
>> page_to_phys()/phys_to_page() can be used by drivers and will work
>> just fine here since the CPU and GPU use the same physical addresses
>> to access memory.
>
> I'm wondering how this is going to pan out when we try adding IOMMU
> support. But I guess we can cross that bridge when we come to it.

Agreed. Besides I hope the day won't come where we have to go through
2 layers of memory translation for the GPU...

[PATCH 2/2] drm/radeon: add proper support for RADEON_VM_BLOCK_SIZE

[Jerome Glisse]

On Thu, May 01, 2014 at 06:52:33PM +0200, Christian K?nig wrote:
> From: Christian K?nig 
> 
> This patch makes it possible to decide how many address
> bits are spend on the page directory vs the page tables.
> 
> Signed-off-by: Christian K?nig 

NAK on the basis you are modifying default behavior and hardware
programming in same patch see below.

> ---
>  drivers/gpu/drm/radeon/cik.c   | 1 +
>  drivers/gpu/drm/radeon/cikd.h  | 1 +
>  drivers/gpu/drm/radeon/ni.c| 1 +
>  drivers/gpu/drm/radeon/nid.h   | 1 +
>  drivers/gpu/drm/radeon/radeon.h| 2 +-
>  drivers/gpu/drm/radeon/radeon_vm.c | 4 +++-
>  drivers/gpu/drm/radeon/si.c| 1 +
>  drivers/gpu/drm/radeon/sid.h   | 1 +
>  8 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 38da9f3..f11a9ab 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -5445,6 +5445,7 @@ static int cik_pcie_gart_enable(struct radeon_device 
> *rdev)
>  (u32)(rdev->dummy_page.addr >> 12));
>   WREG32(VM_CONTEXT1_CNTL2, 4);
>   WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
> + PAGE_TABLE_BLOCK_SIZE(RADEON_VM_BLOCK_SIZE - 9) 
> |
>   RANGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
>   RANGE_PROTECTION_FAULT_ENABLE_DEFAULT |
>   DUMMY_PAGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
> diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
> index dd79263..ae88660 100644
> --- a/drivers/gpu/drm/radeon/cikd.h
> +++ b/drivers/gpu/drm/radeon/cikd.h
> @@ -482,6 +482,7 @@
>  #define  READ_PROTECTION_FAULT_ENABLE_DEFAULT(1 << 
> 16)
>  #define  WRITE_PROTECTION_FAULT_ENABLE_INTERRUPT (1 << 
> 18)
>  #define  WRITE_PROTECTION_FAULT_ENABLE_DEFAULT   (1 << 
> 19)
> +#define  PAGE_TABLE_BLOCK_SIZE(x)(((x) & 
> 0xF) << 24)
>  #define VM_CONTEXT1_CNTL 0x1414
>  #define VM_CONTEXT0_CNTL20x1430
>  #define VM_CONTEXT1_CNTL20x1434
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 5e8db9b..1d3209f 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1268,6 +1268,7 @@ static int cayman_pcie_gart_enable(struct radeon_device 
> *rdev)
>  (u32)(rdev->dummy_page.addr >> 12));
>   WREG32(VM_CONTEXT1_CNTL2, 4);
>   WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
> + PAGE_TABLE_BLOCK_SIZE(RADEON_VM_BLOCK_SIZE - 9) 
> |
>   RANGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
>   RANGE_PROTECTION_FAULT_ENABLE_DEFAULT |
>   DUMMY_PAGE_PROTECTION_FAULT_ENABLE_INTERRUPT |
> diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
> index d996033..2e12e4d 100644
> --- a/drivers/gpu/drm/radeon/nid.h
> +++ b/drivers/gpu/drm/radeon/nid.h
> @@ -128,6 +128,7 @@
>  #define  READ_PROTECTION_FAULT_ENABLE_DEFAULT(1 << 
> 16)
>  #define  WRITE_PROTECTION_FAULT_ENABLE_INTERRUPT (1 << 
> 18)
>  #define  WRITE_PROTECTION_FAULT_ENABLE_DEFAULT   (1 << 
> 19)
> +#define  PAGE_TABLE_BLOCK_SIZE(x)(((x) & 
> 0xF) << 24)
>  #define VM_CONTEXT1_CNTL 0x1414
>  #define VM_CONTEXT0_CNTL20x1430
>  #define VM_CONTEXT1_CNTL20x1434
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index e3d6be3..2d80cf2 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -838,7 +838,7 @@ struct radeon_mec {
>  /* defines number of bits in page table versus page directory,
>   * a page is 4KB so we have 12 bits offset, 9 bits in the page
>   * table and the remaining 19 bits are in the page directory */
> -#define RADEON_VM_BLOCK_SIZE   9
> +#define RADEON_VM_BLOCK_SIZE   12

I would first do a patch that add all the code to set this bit inside the
vm context registers and then a patch that change the default current
value explaining why.

This would allow bisection to either find that the register setting is
guilty or that the default value change is the one introducing problem

But really i am being picky here.

Cheers,
J?r?me

>  
>  /* number of entries in page table */
>  #define RADEON_VM_PTE_COUNT (1 << RADEON_VM_BLOCK_SIZE)
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index 6bf656e..3900ecf 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -964,6 +964,8 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev,
>  

[PATCH 1/2] drm/radeon: add large PTE support for NI, SI and CIK v4

[Jay Cornwall]

On 2014-05-01 11:52, Christian K?nig wrote:

Some minor comment fixes inline. I've been using v3 of this patch on SI 
for quite a while, with no visible failures.

Thanks for pushing this.

> From: Christian K?nig 
> 
> This patch implements support for VRAM page table entry compression.
> PTE construction is enhanced to identify physically contiguous page
> ranges and mark them in the PTE fragment field. L1 TLB and L2 cache
   ^^^
This should read L1/L2 TLB. HW spec refers to the L2 TLB as the VM L2 
"cache", which confused the draft comments.

> support is enabled for 64KB (SI/CIK) and 256KB (NI) PTE fragments,
> significantly improving TLB utilization for VRAM allocations.
> 
> Linear store bandwidth is improved from 60GB/s to 125GB/s on Pitcairn.
> Unigine Heaven 3.0 sees an average improvement from 24.7 to 27.7 FPS
> on default settings at 1920x1200 resolution with vsync disabled.
> 
> See main comment in radeon_gart.c gives a technical description.
> 
> v2 (chk): rebased and simplified.
> v3 (chk): add missing hw setup
> v4 (chk): rebased on current drm-fixes-3.15
> 
> Signed-off-by: Jay Cornwall 
> Signed-off-by: Christian K?nig 
> ---
>  drivers/gpu/drm/radeon/cik.c   |  4 +-
>  drivers/gpu/drm/radeon/ni.c|  2 +
>  drivers/gpu/drm/radeon/radeon.h|  5 +++
>  drivers/gpu/drm/radeon/radeon_vm.c | 91 
> +++---
>  drivers/gpu/drm/radeon/si.c|  5 ++-
>  5 files changed, 98 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/cik.c 
> b/drivers/gpu/drm/radeon/cik.c
> index 38f3fcc..38da9f3 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -5395,6 +5395,7 @@ static int cik_pcie_gart_enable(struct
> radeon_device *rdev)
>   WREG32(MC_VM_MX_L1_TLB_CNTL,
>  (0xA << 7) |
>  ENABLE_L1_TLB |
> +ENABLE_L1_FRAGMENT_PROCESSING |
>  SYSTEM_ACCESS_MODE_NOT_IN_SYS |
>  ENABLE_ADVANCED_DRIVER_MODEL |
>  SYSTEM_APERTURE_UNMAPPED_ACCESS_PASS_THRU);
> @@ -5407,7 +5408,8 @@ static int cik_pcie_gart_enable(struct
> radeon_device *rdev)
>  CONTEXT1_IDENTITY_ACCESS_MODE(1));
>   WREG32(VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS | INVALIDATE_L2_CACHE);
>   WREG32(VM_L2_CNTL3, L2_CACHE_BIGK_ASSOCIATIVITY |
> -L2_CACHE_BIGK_FRAGMENT_SIZE(6));
> +BANK_SELECT(4) |
> +L2_CACHE_BIGK_FRAGMENT_SIZE(4));
>   /* setup context0 */
>   WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR, rdev->mc.gtt_start >> 12);
>   WREG32(VM_CONTEXT0_PAGE_TABLE_END_ADDR, rdev->mc.gtt_end >> 12);
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index d246e04..5e8db9b 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1228,12 +1228,14 @@ static int cayman_pcie_gart_enable(struct
> radeon_device *rdev)
>  SYSTEM_APERTURE_UNMAPPED_ACCESS_PASS_THRU);
>   /* Setup L2 cache */
>   WREG32(VM_L2_CNTL, ENABLE_L2_CACHE |
> +ENABLE_L2_FRAGMENT_PROCESSING |
>  ENABLE_L2_PTE_CACHE_LRU_UPDATE_BY_WRITE |
>  ENABLE_L2_PDE0_CACHE_LRU_UPDATE_BY_WRITE |
>  EFFECTIVE_L2_QUEUE_SIZE(7) |
>  CONTEXT1_IDENTITY_ACCESS_MODE(1));
>   WREG32(VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS | INVALIDATE_L2_CACHE);
>   WREG32(VM_L2_CNTL3, L2_CACHE_BIGK_ASSOCIATIVITY |
> +BANK_SELECT(6) |
>  L2_CACHE_BIGK_FRAGMENT_SIZE(6));
>   /* setup context0 */
>   WREG32(VM_CONTEXT0_PAGE_TABLE_START_ADDR, rdev->mc.gtt_start >> 12);
> diff --git a/drivers/gpu/drm/radeon/radeon.h 
> b/drivers/gpu/drm/radeon/radeon.h
> index 6852861..e3d6be3 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -854,6 +854,11 @@ struct radeon_mec {
>  #define R600_PTE_READABLE(1 << 5)
>  #define R600_PTE_WRITEABLE   (1 << 6)
> 
> +/* PTE (Page Table Entry) fragment field for different page sizes */
> +#define R600_PTE_FRAG_4KB(0 << 7)
> +#define R600_PTE_FRAG_64KB   (4 << 7)
> +#define R600_PTE_FRAG_256KB  (6 << 7)
> +
>  struct radeon_vm_pt {
>   struct radeon_bo*bo;
>   uint64_taddr;
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index 2aae6ce..6bf656e 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -658,6 +658,84 @@ int radeon_vm_update_page_directory(struct
> radeon_device *rdev,
>  }
> 
>  /**
> + * radeon_vm_frag_ptes - add fragment information to PTEs
> + *
> + * @rdev: radeon_device pointer
> + * @ib: IB for the update
> + * @pe_start: first PTE to handle
> + * @pe_end: last PTE to handle
> + * @addr: addr those PTEs should point to
> + * @flags: hw mapping flags
> + *
> + * Global and local mutex must be locked!
> + */
> +static void radeon_vm_frag_ptes(struct 

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Russell King - ARM Linux]

On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
> 2. You replace calls of component_add and component_del with calls
> to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,  
> _component_ops),
> or interface_tracker_ifdown.
> Thats all for components.

How does the master get to decide which components are for it?  As
I see it, all masters see all components of a particular "type".
What if you have a system with two masters each of which are bound
to a set of unique components but some of the components are of a
the same type?

How does the master know what "type" to use?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

Christian K?nig  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #2 from Christian K?nig  ---
Apart from the X problem the kernel shouldn't run into a div zero error but
return -EINVAL instead when some of the parameters are invalid.

Going to take a look into that direction as well.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

--- Comment #1 from Michel D?nzer  ---
(In reply to Darren Salt from comment #0)
> I'm seeing a divide error during X startup, causing X to hang (requiring
> reboot to clear). The trigger is a commit in xserver git:
> 
> commit 4c3932620c29c91dfbbc8eb09c84efcaa7ec873e
> Author: Keith Packard 
> Date:   Fri Apr 25 08:22:15 2014 -0700
> 
> hw/xfree86: Restore API compatibility for cursor loading functions

That commit broke the Xorg video driver ABI. Did you rebuild xf86-video-ati
Git[0] when crossing this xserver Git commit?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PULL] drm-intel-next

[Dave Airlie]

> As discussed on irc this contains a (not yet fully tuned and also not yet
> in granting mode) cmd parser for gen7. Performance is still a bit rough,
> but not quite as bad as originally feared (Ken later on discovered that he
> also changed something in his glamour setup which made things worse). If
> it doesn't get better (and ofc if we don't get all the missing bits in for
> granting mode) I'll disable it before 3.16 again. But I want to give this
> beast as much testing as possible for now to avoid ugly regressions once
> we switch it on.
>
> Also please don't use the autogenerate merge commit since that'll miss the
> stuff from the 1st drm-intel-next tag.
>
> If I read the merges in -nightly correctly there's a bit a conflict in
> i915_gem_context.c. I can provide an example merge if you want (or
> otherwise just peak at linux-next or drm-intel-nightly).
>

Merged, but 32-bit still a thing,

  CC [M]  drivers/gpu/drm/i915/i915_cmd_parser.o
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c: In function
?i915_parse_cmds?:
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c:919:4:
warning: format ?%td? expects argument of type ?ptrdiff_t?, but
argument 5 has type ?long unsigned int? [-Wformat=]
DRM_DEBUG_DRIVER("CMD: Command length exceeds batch length: 0x%08X
length=%u batchlen=%td\n",
^

Dave.

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

Russell King - ARM Linux wrote, On 01.05.2014 00:28:
> On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
>> The main problem with component framework is that componentization
>> significantly changes every driver and changes it in a way which is not
>> compatible with traditional drivers, so devices which are intended to
>> work with different DRM masters are hard to componentize if some of DRMs
>> are componentized and some not.
> Many of the problems which the component helpers are designed to solve
> are those where you need the drm_device structure (or snd_card, or whatever
> subsystem specific card/device representation structure) pre-created in
> order to initialise the components.
>
> In the case of DRM, you can't initialise encoders or connectors without
> their drm_device structure pre-existing - because these components are
> attached to the drm_device.
>
> Your solution to that is to delay those calls, but the DRM subsystem is
> not designed to cope like that - it's designed such that when the
> connector or encoder initialisation functions are called, it is assumed
> that the driver is initialising its state. (I've raised this point before
> but you've just fobbed it off in the past.)
>
> Another issue here is that the order of initialisation matters greatly.
> Take CRTCs for example.  In DRM, the order of attachment of CRTCs defines
> their identity, changing the order changes their identity, and changes
> how they are bound to their respective connectors.
>
The two problems you show here are not a real problems in this framework:
1. making real device initialization during drm initialization - 
decision is left
to driver developer what should be done in probe, what should be done in
'bind', I guess this is also true for components, at least the framework 
allows it.
2. initialization order - if you put initialization into components 
'bind' function,
master can choose any order of calls to 'bind'.

Anyway you can implement the same behaviour as components with
interface_tracker. Just simple proof of concept, how to convert 
componentized
drivers to interface_tracker:
Components:
1. you can reuse component_ops
2. You replace calls of component_add and component_del with calls
to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT, 
_component_ops),
or interface_tracker_ifdown.
Thats all for components.

Master:
1. you register callback for tracking all components.
2. in the callback you check if all components are up, if yes you do the
same as in component framework initialization, to simplify it
helper function can be added.

I guess it should work the same way, if there is interest in it I can 
develop the
helper next week, I hope.

What is the benefit of interface_tracker:
1. interface_tracker is more generic - it can track not only components.
2. you put component initialization code into helper function - sounds 
like mid-layer removal,
developer can choose different helper if it suits better.

So from component point of view interface_tracker can be treated as kind 
of extensions
of the component framework.

I hope I have answerer all your concerns.

I have holidays till Sunday and I am not sure if I will be able to 
answer next emails before
Monday.

Regards
Andrzej

[RFC 1/3] atmel: drm: added drm driver for the atmel hlcd controller

[Jean-Jacques Hiblot]

Hi Boris,

On 04/28/2014 09:22 PM, Boris BREZILLON wrote:
> 
> 
> Hi,
> 
> This is a first review, from someone who's clearly not a DRM/KMS expert
> but who already thought about this specific driver :-).
> 
> I strongly recommend that you wait for DRM/KMS maintainers and/or
> experienced developers reviews before modifying anything ;-).
> 
> 
> On 18/04/2014 11:45, Jean-Jacques Hiblot wrote:
>> Signed-off-by: Jean-Jacques Hiblot 
>> ---
>>  drivers/gpu/drm/Kconfig|   2 +
>>  drivers/gpu/drm/Makefile   |   1 +
>>  drivers/gpu/drm/atmel_hlcdc/Kconfig|  13 +
>>  drivers/gpu/drm/atmel_hlcdc/Makefile   |  12 +
>>  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc.h  | 771 
>> +
>>  .../gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.c|  92 +++
>>  .../gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.h|  25 +
>>  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c | 702 +++
>>  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.c  | 586 
>>  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.h  | 124 
>>  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_ovl.h  | 190 +
>>  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.c| 459 
>>  drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.h|  28 +
>>  13 files changed, 3005 insertions(+)
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/Kconfig
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/Makefile
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc.h
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.c
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_backlight.h
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.c
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_drv.h
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_ovl.h
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.c
>>  create mode 100644 drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_panel.h
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 8e7fa4d..13fec638 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -190,6 +190,8 @@ source "drivers/gpu/drm/omapdrm/Kconfig"
>>  
>>  source "drivers/gpu/drm/tilcdc/Kconfig"
>>  
>> +source "drivers/gpu/drm/atmel_hlcdc/Kconfig"
>> +
>>  source "drivers/gpu/drm/qxl/Kconfig"
>>  
>>  source "drivers/gpu/drm/bochs/Kconfig"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 292a79d..8245aa5 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -57,6 +57,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
>>  obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
>>  obj-$(CONFIG_DRM_OMAP)  += omapdrm/
>>  obj-$(CONFIG_DRM_TILCDC)+= tilcdc/
>> +obj-$(CONFIG_DRM_ATMEL_HLCDC)   += atmel_hlcdc/
>>  obj-$(CONFIG_DRM_QXL) += qxl/
>>  obj-$(CONFIG_DRM_BOCHS) += bochs/
>>  obj-$(CONFIG_DRM_MSM) += msm/
>> diff --git a/drivers/gpu/drm/atmel_hlcdc/Kconfig 
>> b/drivers/gpu/drm/atmel_hlcdc/Kconfig
>> new file mode 100644
>> index 000..6ee5989
>> --- /dev/null
>> +++ b/drivers/gpu/drm/atmel_hlcdc/Kconfig
>> @@ -0,0 +1,13 @@
>> +config DRM_ATMEL_HLCDC
>> +tristate "DRM Support for ATMEL HLCDC Display Controller"
>> +depends on DRM && OF && ARM
>> +select DRM_KMS_HELPER
>> +select DRM_KMS_FB_HELPER
>> +select DRM_KMS_CMA_HELPER
>> +select DRM_GEM_CMA_HELPER
>> +select VIDEOMODE_HELPERS
>> +select BACKLIGHT_CLASS_DEVICE
>> +select BACKLIGHT_LCD_SUPPORT
>> +help
>> +  Choose this option if you have an ATMEL SoC with HLCDC display
>> +  controller, for example SAMA5D36EK.
>> diff --git a/drivers/gpu/drm/atmel_hlcdc/Makefile 
>> b/drivers/gpu/drm/atmel_hlcdc/Makefile
>> new file mode 100644
>> index 000..4935c36
>> --- /dev/null
>> +++ b/drivers/gpu/drm/atmel_hlcdc/Makefile
>> @@ -0,0 +1,12 @@
>> +ccflags-y := -Iinclude/drm
>> +ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
>> +ccflags-y += -Werror
>> +endif
>> +
>> +atmel_hlcdc-y := \
>> +atmel_hlcdc_crtc.o \
>> +atmel_hlcdc_panel.o \
>> +atmel_hlcdc_backlight.o \
>> +atmel_hlcdc_drv.o
>> +
>> +obj-$(CONFIG_DRM_ATMEL_HLCDC)   += atmel_hlcdc.o
>> diff --git a/drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc.h 
>> b/drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc.h
>> new file mode 100644
>> index 000..8ed0767
>> --- /dev/null
>> +++ b/drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc.h
>> @@ -0,0 +1,771 @@
>> +/*
>> + *  Header file for AT91 High end LCD Controller
>> + *
>> + *  Data structure and register user interface
>> + *
>> + *  Copyright (C) 2010 Atmel Corporation
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + 

[RFC 0/2] drm/bridge: panel and chaining

[Ajay kumar]

e other
> >> thread (which I haven't been following).
> >>
> >> Sean
> >>
> >>
> >>
> >> >
> >> >
> >> > Rob Clark (2):
> >> >   drm/bridge: add composite and panel bridges
> >> >   drm/bridge/ptn3460: add panel support
> >> >
> >> >  drivers/gpu/drm/bridge/Makefile  |   2 +
> >> >  drivers/gpu/drm/bridge/drm_bridge_util.c | 251
> +++
> >> >  drivers/gpu/drm/bridge/drm_bridge_util.h |  29 
> >> >  drivers/gpu/drm/bridge/ptn3460.c |  39 -
> >> >  include/drm/bridge/ptn3460.h |   6 +-
> >> >  5 files changed, 319 insertions(+), 8 deletions(-)
> >> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.c
> >> >  create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h
> >> >
> >> > --
> >> > 1.9.0
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org <javascript:;>
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140501/df78f2fe/attachment-0001.html>

[Bug 75211] New: Division error in radeon_compute_pll_avivo (X hang)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=75211

Bug ID: 75211
   Summary: Division error in radeon_compute_pll_avivo (X hang)
   Product: Drivers
   Version: 2.5
Kernel Version: 3.15-rc3
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: bugspam at moreofthesa.me.uk
Regression: No

I'm seeing a divide error during X startup, causing X to hang (requiring reboot
to clear). The trigger is a commit in xserver git:

commit 4c3932620c29c91dfbbc8eb09c84efcaa7ec873e
Author: Keith Packard 
Date:   Fri Apr 25 08:22:15 2014 -0700

hw/xfree86: Restore API compatibility for cursor loading functions

The effect is this:

divide error:  [#1] PREEMPT SMP 
Modules linked in: [...]
CPU: 0 PID: 6579 Comm: Xorg Not tainted 3.15.0-rc3 #2
Hardware name: Gigabyte Technology Co., Ltd. GA-870A-UD3/GA-870A-UD3, BIOS F5
08/01/2011
task: 8800b12d1850 ti: 88021b08e000 task.ti: 88021b08e000
RIP: 0010:[]  []
radeon_compute_pll_avivo+0xb6/0x324
RSP: 0018:88021b08fa08  EFLAGS: 00010246
RAX: 000927c0 RBX: 880236dc8210 RCX: 00124f80
RDX:  RSI: 000927c0 RDI: 0400
RBP: 8800bd6d2c00 R08: 88021b08fb08 R09: 88021b08fb00
R10:  R11:  R12: 880236dc8000
R13:  R14: 4ff6 R15: 03ff
FS:  7f39298d1980() GS:88023fc0() knlGS:e7063b40
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f392a5d3000 CR3: 00021b00b000 CR4: 07f0
Stack:
 cf370004 88021b08fa88 0028 88021b08fb04
  0002 88021b08fafc cf0c
 88021b08fb00 81227da9 001e0004 8802364e6c00
Call Trace:
 [] ? drm_detect_hdmi_monitor+0x54/0x69
 [] ? atombios_crtc_mode_set+0x100/0x593
 [] ? class_dev_iter_next+0xc/0x33
 [] ? class_for_each_device+0x8a/0x9f
 [] ? drm_crtc_helper_set_mode+0x2a3/0x424
 [] ? drm_crtc_helper_set_config+0x601/0x853
 [] ? radeon_crtc_set_config+0x3e/0xd9
 [] ? drm_mode_set_config_internal+0x48/0xc0
 [] ? drm_mode_setcrtc+0x3d3/0x487
 [] ? radeon_crtc_load_lut+0x275/0x630
 [] ? drm_ioctl+0x337/0x3a6
 [] ? drm_mode_setplane+0x325/0x325
 [] ? _raw_spin_unlock_irqrestore+0xf/0x21
 [] ? radeon_drm_ioctl+0x42/0x6e
 [] ? do_vfs_ioctl+0x356/0x420
 [] ? __fget+0x64/0x6c
 [] ? SyS_ioctl+0x33/0x58
 [] ? system_call_fastpath+0x1a/0x1f
Code: 09 8b 6b 08 89 6c 24 20 eb 5f 80 e5 20 74 08 8b 73 1c 8b 4b 20 eb 06 8b
73 14 8b 4b 18 85 ff 74 06 6b f6 0a 6b c9 0a 31 d2 89 f0 <41> f7 f5 89 c2 8d 68
01 41 0f af d5 39 f2 8b 53 30 0f 43 e8 89 
RIP  [] radeon_compute_pll_avivo+0xb6/0x324
 RSP 

Graphics card is R7 260X; two monitors (both 1080p) are attached, one via
HDMI-0 and one via DVI-0 (as reported by xrandr). It may be relevant that as
part of my user-specific X startup scripts, the HDMI-attached monitor (AOC
I2367F) has its frame rate set to 50Hz.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 0/2] libdrm_radeon support for Mullins

[Marek Olšák]

For the series:

Reviewed-by: Marek Ol??k 

Marek

On Thu, May 1, 2014 at 12:44 AM, Alex Deucher  wrote:
> This adds support for the new Mullins and Beema APUs.
>
> Samuel Li (2):
>   radeon: add Mullins chip family
>   radeon: add Mullins pci ids
>
>  radeon/r600_pci_ids.h   | 17 +
>  radeon/radeon_surface.c |  1 +
>  2 files changed, 18 insertions(+)
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] clk: exynos4: export sclk_hdmiphy clock

[Tomasz Figa]

On 04.04.2014 16:53, Tomasz Stanislawski wrote:
> Export sclk_hdmiphy clock to be usable from DT.
>
> Signed-off-by: Tomasz Stanislawski 
> ---
>   drivers/clk/samsung/clk-exynos4.c   |2 +-
>   include/dt-bindings/clock/exynos4.h |1 +
>   2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos4.c 
> b/drivers/clk/samsung/clk-exynos4.c
> index b4f9672..528f8eb 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -428,7 +428,7 @@ static struct samsung_fixed_rate_clock 
> exynos4_fixed_rate_ext_clks[] __initdata
>   /* fixed rate clocks generated inside the soc */
>   static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata 
> = {
>   FRATE(0, "sclk_hdmi24m", NULL, CLK_IS_ROOT, 2400),
> - FRATE(0, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2700),
> + FRATE(CLK_SCLK_HDMIPHY, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2700),
>   FRATE(0, "sclk_usbphy0", NULL, CLK_IS_ROOT, 4800),
>   };
>
> diff --git a/include/dt-bindings/clock/exynos4.h 
> b/include/dt-bindings/clock/exynos4.h
> index 75aff33..0e245eb 100644
> --- a/include/dt-bindings/clock/exynos4.h
> +++ b/include/dt-bindings/clock/exynos4.h
> @@ -33,6 +33,7 @@
>   #define CLK_MOUT_MPLL_USER_C18 /* Exynos4x12 only */
>   #define CLK_MOUT_CORE   19
>   #define CLK_MOUT_APLL   20
> +#define CLK_SCLK_HDMIPHY 22
>
>   /* gate for special clocks (sclk) */
>   #define CLK_SCLK_FIMC0  128
>

Applied.

Best regards,
Tomasz

[PATCH 1/4] clk: propagate parent change up one level

[Tomasz Figa]

Mike,

On 08.04.2014 17:45, Tomasz Figa wrote:
> Hi,
>
> On 04.04.2014 16:53, Tomasz Stanislawski wrote:
>> This patch adds support for propagation of setup of clock's parent one
>> level
>> up.
>>
>> This feature is helpful when a driver changes topology of its clocks
>> using
>> clk_set_parent().  The problem occurs when on one platform/SoC
>> driver's clock
>> is located at MUX output but on the other platform/SoC there is a
>> gated proxy
>> clock between the MUX and driver's clock.  In such a case, driver's
>> code has to
>> be modified to use one clock for enabling and the other clock for
>> setup of a
>> parent.
>>
>> The code updates are avoided by propagating setup of a parent up one
>> level.
>>
>> Additionally, this patch adds CLK_SET_PARENT_PARENT (sorry for naming)
>> flag to
>> inform clk-core that clk_set_parent() should be propagated.
>>
>> Signed-off-by: Tomasz Stanislawski 
>> ---
>>   drivers/clk/clk.c|6 ++
>>   include/linux/clk-provider.h |1 +
>>   2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index dff0373..53bbfda 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1737,6 +1737,12 @@ int clk_set_parent(struct clk *clk, struct clk
>> *parent)
>>
>>   /* try finding the new parent index */
>>   if (parent) {
>> +if ((clk->flags & CLK_SET_PARENT_PARENT)
>> +&& clk->num_parents == 1) {
>> +ret = clk_set_parent(clk->parent, parent);
>> +goto out;
>> +}
>> +
>>   p_index = clk_fetch_parent_index(clk, parent);
>>   p_rate = parent->rate;
>>   if (p_index < 0) {
>> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
>> index 5119174..daa0b03 100644
>> --- a/include/linux/clk-provider.h
>> +++ b/include/linux/clk-provider.h
>> @@ -30,6 +30,7 @@
>>   #define CLK_GET_RATE_NOCACHEBIT(6) /* do not use the cached clk
>> rate */
>>   #define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate
>> change */
>>   #define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk
>> accuracy */
>> +#define CLK_SET_PARENT_PARENTBIT(9) /* propagate parent change up
>> one level */
>>
>>   struct clk_hw;
>>   struct dentry;
>>
>
> This would be very useful, at least on Exynos platforms, with
> mux-div-gate clock paths. PARENT_PARENT sounds a bit funny, though.
>
> Reviewed-by: Tomasz Figa 

Your opinion on this would be greatly appreciated.

Best regards,
Tomasz

[RFC 0/5] drm/tegra: Convert to master/component framework

[Thierry Reding]

On Tue, Apr 22, 2014 at 05:09:28PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Hi,
> 
> This series converts the Tegra DRM driver to the master/component
> framework. The length of the series and the list of people in Cc is
> mostly due to the fact that Tegra has some special requirements as
> opposed to other drivers and therefore requires some changes outside
> of DRM.
> 
> Patches 1 and 2 make some changes to the master/component framework
> which are necessary to convert Tegra DRM to use it. Note that since I'm
> looking for early review I haven't converted any of the existing users
> since I'm not sure if these are acceptable changes.
> 
> Patch 3 adds a new interface framework that supplements the master/
> component framework and can be used in situations where there is no
> struct device * that a driver can bind to.
> 
> A new function is introduced in patch 4 which can be used to get rid of
> the DRM bus infrastructure in individual drivers. It should be able to
> replace the requirement of having a drm_bus for all USB and platform
> DRM drivers. For backwards-compatibility with legacy PCI drivers some-
> thing different will probably be needed.
> 
> Finally, patch 5 converts the Tegra DRM driver over to using the master/
> component framework using the above four patches.
> 
> Each patch has a somewhat more elaborate description of why it is needed
> or what problem it solves. The patchset applies on top of linux-next
> with Daniel's DRM cleanup series applied.
> 
> I welcome any questions or comments you might have.
> 
> Thierry
> 
> Thierry Reding (5):
>   drivers/base: Allow multiple masters per device
>   drivers/base: Allow driver-data to be attached to a master
>   drivers/base: Add interface framework
>   drm: Introduce drm_set_unique()
>   drm/tegra: Convert to master/component framework

Ping. Anyone?

Thierry

>  drivers/base/Makefile  |   2 +-
>  drivers/base/component.c   |  31 ++-
>  drivers/base/interface.c   | 186 ++
>  drivers/gpu/drm/drm_ioctl.c|  37 ++-
>  drivers/gpu/drm/drm_stub.c |   1 +
>  drivers/gpu/drm/tegra/Makefile |   1 -
>  drivers/gpu/drm/tegra/bus.c|  64 -
>  drivers/gpu/drm/tegra/dc.c |  58 ++---
>  drivers/gpu/drm/tegra/drm.c| 171 +
>  drivers/gpu/drm/tegra/drm.h|  27 +-
>  drivers/gpu/drm/tegra/dsi.c| 144 +--
>  drivers/gpu/drm/tegra/gr2d.c   |  78 +++---
>  drivers/gpu/drm/tegra/gr3d.c   |  77 +++---
>  drivers/gpu/drm/tegra/hdmi.c   |  69 ++---
>  drivers/gpu/drm/tegra/sor.c|  71 ++
>  drivers/gpu/host1x/Makefile|   1 -
>  drivers/gpu/host1x/bus.c   | 553 
> -
>  drivers/gpu/host1x/bus.h   |  29 ---
>  drivers/gpu/host1x/dev.c   |  21 +-
>  drivers/gpu/host1x/dev.h   |   7 +-
>  include/drm/drmP.h |   3 +
>  include/linux/component.h  |  20 +-
>  include/linux/host1x.h |  64 +
>  include/linux/interface.h  |  40 +++
>  24 files changed, 625 insertions(+), 1130 deletions(-)
>  create mode 100644 drivers/base/interface.c
>  delete mode 100644 drivers/gpu/drm/tegra/bus.c
>  delete mode 100644 drivers/gpu/host1x/bus.c
>  delete mode 100644 drivers/gpu/host1x/bus.h
>  create mode 100644 include/linux/interface.h
> 
> -- 
> 1.9.2
> 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140501/4c447241/attachment.sig>

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Andrzej Hajda]

Hi Greg,

Thanks for comments. I CC Laurent, I hope it could be interesting for 
him also.

Greg Kroah-Hartman wrote, On 30.04.2014 17:49:
> On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote:
>> Generic framework for tracking internal interfaces
>> ==
>>
>> Summary
>> ---
>>
>> interface_tracker is a generic framework which allows to track appearance
>> and disappearance of different interfaces provided by kernel/driver code 
>> inside
>> the kernel. Examples of such interfaces: clocks, phys, regulators, 
>> drm_panel...
>> Interface is specified by a pair of object pointer and interface type. Object
>> type depends on interface type, for example interface type drm_panel 
>> determines
>> that object is a device_node. Object pointer is used to distinguish different
>> interfaces of the same type and should identify object the interface is 
>> bound to.
>> For example it could be DT node, struct device,...
>>
>> The framework provides two functions for interface providers which should be
>> called just after interface becomes available or just before interface
>> removal. Interface consumers can register callback which will be called
>> when requested interface changes its state, if during callback registration
>> the interface is already up, notification will be sent also.
>>
>> The framework allows nesting calls, for example it is possible to signal one
>> interface in tracker callback of another interface. It is done by putting
>> every request into the queue. If the queue is empty before adding
>> the request, the queue will be processed after, if there is already another
>> request in the queue it means the queue is already processed by different
>> thread so no additional action is required. With this pattern only spinlock
>> is necessary to protect the queue. However in case of removal of either
>> callback or interface caller should be sure that his request has been
>> processed so framework waits until the queue becomes empty, it is done using
>> completion mechanism.
>>
>> The framework functions should not be called in atomic context. Callbacks
>> should be aware that they can be called in any time between registration and
>> de-registration, so they should use synchronization mechanisms carefully.
>> Callbacks should also avoid to perform time consuming tasks, the framework
>> serializes them, so it could stall other callbacks.
>>
>> Use cases
>> -
>>
>> The interface is very generic, there are many situations it can be useful:
>>
>> 1. Replacement for subsystem specific methods of publishing/unpublishing
>> interfaces. Currently many frameworks allows only querying for presence of 
>> given
>> interface. In such cases client can defer probing or implement interface
>> polling, which is usually subobtimal. Additionally subsystems often do not
>> provide methods to signal to the consumers that they are about to be 
>> destroyed.
>>
>> 2. Monitoring for different interfaces provided by the same object. An 
>> example
>> should explain it better. Lets assume in device tree drm crtc device node 
>> have
>> video link to another node, so it knows only that there is something 
>> connected
>> to its RGB output. It can be a RGB panel (drm_panel framework), it can be an
>> image enhancer (SoC specific framework) or it can be some signal converter
>> (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to
>> another node. Currently it is difficult to handle such situations in a 
>> generic
>> way. interface_tracker should make it simple: crtc should monitor all 
>> supported
>> interface types that appears at the device_node pointed by the phandle.
>>
>> Potential use cases
>> ---
>>
>> Points mentioned above were the reasons for writing this framework. During
>> development I have realized that this framework can be also useful for other
>> tasks.
>>
>> 3. Replacement for deferred probing - if for some reason driver do not wants 
>> to
>> defer but it requires given resources it can use interface_tracker. It 
>> should be
>> possible to create an helper which will wait for appearance of all interfaces
>> from a given list, and 'continue' probe only when all resources becomes
>> available.
>>
>> 4. Replacement or helper for subsystem specific solutions:
>> - V4L2 subdev async registration,
>> - component framework.
>> Both frameworks solves a problem of tracking sub-components (un-)registration
>> by master device, it should be possible to do the same with interface_tracker
>> framework. Some additional helpers can be convienent to make the 
>> implementation
>> easier.
>>
>> 5. Cure the situation with sysfs 'unbind' property. Currently many drivers 
>> are
>> providers of different resources/interfaces: regulators, clocks, phys,
>> V4L2 subdevs, ... They are usually protected from module unloading by getting
>> module reference, but there is no protection from driver unbinding using 
>> sysfs
>> 

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

[Russell King - ARM Linux]

On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
> The main problem with component framework is that componentization  
> significantly changes every driver and changes it in a way which is not  
> compatible with traditional drivers, so devices which are intended to  
> work with different DRM masters are hard to componentize if some of DRMs  
> are componentized and some not.

Many of the problems which the component helpers are designed to solve
are those where you need the drm_device structure (or snd_card, or whatever
subsystem specific card/device representation structure) pre-created in
order to initialise the components.

In the case of DRM, you can't initialise encoders or connectors without
their drm_device structure pre-existing - because these components are
attached to the drm_device.

Your solution to that is to delay those calls, but the DRM subsystem is
not designed to cope like that - it's designed such that when the
connector or encoder initialisation functions are called, it is assumed
that the driver is initialising its state. (I've raised this point before
but you've just fobbed it off in the past.)

Another issue here is that the order of initialisation matters greatly.
Take CRTCs for example.  In DRM, the order of attachment of CRTCs defines
their identity, changing the order changes their identity, and changes
how they are bound to their respective connectors.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.