date:20160613

[PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()

2016-06-13 Thread weiyj...@163.com

From: Wei Yongjun 

Add the missing unlock before return from function i915_ppgtt_info()
in the error handling case.

Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex)
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3269033..1035468 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2365,16 +2365,16 @@ static int i915_ppgtt_info(struct seq_file *m, void 
*data)
task = get_pid_task(file->pid, PIDTYPE_PID);
if (!task) {
ret = -ESRCH;
-   goto out_put;
+   goto out_unlock;
}
seq_printf(m, "\nproc: %s\n", task->comm);
put_task_struct(task);
idr_for_each(&file_priv->context_idr, per_file_ctx,
 (void *)(unsigned long)m);
}
+out_unlock:
mutex_unlock(&dev->filelist_mutex);

-out_put:
intel_runtime_pm_put(dev_priv);
mutex_unlock(&dev->struct_mutex);

[PATCH 2/2] drm/amdgpu: stop disabling irqs when it isn't neccessary

2016-06-13 Thread Daniel Vetter

On Mon, Jun 13, 2016 at 7:37 PM, Christian KÃ¶nig
 wrote:
> Am 13.06.2016 um 18:33 schrieb Daniel Vetter:
>>
>> On Mon, Jun 13, 2016 at 04:12:43PM +0200, Christian KÃ¶nig wrote:
>>>
>>> From: Christian KÃ¶nig 
>>>
>>> A regular spin_lock/unlock should do here as well.
>>>
>>> Signed-off-by: Christian KÃ¶nig 
>>
>> Just drive-by comment, but you can't mix up irq spinlocks with normal
>> ones. And there's places where this is still irqsave, but some of these
>> functions can be called directly from the scheduler kthread. You can only
>> drop the _irqsave if you know you're always called from hardirq context
>> (softirq isn't enough), or when you know someone already disabled
>> interrupts. And you can simplify the _irqsave to just _irq when you are in
>> always in process context and irqs are always still enabled.
>>
>> On a super-quick look seems fishy.
>
>
> The point is there isn't even any IRQ involved in all of this.
>
> The spin is either locked from a work item or the kthread, never from irq
> context.

In that case git grep job_list_lock finds more of those in sched_fence.c.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836: wierd condition ?

2016-06-13 Thread Deucher, Alexander

> -Original Message-
> From: David Binderman [mailto:linuxdev.baldrick at gmail.com]
> Sent: Monday, June 13, 2016 4:16 AM
> To: Deucher, Alexander; Koenig, Christian; airlied at linux.ie; dri-
> devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> dcb314 at hotmail.com
> Subject: linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836:
> wierd condition ?
> 
> Hello there,
> 
> linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836]: (style)
> Boolean result is used in bitwise operation. Clarify expression with
> parentheses.
> 
> Source code is
> 
> if ((ring->me == me_id) & (ring->pipe == pipe_id))
> 
> Maybe better code
> 
> if ((ring->me == me_id) && (ring->pipe == pipe_id))
> 

Good catch.  Fixed in the attached patch.

> Also in the same file:
> 
> [drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3866]: (style) Variable 'data'
> is assigned a value that is never used.

The readback of the register here is needed to wake up the block after 
disabling powergating.

> [drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4321]: (style) Variable
> 'mc_shared_chmap' is assigned a value that is never used.

I think this one can be dropped.

> [drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4657]: (style) Variable 'tmp'
> is assigned a value that is never used.
> 

This operation requires a posted write (i.e., a read back of the register to 
make sure the write has completed).

Thanks!

Alex

> Regards
> 
> David Binderman
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-amdgpu-gfx7-fix-broken-condition-check.patch
Type: application/octet-stream
Size: 1036 bytes
Desc: 0001-drm-amdgpu-gfx7-fix-broken-condition-check.patch
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160613/d6888944/attachment.obj>

[Bug 96360] [bisected: 3d02b7] VM fault with kernel 4.7-rc1 on Alien: Isolation

2016-06-13 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #11 from Nicolai HÃ¤hnle  ---
Created attachment 124514
  --> https://bugs.freedesktop.org/attachment.cgi?id=124514&action=edit
