[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

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

--- Comment #6 from Andy Furniss  ---
Created attachment 109744
  --> https://bugs.freedesktop.org/attachment.cgi?id=109744=edit
kernel log with new oops at end

-- 
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/20141119/04a42fdc/attachment.html>

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

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

--- Comment #5 from Andy Furniss  ---
This bug is still alive for me.

Have randomly tested and reproduced since reporting and failed to reproduce
with 

6327b584155d040ae089e65fd6747186bdd9666b reverted.

Just retried with the new agd5f drm-next-319-wip and it's still there - though
this time I got and oops which mentions radeon/ttm so uploading.

To produce I am running a script running mplayer on various blu-rays on hard
disk.

It's not aggressive - run for 10 sec sleep for three 

I added a counter and it got up to 29 before oopsing.

-- 
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/20141119/76e67f07/attachment.html>

[Bug 31532] [RADEON:KMS:RV670:AGP:R600C-R600G] PCIE gart stalls

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

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

Andy Furniss  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Andy Furniss  ---
This is ancient and my AGP box is long dead so no point leaving it open.

-- 
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/20141119/bdf30d13/attachment.html>

[RFC PATCH 1/3] drm/exynos: make kms drivers to be independent modules

[Inki Dae]

2014-11-19 17:49 GMT+09:00 Andrzej Hajda :
> On 11/18/2014 04:26 PM, Inki Dae wrote:
>> This patch makes kms drivers to be independent modules.
>> For this, it removes all register codes to kms drivers
>> from exynos_drm_drv module and adds module_init/exit
>> for each kms driver so that each kms driver can be
>> called independently.
>
>
> It is hard to test if modules are working because I am not able to build
> modules :), see comments below.
>
>
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/Kconfig   |8 +++---
>>  drivers/gpu/drm/exynos/exynos_dp_core.c  |   13 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
>> +++---
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 +
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   13 +
>>  drivers/gpu/drm/exynos/exynos_hdmi.c |   13 +
>>  drivers/gpu/drm/exynos/exynos_mixer.c|   13 +
>>  8 files changed, 72 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
>> index 7f9f6f9..3d5fa69 100644
>> --- a/drivers/gpu/drm/exynos/Kconfig
>> +++ b/drivers/gpu/drm/exynos/Kconfig
>> @@ -25,7 +25,7 @@ config DRM_EXYNOS_DMABUF
>> Choose this option if you want to use DMABUF feature for DRM.
>>
>>  config DRM_EXYNOS_FIMD
>> - bool "Exynos DRM FIMD"
>> + tristate "Exynos DRM FIMD"
>>   depends on DRM_EXYNOS && !FB_S3C
>>   select FB_MODE_HELPERS
>>   select MFD_SYSCON
>> @@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI
>> This enables support for Exynos parallel output.
>>
>>  config DRM_EXYNOS_DSI
>> - bool "EXYNOS DRM MIPI-DSI driver support"
>> + tristate "EXYNOS DRM MIPI-DSI driver support"
>>   depends on DRM_EXYNOS_FIMD
>>   select DRM_MIPI_DSI
>>   select DRM_PANEL
>> @@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI
>> This enables support for Exynos MIPI-DSI device.
>>
>>  config DRM_EXYNOS_DP
>> - bool "EXYNOS DRM DP driver support"
>> + tristate "EXYNOS DRM DP driver support"
>>   depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || 
>> DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
>>   default DRM_EXYNOS
>>   select DRM_PANEL
>> @@ -58,7 +58,7 @@ config DRM_EXYNOS_DP
>> This enables support for DP device.
>>
>>  config DRM_EXYNOS_HDMI
>> - bool "Exynos DRM HDMI"
>> + tristate "Exynos DRM HDMI"
>>   depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_TV
>>   help
>> Choose this option if you want to use Exynos HDMI for DRM.
>
>
> Without corresponding changes in Makefiles you cannot build it as modules.
>
>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index ed818b9..b08d97b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1408,6 +1408,19 @@ struct platform_driver dp_driver = {
>>   },
>>  };
>>
>> +static int exynos_dp_init(void)
>> +{
>> + return platform_driver_register(_driver);
>> +}
>> +
>> +static void exynos_dp_exit(void)
>> +{
>> + platform_driver_unregister(_driver);
>> +}
>> +
>> +module_init(exynos_dp_init);
>> +module_exit(exynos_dp_exit);
>> +
>
> Here and in other modules you can use module_platform_driver macro.
>
>>  MODULE_AUTHOR("Jingoo Han ");
>>  MODULE_DESCRIPTION("Samsung SoC DP Driver");
>>  MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index eab12f0..02d4772 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -484,12 +484,6 @@ static struct component_match 
>> *exynos_drm_match_add(struct device *dev)
>>
>>   mutex_lock(_component_lock);
>>
>> - /* Do not retry to probe if there is no any kms driver regitered. */
>> - if (list_empty(_component_list)) {
>> - mutex_unlock(_component_lock);
>> - return ERR_PTR(-ENODEV);
>> - }
>> -
>
> It is hard to guess how and why it should work with modules.
> For example what should happen if fimd/dsi modules are loaded but
> hdmi/mixer not. When exynos_drv should wait with initialization for hdmi

Right, hdmi/mixer cannot be probed, which means module doesn't work correctly.

> and when it should create drmdev.
>
> DRM system is rather monolithic splitting its components to modules
> seems strange.

Yes, good point. I missed a big point that DRM system should be
monolithic, integrated driver.
However I strongly think it's better to separate them into independent
drivers so that entry point of each sub driver can be called itself.
With this, the probe order of each sub driver can be handled by
component and Exynos drm core properly. it's really not good for all
register codes of sub drivers to be placed in exynos_drm_drv,
and this was my plan for cleanning up Exynos drm long 

[PATCH 6/6] drm/atomic_helper: Make it clear that commit_planes gets the old state

[Daniel Vetter]

On Wed, Nov 19, 2014 at 03:29:30PM -0500, Rob Clark wrote:
> On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter  
> wrote:
> > Oversight from my kerneldoc cleanup when doing the original atomic
> > helper series - I've only applied this clarification to the modeset
> > related helpers, and not the plane update code. Remedy this asap.
> >
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Rob Clark 

Thanks for the review. I've pulled them into my drm patch pile branch and
will send a pull request to Dave in a few days.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[radeonsi, regression, bisected] All my Steam games fail to load into the 3D-engine-powered part (SIGPWR and SIGXCPU)

[Kai Wasserbäch]

rm] ring test on 0 succeeded in 3 usecs
[   35.322445] [drm] ring test on 1 succeeded in 3 usecs
[   35.322465] [drm] ring test on 2 succeeded in 3 usecs
[   35.322605] [drm] ring test on 3 succeeded in 4 usecs
[   35.322614] [drm] ring test on 4 succeeded in 4 usecs
[   35.368313] [drm] ring test on 5 succeeded in 2 usecs
[   35.388178] [drm] UVD initialized successfully.
[   35.497411] [drm] ring test on 6 succeeded in 23 usecs
[   35.497420] [drm] ring test on 7 succeeded in 3 usecs
[   35.497421] [drm] VCE initialized successfully.
[   35.499507] [drm] ib test on ring 0 succeeded in 0 usecs
[   35.499641] [drm] ib test on ring 1 succeeded in 0 usecs
[   35.499775] [drm] ib test on ring 2 succeeded in 0 usecs
[   35.499909] [drm] ib test on ring 3 succeeded in 0 usecs
[   35.500042] [drm] ib test on ring 4 succeeded in 0 usecs
[   36.018648] [drm] ib test on ring 5 succeeded
[   36.039436] [drm] ib test on ring 6 succeeded
[   36.040242] [drm] ib test on ring 7 succeeded
[   36.041280] [drm] Radeon Display Connectors
[   36.041283] [drm] Connector 0:
[   36.041284] [drm]   DP-1
[   36.041285] [drm]   HPD2
[   36.041288] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 
0x653c
[   36.041289] [drm]   Encoders:
[   36.041290] [drm] DFP1: INTERNAL_UNIPHY2
[   36.041292] [drm] Connector 1:
[   36.041293] [drm]   HDMI-A-1
[   36.041294] [drm]   HPD3
[   36.041296] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 
0x655c
[   36.041297] [drm]   Encoders:
[   36.041299] [drm] DFP2: INTERNAL_UNIPHY2
[   36.041300] [drm] Connector 2:
[   36.041301] [drm]   DVI-D-1
[   36.041302] [drm]   HPD1
[   36.041304] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 
0x656c
[   36.041305] [drm]   Encoders:
[   36.041307] [drm] DFP3: INTERNAL_UNIPHY1
[   36.041308] [drm] Connector 3:
[   36.041309] [drm]   DVI-D-2
[   36.041310] [drm]   HPD6
[   36.041312] [drm]   DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 
0x658c
[   36.041313] [drm]   Encoders:
[   36.041315] [drm] DFP4: INTERNAL_UNIPHY
[   36.041505] switching from power state:
[   36.041506]  ui class: none
[   36.041508]  internal class: boot
[   36.041510]  caps:
[   36.041512]  uvdvclk: 0 dclk: 0
[   36.041514]  power level 0sclk: 3 mclk: 15000 pcie gen: 3
pcie lanes: 16
[   36.041515]  status: c b
[   36.041518] switching to power state:
[   36.041519]  ui class: performance
[   36.041520]  internal class: none
[   36.041522]  caps:
[   36.041523]  uvdvclk: 0 dclk: 0
[   36.041525]  power level 0sclk: 3 mclk: 15000 pcie gen: 3
pcie lanes: 16
[   36.041527]  power level 1sclk: 98000 mclk: 125000 pcie gen: 3
pcie lanes: 16
[   36.041528]  status: r
[   36.117075] [drm] fb mappable at 0xE098F000
[   36.117078] [drm] vram apper at 0xE000
[   36.117079] [drm] size 14745600
[   36.117080] [drm] fb depth is 24
[   36.117081] [drm]pitch is 10240
[   36.117225] fbcon: radeondrmfb (fb0) is primary device
[   36.117321] switching from power state:
[   36.117322]  ui class: performance
[   36.117323]  internal class: none
[   36.117323]  caps:
[   36.117324]  uvdvclk: 0 dclk: 0
[   36.117325]  power level 0sclk: 3 mclk: 15000 pcie gen: 3
pcie lanes: 16
[   36.117326]  power level 1sclk: 98000 mclk: 125000 pcie gen: 3
pcie lanes: 16
[   36.117326]  status: c r
[   36.117327] switching to power state:
[   36.117327]  ui class: performance
[   36.117328]  internal class: none
[   36.117328]  caps:
[   36.117329]  uvdvclk: 0 dclk: 0
[   36.117329]  power level 0sclk: 3 mclk: 15000 pcie gen: 3
pcie lanes: 16
[   36.117330]  power level 1sclk: 98000 mclk: 125000 pcie gen: 3
pcie lanes: 16
[   36.117331]  status: c r
[   36.144422] Console: switching to colour frame buffer device 320x90
[   36.153721] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[   36.153722] radeon :01:00.0: registered panic notifier
[   36.165392] [drm] Initialized radeon 2.40.0 20080528 for :01:00.0 on 
minor 0

Let me know, if you need something else.

Cheers,
Kai

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/9123b53b/attachment.sig>

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

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

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

Daniel Otero  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #8 from Daniel Otero  ---
Applying the patch of Alex's commit solved the issue.

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

[PATCH 01/11] drm/radeon: rework vm_flush parameters

[Kai Wasserbäch]

Christian König wrote on 19.11.2014 20:40:
> Am 19.11.2014 um 19:28 schrieb Alex Deucher:
>> On Wed, Nov 19, 2014 at 8:01 AM, Christian König
>>  wrote:
>>> From: Christian König 
>>>
>>> Use ring structure instead of index and provide vm_id and pd_addr 
>>> separately.
>>>
>>> Signed-off-by: Christian König 
>> Pushed to my 3.19-wip tree.  I'll send out a new radeon drm-next pull
>> request later today or tomorrow.
> 
> Please note that I had to fix another bug in the last patch pointed out by Kai
> Wasserbäch.
> 
> The updated patch should already be in your inbox.

Everything is fine, I'm seeing v4 on Alex's tree
(<http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.19-wip=219af8ca826344a136f0be43ff2bcc5d33e5ddc6>).

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/1f735e44/attachment-0001.sig>

[PATCH 01/11] drm/radeon: rework vm_flush parameters

[Christian König]

Am 19.11.2014 um 19:28 schrieb Alex Deucher:
> On Wed, Nov 19, 2014 at 8:01 AM, Christian König
>  wrote:
>> From: Christian König 
>>
>> Use ring structure instead of index and provide vm_id and pd_addr separately.
>>
>> Signed-off-by: Christian König 
> Pushed to my 3.19-wip tree.  I'll send out a new radeon drm-next pull
> request later today or tomorrow.

Please note that I had to fix another bug in the last patch pointed out 
by Kai Wasserbäch.

The updated patch should already be in your inbox.

Christian.

>
> Alex
>
>> ---
>>   drivers/gpu/drm/radeon/cik.c | 23 ++-
>>   drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
>>   drivers/gpu/drm/radeon/ni.c  | 14 +-
>>   drivers/gpu/drm/radeon/ni_dma.c  | 14 +-
>>   drivers/gpu/drm/radeon/radeon.h  |  5 +++--
>>   drivers/gpu/drm/radeon/radeon_asic.h | 18 --
>>   drivers/gpu/drm/radeon/radeon_vm.c   |  3 ++-
>>   drivers/gpu/drm/radeon/si.c  | 18 +++---
>>   drivers/gpu/drm/radeon/si_dma.c  | 19 ---
>>   9 files changed, 61 insertions(+), 75 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 57a359d..d52ead9 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -5967,26 +5967,23 @@ static void cik_vm_decode_fault(struct radeon_device 
>> *rdev,
>>* Update the page table base and flush the VM TLB
>>* using the CP (CIK).
>>*/
>> -void cik_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm 
>> *vm)
>> +void cik_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
>> + unsigned vm_id, uint64_t pd_addr)
>>   {
>> -   struct radeon_ring *ring = >ring[ridx];
>> -   int usepfp = (ridx == RADEON_RING_TYPE_GFX_INDEX);
>> -
>> -   if (vm == NULL)
>> -   return;
>> +   int usepfp = (ring->idx == RADEON_RING_TYPE_GFX_INDEX);
>>
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
>>  radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
>>   WRITE_DATA_DST_SEL(0)));
>> -   if (vm->id < 8) {
>> +   if (vm_id < 8) {
>>  radeon_ring_write(ring,
>> - (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
>> (vm->id << 2)) >> 2);
>> + (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm_id 
>> << 2)) >> 2);
>>  } else {
>>  radeon_ring_write(ring,
>> - (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
>> ((vm->id - 8) << 2)) >> 2);
>> + (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
>> ((vm_id - 8) << 2)) >> 2);
>>  }
>>  radeon_ring_write(ring, 0);
>> -   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
>> +   radeon_ring_write(ring, pd_addr >> 12);
>>
>>  /* update SH_MEM_* regs */
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
>> @@ -5994,7 +5991,7 @@ void cik_vm_flush(struct radeon_device *rdev, int 
>> ridx, struct radeon_vm *vm)
>>   WRITE_DATA_DST_SEL(0)));
>>  radeon_ring_write(ring, SRBM_GFX_CNTL >> 2);
>>  radeon_ring_write(ring, 0);
>> -   radeon_ring_write(ring, VMID(vm->id));
>> +   radeon_ring_write(ring, VMID(vm_id));
>>
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 6));
>>  radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
>> @@ -6015,7 +6012,7 @@ void cik_vm_flush(struct radeon_device *rdev, int 
>> ridx, struct radeon_vm *vm)
>>  radeon_ring_write(ring, VMID(0));
>>
>>  /* HDP flush */
>> -   cik_hdp_flush_cp_ring_emit(rdev, ridx);
>> +   cik_hdp_flush_cp_ring_emit(rdev, ring->idx);
>>
>>  /* bits 0-15 are the VM contexts0-15 */
>>  radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
>> @@ -6023,7 +6020,7 @@ void cik_vm_flush(struct radeon_device *rdev, int 
>> ridx, struct radeon_vm *vm)
>>   WRITE_DATA_DST_SEL(0)));
>>  radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
>>  radeon_ring_write(ring, 0);
>> -   radeon_ring_write(ring, 1 << vm->id);
>> +   radeon_ring_write(ring, 1 << vm_id);
>>
>>  /* compute doesn't have PFP */
>>  if (usepfp) {
>> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
>> b/drivers/gpu/drm/radeon/cik_sdma.c
>> index 4e8432d..7470a2e 100644
>> --- a/drivers/gpu/drm/radeon/cik_sdma.c
>> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
>> @@ -901,25 +901,21 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
>>* Update the page table base and flush the VM TLB
>>* using sDMA (CIK).
>>*/
>> -void cik_dma_vm_flush(struct radeon_device *rdev, int ridx, struct 
>> radeon_vm *vm)
>> +void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
>> + unsigned vm_id, 

3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Michael Marineau]

On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
 wrote:
> Hey,
>
> On 19-11-14 07:43, Michael Marineau wrote:
>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>> lockups shortly after startup, accompanied with one or both of the
>> following errors:
>>
>> nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
>> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
>> nouveau E[ DRM] GPU lockup - switching to software fbcon
>>
>> I was able to trace the issue with bisect to commit
>> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
>> fences for readable objects". The lockups appear to have cleared up
>> since reverting that and a few related followup commits:
>>
>> 809e9447: "drm/nouveau: use shared fences for readable objects"
>> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
>> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
>> nouveau_fence_sync"
>> 15a996bb: "drm/nouveau: assign fence_chan->name correctly"
>
> Weird. I'm not sure yet what causes it.
>
> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect=86be4f216bbb9ea3339843a5658d4c21162c7ee2

Building a kernel from that commit gives me an entirely new behavior:
X hangs for at least 10-20 seconds at a time with brief moments of
responsiveness before hanging again while gitk on the kernel repo
loads. Otherwise the system is responsive. The head of that
fixed-fences-for-bisect branch (1c6aafb5) which is the "use shared
fences for readable objects" commit I originally bisected to does
feature the complete lockups I was seeing before.

>
> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>
> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>
> fctx->base.sequence = nv84_fence_read(chan);
>
> and add back
>
> nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);

Making your suggested change on top of each 86be4f21 and 1c6aafb5 made
no noticeable difference in either of the two behaviors.

>
> If that fails you should compile your kernel with trace events, to get some 
> debugging info from the fences. I'll post debugging info if this does not fix 
> it.

Happy to gather whatever debug log or tracing data you need :)

-- 
Michael Marineau

[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1

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

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

Pavol Klačanský  changed:

   What|Removed |Added

 CC||pavol at klacansky.com

--- Comment #23 from Pavol Klačanský  ---
It occurs at least once a day on 3.18.0-031800rc4-generic.

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

[PATCH] drm/radeon: update the VM after setting BO address v4

[Christian König]

From: Christian König 

This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.

v2: fix vm lock
v3: immediately update unmaps as well
v4: use drm_free_large instead of kfree

Signed-off-by: Christian König 
Tested-by: Kai Wasserbäch 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 64 +
 1 file changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index f752c7f..a748a64 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -518,6 +518,68 @@ out:
return r;
 }