preliminary patch

Problem understood - we're generating bad shader code - though I still need to
double-check all the possible corner cases.

In the meantime, the attached patch for LLVM should fix Alien: Isolation.

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

[PATCH v2 1/2] drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config

2016-06-13 Thread Daniel Vetter

On Mon, Jun 13, 2016 at 06:49:57PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 02.06.2016, 22:28 +0200 schrieb Daniel Vetter:
> > On Thu, Jun 02, 2016 at 07:27:51PM +0200, Philipp Zabel wrote:
> > > Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
> > > in a modeset. (v2)"), the reference counts of all connectors in the
> > > drm_mode_set given to drm_crtc_helper_set_config are incremented, and then
> > > the reference counts of all connectors are decremented on success, but in 
> > > a
> > > temporary copy of the connector structure. This leads to the following
> > > error after the first modeset on imx-drm:
> > > 
> > > Unable to handle kernel NULL pointer dereference at virtual address 
> > > 0004
> > > pgd = ad8c4000
> > > [0004] *pgd=3d9c5831, *pte=, *ppte=
> > > Internal error: Oops: 817 [#1] PREEMPT SMP ARM
> > > Modules linked in:
> > > CPU: 1 PID: 190 Comm: kmsfb-manage Not tainted 4.7.0-rc1+ #657
> > > Hardware name: Freescale i.MX6 Quad/DualLit: [<80506098>]lr : 
> > > [<80252e94>]psr: 200c0013
> > > sp : adca7ca8  ip : adca7b90  fp : adca7cd4
> > > r10:   r9 : 0100  r8 : 0200
> > > r7 : af3c9800  r6 : aded7848  r5 : aded7800  r4 : 
> > > r3 : af3ca058  r2 : 0200  r1 : af3ca058  r0 : 
> > > Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> > > Control: 10c5387d  Table: 3d8c404a  DAC: 0051
> > > Process kmsfb-manage (pid: 190, stack limit = 0xadca6210)
> > > Stack: (0xadca7ca8 to 0xadca8000)
> > > 7ca0:   805190e0 aded7800 aded7820 80501a88 8155a290 
> > > af3c9c6c
> > > 7cc0: adca7ddc 000f adca7cec adca7cd8 80519104 80506044 805190e0 
> > > aded7800
> > > 7ce0: adca7d04 adca7cf0 80501ac0 805190ec aded7820 aded7814 adca7d24 
> > > adca7d08
> > > 7d00: 804fdb80 80501a94 aded7800 af3ca010 aded7afc af3c9c60 adca7d94 
> > > adca7d28
> > > 7d20: 804e3518 804fdb20  af3c9b1c adca7d50 81506f44  
> > > 8093c500
> > > 7d40: af3c9c6c ae4f2ca8 ae4f2c18   ae637f00  
> > > aded7800
> > > 7d60: 0001 af3c9800 af23c300 ae77fcc0 ae4f2c18 0001 af3c9800 
> > > 8155a290
> > > 7d80: af1af700 adca6000 adca7db4 adca7d98 804fea6c 804e2de4 adca7e50 
> > > adb3d940
> > > 7da0: 0001 af3c9800 adca7e24 adca7db8 8050440c 804fea0c ae77fcc0 
> > > 0003
> > > 7dc0: adca7e24 adb3d940 af1af700 ae77fcc0 ae77fccc ae4f2c18 8083d44c 
> > > ae77fcc0
> > > 7de0: ae4002 80d03040 adca7e64 adca7e40 adca7e50 80503f08
> > > 7e40: 7ebd5630 adca7e50 0068 c06864a2 7ebd5be8  0001 
> > > 0018
> > > 7e60: 0026    0001 000115bc 05010500 
> > > 05a0059f
> > > 7e80: 0320 03360321 0337 003c  0040 30383231 
> > > 30303878
> > > 7ea0:       80173058 
> > > 80172e30
> > > 7ec0: 80d77d32 4000 adf7d900 0003  7ebd5630 af342bb0 
> > > adfe3b80
> > > 7ee0: 80272f50 0003 adca6000  adca7f7c adca7f00 802725ec 
> > > 804f52cc
> > > 7f00: 802809cc 80178450   80280880 80145904 adb3d8c0 
> > > adf7d990
> > > 7f20:  0003 4000 01614c10 c06864a2 0003 adca6000 
> > > 
> > > 7f40: adca7f6c adca7f50 80280b04 8028088c 000115bc adfe3b81 7ebd5630 
> > > adfe3b80
> > > 7f60: c06864a2 0003 adca6000  adca7fa4 adca7f80 80272f50 
> > > 80272548
> > > 7f80: 000115bc 00017050 0001 01614c10 0036 801089e4  
> > > adca7fa8
> > > 7fa0: 80108840 80272f18 00017050 0001 0003 c06864a2 7ebd5630 
> > > 000115bc
> > > 7fc0: 00017050 0001 01614c10 0036 0003  0026 
> > > 0018
> > > 7fe0: 00016f38 7ebd562c b5e9 76ef31e6 400c0030 0003 ff5f37db 
> > > bfe7dd4d
> > > Backtrace:
> > > [<80506038>] (drm_connector_cleanup) from [<80519104>] 
> > > (dw_hdmi_connector_destroy+0x24/0x28)
> > >  r10:000f r9:adca7ddc r8:af3c9c6c r7:8155a290 r6:80501a88 
> > > r5:aded7820
> > >  r4:aded7800 r3:805190e0
> > > [<805190e0>] (dw_hdmi_connector_destroy) from [<80501ac0>] 
> > > (drm_connector_free+0x38/0x3c)
> > >  r4:aded7800 nreference) from [<804e3518>] 
> > > (drm_crtc_helper_set_config+0x740/0xbf4)
> > >  r6:af3c9c60 r5:aded7afc r4:af3ca010 r3:aded7800
> > > [<804e2dd8>] (drm_crtc_helper_set_config) from [<804fea6c>] 
> > > (drm_mode_set_config_internal+0x6c/0xf4)
> > >  r10:adca6000 r9:af1af700 r8:8155a290 r7:af3c9800 r6:0001 
> > > r5:ae4f2c18
> > >  r4:ae77fcc0
> > > [<804fea00>] (drm_mode_set_config_internal) from [<8050440c>] 
> > > (drm_mode_setcrtc+0x504/0x57c)
> > >  r7:af3c9800 r6:0001 r5:adb3d940 r4:adca7e50
> > > [<80503f08>] (drm_mode_setcrtc) from [<804f5404>] 
> > > (drm_ioctl+0x144/0x4dc)
> > >  r10:ada2e000 r9:00

[PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache

2016-06-13 Thread Tomasz Figa

On Mon, Jun 13, 2016 at 7:31 PM, Shunqian Zheng
 wrote:
> HI,
>
>
> On 2016å¹´06æ13æ¥ 18:21, Tomasz Figa wrote:
>>
>> On Mon, Jun 13, 2016 at 6:56 PM, Shunqian Zheng
>>  wrote:
>>>
>>> Hi
>>>
>>> On 2016å¹´06æ10æ¥ 17:10, Tomasz Figa wrote:

 Hi,

 On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng 
 wrote:
>
> Use DMA API instead of architecture internal functions like
> __cpuc_flush_dcache_area() etc.
>
> To support the virtual device like DRM the virtual slave iommu
> added in the previous patch, attaching to which the DRM can use
> it own domain->dev for dma_map_*(), dma_sync_*() even VOP is disabled.
>
> With this patch, this driver is available for ARM64 like RK3399.
>
 Could we instead simply allocate coherent memory for page tables using
 dma_alloc_coherent() and skip any flushing on CPU side completely? If
 I'm looking correctly, the driver only reads back the page directory
 when checking if there is a need to allocate new page table, so there
 shouldn't be any significant penalty for disabling the cache.
>>>
>>> I try to use dma_alloc_coherent() to replace the dma_map_single(),
>>> but it doesn't work for me properly.
>>> Because the DRM uses the iommu_dma_ops instead the swiotlb_dma_ops after
>>> attaching
>>> to iommu, so when the iommu domain need to alloc a new page in
>>> rk_iommu_map(),
>>> it would call:
>>> rk_iommu_map()  --> dma_alloc_coherent()  --> ops->alloc()  -->
>>> iommu_map()
>>> --> rk_iommu_map()
>>
>> It shouldn't call iommu_map(), because the IOMMU is not behind another
>> IOMMU. Are you sure you called dma_alloc_coherent() on behalf of the
>> IOMMU struct device and not the DRM device?
>
> I called dma_alloc_coherent() with DRM device but not the IOMMU device,
> because DRM didn't attach to any iommu. Even allocating an virtual one when
> attaching, the iommu->dev
> is DRM device though.
> Am I right here?

What I meant, is that even though rk_iommu_map() is called for DRM
device, the page table allocation happening inside should be called
for the IOMMU device itself, because it's the consumer of these page
tables.

Best regards,
Tomasz

[PATCH 2/2] drm/amdgpu: stop disabling irqs when it isn't neccessary

2016-06-13 Thread Christian König

Am 13.06.2016 um 18:33 schrieb Daniel Vetter:
> On Mon, Jun 13, 2016 at 04:12:43PM +0200, Christian KÃ¶nig wrote:
>> From: Christian KÃ¶nig 
>>
>> A regular spin_lock/unlock should do here as well.
>>
>> Signed-off-by: Christian KÃ¶nig 
> Just drive-by comment, but you can't mix up irq spinlocks with normal
> ones. And there's places where this is still irqsave, but some of these
> functions can be called directly from the scheduler kthread. You can only
> drop the _irqsave if you know you're always called from hardirq context
> (softirq isn't enough), or when you know someone already disabled
> interrupts. And you can simplify the _irqsave to just _irq when you are in
> always in process context and irqs are always still enabled.
>
> On a super-quick look seems fishy.

The point is there isn't even any IRQ involved in all of this.

The spin is either locked from a work item or the kthread, never from 
irq context.

Christian.

> -Daniel
>
>> ---
>>   drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 14 ++
>>   1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> index b1d49c5..e13b140 100644
>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> @@ -331,17 +331,16 @@ static void amd_sched_job_finish(struct work_struct 
>> *work)
>>  struct amd_sched_job *s_job = container_of(work, struct amd_sched_job,
>> finish_work);
>>  struct amd_gpu_scheduler *sched = s_job->sched;
>> -unsigned long flags;
>>   
>>  /* remove job from ring_mirror_list */
>> -spin_lock_irqsave(&sched->job_list_lock, flags);
>> +spin_lock(&sched->job_list_lock);
>>  list_del_init(&s_job->node);
>>  if (sched->timeout != MAX_SCHEDULE_TIMEOUT) {
>>  struct amd_sched_job *next;
>>   
>> -spin_unlock_irqrestore(&sched->job_list_lock, flags);
>> +spin_unlock(&sched->job_list_lock);
>>  cancel_delayed_work_sync(&s_job->work_tdr);
>> -spin_lock_irqsave(&sched->job_list_lock, flags);
>> +spin_lock(&sched->job_list_lock);
>>   
>>  /* queue TDR for next job */
>>  next = list_first_entry_or_null(&sched->ring_mirror_list,
>> @@ -350,7 +349,7 @@ static void amd_sched_job_finish(struct work_struct 
>> *work)
>>  if (next)
>>  schedule_delayed_work(&next->work_tdr, sched->timeout);
>>  }
>> -spin_unlock_irqrestore(&sched->job_list_lock, flags);
>> +spin_unlock(&sched->job_list_lock);
>>  sched->ops->free_job(s_job);
>>   }
>>   
>> @@ -364,15 +363,14 @@ static void amd_sched_job_finish_cb(struct fence *f, 
>> struct fence_cb *cb)
>>   static void amd_sched_job_begin(struct amd_sched_job *s_job)
>>   {
>>  struct amd_gpu_scheduler *sched = s_job->sched;
>> -unsigned long flags;
>>   
>> -spin_lock_irqsave(&sched->job_list_lock, flags);
>> +spin_lock(&sched->job_list_lock);
>>  list_add_tail(&s_job->node, &sched->ring_mirror_list);
>>  if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
>>  list_first_entry_or_null(&sched->ring_mirror_list,
>>   struct amd_sched_job, node) == s_job)
>>  schedule_delayed_work(&s_job->work_tdr, sched->timeout);
>> -spin_unlock_irqrestore(&sched->job_list_lock, flags);
>> +spin_unlock(&sched->job_list_lock);
>>   }
>>   
>>   static void amd_sched_job_timedout(struct work_struct *work)
>> -- 
>> 2.5.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache

2016-06-13 Thread Tomasz Figa

On Mon, Jun 13, 2016 at 6:56 PM, Shunqian Zheng
 wrote:
> Hi
>
> On 2016å¹´06æ10æ¥ 17:10, Tomasz Figa wrote:
>>
>> Hi,
>>
>> On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng 
>> wrote:
>>>
>>> Use DMA API instead of architecture internal functions like
>>> __cpuc_flush_dcache_area() etc.
>>>
>>> To support the virtual device like DRM the virtual slave iommu
>>> added in the previous patch, attaching to which the DRM can use
>>> it own domain->dev for dma_map_*(), dma_sync_*() even VOP is disabled.
>>>
>>> With this patch, this driver is available for ARM64 like RK3399.
>>>
>> Could we instead simply allocate coherent memory for page tables using
>> dma_alloc_coherent() and skip any flushing on CPU side completely? If
>> I'm looking correctly, the driver only reads back the page directory
>> when checking if there is a need to allocate new page table, so there
>> shouldn't be any significant penalty for disabling the cache.
>
> I try to use dma_alloc_coherent() to replace the dma_map_single(),
> but it doesn't work for me properly.
> Because the DRM uses the iommu_dma_ops instead the swiotlb_dma_ops after
> attaching
> to iommu, so when the iommu domain need to alloc a new page in
> rk_iommu_map(),
> it would call:
> rk_iommu_map()  --> dma_alloc_coherent()  --> ops->alloc()  --> iommu_map()
> --> rk_iommu_map()

It shouldn't call iommu_map(), because the IOMMU is not behind another
IOMMU. Are you sure you called dma_alloc_coherent() on behalf of the
IOMMU struct device and not the DRM device?

Best regards,
Tomasz

[Bug 96512] Portal Stories Mel: Player's hands appear black at high shader quality

2016-06-13 Thread bugzilla-dae...@freedesktop.org

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

Bug ID: 96512
Summary: Portal Stories Mel: Player's hands appear black at
high shader quality
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel at lists.freedesktop.org
Reporter: robin at paxnos.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 124512
--> https://bugs.freedesktop.org/attachment.cgi?id=124512&action=edit
Example from Portal Stories: Mel. Upper picture: Shader quality "Very high" (or
high), Lower picture: Shader quality "medium" (or lower)

Hello,

this is my first bug report, so I hope the information provided is sufficient.

In Portal Stories: Mel and Portal 2 (reportedly), the player's arms and hands
(and a few other objects, as demonstrated in the attached picture) appear black
when the shader quality setting is set to "High" or "Very High", but appears
normal if it is medium or lower.

This seems to only happen to a few objects, like the arms. In Portal 2 this is
not visible as often, as the player's arms are usually not visible like that.
Not sure if this is a Mesa bug, but it has been pointed out that the reports
have so far only been on different versions of Mesa, so.. just thought I'd
report it here in case.
I actually wanted to provide apitrace files, but I could not get it to work,
sadly.

I sorted this under radeonsi because this is the driver I use, but among the
other reports have been Intel systems. Please correct the bug report
classification if not accurate.

The bug on Valve's git: https://github.com/ValveSoftware/portal2/issues/255

My system:
Kubuntu 16.04
Intel i5-2400
8 GB DDR3 RAM
Radeon HD 7950 Boost
(Steam Overlay deactivated)

OpenGL renderer string: Gallium 0.4 on AMD TAHITI (DRM 2.43.0 /
4.4.0-24-generic, LLVM 3.9.0)
OpenGL core profile version string: 4.2 (Core Profile) Mesa 12.1.0-devel -
padoka PPA (git-42624ea)
OpenGL core profile shading language version string: 4.20

Please let me know if there's something else you need

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

1 2 >

1 - 100 of 121 matches

Mail list logo