+/**
+ * radeon_gem_va_update_vm -update the bo_va in its VM
+ *
+ * @rdev: radeon_device pointer
+ * @bo_va: bo_va to update
+ *
+ * Update the bo_va directly after setting it's address. Errors are not
+ * vital here, so they are not reported back to userspace.
+ */
+static void radeon_gem_va_update_vm(struct radeon_device *rdev,
+   struct radeon_bo_va *bo_va)
+{
+   struct ttm_validate_buffer tv, *entry;
+   struct radeon_cs_reloc *vm_bos;
+   struct ww_acquire_ctx ticket;
+   struct list_head list;
+   unsigned domain;
+   int r;
+
+   INIT_LIST_HEAD();
+
+   tv.bo = _va->bo->tbo;
+   tv.shared = true;
+   list_add(, );
+
+   vm_bos = radeon_vm_get_bos(rdev, bo_va->vm, );
+   if (!vm_bos)
+   return;
+
+   r = ttm_eu_reserve_buffers(, , true);
+   if (r)
+   goto error_free;
+
+   list_for_each_entry(entry, , head) {
+   domain = radeon_mem_type_to_domain(entry->bo->mem.mem_type);
+   /* if anything is swapped out don't swap it in here,
+  just abort and wait for the next CS */
+   if (domain == RADEON_GEM_DOMAIN_CPU)
+   goto error_unreserve;
+   }
+
+   mutex_lock(_va->vm->mutex);
+   r = radeon_vm_clear_freed(rdev, bo_va->vm);
+   if (r)
+   goto error_unlock;
+
+   if (bo_va->it.start)
+   r = radeon_vm_bo_update(rdev, bo_va, _va->bo->tbo.mem);
+
+error_unlock:
+   mutex_unlock(_va->vm->mutex);
+
+error_unreserve:
+   ttm_eu_backoff_reservation(, );
+
+error_free:
+   drm_free_large(vm_bos);
+
+   if (r)
+   DRM_ERROR("Couldn't update BO_VA (%d)\n", r);
+}
+
 int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp)
 {
@@ -612,6 +674,8 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
default:
break;
}
+   if (!r)
+   radeon_gem_va_update_vm(rdev, bo_va);
args->operation = RADEON_VA_RESULT_OK;
if (r) {
args->operation = RADEON_VA_RESULT_ERROR;
-- 
1.9.1

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, couple of regression fixes, both cc: stable.

BR,
Jani.

The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9:

  Linux 3.18-rc5 (2014-11-16 16:36:20 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-11-19

for you to fetch changes up to 0485c9dc24ec0939b42ca5104c0373297506b555:

  drm/i915: Kick fbdev before vgacon (2014-11-17 10:18:21 +0200)


Daniel Vetter (2):
  drm/i915: drop WaSetupGtModeTdRowDispatch:snb
  drm/i915: Kick fbdev before vgacon

 drivers/gpu/drm/i915/i915_dma.c | 10 ++
 drivers/gpu/drm/i915/intel_pm.c |  5 -
 2 files changed, 6 insertions(+), 9 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 6/6] drm/atomic_helper: Make it clear that commit_planes gets the old state

[Daniel Vetter]

Oversight from my kerneldoc cleanup when doing the original atomic
helper series - I've only applied this clarification to the modeset
related helpers, and not the plane update code. Remedy this asap.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 99095ef147ef..690360038dc1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -976,18 +976,18 @@ EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
 /**
  * drm_atomic_helper_commit_planes - commit plane state
  * @dev: DRM device
- * @state: atomic state
+ * @old_state: atomic state object with old state structures
  *
  * This function commits the new plane state using the plane and atomic helper
  * functions for planes and crtcs. It assumes that the atomic state has already
  * been pushed into the relevant object state pointers, since this step can no
  * longer fail.
  *
- * It still requires the global state object @state to know which planes and
+ * It still requires the global state object @old_state to know which planes 
and
  * crtcs need to be updated though.
  */
 void drm_atomic_helper_commit_planes(struct drm_device *dev,
-struct drm_atomic_state *state)
+struct drm_atomic_state *old_state)
 {
int nplanes = dev->mode_config.num_total_plane;
int ncrtcs = dev->mode_config.num_crtc;
@@ -995,7 +995,7 @@ void drm_atomic_helper_commit_planes(struct drm_device *dev,

for (i = 0; i < ncrtcs; i++) {
struct drm_crtc_helper_funcs *funcs;
-   struct drm_crtc *crtc = state->crtcs[i];
+   struct drm_crtc *crtc = old_state->crtcs[i];

if (!crtc)
continue;
@@ -1010,7 +1010,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,

for (i = 0; i < nplanes; i++) {
struct drm_plane_helper_funcs *funcs;
-   struct drm_plane *plane = state->planes[i];
+   struct drm_plane *plane = old_state->planes[i];

if (!plane)
continue;
@@ -1025,7 +1025,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,

for (i = 0; i < ncrtcs; i++) {
struct drm_crtc_helper_funcs *funcs;
-   struct drm_crtc *crtc = state->crtcs[i];
+   struct drm_crtc *crtc = old_state->crtcs[i];

if (!crtc)
continue;
-- 
2.1.1

[PATCH 5/6] drm: s/enum_blob_list/enum_list/ in drm_property

[Daniel Vetter]

I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.

Shipping userspace seems to have never relied on this, and the kernel
also never put any blob thing onto that property. And nowadays it
would blow up, e.g. in drm_property_destroy. Also it makes no sense to
return values in an ioctl that only returns metadata about everything.

So let's ditch all the internal code for the blob list, rename the
list to be unambiguous and sprinkle comments all over the place to
explain this peculiar piece of api.

v2: Squash in fixup from Rob to remove now unused variables.

Cc: Rob Clark 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c  | 53 +++--
 include/drm/drm_crtc.h  |  2 +-
 include/uapi/drm/drm_mode.h |  2 ++
 3 files changed, 20 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8c550302a9ef..589a921d4313 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3457,7 +3457,7 @@ struct drm_property *drm_property_create(struct 
drm_device *dev, int flags,

property->flags = flags;
property->num_values = num_values;
-   INIT_LIST_HEAD(>enum_blob_list);
+   INIT_LIST_HEAD(>enum_list);

if (name) {
strncpy(property->name, name, DRM_PROP_NAME_LEN);
@@ -3679,8 +3679,8 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
(value > 63))
return -EINVAL;

-   if (!list_empty(>enum_blob_list)) {
-   list_for_each_entry(prop_enum, >enum_blob_list, head) 
{
+   if (!list_empty(>enum_list)) {
+   list_for_each_entry(prop_enum, >enum_list, head) {
if (prop_enum->value == value) {
strncpy(prop_enum->name, name, 
DRM_PROP_NAME_LEN);
prop_enum->name[DRM_PROP_NAME_LEN-1] = '\0';
@@ -3698,7 +3698,7 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
prop_enum->value = value;

property->values[index] = value;
-   list_add_tail(_enum->head, >enum_blob_list);
+   list_add_tail(_enum->head, >enum_list);
return 0;
 }
 EXPORT_SYMBOL(drm_property_add_enum);
@@ -3715,7 +3715,7 @@ void drm_property_destroy(struct drm_device *dev, struct 
drm_property *property)
 {
struct drm_property_enum *prop_enum, *pt;

-   list_for_each_entry_safe(prop_enum, pt, >enum_blob_list, 
head) {
+   list_for_each_entry_safe(prop_enum, pt, >enum_list, head) {
list_del(_enum->head);
kfree(prop_enum);
}
@@ -3839,16 +3839,12 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
struct drm_mode_get_property *out_resp = data;
struct drm_property *property;
int enum_count = 0;
-   int blob_count = 0;
int value_count = 0;
int ret = 0, i;
int copied;
struct drm_property_enum *prop_enum;
struct drm_mode_property_enum __user *enum_ptr;
-   struct drm_property_blob *prop_blob;
-   uint32_t __user *blob_id_ptr;
uint64_t __user *values_ptr;
-   uint32_t __user *blob_length_ptr;

if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -3862,11 +3858,8 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,

if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
-   list_for_each_entry(prop_enum, >enum_blob_list, head)
+   list_for_each_entry(prop_enum, >enum_list, head)
enum_count++;
-   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
-   list_for_each_entry(prop_blob, >enum_blob_list, head)
-   blob_count++;
}

value_count = property->num_values;
@@ -3891,7 +3884,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
if ((out_resp->count_enum_blobs >= enum_count) && enum_count) {
copied = 0;
enum_ptr = (struct drm_mode_property_enum __user 
*)(unsigned long)out_resp->enum_blob_ptr;
-   list_for_each_entry(prop_enum, 
>enum_blob_list, head) {
+   list_for_each_entry(prop_enum, >enum_list, 
head) {

if (copy_to_user(_ptr[copied].value, 
_enum->value, sizeof(uint64_t))) {
ret = -EFAULT;
@@ -3909,28 +3902,16 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
out_resp->count_enum_blobs = enum_count;
}

-   if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
-   if ((out_resp->count_enum_blobs >= blob_count) 

[PATCH 4/6] drm/crtc: Polish kerneldoc

[Daniel Vetter]

- Make it clear that it's a negative errno (more in line with
  everything else).
- Clean up the confusion around get_properties vs. getproperty ioctls:
  One reads per-obj property values, the other reads property
  metadata.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 79 --
 1 file changed, 41 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5c878f172365..8c550302a9ef 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1490,7 +1490,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
  * connectors.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
 {
@@ -1674,7 +1674,7 @@ static void drm_crtc_convert_to_umode(struct 
drm_mode_modeinfo *out,
  * the caller.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 static int drm_crtc_convert_umode(struct drm_display_mode *out,
  const struct drm_mode_modeinfo *in)
@@ -1717,7 +1717,7 @@ static int drm_crtc_convert_umode(struct drm_display_mode 
*out,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getresources(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -1905,7 +1905,7 @@ out:
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getcrtc(struct drm_device *dev,
 void *data, struct drm_file *file_priv)
@@ -1966,7 +1966,7 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getconnector(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2110,7 +2110,7 @@ out:
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getencoder(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -2151,7 +2151,7 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getplane_res(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2212,7 +2212,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
*data,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_getplane(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2386,7 +2386,7 @@ static int setplane_internal(struct drm_plane *plane,
  * valid crtc).
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_setplane(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
@@ -2461,7 +2461,7 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
  * interface. The only thing it adds is correct refcounting dance.
  * 
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_set_config_internal(struct drm_mode_set *set)
 {
@@ -2554,7 +2554,7 @@ EXPORT_SYMBOL(drm_crtc_check_viewport);
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_setcrtc(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
@@ -2717,7 +2717,7 @@ out:
  * userspace wants to make use of these capabilities.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 static int drm_mode_cursor_universal(struct drm_crtc *crtc,
 struct drm_mode_cursor2 *req,
@@ -2865,7 +2865,7 @@ out:
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_cursor_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv)
@@ -2892,7 +2892,7 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
  * Called by the user via ioctl.
  *
  * Returns:
- * Zero on success, errno on failure.
+ * Zero on success, negative errno on failure.
  */
 int drm_mode_cursor2_ioctl(struct drm_device *dev,
   void *data, 

[PATCH 3/6] drm/atomic: Don't overrun the connector array when hotplugging

[Daniel Vetter]

Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar issues.

So store the sizes of the arrays in struct drm_atomic_state and double
check them. We don't really care about races except that we want to
use a consistent value, so ACCESS_ONCE is all we need. And if we
indeed notice that we'd overrun the array then just give up and
restart the entire ioctl.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c| 26 +-
 drivers/gpu/drm/drm_atomic_helper.c | 23 ---
 include/drm/drm_crtc.h  |  2 ++
 3 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 67c1dc894bd9..3624632084e2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -56,6 +56,8 @@ drm_atomic_state_alloc(struct drm_device *dev)
if (!state)
return NULL;

+   state->num_connector = ACCESS_ONCE(dev->mode_config.num_connector);
+
state->crtcs = kcalloc(dev->mode_config.num_crtc,
   sizeof(*state->crtcs), GFP_KERNEL);
if (!state->crtcs)
@@ -72,12 +74,12 @@ drm_atomic_state_alloc(struct drm_device *dev)
  sizeof(*state->plane_states), GFP_KERNEL);
if (!state->plane_states)
goto fail;
-   state->connectors = kcalloc(dev->mode_config.num_connector,
+   state->connectors = kcalloc(state->num_connector,
sizeof(*state->connectors),
GFP_KERNEL);
if (!state->connectors)
goto fail;
-   state->connector_states = kcalloc(dev->mode_config.num_connector,
+   state->connector_states = kcalloc(state->num_connector,
  sizeof(*state->connector_states),
  GFP_KERNEL);
if (!state->connector_states)
@@ -117,7 +119,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state)

DRM_DEBUG_KMS("Clearing atomic state %p\n", state);

-   for (i = 0; i < config->num_connector; i++) {
+   for (i = 0; i < state->num_connector; i++) {
struct drm_connector *connector = state->connectors[i];

if (!connector)
@@ -304,6 +306,21 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,

index = drm_connector_index(connector);

+   /*
+* Construction of atomic state updates can race with a connector
+* hot-add which might overflow. In this case flip the table and just
+* restart the entire ioctl - no one is fast enough to livelock a cpu
+* with physical hotplug events anyway.
+*
+* Note that we only grab the indexes once we have the right lock to
+* prevent hotplug/unplugging of connectors. So removal is no problem,
+* at most the array is a bit too large.
+*/
+   if (index >= state->num_connector) {
+   DRM_DEBUG_KMS("Hot-added connector would overflow state array, 
restarting\n");
+   return -EAGAIN;
+   }
+
if (state->connector_states[index])
return state->connector_states[index];

@@ -499,10 +516,9 @@ int
 drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
   struct drm_crtc *crtc)
 {
-   int nconnectors = state->dev->mode_config.num_connector;
int i, num_connected_connectors = 0;

-   for (i = 0; i < nconnectors; i++) {
+   for (i = 0; i < state->num_connector; i++) {
struct drm_connector_state *conn_state;

conn_state = state->connector_states[i];
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0cd054615920..99095ef147ef 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -249,7 +249,6 @@ static int
 mode_fixup(struct drm_atomic_state *state)
 {
int ncrtcs = state->dev->mode_config.num_crtc;
-   int nconnectors = state->dev->mode_config.num_connector;
struct drm_crtc_state *crtc_state;
struct drm_connector_state *conn_state;
int i;
@@ -264,7 +263,7 @@ mode_fixup(struct drm_atomic_state *state)
drm_mode_copy(_state->adjusted_mode, _state->mode);
}

-   for (i = 0; i < nconnectors; i++) {
+   for (i = 0; i < state->num_connector; i++) {
struct drm_encoder_helper_funcs *funcs;
struct drm_encoder *encoder;

@@ -336,7 +335,6 @@ drm_atomic_helper_check_prepare(struct drm_device *dev,
struct drm_atomic_state *state)
 {
int ncrtcs = 

[PATCH 2/6] drm/atomic: Only destroy connector states with connection mutex held

[Daniel Vetter]

Otherwise the connector might have been unplugged and destroyed while
we didn't look. Yet another fallout from DP MST hotplugging that I
didn't consider.

To make sure we get this right add an appropriate WARN_ON to
drm_atomic_state_clear (obviously only when we actually have a state
to clear up). And reorder all the state_clear and backoff calls to
make it work out properly.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c|  9 ++---
 drivers/gpu/drm/drm_atomic_helper.c | 14 +++---
 2 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 90b2d1644bd7..67c1dc894bd9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -112,21 +112,24 @@ EXPORT_SYMBOL(drm_atomic_state_alloc);
 void drm_atomic_state_clear(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
+   struct drm_mode_config *config = >mode_config;
int i;

DRM_DEBUG_KMS("Clearing atomic state %p\n", state);

-   for (i = 0; i < dev->mode_config.num_connector; i++) {
+   for (i = 0; i < config->num_connector; i++) {
struct drm_connector *connector = state->connectors[i];

if (!connector)
continue;

+   WARN_ON(!drm_modeset_is_locked(>connection_mutex));
+
connector->funcs->atomic_destroy_state(connector,
   
state->connector_states[i]);
}

-   for (i = 0; i < dev->mode_config.num_crtc; i++) {
+   for (i = 0; i < config->num_crtc; i++) {
struct drm_crtc *crtc = state->crtcs[i];

if (!crtc)
@@ -136,7 +139,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state)
  state->crtc_states[i]);
}

-   for (i = 0; i < dev->mode_config.num_total_plane; i++) {
+   for (i = 0; i < config->num_total_plane; i++) {
struct drm_plane *plane = state->planes[i];

if (!plane)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fad2b932cf72..0cd054615920 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1217,8 +1217,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
@@ -1285,8 +1285,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
@@ -1462,8 +1462,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
@@ -1528,8 +1528,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

goto retry;
 }
@@ -1587,8 +1587,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

goto retry;
 }
@@ -1646,8 +1646,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

goto retry;
 }
@@ -1725,8 +1725,8 @@ fail:

return ret;
 backoff:
-   drm_atomic_legacy_backoff(state);
drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);

/*
 * Someone might have exchanged the framebuffer while we dropped locks
-- 
2.1.1

[PATCH 1/6] drm/atomic: Ensure that drm_connector_index is stable

[Daniel Vetter]

I've totally forgotten that with DP MST connectors can now be
hotplugged. And failed to adapt Rob's drm_atomic_state code (which
predates connector hotplugging) to the new realities.

The first step is to make sure that the connector indices used to
access the arrays of pointers are stable. The connection mutex gives
us enough guarantees for that, which means we won't unecessarily block
on concurrent modesets or background probing.

So add a locking WARN_ON and shuffle the code slightly to make sure we
always hold the right lock.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c | 8 
 drivers/gpu/drm/drm_crtc.c   | 5 +
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ed22a719440f..90b2d1644bd7 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -295,15 +295,15 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,
struct drm_mode_config *config = >dev->mode_config;
struct drm_connector_state *connector_state;

+   ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
+   if (ret)
+   return ERR_PTR(ret);
+
index = drm_connector_index(connector);

if (state->connector_states[index])
return state->connector_states[index];

-   ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
-   if (ret)
-   return ERR_PTR(ret);
-
connector_state = connector->funcs->atomic_duplicate_state(connector);
if (!connector_state)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e74b59d..5c878f172365 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -867,6 +867,8 @@ int drm_connector_init(struct drm_device *dev,

drm_connector_get_cmdline_mode(connector);

+   /* We should add connectors at the end to avoid upsetting the connector
+* index too much. */
list_add_tail(>head, >mode_config.connector_list);
dev->mode_config.num_connector++;

@@ -930,6 +932,9 @@ unsigned int drm_connector_index(struct drm_connector 
*connector)
 {
unsigned int index = 0;
struct drm_connector *tmp;
+   struct drm_mode_config *config = >dev->mode_config;
+
+   WARN_ON(!drm_modeset_is_locked(>connection_mutex));

list_for_each_entry(tmp, >dev->mode_config.connector_list, 
head) {
if (tmp == connector)
-- 
2.1.1

[Bug 88501] AMD/ATI RS690M Console blanks to white

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

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

--- Comment #4 from Alex Deucher  ---
Created attachment 158211
  --> https://bugzilla.kernel.org/attachment.cgi?id=158211=edit
possible fix

Does this patch fix the issue (against 3.17 or newer kernel)?

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

[PATCH 2/2] drm/msm: Add the eDP connector in msm drm driver

[Hai Li]

Modified the hard-coded hdmi connector/encoder implementations in msm drm
driver to support both edp and hdmi.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 38 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 47 -
 drivers/gpu/drm/msm/msm_drv.c   |  2 ++
 drivers/gpu/drm/msm/msm_drv.h   |  7 +
 4 files changed, 77 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 25c2fcb..f4159c2 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
  * Copyright (C) 2013 Red Hat
  * Author: Rob Clark 
  *
@@ -151,11 +152,13 @@ static void mdp5_encoder_mode_set(struct drm_encoder 
*encoder,
 {
struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
struct mdp5_kms *mdp5_kms = get_kms(encoder);
+   struct drm_device *dev = encoder->dev;
+   struct drm_connector *connector;
int intf = mdp5_encoder->intf;
uint32_t dtv_hsync_skew, vsync_period, vsync_len, ctrl_pol;
uint32_t display_v_start, display_v_end;
uint32_t hsync_start_x, hsync_end_x;
-   uint32_t format;
+   uint32_t format = 0x2100;
unsigned long flags;

mode = adjusted_mode;
@@ -177,7 +180,28 @@ static void mdp5_encoder_mode_set(struct drm_encoder 
*encoder,
/* probably need to get DATA_EN polarity from panel.. */

dtv_hsync_skew = 0;  /* get this from panel? */
-   format = 0x213f; /* get this from panel? */
+
+   /* Get color format from panel, default is 8bpc */
+   list_for_each_entry(connector, >mode_config.connector_list, head) {
+   if (connector->encoder == encoder) {
+   switch (connector->display_info.bpc) {
+   case 4:
+   format |= 0;
+   break;
+   case 5:
+   format |= 0x15;
+   break;
+   case 6:
+   format |= 0x2A;
+   break;
+   case 8:
+   default:
+   format |= 0x3F;
+   break;
+   }
+   break;
+   }
+   }

hsync_start_x = (mode->htotal - mode->hsync_start);
hsync_end_x = mode->htotal - (mode->hsync_start - mode->hdisplay) - 1;
@@ -187,6 +211,16 @@ static void mdp5_encoder_mode_set(struct drm_encoder 
*encoder,
display_v_start = (mode->vtotal - mode->vsync_start) * mode->htotal + 
dtv_hsync_skew;
display_v_end = vsync_period - ((mode->vsync_start - mode->vdisplay) * 
mode->htotal) + dtv_hsync_skew - 1;

+   /*
+* For edp only:
+* DISPLAY_V_START = (VBP * HCYCLE) + HBP
+* DISPLAY_V_END = (VBP + VACTIVE) * HCYCLE - 1 - HFP
+*/
+   if (mdp5_encoder->intf_id == INTF_eDP) {
+   display_v_start += (mode->htotal - mode->hsync_start);
+   display_v_end -= (mode->hsync_start - mode->hdisplay);
+   }
+
spin_lock_irqsave(_encoder->intf_lock, flags);

mdp5_write(mdp5_kms, REG_MDP5_INTF_HSYNC_CTL(intf),
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index ab5f8d2..9d891e2 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -157,7 +157,7 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
};
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
-   struct drm_encoder *encoder;
+   struct drm_encoder *edp_encoder = NULL, *hdmi_encoder = NULL;
const struct mdp5_cfg_hw *hw_cfg;
int i, ret;

@@ -208,14 +208,6 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
}
}

-   /* Construct encoder for HDMI: */
-   encoder = mdp5_encoder_init(dev, 3, INTF_HDMI);
-   if (IS_ERR(encoder)) {
-   dev_err(dev->dev, "failed to construct encoder\n");
-   ret = PTR_ERR(encoder);
-   goto fail;
-   }
-
/* NOTE: the vsync and error irq's are actually associated with
 * the INTF/encoder.. the easiest way to deal with this (ie. what
 * we do now) is assume a fixed relationship between crtc's and
@@ -224,20 +216,45 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
 * care of error and vblank irq's that the crtc has registered,
 * and also update user-requested vblank_mask.
 */
-   encoder->possible_crtcs = BIT(0);
-   mdp5_crtc_set_intf(priv->crtcs[0], 3, INTF_HDMI);
+   if (priv->hdmi) {
+

[PATCH 1/2] drm/msm: Initial add eDP support in msm drm driver

[Hai Li]

This change adds a new eDP connector in msm drm driver. With this
change, eDP panel can work with msm platform under drm framework.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Makefile|6 +
 drivers/gpu/drm/msm/edp/edp.c   |  211 
 drivers/gpu/drm/msm/edp/edp.h   |   83 ++
 drivers/gpu/drm/msm/edp/edp_aux.c   |  298 +
 drivers/gpu/drm/msm/edp/edp_bridge.c|  206 
 drivers/gpu/drm/msm/edp/edp_connector.c |  155 +++
 drivers/gpu/drm/msm/edp/edp_ctrl.c  | 1799 +++
 drivers/gpu/drm/msm/edp/edp_phy.c   |  123 +++
 drivers/gpu/drm/msm/edp/edp_reg.h   |   92 ++
 drivers/gpu/drm/msm/msm_drv.h   |6 +
 10 files changed, 2979 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/edp/edp.c
 create mode 100644 drivers/gpu/drm/msm/edp/edp.h
 create mode 100644 drivers/gpu/drm/msm/edp/edp_aux.c
 create mode 100644 drivers/gpu/drm/msm/edp/edp_bridge.c
 create mode 100644 drivers/gpu/drm/msm/edp/edp_connector.c
 create mode 100644 drivers/gpu/drm/msm/edp/edp_ctrl.c
 create mode 100644 drivers/gpu/drm/msm/edp/edp_phy.c
 create mode 100644 drivers/gpu/drm/msm/edp/edp_reg.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 143d988..e5464a0 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -16,6 +16,12 @@ msm-y := \
hdmi/hdmi_phy_8960.o \
hdmi/hdmi_phy_8x60.o \
hdmi/hdmi_phy_8x74.o \
+   edp/edp.o \
+   edp/edp_aux.o \
+   edp/edp_bridge.o \
+   edp/edp_connector.o \
+   edp/edp_ctrl.o \
+   edp/edp_phy.o \
mdp/mdp_format.o \
mdp/mdp_kms.o \
mdp/mdp4/mdp4_crtc.o \
diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
new file mode 100644
index 000..779706e
--- /dev/null
+++ b/drivers/gpu/drm/msm/edp/edp.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include "edp.h"
+
+static irqreturn_t edp_irq(int irq, void *dev_id)
+{
+   struct msm_edp *edp = dev_id;
+
+   /* Process eDP irq */
+   return msm_edp_ctrl_irq(edp->ctrl_priv);
+}
+
+static void edp_destroy(struct platform_device *pdev)
+{
+   struct msm_edp *edp = platform_get_drvdata(pdev);
+
+   if (!edp)
+   return;
+
+   if (edp->ctrl_priv) {
+   msm_edp_ctrl_destroy(edp->ctrl_priv);
+   edp->ctrl_priv = NULL;
+   }
+
+   platform_set_drvdata(pdev, NULL);
+
+   kfree(edp);
+}
+
+/* construct hdmi at bind/probe time, grab all the resources. */
+static struct msm_edp *edp_init(struct platform_device *pdev)
+{
+   struct msm_edp *edp = NULL;
+   int ret;
+
+   if (!pdev) {
+   pr_err("no edp device\n");
+   ret = -ENXIO;
+   goto fail;
+   }
+
+   edp = kzalloc(sizeof(*edp), GFP_KERNEL);
+   if (!edp) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+   DBG("edp probed=%p", edp);
+
+   edp->pdev = pdev;
+   platform_set_drvdata(pdev, edp);
+
+   ret = msm_edp_ctrl_init(edp);
+   if (ret)
+   goto fail;
+
+   return edp;
+
+fail:
+   if (edp)
+   edp_destroy(pdev);
+
+   return ERR_PTR(ret);
+}
+
+static int edp_bind(struct device *dev, struct device *master, void *data)
+{
+   struct drm_device *drm = dev_get_drvdata(master);
+   struct msm_drm_private *priv = drm->dev_private;
+   struct msm_edp *edp;
+
+   DBG("");
+   edp = edp_init(to_platform_device(dev));
+   if (IS_ERR(edp))
+   return PTR_ERR(edp);
+   priv->edp = edp;
+
+   return 0;
+}
+
+static void edp_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+   struct drm_device *drm = dev_get_drvdata(master);
+   struct msm_drm_private *priv = drm->dev_private;
+
+   DBG("");
+   if (priv->edp) {
+   edp_destroy(to_platform_device(dev));
+   priv->edp = NULL;
+   }
+}
+
+static const struct component_ops edp_ops = {
+   .bind   = edp_bind,
+   .unbind = edp_unbind,
+};
+
+static int edp_dev_probe(struct platform_device *pdev)
+{
+   DBG("");
+   return component_add(>dev, _ops);
+}
+
+static int edp_dev_remove(struct platform_device *pdev)
+{
+   DBG("");
+   component_del(>dev, _ops);
+   return 0;
+}
+
+static const struct of_device_id dt_match[] = {
+   { .compatible = 

[Bug 88501] AMD/ATI RS690M Console blanks to white

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #3 from Alex Deucher  ---
Does booting a recent kernel with radeon.backlight=0 fix the issue?

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

[PATCH 1/1] DRM-vmwgfx: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Nov 2014 17:50:19 +0100

The vfree() function performes also input parameter validation. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 14b2f50..f9a67b8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -889,8 +889,7 @@ static int vmw_driver_unload(struct drm_device *dev)

if (dev_priv->ctx.res_ht_initialized)
drm_ht_remove(_priv->ctx.res_ht);
-   if (dev_priv->ctx.cmd_bounce)
-   vfree(dev_priv->ctx.cmd_bounce);
+   vfree(dev_priv->ctx.cmd_bounce);
if (dev_priv->enable_fb) {
vmw_fb_close(dev_priv);
vmw_kms_restore_vga(dev_priv);
-- 
2.1.3

[Bug 86471] Unreal Engine 4.6 Editor dont start

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

ass=0xacfb80, InOuter=0x0,
InName=0x7c4d300 L"/Engine/EditorMeshes/EditorSphere.EditorSphere",
Filename=0x0, LoadFlags=0, Sandbox=0x0, bAllowObjectReconciliation=true)
at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectGlobals.cpp:687
#26 0x71fef3d6 in LoadObject (Outer=0x0, Name=0x7c4d300
L"/Engine/EditorMeshes/EditorSphere.EditorSphere", Filename=0x0, LoadFlags=0,
Sandbox=0x0)
at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/UObjectGlobals.h:1106
#27 0x71fef32c in
ConstructorHelpersInternal::FindOrLoadObject (PathName=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/ConstructorHelpers.h:31
#28 0x71fee0f7 in
ConstructorHelpers::FObjectFinder::FObjectFinder
(this=0x7fffecce38e8 <UEditorEngine::UEditorEngine(FObjectInitializer
const&)::ConstructorStatics+32>, 
ObjectToFind=0x7fffec3e2678 L"/Engine/EditorMeshes/EditorSphere") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/ConstructorHelpers.h:91
#29 0x7fffea6597bc in UEditorEngine::UEditorEngine(FObjectInitializer
const&)::FConstructorStatics::FConstructorStatics() (this=0x7fffecce38c8
<UEditorEngine::UEditorEngine(FObjectInitializer const&)::ConstructorStatics>)
at
/home/linuxdonald/UnrealEngine/Engine/Source/Editor/UnrealEd/Private/Editor.cpp:211
#30 0x7fffea659195 in UEditorEngine::UEditorEngine (this=0x5754000,
ObjectInitializer=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Editor/UnrealEd/Private/Editor.cpp:214
#31 0x7fffebe9dde1 in UEditorEngine::__DefaultConstructor (X=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Editor/UnrealEd/Classes/Editor/EditorEngine.h:208
#32 0x7fffebe9dd75 in InternalConstructor (X=...) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Public/UObject/Class.h:2206
#33 0x7654bd0e in UClass::CreateDefaultObject (this=0xaeed40) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/Class.cpp:2512
#34 0x00472507 in UClass::GetDefaultObject (this=0xaeed40,
bCreateIfNeeded=true) at Runtime/CoreUObject/Public/UObject/Class.h:1946
#35 0x767fcab5 in UObjectLoadAllCompiledInDefaultProperties () at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBase.cpp:737
#36 0x767fbd2a in ProcessNewlyLoadedUObjects () at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/CoreUObject/Private/UObject/UObjectBase.cpp:812
#37 0x0042a933 in FEngineLoop::PreInit (this=0x6b0568 ,
CmdLine=0x491318 L"") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/LaunchEngineLoop.cpp:1277
#38 0x0041d5d2 in EnginePreInit (CmdLine=0x491318 L"") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/Launch.cpp:31
#39 0x0044dd74 in GuardedMain (CmdLine=0x491318 L"") at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/Launch.cpp:110
#40 0x00466d66 in main (argc=1, argv=0x7fffe708) at
/home/linuxdonald/UnrealEngine/Engine/Source/Runtime/Launch/Private/Linux/LaunchLinux.cpp:193
(gdb) [2014.11.19-17.15.00:176][  0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:186][  0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:192][  0]LogExit: Exiting.
[2014.11.19-17.15.00:299][  0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:309][  0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:315][  0]LogExit: Exiting.
[2014.11.19-17.15.00:836][  0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:846][  0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:852][  0]LogExit: Exiting.

-- 
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/20141119/0b98624e/attachment-0001.html>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Javier Martinez Canillas]

[adding Paolo and Vivek as cc]

Hello,

On 11/18/2014 07:41 PM, Kevin Hilman wrote:
> 
> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
> it proceeds to panic in the workqueue code called by the asoc max98090
> codec[1].
> 
> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
> but I still don't have display output.
> 

Paolo Pisati pointed out in another thread that he needed the patch
"[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy"
is also needed to get display working for exynos on linux-next.

I've pinged Kukjin to apply this as a -rc fix since is needed after
a5ec598 ("phy: exynos-dp-video: Use syscon support to control pmu register")
landed in 3.18 which broke the Exynos Display Port PHY:

exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap

I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just $subject
and [0] should be enough to have display working on Peach Pi with linux-next but
it fails to me with:

exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
[mem 0x10040714-0x1004071f]

The same issue was reported by Paolo a couple of days ago [1].

Vivek,

Any idea what could cause this regression on linux-next? As reported by Paolo 
this
works well for me in 3.18-rc5.

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/10/30/394
[1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

[Kai Wasserbäch]

t; [  117.820022]  a0602de8 c900061cd000 a060245a
>> 
>> [  117.820055]  c900061ce0a8 8800d21a3d58 8800d4417650
>> 1e7d
>> [  117.820089] Call Trace:
>> [  117.820101]  [] ? kfree+0x2e/0x6d
>> [  117.820137]  [] ? radeon_gem_va_ioctl+0x28c/0x2d3 
>> [radeon]
>> [  117.820176]  [] ? radeon_gem_create_ioctl+0xa4/0xc3 
>> [radeon]
>> [  117.820207]  [] ? drm_ioctl+0x35b/0x3e1
>> [  117.820238]  [] ? radeon_gem_get_tiling_ioctl+0x8e/0x8e
>> [radeon]
>> [  117.820270]  [] ? _raw_spin_unlock_irqrestore+0xc/0xd
>> [  117.820303]  [] ? radeon_drm_ioctl+0x4b/0x7a [radeon]
>> [  117.820331]  [] ? do_vfs_ioctl+0x34e/0x404
>> [  117.820355]  [] ? vfs_read+0xbc/0xea
>> [  117.820377]  [] ? SyS_ioctl+0x51/0x77
>> [  117.820398]  [] ? system_call_fastpath+0x12/0x17
>> [  117.820423] Code: 00 00 80 ff 77 00 00 48 01 fa 48 0f 42 0d 78 99 6f 00 
>> 48 8d
>> 04 11 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 6b c0 38 48 01 d0 <48> 8b 
>> 10
>> 80 e6 80 74 0e 48 8b 50 30 48 8b 08 80 e5 80 48 0f 45
>> [  117.820582] RIP  [] virt_to_head_page+0x33/0x4a
>> [  117.820608]  RSP 
>> [  117.820622] CR2: eae3801564d8
>> [  117.838461] ---[ end trace a6e2a6aa1df3196f ]---
>>
>> I've used Dave Airlie's drm-next as a base (commit
>> d0d6c524bf1d72e6d64134c3a315b77deecc9252) and "git am"-applied your series 
>> (no
>> issues, applied cleanly) on top. Steam games are still entering the defunct
>> state as soon as the 3D engines are fired up on a kernel built from that 
>> source
>> tree.
>>
>> This is with (Debian testing as a base):
>> GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
>> Mesa: Git:master/b69c7c5dac
>> libdrm: Git:master/00847fa48b
>> LLVM: SVN:trunk/r54 (3.6 devel)
>> X.Org: 2:1.16.1-1
>> Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
>> # 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
>> # c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
>> # 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
>> # c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
>> # 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
>> # ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
>> # 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
>> # 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
>> libclc: Git:master/7f6f5bff1f
>> DDX: 1:7.5.0-1
>>
>> Let me know, if you need something else; see also the original thread
>> <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further
>> information.
>>
>> Cheers,
>> Kai
>>
> 

-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: kai at dev.carbon-project.org

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/5e6f1370/attachment-0001.sig>

[RFC 7/7] drm: make the callers of drm_wait_vblank() allocate the memory

[Paulo Zanoni]

From: Paulo Zanoni 

This way, the Kernel users will be able to fully control the lifetime
of struct drm_vblank_wait_item, and they will also be able to wrap it
to store their own information. As a result, one less memory
allocation will happen, and the Kernel codepath will not set all those
drm_pending_vblank_event struct fields.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_irq.c   | 92 -
 drivers/gpu/drm/i915/i915_debugfs.c | 11 ++---
 include/drm/drmP.h  |  2 +-
 3 files changed, 57 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index dd091c3..5fa5431 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1402,36 +1402,26 @@ static void drm_vblank_event_work_func(struct 
work_struct *work)

 static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
  union drm_wait_vblank *vblwait,
- struct drm_file *file_priv,
  bool callback_from_work,
- drm_vblank_callback_t callback)
+ drm_vblank_callback_t callback,
+ struct drm_vblank_wait_item *item)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
-   struct drm_pending_vblank_event *e;
struct timeval now;
unsigned long flags;
unsigned int seq;
int ret;

-   e = kzalloc(sizeof *e, GFP_KERNEL);
-   if (e == NULL) {
-   ret = -ENOMEM;
+   if (WARN_ON(!item)) {
+   ret = -EINVAL;
goto err_put;
}

-   e->item.pipe = pipe;
-   e->base.pid = current->pid;
-   e->event.base.type = DRM_EVENT_VBLANK;
-   e->event.base.length = sizeof e->event;
-   e->event.user_data = vblwait->request.signal;
-   e->base.event = >event.base;
-   e->base.file_priv = file_priv;
-   e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
-   e->item.from_user_space = true;
-   e->item.callback = callback;
-   e->item.callback_from_work = callback_from_work;
+   item->pipe = pipe;
+   item->callback = callback;
+   item->callback_from_work = callback_from_work;
if (callback_from_work)
-   INIT_WORK(>item.callback_work, drm_vblank_event_work_func);
+   INIT_WORK(>callback_work, drm_vblank_event_work_func);

spin_lock_irqsave(>event_lock, flags);

@@ -1447,15 +1437,6 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, int pipe,
goto err_unlock;
}

-   if (file_priv) {
-   if (file_priv->event_space < sizeof e->event) {
-   ret = -EBUSY;
-   goto err_unlock;
-   }
-
-   file_priv->event_space -= sizeof e->event;
-   }
-
seq = drm_vblank_count_and_time(dev, pipe, );

if ((vblwait->request.type & _DRM_VBLANK_NEXTONMISS) &&
@@ -1470,14 +1451,14 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, int pipe,
trace_drm_vblank_event_queued(current->pid, pipe,
  vblwait->request.sequence);

-   e->item.wanted_seq = vblwait->request.sequence;
+   item->wanted_seq = vblwait->request.sequence;
if ((seq - vblwait->request.sequence) <= (1 << 23)) {
drm_vblank_put(dev, pipe);
-   drm_wait_vblank_callback(dev, >item, seq, , false);
+   drm_wait_vblank_callback(dev, item, seq, , false);
vblwait->reply.sequence = seq;
} else {
/* drm_handle_vblank_events will call drm_vblank_put */
-   list_add_tail(>item.link, >vblank_event_list);
+   list_add_tail(>link, >vblank_event_list);
vblwait->reply.sequence = vblwait->request.sequence;
}

@@ -1487,7 +1468,6 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,

 err_unlock:
spin_unlock_irqrestore(>event_lock, flags);
-   kfree(e);
 err_put:
drm_vblank_put(dev, pipe);
return ret;
@@ -1509,9 +1489,9 @@ err_put:
  */
 static int __drm_wait_vblank(struct drm_device *dev,
 union drm_wait_vblank *vblwait,
-struct drm_file *file_priv,
 bool callback_from_work,
-drm_vblank_callback_t callback)
+drm_vblank_callback_t callback,
+struct drm_vblank_wait_item *item)
 {
struct drm_vblank_crtc *vblank;
int ret;
@@ -1566,8 +1546,9 @@ static int __drm_wait_vblank(struct drm_device *dev,
/* must hold on to the vblank ref until the event fires
 * drm_vblank_put will be called asynchronously
 */
-   return 

[RFC 6/7] drm: make vblank_event_list handle drm_vblank_wait_item types

[Paulo Zanoni]

From: Paulo Zanoni 

Which means the list doesn't really need to know if the event is from
user space or kernel space.

The only place here where we have to break the abstraction is at
drm_fops, when we're releasing all the events associated with a
file_priv. Here we introduced item.from_user_space, that needs to be
checked before we transform the item pointer into the appropriate
drm_pending_vblank_event pointer. Other strategies to solve this
problem - instead of adding item->from_user_space - would be to: (i)
store a copy of the file_priv pointer in the drm_vblank_wait_item
structure, but then we'd also need a custom destroy() function; or
(ii) add file_priv->pending_event_list, but then we'd have to keep all
the user space items in sync with dev->vblank_event_list, which could
lead to complicated code.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_fops.c | 15 +++
 drivers/gpu/drm/drm_irq.c  | 33 +
 include/drm/drmP.h |  4 +++-
 3 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 47c5e58..fbdbde2 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -280,18 +280,25 @@ static void drm_events_release(struct drm_file *file_priv)
 {
struct drm_device *dev = file_priv->minor->dev;
struct drm_pending_event *e, *et;
-   struct drm_pending_vblank_event *v, *vt;
+   struct drm_vblank_wait_item *i, *it;
unsigned long flags;

spin_lock_irqsave(>event_lock, flags);

/* Remove pending flips */
-   list_for_each_entry_safe(v, vt, >vblank_event_list, base.link)
+   list_for_each_entry_safe(i, it, >vblank_event_list, link) {
+   struct drm_pending_vblank_event *v;
+
+   if (!i->from_user_space)
+   continue;
+
+   v = container_of(i, struct drm_pending_vblank_event, item);
if (v->base.file_priv == file_priv) {
-   list_del(>base.link);
-   drm_vblank_put(dev, v->item.pipe);
+   list_del(>link);
+   drm_vblank_put(dev, i->pipe);
v->base.destroy(>base);
}
+   }

/* Remove unconsumed events */
list_for_each_entry_safe(e, et, _priv->event_list, link) {
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 4c03240..dd091c3 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1144,7 +1144,7 @@ static void drm_wait_vblank_callback(struct drm_device 
*dev,
 void drm_vblank_off(struct drm_device *dev, int crtc)
 {
struct drm_vblank_crtc *vblank = >vblank[crtc];
-   struct drm_pending_vblank_event *e, *t;
+   struct drm_vblank_wait_item *i, *t;
struct timeval now;
unsigned long irqflags;
unsigned int seq;
@@ -1171,15 +1171,15 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
/* Send any queued vblank events, lest the natives grow disquiet */
seq = drm_vblank_count_and_time(dev, crtc, );

-   list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
-   if (e->item.pipe != crtc)
+   list_for_each_entry_safe(i, t, >vblank_event_list, link) {
+   if (i->pipe != crtc)
continue;
DRM_DEBUG("Sending premature vblank event on disable: \
  wanted %d, current %d\n",
- e->item.wanted_seq, seq);
-   list_del(>base.link);
-   drm_vblank_put(dev, e->item.pipe);
-   drm_wait_vblank_callback(dev, >item, seq, , true);
+i->wanted_seq, seq);
+   list_del(>link);
+   drm_vblank_put(dev, i->pipe);
+   drm_wait_vblank_callback(dev, i, seq, , true);
}
spin_unlock_irqrestore(>event_lock, irqflags);
 }
@@ -1427,6 +1427,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e->base.event = >event.base;
e->base.file_priv = file_priv;
e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
+   e->item.from_user_space = true;
e->item.callback = callback;
e->item.callback_from_work = callback_from_work;
if (callback_from_work)
@@ -1476,7 +1477,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
vblwait->reply.sequence = seq;
} else {
/* drm_handle_vblank_events will call drm_vblank_put */
-   list_add_tail(>base.link, >vblank_event_list);
+   list_add_tail(>item.link, >vblank_event_list);
vblwait->reply.sequence = vblwait->request.sequence;
}

@@ -1635,7 +1636,7 @@ EXPORT_SYMBOL(drm_wait_vblank_kernel);

 static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
 {
-   struct 

[RFC 5/7] drm: change the drm vblank callback item type

[Paulo Zanoni]

From: Paulo Zanoni 

Now that we have created drm_vblank_wait_item, let's use it as the
type passed. In the future, callers will have to use container_of to
find our their original allocated structure, just like we're doing
with the send_vblank_event() callback.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_irq.c   | 40 ++---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 +++-
 include/drm/drmP.h  |  4 +++-
 3 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index a82e5ca..4c03240 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -881,10 +881,13 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, int 
crtc,
 EXPORT_SYMBOL(drm_vblank_count_and_time);

 static void send_vblank_event(struct drm_device *dev,
-   struct drm_pending_vblank_event *e,
+   struct drm_vblank_wait_item *item,
unsigned long seq, struct timeval *now,
bool premature)
 {
+   struct drm_pending_vblank_event *e =
+   container_of(item, struct drm_pending_vblank_event, item);
+
WARN_ON_SMP(!spin_is_locked(>event_lock));
e->event.sequence = seq;
e->event.tv_sec = now->tv_sec;
@@ -919,7 +922,7 @@ void drm_send_vblank_event(struct drm_device *dev, int crtc,
now = get_drm_timestamp();
}
e->item.pipe = crtc;
-   send_vblank_event(dev, e, seq, , false);
+   send_vblank_event(dev, >item, seq, , false);
 }
 EXPORT_SYMBOL(drm_send_vblank_event);

@@ -1109,18 +1112,18 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc)
 EXPORT_SYMBOL(drm_crtc_wait_one_vblank);

 static void drm_wait_vblank_callback(struct drm_device *dev,
-struct drm_pending_vblank_event *e,
+struct drm_vblank_wait_item *item,
 unsigned long seq, struct timeval *now,
 bool premature)
 {
-   if (e->item.callback_from_work) {
-   e->item.callback_args.dev = dev;
-   e->item.callback_args.seq = seq;
-   e->item.callback_args.now = now;
-   e->item.callback_args.premature = premature;
-   schedule_work(>item.callback_work);
+   if (item->callback_from_work) {
+   item->callback_args.dev = dev;
+   item->callback_args.seq = seq;
+   item->callback_args.now = now;
+   item->callback_args.premature = premature;
+   schedule_work(>callback_work);
} else {
-   e->item.callback(dev, e, seq, now, premature);
+   item->callback(dev, item, seq, now, premature);
}
 }

@@ -1176,7 +1179,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
  e->item.wanted_seq, seq);
list_del(>base.link);
drm_vblank_put(dev, e->item.pipe);
-   drm_wait_vblank_callback(dev, e, seq, , true);
+   drm_wait_vblank_callback(dev, >item, seq, , true);
}
spin_unlock_irqrestore(>event_lock, irqflags);
 }
@@ -1390,14 +1393,11 @@ int drm_modeset_ctl(struct drm_device *dev, void *data,

 static void drm_vblank_event_work_func(struct work_struct *work)
 {
-   struct drm_pending_vblank_event *e =
-   container_of(work, struct drm_pending_vblank_event,
-item.callback_work);
+   struct drm_vblank_wait_item *item =
+   container_of(work, struct drm_vblank_wait_item, callback_work);

-   e->item.callback(e->item.callback_args.dev, e,
-e->item.callback_args.seq,
-e->item.callback_args.now,
-e->item.callback_args.premature);
+   item->callback(item->callback_args.dev, item, item->callback_args.seq,
+  item->callback_args.now, item->callback_args.premature);
 }

 static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
@@ -1472,7 +1472,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e->item.wanted_seq = vblwait->request.sequence;
if ((seq - vblwait->request.sequence) <= (1 << 23)) {
drm_vblank_put(dev, pipe);
-   drm_wait_vblank_callback(dev, e, seq, , false);
+   drm_wait_vblank_callback(dev, >item, seq, , false);
vblwait->reply.sequence = seq;
} else {
/* drm_handle_vblank_events will call drm_vblank_put */
@@ -1654,7 +1654,7 @@ static void drm_handle_vblank_events(struct drm_device 
*dev, int crtc)

list_del(>base.link);
drm_vblank_put(dev, e->item.pipe);
-   drm_wait_vblank_callback(dev, e, seq, , false);
+   drm_wait_vblank_callback(dev, >item, seq, , false);

[RFC 4/7] drm: add wanted_seq to drm_vblank_wait_item

[Paulo Zanoni]

From: Paulo Zanoni 

Store the wanted sequence in the wait_item instead of storing it in
the event structure that is eventually going to be sent to user space.
The plan is to make Kernel vblank wait items not have the user space
event, so we need to store the wanted sequence number somewhere.

It is not a problem that we're not filling e->event.sequence inside
drm_queue_vblank_event: we set the value again inside
send_vblank_event().

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_irq.c | 8 
 include/drm/drmP.h| 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 7dcbbdb..a82e5ca 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1173,7 +1173,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
continue;
DRM_DEBUG("Sending premature vblank event on disable: \
  wanted %d, current %d\n",
- e->event.sequence, seq);
+ e->item.wanted_seq, seq);
list_del(>base.link);
drm_vblank_put(dev, e->item.pipe);
drm_wait_vblank_callback(dev, e, seq, , true);
@@ -1469,7 +1469,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
trace_drm_vblank_event_queued(current->pid, pipe,
  vblwait->request.sequence);

-   e->event.sequence = vblwait->request.sequence;
+   e->item.wanted_seq = vblwait->request.sequence;
if ((seq - vblwait->request.sequence) <= (1 << 23)) {
drm_vblank_put(dev, pipe);
drm_wait_vblank_callback(dev, e, seq, , false);
@@ -1646,11 +1646,11 @@ static void drm_handle_vblank_events(struct drm_device 
*dev, int crtc)
list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
if (e->item.pipe != crtc)
continue;
-   if ((seq - e->event.sequence) > (1<<23))
+   if ((seq - e->item.wanted_seq) > (1<<23))
continue;

DRM_DEBUG("vblank event on %d, current %d\n",
- e->event.sequence, seq);
+ e->item.wanted_seq, seq);

list_del(>base.link);
drm_vblank_put(dev, e->item.pipe);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index b8bc55a..dcec05b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -667,6 +667,7 @@ typedef void (*drm_vblank_callback_t)(struct drm_device 
*dev,

 struct drm_vblank_wait_item {
int pipe;
+   unsigned int wanted_seq;

drm_vblank_callback_t callback;
bool callback_from_work;
-- 
2.1.1

[RFC 3/7] drm: introduce struct drm_vblank_wait_item

[Paulo Zanoni]

From: Paulo Zanoni 

It's supposed to contain all the information that is required for both
kernel and user space vblank wait items, but not hold any information
required by just one of them.

For now, we just moved the struct members from one place to another,
but the long term goal is that most of the drm.ko code will only
handle "struct drm_vblank_wait_item", not knowing anything else. This
will allow the callers to wrap this struct in their own private
structures. This will happen in the next patches.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_fops.c |  2 +-
 drivers/gpu/drm/drm_irq.c  | 42 ++
 include/drm/drmP.h | 10 +++---
 3 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 91e1105..47c5e58 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -289,7 +289,7 @@ static void drm_events_release(struct drm_file *file_priv)
list_for_each_entry_safe(v, vt, >vblank_event_list, base.link)
if (v->base.file_priv == file_priv) {
list_del(>base.link);
-   drm_vblank_put(dev, v->pipe);
+   drm_vblank_put(dev, v->item.pipe);
v->base.destroy(>base);
}

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 099aef1..7dcbbdb 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -893,7 +893,7 @@ static void send_vblank_event(struct drm_device *dev,
list_add_tail(>base.link,
  >base.file_priv->event_list);
wake_up_interruptible(>base.file_priv->event_wait);
-   trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
+   trace_drm_vblank_event_delivered(e->base.pid, e->item.pipe,
 e->event.sequence);
 }

@@ -918,7 +918,7 @@ void drm_send_vblank_event(struct drm_device *dev, int crtc,

now = get_drm_timestamp();
}
-   e->pipe = crtc;
+   e->item.pipe = crtc;
send_vblank_event(dev, e, seq, , false);
 }
 EXPORT_SYMBOL(drm_send_vblank_event);
@@ -1113,14 +1113,14 @@ static void drm_wait_vblank_callback(struct drm_device 
*dev,
 unsigned long seq, struct timeval *now,
 bool premature)
 {
-   if (e->callback_from_work) {
-   e->callback_args.dev = dev;
-   e->callback_args.seq = seq;
-   e->callback_args.now = now;
-   e->callback_args.premature = premature;
-   schedule_work(>callback_work);
+   if (e->item.callback_from_work) {
+   e->item.callback_args.dev = dev;
+   e->item.callback_args.seq = seq;
+   e->item.callback_args.now = now;
+   e->item.callback_args.premature = premature;
+   schedule_work(>item.callback_work);
} else {
-   e->callback(dev, e, seq, now, premature);
+   e->item.callback(dev, e, seq, now, premature);
}
 }

@@ -1169,13 +1169,13 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
seq = drm_vblank_count_and_time(dev, crtc, );

list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
-   if (e->pipe != crtc)
+   if (e->item.pipe != crtc)
continue;
DRM_DEBUG("Sending premature vblank event on disable: \
  wanted %d, current %d\n",
  e->event.sequence, seq);
list_del(>base.link);
-   drm_vblank_put(dev, e->pipe);
+   drm_vblank_put(dev, e->item.pipe);
drm_wait_vblank_callback(dev, e, seq, , true);
}
spin_unlock_irqrestore(>event_lock, irqflags);
@@ -1392,10 +1392,12 @@ static void drm_vblank_event_work_func(struct 
work_struct *work)
 {
struct drm_pending_vblank_event *e =
container_of(work, struct drm_pending_vblank_event,
-callback_work);
+item.callback_work);

-   e->callback(e->callback_args.dev, e, e->callback_args.seq,
-   e->callback_args.now, e->callback_args.premature);
+   e->item.callback(e->item.callback_args.dev, e,
+e->item.callback_args.seq,
+e->item.callback_args.now,
+e->item.callback_args.premature);
 }

 static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
@@ -1417,7 +1419,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
goto err_put;
}

-   e->pipe = pipe;
+   e->item.pipe = pipe;
e->base.pid = current->pid;
e->event.base.type = DRM_EVENT_VBLANK;
e->event.base.length = sizeof e->event;
@@ -1425,10 

[RFC 2/7] drm: allow drm_wait_vblank_kernel() callback from workqueues

[Paulo Zanoni]

From: Paulo Zanoni 

This is going to be needed by i915.ko, and I guess other drivers could
use it too.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_irq.c   | 46 -
 drivers/gpu/drm/i915/i915_debugfs.c | 45 
 include/drm/drmP.h  | 11 -
 3 files changed, 86 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f031f77..099aef1 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1108,6 +1108,22 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_wait_one_vblank);

+static void drm_wait_vblank_callback(struct drm_device *dev,
+struct drm_pending_vblank_event *e,
+unsigned long seq, struct timeval *now,
+bool premature)
+{
+   if (e->callback_from_work) {
+   e->callback_args.dev = dev;
+   e->callback_args.seq = seq;
+   e->callback_args.now = now;
+   e->callback_args.premature = premature;
+   schedule_work(>callback_work);
+   } else {
+   e->callback(dev, e, seq, now, premature);
+   }
+}
+
 /**
  * drm_vblank_off - disable vblank events on a CRTC
  * @dev: DRM device
@@ -1160,7 +1176,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
  e->event.sequence, seq);
list_del(>base.link);
drm_vblank_put(dev, e->pipe);
-   e->callback(dev, e, seq, , true);
+   drm_wait_vblank_callback(dev, e, seq, , true);
}
spin_unlock_irqrestore(>event_lock, irqflags);
 }
@@ -1372,9 +1388,20 @@ int drm_modeset_ctl(struct drm_device *dev, void *data,
return 0;
 }

+static void drm_vblank_event_work_func(struct work_struct *work)
+{
+   struct drm_pending_vblank_event *e =
+   container_of(work, struct drm_pending_vblank_event,
+callback_work);
+
+   e->callback(e->callback_args.dev, e, e->callback_args.seq,
+   e->callback_args.now, e->callback_args.premature);
+}
+
 static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
  union drm_wait_vblank *vblwait,
  struct drm_file *file_priv,
+ bool callback_from_work,
  drm_vblank_callback_t callback)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
@@ -1399,6 +1426,9 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e->base.file_priv = file_priv;
e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
e->callback = callback;
+   e->callback_from_work = callback_from_work;
+   if (callback_from_work)
+   INIT_WORK(>callback_work, drm_vblank_event_work_func);

spin_lock_irqsave(>event_lock, flags);

@@ -1440,7 +1470,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e->event.sequence = vblwait->request.sequence;
if ((seq - vblwait->request.sequence) <= (1 << 23)) {
drm_vblank_put(dev, pipe);
-   e->callback(dev, e, seq, , false);
+   drm_wait_vblank_callback(dev, e, seq, , false);
vblwait->reply.sequence = seq;
} else {
/* drm_handle_vblank_events will call drm_vblank_put */
@@ -1477,6 +1507,7 @@ err_put:
 static int __drm_wait_vblank(struct drm_device *dev,
 union drm_wait_vblank *vblwait,
 struct drm_file *file_priv,
+bool callback_from_work,
 drm_vblank_callback_t callback)
 {
struct drm_vblank_crtc *vblank;
@@ -1533,7 +1564,7 @@ static int __drm_wait_vblank(struct drm_device *dev,
 * drm_vblank_put will be called asynchronously
 */
return drm_queue_vblank_event(dev, crtc, vblwait, file_priv,
- callback);
+ callback_from_work, callback);
}

if ((flags & _DRM_VBLANK_NEXTONMISS) &&
@@ -1573,10 +1604,12 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void 
*data,
 {
union drm_wait_vblank *vblwait = data;

-   return __drm_wait_vblank(dev, vblwait, file_priv, send_vblank_event);
+   return __drm_wait_vblank(dev, vblwait, file_priv, false,
+send_vblank_event);
 }

 int drm_wait_vblank_kernel(struct drm_crtc *crtc, int count, bool absolute,
+  bool callback_from_work,
   drm_vblank_callback_t callback,
   unsigned long user_data)
 {
@@ -1593,7 +1626,8 

[RFC 1/7] drm: allow the drivers to call the vblank IOCTL internally

[Paulo Zanoni]

From: Paulo Zanoni 

The i915.ko driver needs a way to schedule certain functions to run
after some amount of vblanks. There are many different pieces of the
driver which could benefit from that.

Since what we want is essentially the vblank ioctl, this patch does
the minimum change required to allow this ioctl to be called
internally.  The noticeable thing here is that the drivers pass a
callback function, which is called by drm.ko after the specified
amount of vblanks passes.

The great benefit of this minimal change is that all the code
responsible for taking care of properly emptying the queues (e.g.,
when the CRTC is disabled) is already there, so we don't need to
rewrite it.

The current wait vblank IOCTL is now implemented on top of these
changes, and it provides its own callback: send_vblank_event().

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_ioctl.c |  2 +-
 drivers/gpu/drm/drm_irq.c   | 65 +
 drivers/gpu/drm/i915/i915_debugfs.c | 62 +++
 include/drm/drmP.h  | 13 ++--
 4 files changed, 125 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 00587a1..fb35173 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -578,7 +578,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SG_ALLOC, drm_legacy_sg_alloc, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_SG_FREE, drm_legacy_sg_free, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),

-   DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank, DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_WAIT_VBLANK, drm_wait_vblank_ioctl, 
DRM_UNLOCKED),

DRM_IOCTL_DEF(DRM_IOCTL_MODESET_CTL, drm_modeset_ctl, 0),

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0e47df4..f031f77 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -882,7 +882,8 @@ EXPORT_SYMBOL(drm_vblank_count_and_time);

 static void send_vblank_event(struct drm_device *dev,
struct drm_pending_vblank_event *e,
-   unsigned long seq, struct timeval *now)
+   unsigned long seq, struct timeval *now,
+   bool premature)
 {
WARN_ON_SMP(!spin_is_locked(>event_lock));
e->event.sequence = seq;
@@ -918,7 +919,7 @@ void drm_send_vblank_event(struct drm_device *dev, int crtc,
now = get_drm_timestamp();
}
e->pipe = crtc;
-   send_vblank_event(dev, e, seq, );
+   send_vblank_event(dev, e, seq, , false);
 }
 EXPORT_SYMBOL(drm_send_vblank_event);

@@ -1159,7 +1160,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
  e->event.sequence, seq);
list_del(>base.link);
drm_vblank_put(dev, e->pipe);
-   send_vblank_event(dev, e, seq, );
+   e->callback(dev, e, seq, , true);
}
spin_unlock_irqrestore(>event_lock, irqflags);
 }
@@ -1373,7 +1374,8 @@ int drm_modeset_ctl(struct drm_device *dev, void *data,

 static int drm_queue_vblank_event(struct drm_device *dev, int pipe,
  union drm_wait_vblank *vblwait,
- struct drm_file *file_priv)
+ struct drm_file *file_priv,
+ drm_vblank_callback_t callback)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
struct drm_pending_vblank_event *e;
@@ -1396,6 +1398,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e->base.event = >event.base;
e->base.file_priv = file_priv;
e->base.destroy = (void (*) (struct drm_pending_event *)) kfree;
+   e->callback = callback;

spin_lock_irqsave(>event_lock, flags);

@@ -1411,12 +1414,15 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, int pipe,
goto err_unlock;
}

-   if (file_priv->event_space < sizeof e->event) {
-   ret = -EBUSY;
-   goto err_unlock;
+   if (file_priv) {
+   if (file_priv->event_space < sizeof e->event) {
+   ret = -EBUSY;
+   goto err_unlock;
+   }
+
+   file_priv->event_space -= sizeof e->event;
}

-   file_priv->event_space -= sizeof e->event;
seq = drm_vblank_count_and_time(dev, pipe, );

if ((vblwait->request.type & _DRM_VBLANK_NEXTONMISS) &&
@@ -1434,7 +1440,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
int pipe,
e->event.sequence = vblwait->request.sequence;
if ((seq - vblwait->request.sequence) <= (1 << 23)) {
drm_vblank_put(dev, pipe);
-   send_vblank_event(dev, e, seq, );
+   e->callback(dev, e, seq, , false);
vblwait->reply.sequence = 

[RFC] drm: add a mechanism for drivers to schedule vblank callbacks

[Paulo Zanoni]

From: Paulo Zanoni 

The drivers need a way to schedule functions to be ran after a certain
number of vblanks. The i915.ko driver has plenty of examples where
this could be used, such as for unpinning buffers after a modeset.
Since the vblank wait IOCTL does basically what we want, but for the
user space, in this patch we add a new list of vblank events
(dev->vblank_kernel_list) and handle it exactly like we handle the
user space events.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/drm_drv.c   |   1 +
 drivers/gpu/drm/drm_irq.c   | 106 ++--
 drivers/gpu/drm/i915/i915_debugfs.c |  81 +++
 include/drm/drmP.h  |  22 
 4 files changed, 206 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 2e5c7d9..b5ae6c8 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -557,6 +557,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
INIT_LIST_HEAD(>vmalist);
INIT_LIST_HEAD(>maplist);
INIT_LIST_HEAD(>vblank_event_list);
+   INIT_LIST_HEAD(>vblank_kernel_list);

spin_lock_init(>buf_lock);
spin_lock_init(>event_lock);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0e47df4..6e04035 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1107,6 +1107,13 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_wait_one_vblank);

+static void send_kernel_vblank_event(struct drm_kernel_vblank_item *item)
+{
+   if (item->callback_from_work)
+   schedule_work(>work);
+   else
+   item->callback(item);
+}
 /**
  * drm_vblank_off - disable vblank events on a CRTC
  * @dev: DRM device
@@ -1124,7 +1131,8 @@ EXPORT_SYMBOL(drm_crtc_wait_one_vblank);
 void drm_vblank_off(struct drm_device *dev, int crtc)
 {
struct drm_vblank_crtc *vblank = >vblank[crtc];
-   struct drm_pending_vblank_event *e, *t;
+   struct drm_pending_vblank_event *e, *et;
+   struct drm_kernel_vblank_item *i, *it;
struct timeval now;
unsigned long irqflags;
unsigned int seq;
@@ -1151,7 +1159,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
/* Send any queued vblank events, lest the natives grow disquiet */
seq = drm_vblank_count_and_time(dev, crtc, );

-   list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
+   list_for_each_entry_safe(e, et, >vblank_event_list, base.link) {
if (e->pipe != crtc)
continue;
DRM_DEBUG("Sending premature vblank event on disable: \
@@ -1161,6 +1169,21 @@ void drm_vblank_off(struct drm_device *dev, int crtc)
drm_vblank_put(dev, e->pipe);
send_vblank_event(dev, e, seq, );
}
+
+   list_for_each_entry_safe(i, it, >vblank_kernel_list, link) {
+   int pipe = drm_crtc_index(i->crtc);
+
+   if (pipe != crtc)
+   continue;
+
+   DRM_DEBUG("Sending premature kernel vblank event on disable: \
+ wanted %d, current %d\n",
+ i->target_seq, seq);
+   i->premature = true;
+   list_del(>link);
+   drm_vblank_put(dev, pipe);
+   send_kernel_vblank_event(i);
+   }
spin_unlock_irqrestore(>event_lock, irqflags);
 }
 EXPORT_SYMBOL(drm_vblank_off);
@@ -1560,9 +1583,68 @@ done:
return ret;
 }

+static void drm_kernel_vblank_work_func(struct work_struct *work)
+{
+   struct drm_kernel_vblank_item *item =
+   container_of(work, struct drm_kernel_vblank_item, work);
+
+   item->callback(item);
+}
+
+int drm_wait_vblank_kernel(struct drm_kernel_vblank_item *item)
+{
+   struct drm_crtc *crtc = item->crtc;
+   struct drm_device *dev = crtc->dev;
+   int pipe = drm_crtc_index(crtc);
+   struct drm_vblank_crtc *vblank = >vblank[pipe];
+   unsigned int seq;
+   unsigned long irqflags;
+   int ret = 0;
+
+   if (!dev->irq_enabled)
+   return -EINVAL;
+
+   if (item->callback_from_work)
+   INIT_WORK(>work, drm_kernel_vblank_work_func);
+
+   ret = drm_vblank_get(dev, pipe);
+   if (ret) {
+   DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
+   return ret;
+   }
+
+   seq = drm_vblank_count(dev, pipe);
+   if (!item->absolute)
+   item->target_seq += seq;
+
+   spin_lock_irqsave(>event_lock, irqflags);
+
+   if (!vblank->enabled) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   if (seq - item->target_seq <= (1 << 23)) {
+   drm_vblank_put(dev, pipe);
+   send_kernel_vblank_event(item);
+   } else {
+   list_add_tail(>link, 

[RFC 0/7+1] Add in-kernel vblank delaying mechanism

[Paulo Zanoni]

From: Paulo Zanoni 

Hi

---
TL;DR summary:
I wrote patches. Help me choose the best implementation and interface.
---

So the i915.ko driver could use some mechanism to run functions after a given
number of vblanks. Implementations for this mechanism were already proposed in
the past (by Chris Wilson and others), but they were i915-specific instead of a
generic drm.ko implementation. We even had patches that make use of this new
mechanism.

Since this is very similar to the vblank IOCTL we currently have, but with the
caller being a Kernel module instead of user space, I decided to write an
implementation that tries to reuse the current IOCTL infrastructure.

In the first patch we add all the necessary code to allow the modules to call
the vblank ioctl from Kernel space: they provide a callback function that is
going to be called instead of the traditional send_vblank_event(), which means
the Kernel callers don't have to deal with the file descriptors and DRM events.

In the second patch we add a simple extension of the feature, to allow the
drivers to have their callbacks called in a non-atomic context.

In all the other subsequent patches we rework the underlying code so that
the common aspects between the user space vblank IOCTL and the Kernel interface
are all stored in a single structure (struct drm_vblank_wait_item), and then
anything that is specific to the different users is stored in a structure that
contains struct drm_vblank_wait_item. This way, most of the drm.ko code only
needs to deal with struct drm_vblank_wait_item, not really knowing how it is
wrapped. The advantage of this rework is that it reduces the number of memory
allocations needed in some cases (from 2 to 1) and it also reduces the amount of
memory used on each allocation.

But while this all sounds nice in the above description, I had the feeling that
this adds a lot of complexity and makes the code not-so-beautiful. If we ever
need more extensions/options to this feature, we're going to have to untangle
the code even more from the IOCTL part. We also have a small "abstraction break"
in change introduced in patch 6. And there's the risk that some of the reworks
may have added a regression somewhere.

Based on that, I decided to also provide an alternative implementation. In this
implementation we add a new dev->vblank_kernel_list instead of reusing
dev->vblank_event_list, and add new code to handle that this. This new code is
completely based on the code that handles dev->vblank_kernel_list, so there's
some duplication here. On the other hand, since the in-Kernel infrastructure is
not tied to the IOCTL structure, we can very easily grow and adapt the Kernel
code without having to fight against the IOCTL code. And the risk of regressions
is greatly reduced.

The second difference of this alternative implementation is the signature of the
drm_wait_vblank_kernel() function. While it could be exactly the same as the one
used in the other series, I decided to make it different so we can also choose
which one to use. In the 7-patch series implementation, all the user needs to do
is to allocate the structure, and call the function, properly setting all its
arguments. Then the function is responsible for parsing the arguments and
populating the structure based on that. On the alternative implementation, the
user has to fill the structure with the appropriate arguments, and then call
drm_wait_vblank_kernel() passing just the allocated structure as an argument.

If you notice, you will see that these patches add a new debugfs file to
i915.ko. This file is just a very simple example user of the new interface,
which I used while developing. If you have difficulty understanding the new
interface, please also look at the i915/i915_debugfs.c diff. Of course, I plan
to exclude this debugfs interface from the final to-be-merged patches.

So, in summary, we have a few things we need to discuss:

 1. Which implementation to use?

   a. Just the 2 first patches of the 7-patch series?
  Pros:
- the Kernel users basically call the vblank IOCTL
- the code changes are minimal
 Cons:
- The amount of memory allocations and memory space consumed is not
  optimal

   b. The full 7-patch series?
  Pros:
- The same backend is used for both the Kernel and IOCTL.
  Cons:
- The code gets more complex.
- Extending the Kernel interface can get complicated due to the fact
  that it shares code with the IOCTL interface.
- I didn't really like this solution.

   c. The alternative implementation I wrote?
  Pros:
- It's independent from the IOCTL code, making further patches easier.
  Cons:
- There is some duplicated code.

   d. Something totally different from these alternatives?

 2. How should the driver interface look like?

   a. All the possibilities are passed through the function call, so the drm.ko
  code needs to set 

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Andreas Färber]

Am 19.11.2014 um 17:28 schrieb Javier Martinez Canillas:
> On 11/19/2014 05:22 PM, Paolo Pisati wrote:
>> On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote:
>>>
>>> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
>>> the needed patches.
>>>
>>> Ajay, feel free to add to your series:
>>>
>>> Tested-by: Javier Martinez Canillas 
>>>
>>> Best regards,
>>> Javier
>>>
>>> [0]: git://git.collabora.co.uk/git/user/javier/linux.git wip/exynos/dp-integ
>>
>> doesn't peach pi require the same dts modification as peach pit/snow?
>>
> 
> No, because the Peach Pit and Snow have an eDP to LVDS bridge chip but the
> Peach Pi does not have a bridge. Ajay's series is to add DRM bridge support
> to Exynos Display Port driver and so is only relevant to Snow and Pit.

... and to Spring.

So, what's the timing here - is this series headed for 3.20 now or 3.19?

Regards,
Andreas

-- 
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 21284 AG Nürnberg

[PATCH 1/1] DRM-UDL: Deletion of an unnecessary check before the function call "vunmap"

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Nov 2014 17:33:32 +0100

The vunmap() function performes also input parameter validation. Thus the test
around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/udl/udl_gem.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 8044f5f..2979625 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -164,8 +164,7 @@ void udl_gem_vunmap(struct udl_gem_object *obj)
return;
}

-   if (obj->vmapping)
-   vunmap(obj->vmapping);
+   vunmap(obj->vmapping);

udl_gem_put_pages(obj);
 }
-- 
2.1.3

[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Vivek Gautam]

Hi Javier,


On Wed, Nov 19, 2014 at 5:06 PM, Javier Martinez Canillas
 wrote:
> [adding Kukjin to cc list]
>
> Hello Vivek,
>
> On Wed, Nov 12, 2014 at 5:21 AM, Jingoo Han  wrote:
>> On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
>>>
>>> DP PHY now require pmu-system-controller to handle PMU register
>>> to control PHY's power isolation. Adding the same to dp-phy
>>> node.
>>>
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Jingoo Han 
>>
>> Reviewed-by: Jingoo Han 
>>
>
> Tested-by: Javier Martinez Canillas 

Thanks for testing.

>
> Kukjin,

Sorry for not adding Kukjin to the list and thereby for the delay
about this patch.

>
> This patch is -rc material and is needed to have display working in
> 3.18 again since commit a5ec598 ("phy: exynos-dp-video: Use syscon
> support to control pmu register") landed in 3.18 and broke the Exynos
> Display Port PHY:
>
> exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap

Yes, we should pick this up and merge it since the driver patch is merged now.



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Javier Martinez Canillas]

Hello Paolo,

On 11/19/2014 05:22 PM, Paolo Pisati wrote:
> On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote:
>> 
>> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
>> the needed patches.
>> 
>> Ajay, feel free to add to your series:
>> 
>> Tested-by: Javier Martinez Canillas 
>> 
>> Best regards,
>> Javier
>> 
>> [0]: git://git.collabora.co.uk/git/user/javier/linux.git wip/exynos/dp-integ
> 
> doesn't peach pi require the same dts modification as peach pit/snow?
> 

No, because the Peach Pit and Snow have an eDP to LVDS bridge chip but the
Peach Pi does not have a bridge. Ajay's series is to add DRM bridge support
to Exynos Display Port driver and so is only relevant to Snow and Pit.

Best regards,
Javier

[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes

[Alex Deucher]

On Wed, Nov 19, 2014 at 4:59 PM, Alexandre Demers
 wrote:
> Technical reminder about this patch: usually, for electronic
> stability, you'll have to raise the voltage BEFORE increasing the
> clock speed; on the other, you'll have to lower the voltage AFTER
> lowering the clock speed. You may encounter stability problem if you
> don't follow this order.
>
> The patch fixes the first case, but you may end up creating the
> opposite problem by only moving
> ci_apply_disp_minimum_voltage_request(rdev) earlier in the process.
> But it may actually be covered by ci_send_msg_to_smc_with_parameter()
> or it may not be actually what ci_upload_dpm_level_enable_mask() is
> about.
>
> Is this patch linked to a specific bug?

There's no specific bug and the smc actually changes the voltages and
clocks internally in firmware so the driver doesn't really have to
worry about that.  This specific function just tells the smc to set a
new voltage floor based on potentially new requirements from the
display hw.  I don't know of any specific problems, it's just the
current recommended order from the power teams.

Alex

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Paolo Pisati]

On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote:
> 
> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
> the needed patches.
> 
> Ajay, feel free to add to your series:
> 
> Tested-by: Javier Martinez Canillas 
> 
> Best regards,
> Javier
> 
> [0]: git://git.collabora.co.uk/git/user/javier/linux.git wip/exynos/dp-integ

doesn't peach pi require the same dts modification as peach pit/snow?

-- 
bye,
p.

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

[Christian König]

raw_spin_unlock_irqrestore+0xc/0xd
> [  117.820303]  [] ? radeon_drm_ioctl+0x4b/0x7a [radeon]
> [  117.820331]  [] ? do_vfs_ioctl+0x34e/0x404
> [  117.820355]  [] ? vfs_read+0xbc/0xea
> [  117.820377]  [] ? SyS_ioctl+0x51/0x77
> [  117.820398]  [] ? system_call_fastpath+0x12/0x17
> [  117.820423] Code: 00 00 80 ff 77 00 00 48 01 fa 48 0f 42 0d 78 99 6f 00 48 
> 8d
> 04 11 48 ba 00 00 00 00 00 ea ff ff 48 c1 e8 0c 48 6b c0 38 48 01 d0 <48> 8b 
> 10
> 80 e6 80 74 0e 48 8b 50 30 48 8b 08 80 e5 80 48 0f 45
> [  117.820582] RIP  [] virt_to_head_page+0x33/0x4a
> [  117.820608]  RSP 
> [  117.820622] CR2: eae3801564d8
> [  117.838461] ---[ end trace a6e2a6aa1df3196f ]---
>
> I've used Dave Airlie's drm-next as a base (commit
> d0d6c524bf1d72e6d64134c3a315b77deecc9252) and "git am"-applied your series (no
> issues, applied cleanly) on top. Steam games are still entering the defunct
> state as soon as the 3D engines are fired up on a kernel built from that 
> source
> tree.
>
> This is with (Debian testing as a base):
> GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
> Mesa: Git:master/b69c7c5dac
> libdrm: Git:master/00847fa48b
> LLVM: SVN:trunk/r54 (3.6 devel)
> X.Org: 2:1.16.1-1
> Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
> # 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
> # c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
> # 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
> # c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
> # 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
> # ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
> # 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
> # 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
> libclc: Git:master/7f6f5bff1f
> DDX: 1:7.5.0-1
>
> Let me know, if you need something else; see also the original thread
> <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further 
> information.
>
> Cheers,
> Kai
>

-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-update-the-VM-after-setting-BO-address-v4.patch
Type: text/x-diff
Size: 2831 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/253ea8dc/attachment.patch>

[PATCH 1/1] DRM-tilcdc: Deletion of an unnecessary check before the function call "drm_fbdev_cma_hotplug_event"

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Nov 2014 17:05:20 +0100

The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 000428e..335b1dc 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -58,8 +58,7 @@ static struct drm_framebuffer *tilcdc_fb_create(struct 
drm_device *dev,
 static void tilcdc_fb_output_poll_changed(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
-   if (priv->fbdev)
-   drm_fbdev_cma_hotplug_event(priv->fbdev);
+   drm_fbdev_cma_hotplug_event(priv->fbdev);
 }

 static const struct drm_mode_config_funcs mode_config_funcs = {
-- 
2.1.3

[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes

[Alexandre Demers]

Technical reminder about this patch: usually, for electronic
stability, you'll have to raise the voltage BEFORE increasing the
clock speed; on the other, you'll have to lower the voltage AFTER
lowering the clock speed. You may encounter stability problem if you
don't follow this order.

The patch fixes the first case, but you may end up creating the
opposite problem by only moving
ci_apply_disp_minimum_voltage_request(rdev) earlier in the process.
But it may actually be covered by ci_send_msg_to_smc_with_parameter()
or it may not be actually what ci_upload_dpm_level_enable_mask() is
about.

Is this patch linked to a specific bug?

Alexandre Demers

Long radeon stalls on recent kernels

[Andy Lutomirski]

On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski  wrote:
> On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer  
> wrote:
>> On 19.11.2014 09:21, Andy Lutomirski wrote:
>>>
>>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer  
>>> wrote:

 On 15.11.2014 07:21, Andy Lutomirski wrote:
>
>
> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
> graphics intensive seems to cause my system to become unusable for
> tens of seconds.  Pointing Firefox at Google Maps is a big offender --
> it can take several minutes for me to move my mouse far enough to
> close the tab and get my computer back.
>
> On bootup, I get this warning:
> [drm:btc_dpm_set_power_state] *ERROR*
> rv770_restrict_performance_levels_before_switch failed
>
> Setting radeon.dpm=0 seems to work around this problem at the cost of
> giving my rather slow graphics.
>
> Are there known issues here?



 Can you bisect the kernel, or at least isolate which kernel version first
 introduced the problem?
>>>
>>>
>>> With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15,
>>> 3.16, and 3.18-rc4+.  I haven't tried other versions.
>>>
>>> With radeon.dpm=0, I can still trigger short stalls (around one
>>> second), but I seem unable to trigger long stalls easily.  (I say
>>> easily because, just as I was typing this email, my system stalled for
>>> about a minute.)
>>
>>
>> I can only think of two things offhand that could cause such extremely long
>> stalls: Swap thrashing or IRQ storms.
>>
>> With a setup where you can easily trigger long stalls, can you try getting a
>> CPU profile for a stall with sysprof or perf?
>>
>>
>
> Got one with perf:
>
>   16.82% Xorg  libc-2.18.so[.]
> __memcpy_sse2_unaligned
>9.20%  swapper  [kernel.kallsyms]   [k] intel_idle
>1.00% Xorg  [kernel.kallsyms]   [k]
> evergreen_irq_set
>0.83%  firefox  libxul.so   [.]
> 0x01d93281
>0.69%  firefox  libxul.so   [.]
> 0x01d932ad
>0.62%  firefox  [kernel.kallsyms]   [k]
> copy_user_generic_string
>0.55%  swapper  [kernel.kallsyms]   [k]
> evergreen_irq_ack
>0.54%  firefox  libpthread-2.18.so  [.]
> pthread_mutex_lock
>0.52%  firefox  libpthread-2.18.so  [.]
> pthread_mutex_unlock
>0.45% Xorg  [kernel.kallsyms]   [k]
> drm_mm_insert_node_in_range_generic
>0.41% Xorg  [kernel.kallsyms]   [k] 
> lock_release
>0.40% Xorg  [kernel.kallsyms]   [k] 
> lock_acquire
>0.35%  firefox  firefox [.]
> 0x0001245d
>0.33% Xorg  [kernel.kallsyms]   [k]
> __module_address
>0.31%  firefox  [kernel.kallsyms]   [k] 
> clear_page_c
>0.29% Xorg  [kernel.kallsyms]   [k]
> copy_user_generic_string
>0.28%  firefox  firefox [.]
> 0x00013159
>
> and:
>
> Samples: 11K of event 'irq:irq_handler_entry', Event count (approx.): 11802
>   87.43%  swapper  [kernel.kallsyms]  [k] handle_irq_event_percpu
>7.52%  firefox  [kernel.kallsyms]  [k] handle_irq_event_percpu
>1.84%  irq/36-ahci  [kernel.kallsyms]  [k] handle_irq_event_percpu
>1.14% Xorg  [kernel.kallsyms]  [k] handle_irq_event_percpu
>0.75%  kworker/5:0  [kernel.kallsyms]  [k] handle_irq_event_percpu
>0.32%  gnome-shell  [kernel.kallsyms]  [k] handle_irq_event_percpu
>0.25% kworker/5:1H  [kernel.kallsyms]  [k] handle_irq_event_percpu
>0.25%  Media D~ode #10  [kernel.kallsyms]  [k] handle_irq_event_percpu
>0.19%  ImageDe~er #330  [kernel.kallsyms]  [k] handle_irq_event_percpu
>0.07%   pulseaudio  [kernel.kallsyms]  [k] handle_irq_event_percpu
>
> The cycles were with -e cycles:pp, so I think that iret would have
> shown up if there were enough IRQs to cause the problem.
>
> I'll build a kernel with latencytop.
>

I just caught call_rwsem_down_write_failed for 5379 ms in khugepaged
(holy crap) and radeon_fence_default_wait for 489.2ms in Xorg.

Turning off THP gets rid of the khugepaged thing.  The 489.2ms is
radeon_fence_default_wait is amazingly reproducible -- I've seen that
exact number three times now.

> --Andy



-- 
Andy Lutomirski
AMA Capital Management, LLC

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #7 from Alex Deucher  ---
Should be fixed by
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83d04c39f9048807a8500e575ae3f1718a3f45bb
which needs to go to stable.

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

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

[Kai Wasserbäch]

7deecc9252) and "git am"-applied your series (no
issues, applied cleanly) on top. Steam games are still entering the defunct
state as soon as the 3D engines are fired up on a kernel built from that source
tree.

This is with (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/b69c7c5dac
libdrm: Git:master/00847fa48b
LLVM: SVN:trunk/r54 (3.6 devel)
X.Org: 2:1.16.1-1
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
# 9e05820da42549ce9c89d147cf1f8e19  hawaii_ce.bin
# c8bab593090fc54f239c8d7596c8d846  hawaii_mc.bin
# 3618dbb955d8a84970e262bb2e6d2a16  hawaii_me.bin
# c000b0fc9ff6582145f66504b0ec9597  hawaii_mec.bin
# 0643ad24b3beff2214cce533e094c1b7  hawaii_pfp.bin
# ba6054b7d78184a74602fd81607e1386  hawaii_rlc.bin
# 11288f635737331b69de9ee82fe04898  hawaii_sdma.bin
# 284429675a5560e0fad42aa982965fc2  hawaii_smc.bin
libclc: Git:master/7f6f5bff1f
DDX: 1:7.5.0-1

Let me know, if you need something else; see also the original thread
<http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further 
information.

Cheers,
Kai

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/5e6b6ca9/attachment.sig>

[PATCH 1/1] DRM-EDID: Deletion of an unnecessary check before the function call "release_firmware"

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 19 Nov 2014 16:33:17 +0100

The release_firmware() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/drm_edid_load.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 0a235fe..732cb6f 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -254,8 +254,7 @@ static void *edid_load(struct drm_connector *connector, 
const char *name,
name, connector_name);

 out:
-   if (fw)
-   release_firmware(fw);
+   release_firmware(fw);
return edid;
 }

-- 
2.1.3

Long radeon stalls on recent kernels

[Michel Dänzer]

On 19.11.2014 09:21, Andy Lutomirski wrote:
> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer  wrote:
>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>
>>> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
>>> graphics intensive seems to cause my system to become unusable for
>>> tens of seconds.  Pointing Firefox at Google Maps is a big offender --
>>> it can take several minutes for me to move my mouse far enough to
>>> close the tab and get my computer back.
>>>
>>> On bootup, I get this warning:
>>> [drm:btc_dpm_set_power_state] *ERROR*
>>> rv770_restrict_performance_levels_before_switch failed
>>>
>>> Setting radeon.dpm=0 seems to work around this problem at the cost of
>>> giving my rather slow graphics.
>>>
>>> Are there known issues here?
>>
>>
>> Can you bisect the kernel, or at least isolate which kernel version first
>> introduced the problem?
>
> With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15,
> 3.16, and 3.18-rc4+.  I haven't tried other versions.
>
> With radeon.dpm=0, I can still trigger short stalls (around one
> second), but I seem unable to trigger long stalls easily.  (I say
> easily because, just as I was typing this email, my system stalled for
> about a minute.)

I can only think of two things offhand that could cause such extremely 
long stalls: Swap thrashing or IRQ storms.

With a setup where you can easily trigger long stalls, can you try 
getting a CPU profile for a stall with sysprof or perf?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

3.18-rc regression: drm/nouveau: use shared fences for readable objects

[Tobias Klausmann]

On 19.11.2014 09:10, Maarten Lankhorst wrote:
> Hey,
>
> On 19-11-14 07:43, Michael Marineau wrote:
>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>> lockups shortly after startup, accompanied with one or both of the
>> following errors:
>>
>> nouveau E[   PFIFO][:01:00.0] read fault at 0x000734a000 [PTE]
>> from PBDMA0/HOST_CPU on channel 0x007faa3000 [unknown]
>> nouveau E[ DRM] GPU lockup - switching to software fbcon
>>
>> I was able to trace the issue with bisect to commit
>> 809e9447b92ffe1346b2d6ec390e212d5307f61c "drm/nouveau: use shared
>> fences for readable objects". The lockups appear to have cleared up
>> since reverting that and a few related followup commits:
>>
>> 809e9447: "drm/nouveau: use shared fences for readable objects"
>> 055dffdf: "drm/nouveau: bump driver patchlevel to 1.2.1"
>> e3be4c23: "drm/nouveau: specify if interruptible wait is desired in
>> nouveau_fence_sync"
>> 15a996bb: "drm/nouveau: assign fence_chan->name correctly"
> Weird. I'm not sure yet what causes it.
>
> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?h=fixed-fences-for-bisect=86be4f216bbb9ea3339843a5658d4c21162c7ee2
>
> On the EDITED patch from fixed-fences-for-bisect, can you do the following:
>
> In nouveau/nv84_fence.c function nv84_fence_context_new, remove
>
> fctx->base.sequence = nv84_fence_read(chan);
>
> and add back
>
> nouveau_bo_wr32(priv->bo, chan->chid * 16/4, 0x);
>
> If that fails you should compile your kernel with trace events, to get some 
> debugging info from the fences. I'll post debugging info if this does not fix 
> it.
>
> ~Maarten

Hey,
as mentioned in IRC the new fencing hangs my GPU for a while as well (nve7).
Bisected back to  86be4f216bbb9ea3339843a5658d4c21162c7ee2
, EDITED

from the fixed-fences-for-bisect branch mentioned above.

Original bisect on linus brach brought me to:
29ba89b2371d466ca68973525816cf10debc2655
drm/nouveau: rework to new fence interface

Michael if you are going to bisect the "fixed-fences-for-bisect" branch, 
maybe take a closer look if you come anywhere near that commit, if that 
does or does not trigger the GPU hangs for you!

Tobias

[Bug 88501] AMD/ATI RS690M Console blanks to white

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

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

--- Comment #2 from business.kid at gmail.com ---
Created attachment 158201
  --> https://bugzilla.kernel.org/attachment.cgi?id=158201=edit
Kernel Config 3.6.0-rc5+

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

Long radeon stalls on recent kernels

[Andy Lutomirski]

On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer  wrote:
> On 19.11.2014 09:21, Andy Lutomirski wrote:
>>
>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer  
>> wrote:
>>>
>>> On 15.11.2014 07:21, Andy Lutomirski wrote:


 On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
 graphics intensive seems to cause my system to become unusable for
 tens of seconds.  Pointing Firefox at Google Maps is a big offender --
 it can take several minutes for me to move my mouse far enough to
 close the tab and get my computer back.

 On bootup, I get this warning:
 [drm:btc_dpm_set_power_state] *ERROR*
 rv770_restrict_performance_levels_before_switch failed

 Setting radeon.dpm=0 seems to work around this problem at the cost of
 giving my rather slow graphics.

 Are there known issues here?
>>>
>>>
>>>
>>> Can you bisect the kernel, or at least isolate which kernel version first
>>> introduced the problem?
>>
>>
>> With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15,
>> 3.16, and 3.18-rc4+.  I haven't tried other versions.
>>
>> With radeon.dpm=0, I can still trigger short stalls (around one
>> second), but I seem unable to trigger long stalls easily.  (I say
>> easily because, just as I was typing this email, my system stalled for
>> about a minute.)
>
>
> I can only think of two things offhand that could cause such extremely long
> stalls: Swap thrashing or IRQ storms.
>
> With a setup where you can easily trigger long stalls, can you try getting a
> CPU profile for a stall with sysprof or perf?
>
>

Got one with perf:

  16.82% Xorg  libc-2.18.so[.]
__memcpy_sse2_unaligned
   9.20%  swapper  [kernel.kallsyms]   [k] intel_idle
   1.00% Xorg  [kernel.kallsyms]   [k]
evergreen_irq_set
   0.83%  firefox  libxul.so   [.]
0x01d93281
   0.69%  firefox  libxul.so   [.]
0x01d932ad
   0.62%  firefox  [kernel.kallsyms]   [k]
copy_user_generic_string
   0.55%  swapper  [kernel.kallsyms]   [k]
evergreen_irq_ack
   0.54%  firefox  libpthread-2.18.so  [.]
pthread_mutex_lock
   0.52%  firefox  libpthread-2.18.so  [.]
pthread_mutex_unlock
   0.45% Xorg  [kernel.kallsyms]   [k]
drm_mm_insert_node_in_range_generic
   0.41% Xorg  [kernel.kallsyms]   [k] lock_release
   0.40% Xorg  [kernel.kallsyms]   [k] lock_acquire
   0.35%  firefox  firefox [.]
0x0001245d
   0.33% Xorg  [kernel.kallsyms]   [k]
__module_address
   0.31%  firefox  [kernel.kallsyms]   [k] clear_page_c
   0.29% Xorg  [kernel.kallsyms]   [k]
copy_user_generic_string
   0.28%  firefox  firefox [.]
0x00013159

and:

Samples: 11K of event 'irq:irq_handler_entry', Event count (approx.): 11802
  87.43%  swapper  [kernel.kallsyms]  [k] handle_irq_event_percpu
   7.52%  firefox  [kernel.kallsyms]  [k] handle_irq_event_percpu
   1.84%  irq/36-ahci  [kernel.kallsyms]  [k] handle_irq_event_percpu
   1.14% Xorg  [kernel.kallsyms]  [k] handle_irq_event_percpu
   0.75%  kworker/5:0  [kernel.kallsyms]  [k] handle_irq_event_percpu
   0.32%  gnome-shell  [kernel.kallsyms]  [k] handle_irq_event_percpu
   0.25% kworker/5:1H  [kernel.kallsyms]  [k] handle_irq_event_percpu
   0.25%  Media D~ode #10  [kernel.kallsyms]  [k] handle_irq_event_percpu
   0.19%  ImageDe~er #330  [kernel.kallsyms]  [k] handle_irq_event_percpu
   0.07%   pulseaudio  [kernel.kallsyms]  [k] handle_irq_event_percpu

The cycles were with -e cycles:pp, so I think that iret would have
shown up if there were enough IRQs to cause the problem.

I'll build a kernel with latencytop.

--Andy

[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

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

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

--- Comment #7 from Alex Deucher  ---
possibly related bug 73528.

-- 
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/20141119/76751ce7/attachment.html>

[PATCH v2] drm/tilcdc: add missing clk_put in tilcdc_unload()

[Julien CHAUVEAU]

We need to call clk_put on display clock, in the same way as functional clock.
Also remove the check for priv->clk, since clk_put() is safe against NULL 
pointers.

Signed-off-by: Julien CHAUVEAU 
---
Changes since v1:
- remove the check for priv->clk, as suggested by Felipe Balbi

 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 79a34cb..b0c9687 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -136,8 +136,8 @@ static int tilcdc_unload(struct drm_device *dev)
CPUFREQ_TRANSITION_NOTIFIER);
 #endif

-   if (priv->clk)
-   clk_put(priv->clk);
+   clk_put(priv->disp_clk);
+   clk_put(priv->clk);

if (priv->mmio)
iounmap(priv->mmio);
-- 
2.1.0

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

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

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

Daniel Otero  changed:

   What|Removed |Added

 Attachment #158101|application/octet-stream|text/plain
  mime type||

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

[Bug 88501] AMD/ATI RS690M Console blanks to white

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

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

--- Comment #1 from business.kid at gmail.com ---
Created attachment 158191
  --> https://bugzilla.kernel.org/attachment.cgi?id=158191=edit
LSPCI -vnn

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

[Bug 88501] New: AMD/ATI RS690M Console blanks to white

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

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

Bug ID: 88501
   Summary: AMD/ATI RS690M Console blanks to white
   Product: Drivers
   Version: 2.5
Kernel Version: 3.6.0-rc5 to 3.18.0-rc4
  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: business.kid at gmail.com
Regression: Yes

Created attachment 158181
  --> https://bugzilla.kernel.org/attachment.cgi?id=158181=edit
Git Bisect log, & git visualise o/p

Without X running, linux consoles blank after a period adjustable by setterm.
Mine does not. It goes white. If I invert the screen colours, it goes whiter.
Backlight?
I cloned the Linus-stable git and tried it. 3.18.0-rc4 twists this slightly -
The FIRST time the screen blanks, it does so correctly; every other time, it
blanks to white. 
I'm a hardware guy, not a software expert. Git bisect gives the output below.
Details of the box also attached

The box is a HP 6715S, twin core Turion, 3G ram. It's running Slackware-current
as of Sept 30th, 2014. LSPCI output attached. Bios Version: ATI 02/13/08,1.

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

[PATCH 6/6] drm/atomic_helper: Make it clear that commit_planes gets the old state

[Rob Clark]

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter  
wrote:
> Oversight from my kerneldoc cleanup when doing the original atomic
> helper series - I've only applied this clarification to the modeset
> related helpers, and not the plane update code. Remedy this asap.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 99095ef147ef..690360038dc1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -976,18 +976,18 @@ EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
>  /**
>   * drm_atomic_helper_commit_planes - commit plane state
>   * @dev: DRM device
> - * @state: atomic state
> + * @old_state: atomic state object with old state structures
>   *
>   * This function commits the new plane state using the plane and atomic 
> helper
>   * functions for planes and crtcs. It assumes that the atomic state has 
> already
>   * been pushed into the relevant object state pointers, since this step can 
> no
>   * longer fail.
>   *
> - * It still requires the global state object @state to know which planes and
> + * It still requires the global state object @old_state to know which planes 
> and
>   * crtcs need to be updated though.
>   */
>  void drm_atomic_helper_commit_planes(struct drm_device *dev,
> -struct drm_atomic_state *state)
> +struct drm_atomic_state *old_state)
>  {
> int nplanes = dev->mode_config.num_total_plane;
> int ncrtcs = dev->mode_config.num_crtc;
> @@ -995,7 +995,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>
> for (i = 0; i < ncrtcs; i++) {
> struct drm_crtc_helper_funcs *funcs;
> -   struct drm_crtc *crtc = state->crtcs[i];
> +   struct drm_crtc *crtc = old_state->crtcs[i];
>
> if (!crtc)
> continue;
> @@ -1010,7 +1010,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>
> for (i = 0; i < nplanes; i++) {
> struct drm_plane_helper_funcs *funcs;
> -   struct drm_plane *plane = state->planes[i];
> +   struct drm_plane *plane = old_state->planes[i];
>
> if (!plane)
> continue;
> @@ -1025,7 +1025,7 @@ void drm_atomic_helper_commit_planes(struct drm_device 
> *dev,
>
> for (i = 0; i < ncrtcs; i++) {
> struct drm_crtc_helper_funcs *funcs;
> -   struct drm_crtc *crtc = state->crtcs[i];
> +   struct drm_crtc *crtc = old_state->crtcs[i];
>
> if (!crtc)
> continue;
> --
> 2.1.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/6] drm/crtc: Polish kerneldoc

[Rob Clark]

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter  
wrote:
> - Make it clear that it's a negative errno (more in line with
>   everything else).
> - Clean up the confusion around get_properties vs. getproperty ioctls:
>   One reads per-obj property values, the other reads property
>   metadata.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_crtc.c | 79 
> --
>  1 file changed, 41 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 5c878f172365..8c550302a9ef 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1490,7 +1490,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>   * connectors.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
>  {
> @@ -1674,7 +1674,7 @@ static void drm_crtc_convert_to_umode(struct 
> drm_mode_modeinfo *out,
>   * the caller.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  static int drm_crtc_convert_umode(struct drm_display_mode *out,
>   const struct drm_mode_modeinfo *in)
> @@ -1717,7 +1717,7 @@ static int drm_crtc_convert_umode(struct 
> drm_display_mode *out,
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_getresources(struct drm_device *dev, void *data,
>   struct drm_file *file_priv)
> @@ -1905,7 +1905,7 @@ out:
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_getcrtc(struct drm_device *dev,
>  void *data, struct drm_file *file_priv)
> @@ -1966,7 +1966,7 @@ static bool drm_mode_expose_to_userspace(const struct 
> drm_display_mode *mode,
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_getconnector(struct drm_device *dev, void *data,
>   struct drm_file *file_priv)
> @@ -2110,7 +2110,7 @@ out:
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_getencoder(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> @@ -2151,7 +2151,7 @@ int drm_mode_getencoder(struct drm_device *dev, void 
> *data,
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_getplane_res(struct drm_device *dev, void *data,
>   struct drm_file *file_priv)
> @@ -2212,7 +2212,7 @@ int drm_mode_getplane_res(struct drm_device *dev, void 
> *data,
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_getplane(struct drm_device *dev, void *data,
>   struct drm_file *file_priv)
> @@ -2386,7 +2386,7 @@ static int setplane_internal(struct drm_plane *plane,
>   * valid crtc).
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_setplane(struct drm_device *dev, void *data,
>   struct drm_file *file_priv)
> @@ -2461,7 +2461,7 @@ int drm_mode_setplane(struct drm_device *dev, void 
> *data,
>   * interface. The only thing it adds is correct refcounting dance.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_set_config_internal(struct drm_mode_set *set)
>  {
> @@ -2554,7 +2554,7 @@ EXPORT_SYMBOL(drm_crtc_check_viewport);
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_setcrtc(struct drm_device *dev, void *data,
>  struct drm_file *file_priv)
> @@ -2717,7 +2717,7 @@ out:
>   * userspace wants to make use of these capabilities.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  static int drm_mode_cursor_universal(struct drm_crtc *crtc,
>  struct drm_mode_cursor2 *req,
> @@ -2865,7 +2865,7 @@ out:
>   * Called by the user via ioctl.
>   *
>   * Returns:
> - * Zero on success, errno on failure.
> + * Zero on success, negative errno on failure.
>   */
>  int drm_mode_cursor_ioctl(struct drm_device *dev,
>

[PATCH 5/6] drm: s/enum_blob_list/enum_list/ in drm_property

[Rob Clark]

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter  
wrote:
> I guess for hysterical raisins this was meant to be the way to read
> blob properties. But that's done with the two-stage approach which
> uses separate blob kms object and the special-purpose get_blob ioctl.
>
> Shipping userspace seems to have never relied on this, and the kernel
> also never put any blob thing onto that property. And nowadays it
> would blow up, e.g. in drm_property_destroy. Also it makes no sense to
> return values in an ioctl that only returns metadata about everything.
>
> So let's ditch all the internal code for the blob list, rename the
> list to be unambiguous and sprinkle comments all over the place to
> explain this peculiar piece of api.
>
> v2: Squash in fixup from Rob to remove now unused variables.
>
> Cc: Rob Clark 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_crtc.c  | 53 
> +++--
>  include/drm/drm_crtc.h  |  2 +-
>  include/uapi/drm/drm_mode.h |  2 ++
>  3 files changed, 20 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 8c550302a9ef..589a921d4313 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3457,7 +3457,7 @@ struct drm_property *drm_property_create(struct 
> drm_device *dev, int flags,
>
> property->flags = flags;
> property->num_values = num_values;
> -   INIT_LIST_HEAD(>enum_blob_list);
> +   INIT_LIST_HEAD(>enum_list);
>
> if (name) {
> strncpy(property->name, name, DRM_PROP_NAME_LEN);
> @@ -3679,8 +3679,8 @@ int drm_property_add_enum(struct drm_property 
> *property, int index,
> (value > 63))
> return -EINVAL;
>
> -   if (!list_empty(>enum_blob_list)) {
> -   list_for_each_entry(prop_enum, >enum_blob_list, 
> head) {
> +   if (!list_empty(>enum_list)) {
> +   list_for_each_entry(prop_enum, >enum_list, head) {
> if (prop_enum->value == value) {
> strncpy(prop_enum->name, name, 
> DRM_PROP_NAME_LEN);
> prop_enum->name[DRM_PROP_NAME_LEN-1] = '\0';
> @@ -3698,7 +3698,7 @@ int drm_property_add_enum(struct drm_property 
> *property, int index,
> prop_enum->value = value;
>
> property->values[index] = value;
> -   list_add_tail(_enum->head, >enum_blob_list);
> +   list_add_tail(_enum->head, >enum_list);
> return 0;
>  }
>  EXPORT_SYMBOL(drm_property_add_enum);
> @@ -3715,7 +3715,7 @@ void drm_property_destroy(struct drm_device *dev, 
> struct drm_property *property)
>  {
> struct drm_property_enum *prop_enum, *pt;
>
> -   list_for_each_entry_safe(prop_enum, pt, >enum_blob_list, 
> head) {
> +   list_for_each_entry_safe(prop_enum, pt, >enum_list, head) {
> list_del(_enum->head);
> kfree(prop_enum);
> }
> @@ -3839,16 +3839,12 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> struct drm_mode_get_property *out_resp = data;
> struct drm_property *property;
> int enum_count = 0;
> -   int blob_count = 0;
> int value_count = 0;
> int ret = 0, i;
> int copied;
> struct drm_property_enum *prop_enum;
> struct drm_mode_property_enum __user *enum_ptr;
> -   struct drm_property_blob *prop_blob;
> -   uint32_t __user *blob_id_ptr;
> uint64_t __user *values_ptr;
> -   uint32_t __user *blob_length_ptr;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return -EINVAL;
> @@ -3862,11 +3858,8 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
>
> if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
> drm_property_type_is(property, 
> DRM_MODE_PROP_BITMASK)) {
> -   list_for_each_entry(prop_enum, >enum_blob_list, 
> head)
> +   list_for_each_entry(prop_enum, >enum_list, head)
> enum_count++;
> -   } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
> -   list_for_each_entry(prop_blob, >enum_blob_list, 
> head)
> -   blob_count++;
> }
>
> value_count = property->num_values;
> @@ -3891,7 +3884,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> if ((out_resp->count_enum_blobs >= enum_count) && enum_count) 
> {
> copied = 0;
> enum_ptr = (struct drm_mode_property_enum __user 
> *)(unsigned long)out_resp->enum_blob_ptr;
> -   list_for_each_entry(prop_enum, 
> >enum_blob_list, head) {
> +   list_for_each_entry(prop_enum, >enum_list, 
> head) {
>
> if (copy_to_user(_ptr[copied].value, 
> _enum->value, sizeof(uint64_t))) {
>

[Intel-gfx] [PATCH 3/6] drm/atomic: Don't overrun the connector array when hotplugging

[Rob Clark]

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter  
wrote:
> Yet another fallout from not considering DP MST hotplug. With the
> previous patches we have stable indices, but it might still happen
> that a connector gets added between when we allocate the array and
> when we actually add a connector. Especially when we back off due to
> ww mutex contention or similar issues.
>
> So store the sizes of the arrays in struct drm_atomic_state and double
> check them. We don't really care about races except that we want to
> use a consistent value, so ACCESS_ONCE is all we need. And if we
> indeed notice that we'd overrun the array then just give up and
> restart the entire ioctl.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_atomic.c| 26 +-
>  drivers/gpu/drm/drm_atomic_helper.c | 23 ---
>  include/drm/drm_crtc.h  |  2 ++
>  3 files changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 67c1dc894bd9..3624632084e2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -56,6 +56,8 @@ drm_atomic_state_alloc(struct drm_device *dev)
> if (!state)
> return NULL;
>
> +   state->num_connector = ACCESS_ONCE(dev->mode_config.num_connector);
> +
> state->crtcs = kcalloc(dev->mode_config.num_crtc,
>sizeof(*state->crtcs), GFP_KERNEL);
> if (!state->crtcs)
> @@ -72,12 +74,12 @@ drm_atomic_state_alloc(struct drm_device *dev)
>   sizeof(*state->plane_states), 
> GFP_KERNEL);
> if (!state->plane_states)
> goto fail;
> -   state->connectors = kcalloc(dev->mode_config.num_connector,
> +   state->connectors = kcalloc(state->num_connector,
> sizeof(*state->connectors),
> GFP_KERNEL);
> if (!state->connectors)
> goto fail;
> -   state->connector_states = kcalloc(dev->mode_config.num_connector,
> +   state->connector_states = kcalloc(state->num_connector,
>   sizeof(*state->connector_states),
>   GFP_KERNEL);
> if (!state->connector_states)
> @@ -117,7 +119,7 @@ void drm_atomic_state_clear(struct drm_atomic_state 
> *state)
>
> DRM_DEBUG_KMS("Clearing atomic state %p\n", state);
>
> -   for (i = 0; i < config->num_connector; i++) {
> +   for (i = 0; i < state->num_connector; i++) {
> struct drm_connector *connector = state->connectors[i];
>
> if (!connector)
> @@ -304,6 +306,21 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
>
> index = drm_connector_index(connector);
>
> +   /*
> +* Construction of atomic state updates can race with a connector
> +* hot-add which might overflow. In this case flip the table and just
> +* restart the entire ioctl - no one is fast enough to livelock a cpu
> +* with physical hotplug events anyway.
> +*
> +* Note that we only grab the indexes once we have the right lock to
> +* prevent hotplug/unplugging of connectors. So removal is no problem,
> +* at most the array is a bit too large.
> +*/
> +   if (index >= state->num_connector) {
> +   DRM_DEBUG_KMS("Hot-added connector would overflow state 
> array, restarting\n");
> +   return -EAGAIN;
> +   }
> +
> if (state->connector_states[index])
> return state->connector_states[index];
>
> @@ -499,10 +516,9 @@ int
>  drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
>struct drm_crtc *crtc)
>  {
> -   int nconnectors = state->dev->mode_config.num_connector;
> int i, num_connected_connectors = 0;
>
> -   for (i = 0; i < nconnectors; i++) {
> +   for (i = 0; i < state->num_connector; i++) {
> struct drm_connector_state *conn_state;
>
> conn_state = state->connector_states[i];
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0cd054615920..99095ef147ef 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -249,7 +249,6 @@ static int
>  mode_fixup(struct drm_atomic_state *state)
>  {
> int ncrtcs = state->dev->mode_config.num_crtc;
> -   int nconnectors = state->dev->mode_config.num_connector;
> struct drm_crtc_state *crtc_state;
> struct drm_connector_state *conn_state;
> int i;
> @@ -264,7 +263,7 @@ mode_fixup(struct drm_atomic_state *state)
> drm_mode_copy(_state->adjusted_mode, _state->mode);
> }
>
> -   for (i = 0; i < nconnectors; i++) {
> +   for (i = 0; i < 

[Intel-gfx] [PATCH 2/6] drm/atomic: Only destroy connector states with connection mutex held

[Rob Clark]

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter  
wrote:
> Otherwise the connector might have been unplugged and destroyed while
> we didn't look. Yet another fallout from DP MST hotplugging that I
> didn't consider.
>
> To make sure we get this right add an appropriate WARN_ON to
> drm_atomic_state_clear (obviously only when we actually have a state
> to clear up). And reorder all the state_clear and backoff calls to
> make it work out properly.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_atomic.c|  9 ++---
>  drivers/gpu/drm/drm_atomic_helper.c | 14 +++---
>  2 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 90b2d1644bd7..67c1dc894bd9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -112,21 +112,24 @@ EXPORT_SYMBOL(drm_atomic_state_alloc);
>  void drm_atomic_state_clear(struct drm_atomic_state *state)
>  {
> struct drm_device *dev = state->dev;
> +   struct drm_mode_config *config = >mode_config;
> int i;
>
> DRM_DEBUG_KMS("Clearing atomic state %p\n", state);
>
> -   for (i = 0; i < dev->mode_config.num_connector; i++) {
> +   for (i = 0; i < config->num_connector; i++) {
> struct drm_connector *connector = state->connectors[i];
>
> if (!connector)
> continue;
>
> +   WARN_ON(!drm_modeset_is_locked(>connection_mutex));
> +
> connector->funcs->atomic_destroy_state(connector,
>
> state->connector_states[i]);
> }
>
> -   for (i = 0; i < dev->mode_config.num_crtc; i++) {
> +   for (i = 0; i < config->num_crtc; i++) {
> struct drm_crtc *crtc = state->crtcs[i];
>
> if (!crtc)
> @@ -136,7 +139,7 @@ void drm_atomic_state_clear(struct drm_atomic_state 
> *state)
>   state->crtc_states[i]);
> }
>
> -   for (i = 0; i < dev->mode_config.num_total_plane; i++) {
> +   for (i = 0; i < config->num_total_plane; i++) {
> struct drm_plane *plane = state->planes[i];
>
> if (!plane)
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index fad2b932cf72..0cd054615920 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1217,8 +1217,8 @@ fail:
>
> return ret;
>  backoff:
> -   drm_atomic_legacy_backoff(state);
> drm_atomic_state_clear(state);
> +   drm_atomic_legacy_backoff(state);
>
> /*
>  * Someone might have exchanged the framebuffer while we dropped locks
> @@ -1285,8 +1285,8 @@ fail:
>
> return ret;
>  backoff:
> -   drm_atomic_legacy_backoff(state);
> drm_atomic_state_clear(state);
> +   drm_atomic_legacy_backoff(state);
>
> /*
>  * Someone might have exchanged the framebuffer while we dropped locks
> @@ -1462,8 +1462,8 @@ fail:
>
> return ret;
>  backoff:
> -   drm_atomic_legacy_backoff(state);
> drm_atomic_state_clear(state);
> +   drm_atomic_legacy_backoff(state);
>
> /*
>  * Someone might have exchanged the framebuffer while we dropped locks
> @@ -1528,8 +1528,8 @@ fail:
>
> return ret;
>  backoff:
> -   drm_atomic_legacy_backoff(state);
> drm_atomic_state_clear(state);
> +   drm_atomic_legacy_backoff(state);
>
> goto retry;
>  }
> @@ -1587,8 +1587,8 @@ fail:
>
> return ret;
>  backoff:
> -   drm_atomic_legacy_backoff(state);
> drm_atomic_state_clear(state);
> +   drm_atomic_legacy_backoff(state);
>
> goto retry;
>  }
> @@ -1646,8 +1646,8 @@ fail:
>
> return ret;
>  backoff:
> -   drm_atomic_legacy_backoff(state);
> drm_atomic_state_clear(state);
> +   drm_atomic_legacy_backoff(state);
>
> goto retry;
>  }
> @@ -1725,8 +1725,8 @@ fail:
>
> return ret;
>  backoff:
> -   drm_atomic_legacy_backoff(state);
> drm_atomic_state_clear(state);
> +   drm_atomic_legacy_backoff(state);
>
> /*
>  * Someone might have exchanged the framebuffer while we dropped locks
> --
> 2.1.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/6] drm/atomic: Ensure that drm_connector_index is stable

[Rob Clark]

On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter  
wrote:
> I've totally forgotten that with DP MST connectors can now be
> hotplugged. And failed to adapt Rob's drm_atomic_state code (which
> predates connector hotplugging) to the new realities.
>
> The first step is to make sure that the connector indices used to
> access the arrays of pointers are stable. The connection mutex gives
> us enough guarantees for that, which means we won't unecessarily block
> on concurrent modesets or background probing.
>
> So add a locking WARN_ON and shuffle the code slightly to make sure we
> always hold the right lock.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_atomic.c | 8 
>  drivers/gpu/drm/drm_crtc.c   | 5 +
>  2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ed22a719440f..90b2d1644bd7 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -295,15 +295,15 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
> struct drm_mode_config *config = >dev->mode_config;
> struct drm_connector_state *connector_state;
>
> +   ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
> +   if (ret)
> +   return ERR_PTR(ret);
> +
> index = drm_connector_index(connector);
>
> if (state->connector_states[index])
> return state->connector_states[index];
>
> -   ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
> -   if (ret)
> -   return ERR_PTR(ret);
> -
> connector_state = connector->funcs->atomic_duplicate_state(connector);
> if (!connector_state)
> return ERR_PTR(-ENOMEM);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 56737e74b59d..5c878f172365 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -867,6 +867,8 @@ int drm_connector_init(struct drm_device *dev,
>
> drm_connector_get_cmdline_mode(connector);
>
> +   /* We should add connectors at the end to avoid upsetting the 
> connector
> +* index too much. */
> list_add_tail(>head, >mode_config.connector_list);
> dev->mode_config.num_connector++;
>
> @@ -930,6 +932,9 @@ unsigned int drm_connector_index(struct drm_connector 
> *connector)
>  {
> unsigned int index = 0;
> struct drm_connector *tmp;
> +   struct drm_mode_config *config = >dev->mode_config;
> +
> +   WARN_ON(!drm_modeset_is_locked(>connection_mutex));
>
> list_for_each_entry(tmp, >dev->mode_config.connector_list, 
> head) {
> if (tmp == connector)
> --
> 2.1.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 01/11] drm/radeon: rework vm_flush parameters

[Alex Deucher]

On Wed, Nov 19, 2014 at 2:48 PM, Kai Wasserbäch
 wrote:
> Christian König wrote on 19.11.2014 20:40:
>> Am 19.11.2014 um 19:28 schrieb Alex Deucher:
>>> On Wed, Nov 19, 2014 at 8:01 AM, Christian König
>>>  wrote:
 From: Christian König 

 Use ring structure instead of index and provide vm_id and pd_addr 
 separately.

 Signed-off-by: Christian König 
>>> Pushed to my 3.19-wip tree.  I'll send out a new radeon drm-next pull
>>> request later today or tomorrow.
>>
>> Please note that I had to fix another bug in the last patch pointed out by 
>> Kai
>> Wasserbäch.
>>
>> The updated patch should already be in your inbox.
>
> Everything is fine, I'm seeing v4 on Alex's tree
> ().
>

Yup, I grabbed the latest version.

Alex

[PATCH] drm/tilcdc: add missing clk_put in tilcdc_unload()

[Julien CHAUVEAU]

We need to call clk_put on display clock, in the same way as functional clock.

Signed-off-by: Julien CHAUVEAU 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 79a34cb..ccc1cdb 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -136,6 +136,9 @@ static int tilcdc_unload(struct drm_device *dev)
CPUFREQ_TRANSITION_NOTIFIER);
 #endif

+   if (priv->disp_clk)
+   clk_put(priv->disp_clk);
+
if (priv->clk)
clk_put(priv->clk);

-- 
2.1.0

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Hi Javier,

In the cover letter, I have mentioned that it is tested on Linus tree:

"This series is based on master branch of Linus tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"

Kindly test the patches with that.

Ajay

On Wed, Nov 19, 2014 at 3:05 PM, Javier Martinez Canillas
 wrote:
> Hello Ajay,
>
> On 11/18/2014 07:20 AM, Ajay kumar wrote:
>> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar  
>> wrote:
>>> This series is based on master branch of Linus tree at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> I applied your series on top of 3.18-rc5 + linux-next's commit:
>
> 0ef76ae ("ARM: exynos_defconfig: Enable options for display panel support").
>
> I think you should had mentioned what other patches are needed as a
> dependency since I spent quite a bit of time figuring out why the
> ps8622 bridge driver probe was always deferred due of_drm_find_panel()
> failing and then I noticed that a patch from linux-next was needed:
>
> e35e305 ("drm/panel: simple: Add AUO B116XW03 panel support")
>
> With that commit the ps8622 drm bridge driver probe succeed but I still
> don't have display working on an Exynos5240 Peach Pit, the kernel log shows:
>
> platform 145b.dp-controller: Driver exynos-dp requests probe deferral
> exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops)
> exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops 
> exynos_dp_ops): -517
> exynos-drm exynos-drm: master bind failed: -517
> platform 145b.dp-controller: Driver exynos-dp requests probe deferral
>
> Any idea what else I could be missing here?
>
> Your patches don't apply cleanly in linux-next btw, although the are many
> issues with the Exynos DRM currently in linux-next anyways so probably using
> 3.18-rc as a base makes more sense for now until all those things get fixed
> but you should rebase so they can be picked.
>
> Best regards,
> Javier

[Bug 86320] Monitor on DisplayPort doesn't wake up

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

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

--- Comment #3 from Stefan Brüns  ---
Please attach the whole dmesg output/Xorg log, as requested. Otherwise it is
really difficult to get the whole picture.

Currently, there is no information provided by you indicating kernel version,
XOrg server version, radeon xorg driver version, distribution. All this would
be available when you provided the full logs.

-- 
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/20141119/8a3014cc/attachment.html>

NULL derefs after failed suspend (i915, pm, ext4, slub)

[Johan Hovold]

On Tue, Oct 28, 2014 at 03:29:10PM +0100, Johan Hovold wrote:
> Hi, 
> 
> I have had some problems with crashes involving suspend-to-disk after
> updating to v3.16.
> 
> Below is a log with 3.16.6 from a failed suspend attempt after which I
> get a NULL deref in ext4 code.
> 
> A couple of weeks ago I got something similar, with backtraces from 
> ext4 (ext4_alloc_inode) and NULL-derefs in vfs (vfs_get_attr_nosec) when
> trying to do IO after resuming from suspend. That was with 3.16.3 and I
> was hoping that whatever it was would have been fixed in 3.16.6 (there
> were some ext4 error handling patches in there). I only got photos of
> those oopses but it involved kmem_cache_alloc (slub) and a NULL-deref in
> vfs_get_attr_nosec. I can put the photos up somewhere. That time I also
> got back to X and could issue a dmesg in an xterm, but any process trying
> to do IO died.
> 
> Something similar happened with 3.16.1 but unfortunately I do not have
> any logs from that.

For the record, it seems this problem went away with 3.17 (.2 and .3).
Been suspending daily now for almost three weeks without triggering this
again.

Since 3.16 is EOL (and 3.15 did not suffer from this) I guess there's no
need to track it down for stable.

Johan

[PATCH v8 2/2] drm: add DT bindings documentation for atmel-hlcdc-dc driver

[Boris Brezillon]

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.

The atmel,panel property link the HLCDC RGB output with the LCD panel
connected on this port (note that the HLCDC RGB connector implementation
makes use of the DRM panel framework).

Connection to other external devices (DRM bridges) might be added later by
mean of a new atmel,xxx (atmel,bridge) property.

Signed-off-by: Boris Brezillon 
---
 .../devicetree/bindings/drm/atmel/hlcdc-dc.txt | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt

diff --git a/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt 
b/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
new file mode 100644
index 000..ebc1a91
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
@@ -0,0 +1,53 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
+
+The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
+See ../mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be "atmel,hlcdc-display-controller"
+ - pinctrl-names: the pin control state names. Should contain "default".
+ - pinctrl-0: should contain the default pinctrl states.
+ - #address-cells: should be set to 1.
+ - #size-cells: should be set to 0.
+
+Required children nodes:
+ Children nodes are encoding available output ports and their connections
+ to external devices using the OF graph reprensentation (see ../graph.txt).
+ At least one port node is required.
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-display-controller";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_base _lcd_rgb888>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hlcdc_panel_output: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+   };
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.9.1

[PATCH v8 1/2] drm: add Atmel HLCDC Display Controller support

[Boris Brezillon]

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

At the moment, this driver only implements an RGB connector to interface
with LCD panels, but support for other kind of external devices might be
added later.

Signed-off-by: Boris Brezillon 
Reviewed-by: Rob Clark 
Tested-by: Anthony Harivel 
Tested-by: Ludovic Desroches 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig  |  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 406 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 579 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 213 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c  | 667 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h  | 398 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 323 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 856 +++
 11 files changed, 3463 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_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e3b4b0f..7b0f7fe 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -181,6 +181,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"

 source "drivers/gpu/drm/armada/Kconfig"

+source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
+
 source "drivers/gpu/drm/rcar-du/Kconfig"

 source "drivers/gpu/drm/shmobile/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9292a76..223dbca 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
 obj-$(CONFIG_DRM_ARMADA) += armada/
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc/
 obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig 
b/drivers/gpu/drm/atmel-hlcdc/Kconfig
new file mode 100644
index 000..1a08562
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig
@@ -0,0 +1,11 @@
+config DRM_ATMEL_HLCDC
+   tristate "DRM Support for ATMEL HLCDC Display Controller"
+   depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL
+   help
+ Choose this option if you have an ATMEL SoC with an HLCDC display
+ controller (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family).
diff --git a/drivers/gpu/drm/atmel-hlcdc/Makefile 
b/drivers/gpu/drm/atmel-hlcdc/Makefile
new file mode 100644
index 000..10ae426
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Makefile
@@ -0,0 +1,7 @@
+atmel-hlcdc-dc-y := atmel_hlcdc_crtc.o \
+   atmel_hlcdc_dc.o \
+   atmel_hlcdc_layer.o \
+   atmel_hlcdc_output.o \
+   atmel_hlcdc_plane.o
+
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc-dc.o
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
new file mode 100644
index 000..0409b90
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -0,0 +1,406 @@
+/*
+ * Copyright (C) 2014 Traphandler
+ * Copyright (C) 2014 Free Electrons
+ *
+ * Author: Jean-Jacques Hiblot 
+ * Author: Boris BREZILLON 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+

[PATCH v8 0/2] drm: add support for Atmel HLCDC Display Controller

[Boris Brezillon]

Hello,

This patch series adds support for the Atmel HLCDC Display Controller
embedded in the HLCDC block.

The drivers supports basic CRTC functionalities, several overlays and
provides an hardware cursor.

At the moment, it only supports connection to LCD panels through an RGB
connector (defined as an LVDS connector in my implementation), though
connection to other kind of devices (like DRM bridges) could be added later.

It also supports several RGB formats on all planes and some YUV formats on
the HEO overlay plane.

Best Regards,

Boris

Changes since v7:
 - split MFD, PWM and Display Controller drivers in several patch series
 - fix inline documentation (suggested by Nicolas)
 - fix DMA BURST LEN config (suggested by Nicolas)
 - call load and unload in probe and remove functions instead of setting
   them in drm_driver struct

Changes since v6:
- move interrupts property from hlcdc display controller node to its
  parent node (the MFD device)
- add mode_set_base implementation
- rework page flip handling to rely on vblank events instead of DMA
  transfer events (the end of a DMA transfer does not mean the frame
  is actually flipped: data are first copied to an output FIFO before
  being sent on the RGB/DPI connector)
- few minor coding style fixes

Changes since v5:
- fix Kconfig dependency bug
- use adjusted mode in crtc config
- move signal config (clk, hsync, vsync) from connector to crtc mode_set
  function
- use standard rotation property
- check display_mode validity in connecto mode_valid function
- remove dma_set_coherent mask call (now done in MFD core)
- do not use drm_platform_init

Changes since v4:
- fix a few more bugs in rotation handling (rotation was buggy on some
  formats)
- return connector_status_unknown until a panel is exposed by the
  drm_panel infrastructure (prevent fbdev creation until everyting is
  in place)
- rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration
  (automatically select this option when selecting the HLCDC PMW or DRM
  driver, instead of depending on this option)

Changes since v3:
- rework the layer code to simplify several parts (locking and layer
  disabling)
- make use of the drm_flip_work infrastructure
- rely on default HW cursor implementation using on the cursor plane
- rework the display controller DT bindings (based on OF graph
  representation)
- add rotation support
- retrive RGB bus format from drm_display_info
- drop the dynamic pinctrl state selection
- rework HLCDC output handling (previously specialized to interface
  with LCD panels)
- drop ".module = THIS_MODULE" lines
- change display controller compatible string

Changes since v2:
- fix coding style issues (macro indentation)
- make use of GENMASK in several places
- declare regmap config as a static structure
- rework hlcdc plane update API
- rework cursor handling to make use of the new plane update API
- fix backporch config
- do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
  clk disable calls when accessing registers
- explicitely include regmap and clk headers instead of relying on
  atmel-hlcdc.h inclusions
- make the atmel-hlcdc driver depends on CONFIG_OF
- separate DT bindings documentation from driver implementation
- support several pin muxing for HLCDC pins on sama5d3 SoCs

Changes since v1:
- replace the backlight driver by a PWM driver
- make use of drm_panel infrastructure
- split driver code in several subsystem: MFD, PWM and DRM
- add support for overlays
- add support for hardware cursor

Boris Brezillon (2):
  drm: add Atmel HLCDC Display Controller support
  drm: add DT bindings documentation for atmel-hlcdc-dc driver

 .../devicetree/bindings/drm/atmel/hlcdc-dc.txt |  53 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 406 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 579 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 213 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 667 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 398 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 323 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 856 +
 12 files changed, 3516 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
 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_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 

[Bug 88481] Kernel oops leaves system without graphical output [radeon]

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

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

--- Comment #6 from Daniel Otero  ---
Reverting the commit ffe0245532b98efc4bc0e06f29c51d3f0e471152 from the tag
v3.17.3 does resolve the issue.

Thanks for your time.

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

[PATCH] device coredump: fix minor issue in Kconfig file

[Johannes Berg]

On Wed, 2014-11-19 at 05:28 -0800, Amitkumar Karwar wrote:
> if "CONFIG_DEV_COREDUMP=y" is added to configuration file, it
> gets removed when final configuration file is generated. The
> reason is it requires CONFIG_WANT_DEV_COREDUMP to be enabled.
> 
> Currently "make menuconfig" doesn't display an option to enable
> WANT_DEV_COREDUMP. This patch updates Kconfig so that user can
> enable WANT_DEV_COREDUMP.

This is completely intentional - drivers should "select
WANT_DEV_COREDUMP" and users are only able to set "ALLOW_DEV_COREDUMP=n"
to prevent it.

johannes

[PATCH] drm/tilcdc: fix check for display clock in tilcdc_load()

[Julien CHAUVEAU]

This appears to be a copy-paste error. We need to check for errors on disp_clk.

Signed-off-by: Julien CHAUVEAU 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 79a34cb..9f2bd8a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -200,7 +200,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
}

priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
-   if (IS_ERR(priv->clk)) {
+   if (IS_ERR(priv->disp_clk)) {
dev_err(dev->dev, "failed to get display clock\n");
ret = -ENODEV;
goto fail_put_clk;
-- 
2.1.0

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

[Christian König]

Am 19.11.2014 um 14:16 schrieb Kai Wasserbäch:
> Dear Christian,
> Christian König wrote on 19.11.2014 14:01:
>> From: Christian König 
>>
>> This way the necessary VM update is kicked off immediately
>> if all BOs involved are in GPU accessible memory.
>>
>> v2: fix vm lock
>> v3: immediately update unmaps as well
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/radeon/radeon_gem.c | 64 
>> +
>>   1 file changed, 64 insertions(+)
> Is this a fix for 
> which I bisected to the v2 of this patch
> () as
> present on the drm-next-3.19-wip branch?

Yes and no, it was actually the patch before this one which triggered 
the problem. The last one just made it much more likely to appear.

Please test the whole patchset on top of Dave's drm-next tree if your 
problem still exists.

Thanks,
Christian.

>
> Cheers,
> Kai
>

[RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

[Kevin Hilman]

Kevin Hilman  writes:

> Javier Martinez Canillas  writes:
>
>> [adding Paolo and Vivek as cc]
>>
>> Hello,
>>
>> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>> 
>>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>>> it proceeds to panic in the workqueue code called by the asoc max98090
>>> codec[1].
>>> 
>>> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
>>> but I still don't have display output.
>>> 
>>
>> Paolo Pisati pointed out in another thread that he needed the patch
>> "[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
>> phy"
>> is also needed to get display working for exynos on linux-next.
>>
>> I've pinged Kukjin to apply this as a -rc fix since is needed after
>> a5ec598 ("phy: exynos-dp-video: Use syscon support to control pmu register")
>> landed in 3.18 which broke the Exynos Display Port PHY:
>>
>> exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap
>>
>> I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just 
>> $subject
>> and [0] should be enough to have display working on Peach Pi 
>
> Yes, with those two patches, peach-pi display working on v3.18-rc5 for me.
>
>> with linux-next but
>> it fails to me with:
>>
>> exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
>> [mem 0x10040714-0x1004071f]
>>
>> The same issue was reported by Paolo a couple of days ago [1].
>
> For me, with linux-next, I'm still getting the DRM deadlock.  Trying
> your patch that moves things to module_init gets past the deadlock, but
> still doesn't boot unless I disable CONFIG_SND_SOC_SNOW.  Doing that I
> see the same video-phy error though.

Another interesting data point is that the 2 patches which get things
working on v3.18-rc5, when applied on Kukjin's for-next branch, result
in a kernel that boots (which is better than linux-next), but without
a working display. :(

Kevin

[RFC] drm: Start documenting userspace ABI

[Daniel Vetter]

On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote:
> On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> > Hi
> > 
> > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
> >  wrote:
> > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> > >> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > >> > From: Thierry Reding 
> > >> >
> > >> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> > >> > different semantics on different drivers it seems like a good idea to
> > >> > start to more rigorously document userspace ABI to avoid these things
> > >> > in the future.
> > >> >
> > >> > This is a first draft of what such documentation could look like. Not
> > >> > all IOCTLs are documented and some explanation about the other system
> > >> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> > >> > send this out for early review to see if the direction is reasonable.
> > >> > If so my plan is to continue to chip away at this as I find time.
> > >> >
> > >> > Signed-off-by: Thierry Reding 
> > >>
> > >> Imo for ioctls the right thing to do is having proper manpages, not
> > >> kerneldoc or DocBook sections. manpages really lend themselves well to
> > >> specify all the different facets of a single interface.
> > >
> > > I don't think I've ever seen manpages document IOCTLs at this level of
> > > detail. The intention of this is to add documentation about the IOCTLs
> > > at the kernel/userspace transition. Keeping this in the kernel has the
> > > advantage that it's a whole lot easier to keep updated, much like what
> > > we do with the other kerneldoc.
> > >
> > > That doesn't mean we shouldn't have manpages, but I think both are for
> > > the most part orthogonal, even though they may describe various facets
> > > of the same interfaces.
> > 
> > tty_ioctl(4)
> > console_ioctl(4)
> > 
> > I think a similar man-page ala drm_ioctl(4) makes a lot of sense.
> > 
> > >> Also, we already have some skeleton of that in libdrm, so I think
> > >> extending that would be best.
> > >
> > > One other reason why I don't think libdrm is the best fit for this is
> > > that libdrm is just one userspace implementation abstracting away the
> > > interfaces that this describes. Not everyone will use libdrm. So in my
> > > opinion its great if libdrm documents the API that it exposes, but I
> > > don't think it should document the kernel interfaces that it uses. The
> > > kernel exposes them, so it should provide the documentation for it as
> > > well.
> > 
> > I don't mind documenting this in the kernel-doc. But if we start
> > something like drm_ioctl(4) (I pushed some more generic man-pages to
> > libdrm a few years ago), we have this documented in 2 places, which is
> > always annoying for updates.
> 
> I wonder if it would somehow be possible to generate manpages from the
> DocBook to avoid this duplication. One of the things that
> DRM_IOCTL_MODE_CREATE_DUMB showed is that both drivers and userspace can
> interpret things wrongly, and I fear that if all we have is a manpage to
> document the IOCTLs, people writing the drivers may not be tempted
> enough to read that manpage. So I think we want documentation for both
> driver and userspace developers.

Imo docs don't help with that kind of fumble, only nasty testcases will.
People only read docs when they don't understand stuff (i.e. trying to
write drivers). Imo manpages an ioctl docs are only really good for
designing the interface (since it forces you to really think through the
semantics to be able to describe them concisely and precisely). But even
there I think having solid testcases is better invested time.

Documentation for developers is imo an entirely different matter, I think
that gets used a lot more. Or at least I find them fairly useful.

> Documenting this within the kernel is also pretty easy. I know that I'll
> be much more tempted to do it within the kernel than if I have to switch
> to some other repository, build system and whatnot.
> 
> Perhaps in this case having two places where it's documented isn't all
> that bad. It's ABI after all, so the documentation never needs to
> change. Theoretically.
> 
> > And even if people don't use libdrm, I think it's totally acceptable
> > to ship man-pages with libdrm. Distributions are free to provide
> > drm-man-pages as stand-alone package (which is _really_ easy to
> > generate from libdrm).
> 
> I guess one other home for these could be the man-pages project on
> kernel.org. It's what carries most (all?) of the Linux kernel-specific
> man-pages (like the tty_ioctl and console_ioctl ones that you referred
> to).

There has been talks about merging the linux manpages back into the kernel
actually. But yeah that seems like a good home, especially since Micheal
Kerrisk seems pretty sharp with reviewing manpages.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v12 1/3] drm: rockchip: Add basic drm driver

[Daniel Vetter]

On Wed, Nov 19, 2014 at 10:04:13AM +0100, Boris Brezillon wrote:
> AFAIU, the suggestion was to split drm_connector_init and
> drm_connector_register calls:
>  - drm_connector_init call should still be part of the load procedure
>(this function adds the connector to the connector list which is used
>by drm_mode_group_init_legacy_group)
>  - drm_connector_register should be called after the device has been
>registered
> 
> Here what I've done and it seems to work:
> 
> static int atmel_hlcdc_dc_connector_plug_all(struct drm_device *dev)
> {
>   struct drm_connector *connector, *failed;
>   int ret;
> 
>   mutex_lock(>mode_config.mutex);
>   list_for_each_entry(connector,
>   >mode_config.connector_list, head) { ret =
>   drm_connector_register(connector); if (ret) {
>   failed = connector;
>   goto err;
>   }
>   }
>   mutex_unlock(>mode_config.mutex);
>   return 0;
> 
> err:
>   list_for_each_entry(connector, >mode_config.connector_list, head) {
>   if (failed == connector)
>   break;
> 
>   drm_connector_unregister(connector);
>   }
>   mutex_unlock(>mode_config.mutex);
> 
>   return ret;
> }
> 
> [...]
> 
> static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev)
> {
>   struct drm_device *ddev;
>   int ret;
> 
>   ddev = drm_dev_alloc(_hlcdc_dc_driver, >dev);
>   if (!ddev)
>   return -ENOMEM;
> 
>   ret = drm_dev_set_unique(ddev, dev_name(ddev->dev));
>   if (ret)
>   goto err_unref;
> 
>   ret = atmel_hlcdc_dc_load(ddev);
>   if (ret)
>   goto err_unref;
> 
>   ret = drm_dev_register(ddev, 0);
>   if (ret)
>   goto err_unload;
> 
>   ret = atmel_hlcdc_dc_connector_plug_all(ddev);
>   if (ret)
>   goto err_unregister;
> 
>   return 0;
> 
> err_unregister:
>   drm_dev_unregister(ddev);
> 
> err_unload:
>   atmel_hlcdc_dc_unload(ddev);
> 
> err_unref:
>   drm_dev_unref(ddev);
> 
>   return ret;
> }
> 
> Daniel, can you confirm that's what you had in mind ?

Yup. To be able to have race-free driver load we need to split object
into an _init step (allocates structs and links to kernel-internal lists)
and _register (makes the object userspace-visible through sysfs and
dev-node kms object lookup idr).

This entire mess is all still fallout from the dark ages of the drm
midlayer and we'll probably have fun with this for another few years ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

[Kai Wasserbäch]

Dear Christian,
Christian König wrote on 19.11.2014 14:01:
> From: Christian König 
> 
> This way the necessary VM update is kicked off immediately
> if all BOs involved are in GPU accessible memory.
> 
> v2: fix vm lock
> v3: immediately update unmaps as well
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/radeon/radeon_gem.c | 64 
> +
>  1 file changed, 64 insertions(+)

Is this a fix for <http://thread.gmane.org/gmane.comp.video.dri.devel/118415>
which I bisected to the v2 of this patch
(<http://thread.gmane.org/gmane.comp.video.dri.devel/118415/focus=118425>) as
present on the drm-next-3.19-wip branch?

Cheers,
Kai

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/f633607a/attachment-0001.sig>

[PATCH 11/11] drm/radeon: update the VM after setting BO address v3

[Christian König]

From: Christian König 

This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.

v2: fix vm lock
v3: immediately update unmaps as well

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 64 +
 1 file changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index f752c7f..2e0e370 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -518,6 +518,68 @@ out:
return r;
 }

+/**
+ * radeon_gem_va_update_vm -update the bo_va in its VM
+ *
+ * @rdev: radeon_device pointer
+ * @bo_va: bo_va to update
+ *
+ * Update the bo_va directly after setting it's address. Errors are not
+ * vital here, so they are not reported back to userspace.
+ */
+static void radeon_gem_va_update_vm(struct radeon_device *rdev,
+   struct radeon_bo_va *bo_va)
+{
+   struct ttm_validate_buffer tv, *entry;
+   struct radeon_cs_reloc *vm_bos;
+   struct ww_acquire_ctx ticket;
+   struct list_head list;
+   unsigned domain;
+   int r;
+
+   INIT_LIST_HEAD();
+
+   tv.bo = _va->bo->tbo;
+   tv.shared = true;
+   list_add(, );
+
+   vm_bos = radeon_vm_get_bos(rdev, bo_va->vm, );
+   if (!vm_bos)
+   return;
+
+   r = ttm_eu_reserve_buffers(, , true);
+   if (r)
+   goto error_free;
+
+   list_for_each_entry(entry, , head) {
+   domain = radeon_mem_type_to_domain(entry->bo->mem.mem_type);
+   /* if anything is swapped out don't swap it in here,
+  just abort and wait for the next CS */
+   if (domain == RADEON_GEM_DOMAIN_CPU)
+   goto error_unreserve;
+   }
+
+   mutex_lock(_va->vm->mutex);
+   r = radeon_vm_clear_freed(rdev, bo_va->vm);
+   if (r)
+   goto error_unlock;
+
+   if (bo_va->it.start)
+   r = radeon_vm_bo_update(rdev, bo_va, _va->bo->tbo.mem);
+
+error_unlock:
+   mutex_unlock(_va->vm->mutex);
+
+error_unreserve:
+   ttm_eu_backoff_reservation(, );
+
+error_free:
+   kfree(vm_bos);
+
+   if (r)
+   DRM_ERROR("Couldn't update BO_VA (%d)\n", r);
+}
+
 int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp)
 {
@@ -612,6 +674,8 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
default:
break;
}
+   if (!r)
+   radeon_gem_va_update_vm(rdev, bo_va);
args->operation = RADEON_VA_RESULT_OK;
if (r) {
args->operation = RADEON_VA_RESULT_ERROR;
-- 
1.9.1

[PATCH 10/11] drm/radeon: sync PT updates as shared v2

[Christian König]

From: Christian König 

Only invalidating PTEs needs to be executed synchronized to using the PT.

v2: fix sync to uses

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 470451c..0b10f3a 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -820,7 +820,7 @@ static void radeon_vm_update_ptes(struct radeon_device 
*rdev,
unsigned nptes;
uint64_t pte;

-   radeon_sync_resv(rdev, >sync, pt->tbo.resv, false);
+   radeon_sync_resv(rdev, >sync, pt->tbo.resv, true);

if ((addr & ~mask) == (end & ~mask))
nptes = end - addr;
@@ -980,6 +980,13 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
return r;
ib.length_dw = 0;

+   if (!(bo_va->flags & RADEON_VM_PAGE_VALID)) {
+   unsigned i;
+
+   for (i = 0; i < RADEON_NUM_RINGS; ++i)
+   radeon_sync_fence(, vm->ids[i].last_id_use);
+   }
+
radeon_vm_update_ptes(rdev, vm, , bo_va->it.start,
  bo_va->it.last + 1, addr,
  radeon_vm_page_flags(bo_va->flags));
-- 
1.9.1

[PATCH 09/11] drm/radeon: sync PD updates as shared

[Christian König]

From: Christian König 

We never invalidate PD entries and making them valid can
run with other users in parallel.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index f457614..470451c 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -695,7 +695,7 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
if (ib.length_dw != 0) {
radeon_asic_vm_pad_ib(rdev, );

-   radeon_sync_resv(rdev, , pd->tbo.resv, false);
+   radeon_sync_resv(rdev, , pd->tbo.resv, true);
WARN_ON(ib.length_dw > ndw);
r = radeon_ib_schedule(rdev, , NULL, false);
if (r) {
-- 
1.9.1

[PATCH 08/11] drm/radeon: fence BO_VAs manually

[Christian König]

From: Christian König 

This allows us to finally remove the VM fence and
so allow concurrent use of it from different engines.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h|  7 +++
 drivers/gpu/drm/radeon/radeon_cs.c |  6 +-
 drivers/gpu/drm/radeon/radeon_vm.c | 17 ++---
 3 files changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index e3e77f7..1805067 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -456,6 +456,7 @@ struct radeon_bo_va {
struct list_headbo_list;
uint32_tflags;
uint64_taddr;
+   struct radeon_fence *last_pt_update;
unsignedref_count;

/* protected by vm mutex */
@@ -911,6 +912,8 @@ struct radeon_vm_id {
 };

 struct radeon_vm {
+   struct mutexmutex;
+
struct rb_root  va;

/* BOs moved, but not yet updated in the PT */
@@ -928,10 +931,6 @@ struct radeon_vm {

struct radeon_bo_va *ib_bo_va;

-   struct mutexmutex;
-   /* last fence for cs using this vm */
-   struct radeon_fence *fence;
-
/* for id and flush management per ring */
struct radeon_vm_id ids[RADEON_NUM_RINGS];
 };
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 30437aa..75f22e5 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -505,6 +505,9 @@ static int radeon_bo_vm_update_pte(struct radeon_cs_parser 
*p,
if (r)
return r;

+   radeon_sync_resv(p->rdev, >ib.sync, vm->page_directory->tbo.resv,
+true);
+
r = radeon_vm_clear_freed(rdev, vm);
if (r)
return r;
@@ -536,6 +539,8 @@ static int radeon_bo_vm_update_pte(struct radeon_cs_parser 
*p,
r = radeon_vm_bo_update(rdev, bo_va, >tbo.mem);
if (r)
return r;
+
+   radeon_sync_fence(>ib.sync, bo_va->last_pt_update);
}

return radeon_vm_clear_invalids(rdev, vm);
@@ -580,7 +585,6 @@ static int radeon_cs_ib_vm_chunk(struct radeon_device *rdev,
DRM_ERROR("Failed to sync rings: %i\n", r);
goto out;
}
-   radeon_sync_fence(>ib.sync, vm->fence);

if ((rdev->family >= CHIP_TAHITI) &&
(parser->chunk_const_ib_idx != -1)) {
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index e38efe4..f457614 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -275,9 +275,6 @@ void radeon_vm_fence(struct radeon_device *rdev,
 {
unsigned vm_id = vm->ids[fence->ring].id;

-   radeon_fence_unref(>fence);
-   vm->fence = radeon_fence_ref(fence);
-
radeon_fence_unref(>vm_manager.active[vm_id]);
rdev->vm_manager.active[vm_id] = radeon_fence_ref(fence);

@@ -707,8 +704,6 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
}
ib.fence->is_vm_update = true;
radeon_bo_fence(pd, ib.fence, false);
-   radeon_fence_unref(>fence);
-   vm->fence = radeon_fence_ref(ib.fence);
}
radeon_ib_free(rdev, );

@@ -999,8 +994,8 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
}
ib.fence->is_vm_update = true;
radeon_vm_fence_pts(vm, bo_va->it.start, bo_va->it.last + 1, ib.fence);
-   radeon_fence_unref(>fence);
-   vm->fence = radeon_fence_ref(ib.fence);
+   radeon_fence_unref(_va->last_pt_update);
+   bo_va->last_pt_update = radeon_fence_ref(ib.fence);
radeon_ib_free(rdev, );

return 0;
@@ -1026,6 +1021,7 @@ int radeon_vm_clear_freed(struct radeon_device *rdev,
list_for_each_entry_safe(bo_va, tmp, >freed, vm_status) {
r = radeon_vm_bo_update(rdev, bo_va, NULL);
radeon_bo_unref(_va->bo);
+   radeon_fence_unref(_va->last_pt_update);
kfree(bo_va);
if (r)
return r;
@@ -1084,6 +1080,7 @@ void radeon_vm_bo_rmv(struct radeon_device *rdev,
bo_va->bo = radeon_bo_ref(bo_va->bo);
list_add(_va->vm_status, >freed);
} else {
+   radeon_fence_unref(_va->last_pt_update);
kfree(bo_va);
}

@@ -1130,8 +1127,6 @@ int radeon_vm_init(struct radeon_device *rdev, struct 
radeon_vm *vm)
int i, r;

vm->ib_bo_va = NULL;
-   vm->fence = NULL;
-
for (i = 0; i < RADEON_NUM_RINGS; ++i) {
vm->ids[i].id = 0;
vm->ids[i].flushed_updates = NULL;
@@ -1192,11 +1187,13 @@ void radeon_vm_fini(struct radeon_device *rdev, 

[PATCH 07/11] drm/radeon: use one VMID for each ring

[Christian König]

From: Christian König 

Use multiple VMIDs for each VM, one for each ring. That allows
us to execute flushes separately on each ring, still not ideal
cause in a lot of cases rings can share IDs.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/cik.c   |  4 +--
 drivers/gpu/drm/radeon/cik_sdma.c  |  2 +-
 drivers/gpu/drm/radeon/ni.c|  6 ++--
 drivers/gpu/drm/radeon/ni_dma.c|  3 +-
 drivers/gpu/drm/radeon/radeon.h| 36 +--
 drivers/gpu/drm/radeon/radeon_vm.c | 59 +++---
 drivers/gpu/drm/radeon/si.c|  6 ++--
 7 files changed, 68 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 6bb8b84..510aeef 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4051,6 +4051,7 @@ struct radeon_fence *cik_copy_cpdma(struct radeon_device 
*rdev,
 void cik_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib)
 {
struct radeon_ring *ring = >ring[ib->ring];
+   unsigned vm_id = ib->vm ? ib->vm->ids[ib->ring].id : 0;
u32 header, control = INDIRECT_BUFFER_VALID;

if (ib->is_const_ib) {
@@ -4079,8 +4080,7 @@ void cik_ring_ib_execute(struct radeon_device *rdev, 
struct radeon_ib *ib)
header = PACKET3(PACKET3_INDIRECT_BUFFER, 2);
}

-   control |= ib->length_dw |
-   (ib->vm ? (ib->vm->id << 24) : 0);
+   control |= ib->length_dw | (vm_id << 24);

radeon_ring_write(ring, header);
radeon_ring_write(ring,
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 604e2e7..54b9837 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -134,7 +134,7 @@ void cik_sdma_ring_ib_execute(struct radeon_device *rdev,
  struct radeon_ib *ib)
 {
struct radeon_ring *ring = >ring[ib->ring];
-   u32 extra_bits = (ib->vm ? ib->vm->id : 0) & 0xf;
+   u32 extra_bits = (ib->vm ? ib->vm->ids[ib->ring].id : 0) & 0xf;

if (rdev->wb.enabled) {
u32 next_rptr = ring->wptr + 5;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index bee432d..360de9f 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1373,6 +1373,7 @@ void cayman_fence_ring_emit(struct radeon_device *rdev,
 void cayman_ring_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib)
 {
struct radeon_ring *ring = >ring[ib->ring];
+   unsigned vm_id = ib->vm ? ib->vm->ids[ib->ring].id : 0;
u32 cp_coher_cntl = PACKET3_FULL_CACHE_ENA | PACKET3_TC_ACTION_ENA |
PACKET3_SH_ACTION_ENA;

@@ -1395,15 +1396,14 @@ void cayman_ring_ib_execute(struct radeon_device *rdev, 
struct radeon_ib *ib)
 #endif
  (ib->gpu_addr & 0xFFFC));
radeon_ring_write(ring, upper_32_bits(ib->gpu_addr) & 0xFF);
-   radeon_ring_write(ring, ib->length_dw | 
- (ib->vm ? (ib->vm->id << 24) : 0));
+   radeon_ring_write(ring, ib->length_dw | (vm_id << 24));

/* flush read cache over gart for this vmid */
radeon_ring_write(ring, PACKET3(PACKET3_SURFACE_SYNC, 3));
radeon_ring_write(ring, PACKET3_ENGINE_ME | cp_coher_cntl);
radeon_ring_write(ring, 0x);
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, ((ib->vm ? ib->vm->id : 0) << 24) | 10); /* 
poll interval */
+   radeon_ring_write(ring, (vm_id << 24) | 10); /* poll interval */
 }

 static void cayman_cp_enable(struct radeon_device *rdev, bool enable)
diff --git a/drivers/gpu/drm/radeon/ni_dma.c b/drivers/gpu/drm/radeon/ni_dma.c
index 5a72404..50f8861 100644
--- a/drivers/gpu/drm/radeon/ni_dma.c
+++ b/drivers/gpu/drm/radeon/ni_dma.c
@@ -123,6 +123,7 @@ void cayman_dma_ring_ib_execute(struct radeon_device *rdev,
struct radeon_ib *ib)
 {
struct radeon_ring *ring = >ring[ib->ring];
+   unsigned vm_id = ib->vm ? ib->vm->ids[ib->ring].id : 0;

if (rdev->wb.enabled) {
u32 next_rptr = ring->wptr + 4;
@@ -140,7 +141,7 @@ void cayman_dma_ring_ib_execute(struct radeon_device *rdev,
 */
while ((ring->wptr & 7) != 5)
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_NOP, 0, 0, 0));
-   radeon_ring_write(ring, DMA_IB_PACKET(DMA_PACKET_INDIRECT_BUFFER, 
ib->vm ? ib->vm->id : 0, 0));
+   radeon_ring_write(ring, DMA_IB_PACKET(DMA_PACKET_INDIRECT_BUFFER, 
vm_id, 0));
radeon_ring_write(ring, (ib->gpu_addr & 0xFFE0));
radeon_ring_write(ring, (ib->length_dw << 12) | 
(upper_32_bits(ib->gpu_addr) & 0xFF));

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index ac4660a..e3e77f7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -901,33 +901,39 @@ struct radeon_vm_pt {

[PATCH 06/11] drm/radeon: track VM update fences separately

[Christian König]

From: Christian König 

Note for each fence if it's a VM page table update or not. This allows
us to determine the last VM update in a sync object and so to figure
out if we need to flush the TLB or not.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h   | 18 ++
 drivers/gpu/drm/radeon/radeon_fence.c |  1 +
 drivers/gpu/drm/radeon/radeon_ib.c|  3 ++-
 drivers/gpu/drm/radeon/radeon_sync.c  |  7 +++
 drivers/gpu/drm/radeon/radeon_vm.c| 25 +
 5 files changed, 33 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5e88e75..ac4660a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -360,14 +360,15 @@ struct radeon_fence_driver {
 };

 struct radeon_fence {
-   struct fence base;
+   struct fencebase;

-   struct radeon_device*rdev;
-   uint64_tseq;
+   struct radeon_device*rdev;
+   uint64_tseq;
/* RB, DMA, etc. */
-   unsignedring;
+   unsignedring;
+   boolis_vm_update;

-   wait_queue_tfence_wake;
+   wait_queue_tfence_wake;
 };

 int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
@@ -594,6 +595,7 @@ void radeon_semaphore_free(struct radeon_device *rdev,
 struct radeon_sync {
struct radeon_semaphore *semaphores[RADEON_NUM_SYNCS];
struct radeon_fence *sync_to[RADEON_NUM_RINGS];
+   struct radeon_fence *last_vm_update;
 };

 void radeon_sync_create(struct radeon_sync *sync);
@@ -922,8 +924,8 @@ struct radeon_vm {
struct mutexmutex;
/* last fence for cs using this vm */
struct radeon_fence *fence;
-   /* last flush or NULL if we still need to flush */
-   struct radeon_fence *last_flush;
+   /* last flushed PD/PT update */
+   struct radeon_fence *flushed_updates;
/* last use of vmid */
struct radeon_fence *last_id_use;
 };
@@ -2961,7 +2963,7 @@ struct radeon_fence *radeon_vm_grab_id(struct 
radeon_device *rdev,
   struct radeon_vm *vm, int ring);
 void radeon_vm_flush(struct radeon_device *rdev,
  struct radeon_vm *vm,
- int ring);
+int ring, struct radeon_fence *fence);
 void radeon_vm_fence(struct radeon_device *rdev,
 struct radeon_vm *vm,
 struct radeon_fence *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 9951670..d13d1b5 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -140,6 +140,7 @@ int radeon_fence_emit(struct radeon_device *rdev,
(*fence)->rdev = rdev;
(*fence)->seq = seq;
(*fence)->ring = ring;
+   (*fence)->is_vm_update = false;
fence_init(&(*fence)->base, _fence_ops,
   >fence_queue.lock, rdev->fence_context + ring, seq);
radeon_fence_ring_emit(rdev, ring, *fence);
diff --git a/drivers/gpu/drm/radeon/radeon_ib.c 
b/drivers/gpu/drm/radeon/radeon_ib.c
index 56a1704..c39ce1f 100644
--- a/drivers/gpu/drm/radeon/radeon_ib.c
+++ b/drivers/gpu/drm/radeon/radeon_ib.c
@@ -154,7 +154,8 @@ int radeon_ib_schedule(struct radeon_device *rdev, struct 
radeon_ib *ib,
}

if (ib->vm)
-   radeon_vm_flush(rdev, ib->vm, ib->ring);
+   radeon_vm_flush(rdev, ib->vm, ib->ring,
+   ib->sync.last_vm_update);

if (const_ib) {
radeon_ring_ib_execute(rdev, const_ib->ring, const_ib);
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c 
b/drivers/gpu/drm/radeon/radeon_sync.c
index ddd88fb..02ac8a1 100644
--- a/drivers/gpu/drm/radeon/radeon_sync.c
+++ b/drivers/gpu/drm/radeon/radeon_sync.c
@@ -48,6 +48,8 @@ void radeon_sync_create(struct radeon_sync *sync)

for (i = 0; i < RADEON_NUM_RINGS; ++i)
sync->sync_to[i] = NULL;
+
+   sync->last_vm_update = NULL;
 }

 /**
@@ -68,6 +70,11 @@ void radeon_sync_fence(struct radeon_sync *sync,

other = sync->sync_to[fence->ring];
sync->sync_to[fence->ring] = radeon_fence_later(fence, other);
+
+   if (fence->is_vm_update) {
+   other = sync->last_vm_update;
+   sync->last_vm_update = radeon_fence_later(fence, other);
+   }
 }

 /**
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 4ca2779..6ff5741 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -190,7 +190,7 @@ struct radeon_fence *radeon_vm_grab_id(struct radeon_device 
*rdev,
return NULL;

[PATCH 05/11] drm/radeon: fence PT updates manually v2

[Christian König]

From: Christian König 

This allows us to add the real execution fence as shared.

v2: fix typo

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_object.c | 19 ++
 drivers/gpu/drm/radeon/radeon_object.h |  2 ++
 drivers/gpu/drm/radeon/radeon_vm.c | 65 +-
 3 files changed, 62 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 33e6c7a..686e450 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -818,3 +818,22 @@ int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type, 
bool no_wait)
ttm_bo_unreserve(>tbo);
return r;
 }
+
+/**
+ * radeon_bo_fence - add fence to buffer object
+ *
+ * @bo: buffer object in question
+ * @fence: fence to add
+ * @shared: true if fence should be added shared
+ *
+ */
+void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
+ bool shared)
+{
+   struct reservation_object *resv = bo->tbo.resv;
+
+   if (shared)
+   reservation_object_add_shared_fence(resv, >base);
+   else
+   reservation_object_add_excl_fence(resv, >base);
+}
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index 1b8ec79..3b0b377 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -155,6 +155,8 @@ extern void radeon_bo_move_notify(struct ttm_buffer_object 
*bo,
  struct ttm_mem_reg *new_mem);
 extern int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
 extern int radeon_bo_get_surface_reg(struct radeon_bo *bo);
+extern void radeon_bo_fence(struct radeon_bo *bo, struct radeon_fence *fence,
+   bool shared);

 /*
  * sub allocation
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 20ef826..4ca2779 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -143,7 +143,7 @@ struct radeon_cs_reloc *radeon_vm_get_bos(struct 
radeon_device *rdev,
list[0].prefered_domains = RADEON_GEM_DOMAIN_VRAM;
list[0].allowed_domains = RADEON_GEM_DOMAIN_VRAM;
list[0].tv.bo = >page_directory->tbo;
-   list[0].tv.shared = false;
+   list[0].tv.shared = true;
list[0].tiling_flags = 0;
list[0].handle = 0;
list_add([0].tv.head, head);
@@ -157,7 +157,7 @@ struct radeon_cs_reloc *radeon_vm_get_bos(struct 
radeon_device *rdev,
list[idx].prefered_domains = RADEON_GEM_DOMAIN_VRAM;
list[idx].allowed_domains = RADEON_GEM_DOMAIN_VRAM;
list[idx].tv.bo = [idx].robj->tbo;
-   list[idx].tv.shared = false;
+   list[idx].tv.shared = true;
list[idx].tiling_flags = 0;
list[idx].handle = 0;
list_add([idx++].tv.head, head);
@@ -388,35 +388,25 @@ static void radeon_vm_set_pages(struct radeon_device 
*rdev,
 static int radeon_vm_clear_bo(struct radeon_device *rdev,
  struct radeon_bo *bo)
 {
-struct ttm_validate_buffer tv;
-struct ww_acquire_ctx ticket;
-struct list_head head;
struct radeon_ib ib;
unsigned entries;
uint64_t addr;
int r;

-memset(, 0, sizeof(tv));
-tv.bo = >tbo;
-   tv.shared = false;
-
-INIT_LIST_HEAD();
-list_add(, );
-
-r = ttm_eu_reserve_buffers(, , true);
-if (r)
+   r = radeon_bo_reserve(bo, false);
+   if (r)
return r;

-r = ttm_bo_validate(>tbo, >placement, true, false);
-if (r)
-goto error;
+   r = ttm_bo_validate(>tbo, >placement, true, false);
+   if (r)
+   goto error_unreserve;

addr = radeon_bo_gpu_offset(bo);
entries = radeon_bo_size(bo) / 8;

r = radeon_ib_get(rdev, R600_RING_TYPE_DMA_INDEX, , NULL, 256);
if (r)
-goto error;
+   goto error_unreserve;

ib.length_dw = 0;

@@ -426,15 +416,15 @@ static int radeon_vm_clear_bo(struct radeon_device *rdev,

r = radeon_ib_schedule(rdev, , NULL, false);
if (r)
-goto error;
+   goto error_free;

-   ttm_eu_fence_buffer_objects(, , >base);
-   radeon_ib_free(rdev, );
+   radeon_bo_fence(bo, ib.fence, false);

-   return 0;
+error_free:
+   radeon_ib_free(rdev, );

-error:
-   ttm_eu_backoff_reservation(, );
+error_unreserve:
+   radeon_bo_unreserve(bo);
return r;
 }

@@ -707,6 +697,7 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
radeon_ib_free(rdev, );
return r;
}
+   radeon_bo_fence(pd, ib.fence, false);

[PATCH 04/11] drm/radeon: split semaphore and sync object handling v2

[Christian König]

From: Christian König 

Previously we just allocated space for four hardware semaphores
in each software semaphore object. Make software semaphore objects
represent only one hardware semaphore address again by splitting
the sync code into it's own object.

v2: fix typo in comment

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/Makefile   |   3 +-
 drivers/gpu/drm/radeon/cik.c  |  18 +--
 drivers/gpu/drm/radeon/cik_sdma.c |  18 +--
 drivers/gpu/drm/radeon/evergreen_dma.c|  18 +--
 drivers/gpu/drm/radeon/r600.c |  18 +--
 drivers/gpu/drm/radeon/r600_dma.c |  18 +--
 drivers/gpu/drm/radeon/radeon.h   |  42 +++---
 drivers/gpu/drm/radeon/radeon_cs.c|   8 +-
 drivers/gpu/drm/radeon/radeon_ib.c|  13 +-
 drivers/gpu/drm/radeon/radeon_semaphore.c | 154 +
 drivers/gpu/drm/radeon/radeon_sync.c  | 213 ++
 drivers/gpu/drm/radeon/radeon_vm.c|   4 +-
 drivers/gpu/drm/radeon/rv770_dma.c|  18 +--
 drivers/gpu/drm/radeon/si_dma.c   |  18 +--
 14 files changed, 303 insertions(+), 260 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_sync.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index d01b879..a02434a 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,8 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
-   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o
+   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o 
\
+   radeon_sync.o

 # add async DMA block
 radeon-y += \
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index d52ead9..6bb8b84 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3979,31 +3979,27 @@ struct radeon_fence *cik_copy_cpdma(struct 
radeon_device *rdev,
unsigned num_gpu_pages,
struct reservation_object *resv)
 {
-   struct radeon_semaphore *sem = NULL;
struct radeon_fence *fence;
+   struct radeon_sync sync;
int ring_index = rdev->asic->copy.blit_ring_index;
struct radeon_ring *ring = >ring[ring_index];
u32 size_in_bytes, cur_size_in_bytes, control;
int i, num_loops;
int r = 0;

-   r = radeon_semaphore_create(rdev, );
-   if (r) {
-   DRM_ERROR("radeon: moving bo (%d).\n", r);
-   return ERR_PTR(r);
-   }
+   radeon_sync_create();

size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);
num_loops = DIV_ROUND_UP(size_in_bytes, 0x1f);
r = radeon_ring_lock(rdev, ring, num_loops * 7 + 18);
if (r) {
DRM_ERROR("radeon: moving bo (%d).\n", r);
-   radeon_semaphore_free(rdev, , NULL);
+   radeon_sync_free(rdev, , NULL);
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(rdev, sem, resv, false);
-   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
+   radeon_sync_resv(rdev, , resv, false);
+   radeon_sync_rings(rdev, , ring->idx);

for (i = 0; i < num_loops; i++) {
cur_size_in_bytes = size_in_bytes;
@@ -4027,12 +4023,12 @@ struct radeon_fence *cik_copy_cpdma(struct 
radeon_device *rdev,
r = radeon_fence_emit(rdev, , ring->idx);
if (r) {
radeon_ring_unlock_undo(rdev, ring);
-   radeon_semaphore_free(rdev, , NULL);
+   radeon_sync_free(rdev, , NULL);
return ERR_PTR(r);
}

radeon_ring_unlock_commit(rdev, ring, false);
-   radeon_semaphore_free(rdev, , fence);
+   radeon_sync_free(rdev, , fence);

return fence;
 }
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 7470a2e..604e2e7 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -541,31 +541,27 @@ struct radeon_fence *cik_copy_dma(struct radeon_device 
*rdev,
  unsigned num_gpu_pages,
  struct reservation_object *resv)
 {
-   struct radeon_semaphore *sem = NULL;
struct radeon_fence *fence;
+   struct radeon_sync sync;
int ring_index = rdev->asic->copy.dma_ring_index;
struct radeon_ring *ring = >ring[ring_index];
u32 size_in_bytes, cur_size_in_bytes;
int i, num_loops;
int r = 0;

-   r = radeon_semaphore_create(rdev, );
-   if (r) {
-   DRM_ERROR("radeon: moving bo (%d).\n", r);
-   return 

[PATCH 03/11] drm/radeon: remove unnecessary VM syncs

[Christian König]

From: Christian König 

The PD/PTs reservation object now contains everything needed.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_vm.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index db0ed3a..d8c49ad 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -701,7 +701,6 @@ int radeon_vm_update_page_directory(struct radeon_device 
*rdev,
radeon_asic_vm_pad_ib(rdev, );

radeon_semaphore_sync_resv(rdev, ib.semaphore, pd->tbo.resv, 
false);
-   radeon_semaphore_sync_fence(ib.semaphore, vm->last_id_use);
WARN_ON(ib.length_dw > ndw);
r = radeon_ib_schedule(rdev, , NULL, false);
if (r) {
@@ -969,7 +968,6 @@ int radeon_vm_bo_update(struct radeon_device *rdev,
radeon_asic_vm_pad_ib(rdev, );
WARN_ON(ib.length_dw > ndw);

-   radeon_semaphore_sync_fence(ib.semaphore, vm->fence);
r = radeon_ib_schedule(rdev, , NULL, false);
if (r) {
radeon_ib_free(rdev, );
-- 
1.9.1

[PATCH 02/11] drm/radeon: stop re-reserving the BO in radeon_vm_bo_set_addr

[Christian König]

From: Christian König 

That's useless when all callers drop the reservation
immediately after calling the function.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 2 --
 drivers/gpu/drm/radeon/radeon_vm.c  | 4 ++--
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index c194497..f752c7f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -601,6 +601,7 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
if (bo_va->it.start) {
args->operation = RADEON_VA_RESULT_VA_EXIST;
args->offset = bo_va->it.start * RADEON_GPU_PAGE_SIZE;
+   radeon_bo_unreserve(rbo);
goto out;
}
r = radeon_vm_bo_set_addr(rdev, bo_va, args->offset, 
args->flags);
@@ -616,7 +617,6 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
args->operation = RADEON_VA_RESULT_ERROR;
}
 out:
-   radeon_bo_unreserve(rbo);
drm_gem_object_unreference_unlocked(gobj);
return r;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 8309b11..85ee6f7 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -621,8 +621,6 @@ int radeon_driver_open_kms(struct drm_device *dev, struct 
drm_file *file_priv)
  RADEON_VA_IB_OFFSET,
  RADEON_VM_PAGE_READABLE |
  RADEON_VM_PAGE_SNOOPED);
-
-   radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
if (r) {
radeon_vm_fini(rdev, vm);
kfree(fpriv);
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 9d0f87b..db0ed3a 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -450,7 +450,7 @@ error:
  * Validate and set the offset requested within the vm address space.
  * Returns 0 for success, error for failure.
  *
- * Object has to be reserved!
+ * Object has to be reserved and gets unreserved by this function!
  */
 int radeon_vm_bo_set_addr(struct radeon_device *rdev,
  struct radeon_bo_va *bo_va,
@@ -576,7 +576,7 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
}

mutex_unlock(>mutex);
-   return radeon_bo_reserve(bo_va->bo, false);
+   return 0;
 }

 /**
-- 
1.9.1

[PATCH 01/11] drm/radeon: rework vm_flush parameters

[Christian König]

From: Christian König 

Use ring structure instead of index and provide vm_id and pd_addr separately.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/cik.c | 23 ++-
 drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
 drivers/gpu/drm/radeon/ni.c  | 14 +-
 drivers/gpu/drm/radeon/ni_dma.c  | 14 +-
 drivers/gpu/drm/radeon/radeon.h  |  5 +++--
 drivers/gpu/drm/radeon/radeon_asic.h | 18 --
 drivers/gpu/drm/radeon/radeon_vm.c   |  3 ++-
 drivers/gpu/drm/radeon/si.c  | 18 +++---
 drivers/gpu/drm/radeon/si_dma.c  | 19 ---
 9 files changed, 61 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 57a359d..d52ead9 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -5967,26 +5967,23 @@ static void cik_vm_decode_fault(struct radeon_device 
*rdev,
  * Update the page table base and flush the VM TLB
  * using the CP (CIK).
  */
-void cik_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm)
+void cik_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
+ unsigned vm_id, uint64_t pd_addr)
 {
-   struct radeon_ring *ring = >ring[ridx];
-   int usepfp = (ridx == RADEON_RING_TYPE_GFX_INDEX);
-
-   if (vm == NULL)
-   return;
+   int usepfp = (ring->idx == RADEON_RING_TYPE_GFX_INDEX);

radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
 WRITE_DATA_DST_SEL(0)));
-   if (vm->id < 8) {
+   if (vm_id < 8) {
radeon_ring_write(ring,
- (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id 
<< 2)) >> 2);
+ (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm_id << 
2)) >> 2);
} else {
radeon_ring_write(ring,
- (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm->id 
- 8) << 2)) >> 2);
+ (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm_id - 
8) << 2)) >> 2);
}
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
+   radeon_ring_write(ring, pd_addr >> 12);

/* update SH_MEM_* regs */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
@@ -5994,7 +5991,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
 WRITE_DATA_DST_SEL(0)));
radeon_ring_write(ring, SRBM_GFX_CNTL >> 2);
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, VMID(vm->id));
+   radeon_ring_write(ring, VMID(vm_id));

radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 6));
radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
@@ -6015,7 +6012,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
radeon_ring_write(ring, VMID(0));

/* HDP flush */
-   cik_hdp_flush_cp_ring_emit(rdev, ridx);
+   cik_hdp_flush_cp_ring_emit(rdev, ring->idx);

/* bits 0-15 are the VM contexts0-15 */
radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
@@ -6023,7 +6020,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
struct radeon_vm *vm)
 WRITE_DATA_DST_SEL(0)));
radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
radeon_ring_write(ring, 0);
-   radeon_ring_write(ring, 1 << vm->id);
+   radeon_ring_write(ring, 1 << vm_id);

/* compute doesn't have PFP */
if (usepfp) {
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index 4e8432d..7470a2e 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -901,25 +901,21 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
  * Update the page table base and flush the VM TLB
  * using sDMA (CIK).
  */
-void cik_dma_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm 
*vm)
+void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
+ unsigned vm_id, uint64_t pd_addr)
 {
-   struct radeon_ring *ring = >ring[ridx];
-
-   if (vm == NULL)
-   return;
-
radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 0xf000));
-   if (vm->id < 8) {
-   radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm->id << 2)) >> 2);
+   if (vm_id < 8) {
+   radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm_id << 2)) >> 2);
} else {
-   radeon_ring_write(ring, (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
((vm->id - 8) << 2)) >> 2);
+   radeon_ring_write(ring, (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
((vm_id - 8) << 2)) >> 2);
}
-   

[RFC PATCH v2] drm/exynos: make non kms drivers to be indenpendent modules

[Inki Dae]

Hi YoungJun,

On 2014년 11월 19일 13:39, YoungJun Cho wrote:
> Hi Inki,
> 
> There are 3 comments below.
> 
> On 11/19/2014 12:19 PM, Inki Dae wrote:
>> This patch makes non kms drivers to be independent modules.
>> For this, it removes all register codes to non kms drivers
>> from exynos_drm_drv module and adds module_init/exit
>> for each non kms driver so that each non kms driver can be
>> called independently.
>>
>> In addition, this patch adds non kms register/unregister functions
>> to exynos_drm_core module and also modifies existing codes relevant
>> to sub driver.
>>
>> The idea is that non kms driver is registered by entry point,
>> module_init, of each non kms driver and sets its own sub driver
>> to registered non kms driver object when the sub driver is probed.
>> For this, this patch adds a new structure, exynos_drm_non_kms_dev,
>> to exynos_drm_core module.
>>
>> Changelog v2:
>> - check if available g2d device node.
>> - return 0 instead of -EPROBE_DEFER in case of no non kms device
>>registered. This case is not error.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>   drivers/gpu/drm/exynos/exynos_drm_core.c|  164
>> +++
>>   drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
>>   drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
>>   drivers/gpu/drm/exynos/exynos_drm_fimc.c|   13 +++
>>   drivers/gpu/drm/exynos/exynos_drm_g2d.c |   42 +++
>>   drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 ++
>>   drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
>>   drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++
>>   8 files changed, 271 insertions(+), 90 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> index 4c9f972..715a0ad 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
>> @@ -19,6 +19,13 @@
>>   #include "exynos_drm_fbdev.h"
>>
>>   static LIST_HEAD(exynos_drm_subdrv_list);
>> +DEFINE_MUTEX(list_lock);
>> +
>> +struct exynos_drm_non_kms_dev {
>> +struct list_head list;
>> +struct exynos_drm_subdrv *subdrv;
>> +unsigned int device_type;
>> +};
>>
>>   int exynos_drm_create_enc_conn(struct drm_device *dev,
>>   struct exynos_drm_display *display)
>> @@ -55,12 +62,66 @@ err_destroy_encoder:
>>   return ret;
>>   }
>>
>> +int exynos_drm_non_kms_register(unsigned int device_type)
>> +{
>> +struct exynos_drm_non_kms_dev *dev;
>> +
>> +dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>> +if (!dev)
>> +return -ENOMEM;
>> +
>> +dev->device_type = device_type;
>> +
>> +mutex_lock(_lock);
>> +list_add_tail(>list, _drm_subdrv_list);
>> +mutex_unlock(_lock);
>> +
>> +return 0;
>> +}
>> +
>> +void exynos_drm_non_kms_unregister(unsigned int device_type)
>> +{
>> +struct exynos_drm_non_kms_dev *dev, *next;
>> +
>> +mutex_lock(_lock);
>> +list_for_each_entry_safe(dev, next, _drm_subdrv_list, list) {
>> +mutex_unlock(_lock);
>> +if (dev->device_type == device_type) {
>> +list_del_init(>list);
>> +kfree(dev);
>> +mutex_lock(_lock);
>> +break;
>> +}
>> +mutex_lock(_lock);
>> +}
>> +mutex_unlock(_lock);
>> +}
>> +
>>   int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
>>   {
>> +struct exynos_drm_non_kms_dev *dev;
>> +
>>   if (!subdrv)
>>   return -EINVAL;
>>
>> -list_add_tail(>list, _drm_subdrv_list);
>> +mutex_lock(_lock);
>> +if (list_empty(_drm_subdrv_list)) {
>> +mutex_unlock(_lock);
>> +return -ENODEV;
>> +}
>> +mutex_unlock(_lock);
> 
> The list_for_each_entry() could handle empty list, so list_empty() could
> be removed.

This is required for some codes for checking which error type should be
returned. So it would  better to just check list_empty.

> 
>> +
>> +mutex_lock(_lock);
>> +list_for_each_entry(dev, _drm_subdrv_list, list) {
>> +mutex_unlock(_lock);
>> +if (dev->device_type == subdrv->device_type) {
>> +dev->subdrv = subdrv;
>> +mutex_lock(_lock);
>> +break;
>> +}
>> +mutex_lock(_lock);
>> +}
>> +mutex_unlock(_lock);
>>
>>   return 0;
>>   }
>> @@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);
>>
>>   int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
>>   {
>> +struct exynos_drm_non_kms_dev *dev;
>> +
>>   if (!subdrv)
>>   return -EINVAL;
>>
>> -list_del(>list);
>> +mutex_lock(_lock);
>> +list_for_each_entry(dev, _drm_subdrv_list, list) {
>> +mutex_unlock(_lock);
>> +if (dev->device_type == subdrv->device_type) {
>> +dev->subdrv = NULL;
>> +break;
>> +}
>> +mutex_lock(_lock);
>> +}
>> +mutex_unlock(_lock);
>>
>>   return 0;
>>   }
>>   

[RFC PATCH v2] drm/exynos: make non kms drivers to be indenpendent modules

[YoungJun Cho]

Hi Inki,

There are 3 comments below.

On 11/19/2014 12:19 PM, Inki Dae wrote:
> This patch makes non kms drivers to be independent modules.
> For this, it removes all register codes to non kms drivers
> from exynos_drm_drv module and adds module_init/exit
> for each non kms driver so that each non kms driver can be
> called independently.
>
> In addition, this patch adds non kms register/unregister functions
> to exynos_drm_core module and also modifies existing codes relevant
> to sub driver.
>
> The idea is that non kms driver is registered by entry point,
> module_init, of each non kms driver and sets its own sub driver
> to registered non kms driver object when the sub driver is probed.
> For this, this patch adds a new structure, exynos_drm_non_kms_dev,
> to exynos_drm_core module.
>
> Changelog v2:
> - check if available g2d device node.
> - return 0 instead of -EPROBE_DEFER in case of no non kms device
>registered. This case is not error.
>
> Signed-off-by: Inki Dae 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_core.c|  164 
> +++
>   drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
>   drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c|   13 +++
>   drivers/gpu/drm/exynos/exynos_drm_g2d.c |   42 +++
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c |   12 ++
>   drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
>   drivers/gpu/drm/exynos/exynos_drm_rotator.c |   13 +++
>   8 files changed, 271 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
> b/drivers/gpu/drm/exynos/exynos_drm_core.c
> index 4c9f972..715a0ad 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
> @@ -19,6 +19,13 @@
>   #include "exynos_drm_fbdev.h"
>
>   static LIST_HEAD(exynos_drm_subdrv_list);
> +DEFINE_MUTEX(list_lock);
> +
> +struct exynos_drm_non_kms_dev {
> + struct list_head list;
> + struct exynos_drm_subdrv *subdrv;
> + unsigned int device_type;
> +};
>
>   int exynos_drm_create_enc_conn(struct drm_device *dev,
>   struct exynos_drm_display *display)
> @@ -55,12 +62,66 @@ err_destroy_encoder:
>   return ret;
>   }
>
> +int exynos_drm_non_kms_register(unsigned int device_type)
> +{
> + struct exynos_drm_non_kms_dev *dev;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
> +
> + dev->device_type = device_type;
> +
> + mutex_lock(_lock);
> + list_add_tail(>list, _drm_subdrv_list);
> + mutex_unlock(_lock);
> +
> + return 0;
> +}
> +
> +void exynos_drm_non_kms_unregister(unsigned int device_type)
> +{
> + struct exynos_drm_non_kms_dev *dev, *next;
> +
> + mutex_lock(_lock);
> + list_for_each_entry_safe(dev, next, _drm_subdrv_list, list) {
> + mutex_unlock(_lock);
> + if (dev->device_type == device_type) {
> + list_del_init(>list);
> + kfree(dev);
> + mutex_lock(_lock);
> + break;
> + }
> + mutex_lock(_lock);
> + }
> + mutex_unlock(_lock);
> +}
> +
>   int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
>   {
> + struct exynos_drm_non_kms_dev *dev;
> +
>   if (!subdrv)
>   return -EINVAL;
>
> - list_add_tail(>list, _drm_subdrv_list);
> + mutex_lock(_lock);
> + if (list_empty(_drm_subdrv_list)) {
> + mutex_unlock(_lock);
> + return -ENODEV;
> + }
> + mutex_unlock(_lock);

The list_for_each_entry() could handle empty list, so list_empty() could 
be removed.

> +
> + mutex_lock(_lock);
> + list_for_each_entry(dev, _drm_subdrv_list, list) {
> + mutex_unlock(_lock);
> + if (dev->device_type == subdrv->device_type) {
> + dev->subdrv = subdrv;
> + mutex_lock(_lock);
> + break;
> + }
> + mutex_lock(_lock);
> + }
> + mutex_unlock(_lock);
>
>   return 0;
>   }
> @@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);
>
>   int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
>   {
> + struct exynos_drm_non_kms_dev *dev;
> +
>   if (!subdrv)
>   return -EINVAL;
>
> - list_del(>list);
> + mutex_lock(_lock);
> + list_for_each_entry(dev, _drm_subdrv_list, list) {
> + mutex_unlock(_lock);
> + if (dev->device_type == subdrv->device_type) {
> + dev->subdrv = NULL;
> + break;
> + }
> + mutex_lock(_lock);
> + }
> + mutex_unlock(_lock);
>
>   return 0;
>   }
>   EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);
>
> -int exynos_drm_device_subdrv_probe(struct drm_device *dev)
> +int 

[PATCH 01/11] drm/radeon: rework vm_flush parameters

[Alex Deucher]

On Wed, Nov 19, 2014 at 8:01 AM, Christian König
 wrote:
> From: Christian König 
>
> Use ring structure instead of index and provide vm_id and pd_addr separately.
>
> Signed-off-by: Christian König 

Pushed to my 3.19-wip tree.  I'll send out a new radeon drm-next pull
request later today or tomorrow.

Alex

> ---
>  drivers/gpu/drm/radeon/cik.c | 23 ++-
>  drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
>  drivers/gpu/drm/radeon/ni.c  | 14 +-
>  drivers/gpu/drm/radeon/ni_dma.c  | 14 +-
>  drivers/gpu/drm/radeon/radeon.h  |  5 +++--
>  drivers/gpu/drm/radeon/radeon_asic.h | 18 --
>  drivers/gpu/drm/radeon/radeon_vm.c   |  3 ++-
>  drivers/gpu/drm/radeon/si.c  | 18 +++---
>  drivers/gpu/drm/radeon/si_dma.c  | 19 ---
>  9 files changed, 61 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 57a359d..d52ead9 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -5967,26 +5967,23 @@ static void cik_vm_decode_fault(struct radeon_device 
> *rdev,
>   * Update the page table base and flush the VM TLB
>   * using the CP (CIK).
>   */
> -void cik_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm *vm)
> +void cik_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
> + unsigned vm_id, uint64_t pd_addr)
>  {
> -   struct radeon_ring *ring = >ring[ridx];
> -   int usepfp = (ridx == RADEON_RING_TYPE_GFX_INDEX);
> -
> -   if (vm == NULL)
> -   return;
> +   int usepfp = (ring->idx == RADEON_RING_TYPE_GFX_INDEX);
>
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
>  WRITE_DATA_DST_SEL(0)));
> -   if (vm->id < 8) {
> +   if (vm_id < 8) {
> radeon_ring_write(ring,
> - (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm->id 
> << 2)) >> 2);
> + (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + (vm_id 
> << 2)) >> 2);
> } else {
> radeon_ring_write(ring,
> - (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + 
> ((vm->id - 8) << 2)) >> 2);
> + (VM_CONTEXT8_PAGE_TABLE_BASE_ADDR + ((vm_id 
> - 8) << 2)) >> 2);
> }
> radeon_ring_write(ring, 0);
> -   radeon_ring_write(ring, vm->pd_gpu_addr >> 12);
> +   radeon_ring_write(ring, pd_addr >> 12);
>
> /* update SH_MEM_* regs */
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> @@ -5994,7 +5991,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
> struct radeon_vm *vm)
>  WRITE_DATA_DST_SEL(0)));
> radeon_ring_write(ring, SRBM_GFX_CNTL >> 2);
> radeon_ring_write(ring, 0);
> -   radeon_ring_write(ring, VMID(vm->id));
> +   radeon_ring_write(ring, VMID(vm_id));
>
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 6));
> radeon_ring_write(ring, (WRITE_DATA_ENGINE_SEL(usepfp) |
> @@ -6015,7 +6012,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
> struct radeon_vm *vm)
> radeon_ring_write(ring, VMID(0));
>
> /* HDP flush */
> -   cik_hdp_flush_cp_ring_emit(rdev, ridx);
> +   cik_hdp_flush_cp_ring_emit(rdev, ring->idx);
>
> /* bits 0-15 are the VM contexts0-15 */
> radeon_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> @@ -6023,7 +6020,7 @@ void cik_vm_flush(struct radeon_device *rdev, int ridx, 
> struct radeon_vm *vm)
>  WRITE_DATA_DST_SEL(0)));
> radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
> radeon_ring_write(ring, 0);
> -   radeon_ring_write(ring, 1 << vm->id);
> +   radeon_ring_write(ring, 1 << vm_id);
>
> /* compute doesn't have PFP */
> if (usepfp) {
> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
> b/drivers/gpu/drm/radeon/cik_sdma.c
> index 4e8432d..7470a2e 100644
> --- a/drivers/gpu/drm/radeon/cik_sdma.c
> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
> @@ -901,25 +901,21 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
>   * Update the page table base and flush the VM TLB
>   * using sDMA (CIK).
>   */
> -void cik_dma_vm_flush(struct radeon_device *rdev, int ridx, struct radeon_vm 
> *vm)
> +void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
> + unsigned vm_id, uint64_t pd_addr)
>  {
> -   struct radeon_ring *ring = >ring[ridx];
> -
> -   if (vm == NULL)
> -   return;
> -
> radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 
> 0xf000));
> -   if (vm->id < 8) {
> -   radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
> (vm->id << 2)) >> 2);
> +   if 

[PATCH] drm/tegra: Select root window for event dispatch

[Sean Paul]

In finish pageflip, the driver was not selecting the root
window when dispatching events. This exposed a race where
a plane update would change the window selection and cause
tegra_dc_finish_page_flip to check the wrong base address.

This patch also protects access to the window selection register
as well as the registers affected by it.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/tegra/dc.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b957908..a3b41ea 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -168,7 +168,7 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
 const struct tegra_dc_window *window)
 {
unsigned h_offset, v_offset, h_size, v_size, h_dda, v_dda, bpp;
-   unsigned long value;
+   unsigned long value, flags;
bool yuv, planar;

/*
@@ -181,6 +181,8 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
else
bpp = planar ? 1 : 2;

+   spin_lock_irqsave(>lock, flags);
+
value = WINDOW_A_SELECT << index;
tegra_dc_writel(dc, value, DC_CMD_DISPLAY_WINDOW_HEADER);

@@ -273,6 +275,7 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,

case TEGRA_BO_TILING_MODE_BLOCK:
DRM_ERROR("hardware doesn't support block linear 
mode\n");
+   spin_unlock_irqrestore(>lock, flags);
return -EINVAL;
}

@@ -330,6 +333,7 @@ static int tegra_dc_setup_window(struct tegra_dc *dc, 
unsigned int index,
}

tegra_dc_window_commit(dc, index);
+   spin_unlock_irqrestore(>lock, flags);

return 0;
 }
@@ -339,10 +343,12 @@ static int tegra_window_plane_disable(struct drm_plane 
*plane)
struct tegra_dc *dc = to_tegra_dc(plane->crtc);
struct tegra_plane *p = to_tegra_plane(plane);
u32 value;
+   unsigned long flags;

if (!plane->crtc)
return 0;

+   spin_lock_irqsave(>lock, flags);
value = WINDOW_A_SELECT << p->index;
tegra_dc_writel(dc, value, DC_CMD_DISPLAY_WINDOW_HEADER);

@@ -351,6 +357,7 @@ static int tegra_window_plane_disable(struct drm_plane 
*plane)
tegra_dc_writel(dc, value, DC_WIN_WIN_OPTIONS);

tegra_dc_window_commit(dc, p->index);
+   spin_unlock_irqrestore(>lock, flags);

return 0;
 }
@@ -700,13 +707,14 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
unsigned int h_offset = 0, v_offset = 0;
struct tegra_bo_tiling tiling;
unsigned int format, swap;
-   unsigned long value;
+   unsigned long value, flags;
int err;

err = tegra_fb_get_tiling(fb, );
if (err < 0)
return err;

+   spin_lock_irqsave(>lock, flags);
tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);

value = fb->offsets[0] + y * fb->pitches[0] +
@@ -752,6 +760,7 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,

case TEGRA_BO_TILING_MODE_BLOCK:
DRM_ERROR("hardware doesn't support block linear 
mode\n");
+   spin_unlock_irqrestore(>lock, flags);
return -EINVAL;
}

@@ -777,6 +786,7 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
tegra_dc_writel(dc, value << 8, DC_CMD_STATE_CONTROL);
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
+   spin_unlock_irqrestore(>lock, flags);

return 0;
 }
@@ -790,7 +800,6 @@ void tegra_dc_enable_vblank(struct tegra_dc *dc)
value = tegra_dc_readl(dc, DC_CMD_INT_MASK);
value |= VBLANK_INT;
tegra_dc_writel(dc, value, DC_CMD_INT_MASK);
-
spin_unlock_irqrestore(>lock, flags);
 }

@@ -819,11 +828,16 @@ static void tegra_dc_finish_page_flip(struct tegra_dc *dc)

bo = tegra_fb_get_plane(crtc->primary->fb, 0);

+   spin_lock_irqsave(>lock, flags);
+
/* check if new start address has been latched */
+   tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
tegra_dc_writel(dc, READ_MUX, DC_CMD_STATE_ACCESS);
base = tegra_dc_readl(dc, DC_WINBUF_START_ADDR);
tegra_dc_writel(dc, 0, DC_CMD_STATE_ACCESS);

+   spin_unlock_irqrestore(>lock, flags);
+
if (base == bo->paddr + crtc->primary->fb->offsets[0]) {
spin_lock_irqsave(>event_lock, flags);
drm_send_vblank_event(drm, dc->pipe, dc->event);
-- 
2.1.1

[PATCH 11/11] drm/radeon/ci: disable needless sclk changes

[Alex Deucher]

The current code always reprogrammed the sclk levels,
but we don't currently handle disp sclk requirements
so just skip it.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 630434c..3f898d0 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3809,7 +3809,7 @@ static void ci_find_dpm_states_clocks_in_dpm_table(struct 
radeon_device *rdev,
pi->need_update_smu7_dpm_table |= DPMTABLE_OD_UPDATE_SCLK;
} else {
/* XXX check display min clock requirements */
-   if (0 != CISLAND_MINIMUM_ENGINE_CLOCK)
+   if (CISLAND_MINIMUM_ENGINE_CLOCK != 
CISLAND_MINIMUM_ENGINE_CLOCK)
pi->need_update_smu7_dpm_table |= DPMTABLE_UPDATE_SCLK;
}

-- 
1.8.3.1

[PATCH 10/11] drm/radeon/ci: force pcie level before sclk and mclk

[Alex Deucher]

Preferred ordering.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 73f8c4b..630434c 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4143,57 +4143,57 @@ int ci_dpm_force_performance_level(struct radeon_device 
*rdev,
int ret;

if (level == RADEON_DPM_FORCED_LEVEL_HIGH) {
-   if ((!pi->sclk_dpm_key_disabled) &&
-   pi->dpm_level_enable_mask.sclk_dpm_enable_mask) {
+   if ((!pi->pcie_dpm_key_disabled) &&
+   pi->dpm_level_enable_mask.pcie_dpm_enable_mask) {
levels = 0;
-   tmp = pi->dpm_level_enable_mask.sclk_dpm_enable_mask;
+   tmp = pi->dpm_level_enable_mask.pcie_dpm_enable_mask;
while (tmp >>= 1)
levels++;
if (levels) {
-   ret = ci_dpm_force_state_sclk(rdev, levels);
+   ret = ci_dpm_force_state_pcie(rdev, level);
if (ret)
return ret;
for (i = 0; i < rdev->usec_timeout; i++) {
-   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX) &
-  CURR_SCLK_INDEX_MASK) >> 
CURR_SCLK_INDEX_SHIFT;
+   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX_1) &
+  CURR_PCIE_INDEX_MASK) >> 
CURR_PCIE_INDEX_SHIFT;
if (tmp == levels)
break;
udelay(1);
}
}
}
-   if ((!pi->mclk_dpm_key_disabled) &&
-   pi->dpm_level_enable_mask.mclk_dpm_enable_mask) {
+   if ((!pi->sclk_dpm_key_disabled) &&
+   pi->dpm_level_enable_mask.sclk_dpm_enable_mask) {
levels = 0;
-   tmp = pi->dpm_level_enable_mask.mclk_dpm_enable_mask;
+   tmp = pi->dpm_level_enable_mask.sclk_dpm_enable_mask;
while (tmp >>= 1)
levels++;
if (levels) {
-   ret = ci_dpm_force_state_mclk(rdev, levels);
+   ret = ci_dpm_force_state_sclk(rdev, levels);
if (ret)
return ret;
for (i = 0; i < rdev->usec_timeout; i++) {
tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX) &
-  CURR_MCLK_INDEX_MASK) >> 
CURR_MCLK_INDEX_SHIFT;
+  CURR_SCLK_INDEX_MASK) >> 
CURR_SCLK_INDEX_SHIFT;
if (tmp == levels)
break;
udelay(1);
}
}
}
-   if ((!pi->pcie_dpm_key_disabled) &&
-   pi->dpm_level_enable_mask.pcie_dpm_enable_mask) {
+   if ((!pi->mclk_dpm_key_disabled) &&
+   pi->dpm_level_enable_mask.mclk_dpm_enable_mask) {
levels = 0;
-   tmp = pi->dpm_level_enable_mask.pcie_dpm_enable_mask;
+   tmp = pi->dpm_level_enable_mask.mclk_dpm_enable_mask;
while (tmp >>= 1)
levels++;
if (levels) {
-   ret = ci_dpm_force_state_pcie(rdev, level);
+   ret = ci_dpm_force_state_mclk(rdev, levels);
if (ret)
return ret;
for (i = 0; i < rdev->usec_timeout; i++) {
-   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX_1) &
-  CURR_PCIE_INDEX_MASK) >> 
CURR_PCIE_INDEX_SHIFT;
+   tmp = 
(RREG32_SMC(TARGET_AND_CURRENT_PROFILE_INDEX) &
+  CURR_MCLK_INDEX_MASK) >> 
CURR_MCLK_INDEX_SHIFT;
if (tmp == levels)
break;
udelay(1);
-- 
1.8.3.1

[PATCH 09/11] drm/radeon/ci: use different smc command for pcie dpm

[Alex Deucher]

Use unforce levels rather than enable mask instruction.
This is the preferred method.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index e781628..73f8c4b 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3773,7 +3773,7 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
return -EINVAL;
}
}
-
+#if 0
if (!pi->pcie_dpm_key_disabled) {
if (pi->dpm_level_enable_mask.pcie_dpm_enable_mask) {
result = ci_send_msg_to_smc_with_parameter(rdev,
@@ -3783,7 +3783,7 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
return -EINVAL;
}
}
-
+#endif
return 0;
 }

@@ -4247,6 +4247,14 @@ int ci_dpm_force_performance_level(struct radeon_device 
*rdev,
}
}
} else if (level == RADEON_DPM_FORCED_LEVEL_AUTO) {
+   if (!pi->pcie_dpm_key_disabled) {
+   PPSMC_Result smc_result;
+
+   smc_result = ci_send_msg_to_smc(rdev,
+   
PPSMC_MSG_PCIeDPM_UnForceLevel);
+   if (smc_result != PPSMC_Result_OK)
+   return -EINVAL;
+   }
ret = ci_upload_dpm_level_enable_mask(rdev);
if (ret)
return ret;
-- 
1.8.3.1

[PATCH 08/11] drm/radeon/ci: apply disp voltage changes before clk changes

[Alex Deucher]

Apply voltage changes for displays before changing clocks.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index c9963b5..e781628 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3752,6 +3752,8 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
struct ci_power_info *pi = ci_get_pi(rdev);
PPSMC_Result result;

+   ci_apply_disp_minimum_voltage_request(rdev);
+
if (!pi->sclk_dpm_key_disabled) {
if (pi->dpm_level_enable_mask.sclk_dpm_enable_mask) {
result = ci_send_msg_to_smc_with_parameter(rdev,
@@ -3782,8 +3784,6 @@ static int ci_upload_dpm_level_enable_mask(struct 
radeon_device *rdev)
}
}

-   ci_apply_disp_minimum_voltage_request(rdev);
-
return 0;
 }

-- 
1.8.3.1

[PATCH 07/11] drm/radeon: fix PCC debugging message for CI DPM

[Alex Deucher]

Add missing newline and print the bad gpio shift.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 8312140..c9963b5 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -5773,7 +5773,7 @@ int ci_dpm_init(struct radeon_device *rdev)
tmp |= DPM_ENABLED;
break;
default:
-   DRM_ERROR("Invalid PCC GPIO!");
+   DRM_ERROR("Invalid PCC GPIO: %u!\n", gpio.shift);
break;
}
WREG32_SMC(CNB_PWRMGT_CNTL, tmp);
-- 
1.8.3.1