Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

2017-08-17 Thread Ben Skeggs 
On 08/18/2017 08:20 AM, Ben Skeggs wrote:
> On 08/18/2017 08:16 AM, Colin Ian King wrote:
>> On 17/08/17 23:07, Ilia Mirkin wrote:
>>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  
>>> wrote:
 From: Colin Ian King 

 The null check on the array msto is incorrect since msto is never
 null. The null check should be instead on msto[i] since this is
 being dereferenced in the call to drm_mode_connector_attach_encoder.

 Thanks to Emil Velikov for pointing out the mistake in my original
 fix and for suggesting the correct fix.

 Detected by CoverityScan, CID#1375915 ("Array compared against 0")

 Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
 multi-stream")
 Signed-off-by: Colin Ian King 
 ---
  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
 b/drivers/gpu/drm/nouveau/nv50_display.c
 index f7b4326a4641..ed444ecd9e85 100644
 --- a/drivers/gpu/drm/nouveau/nv50_display.c
 +++ b/drivers/gpu/drm/nouveau/nv50_display.c
 @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
 drm_dp_mst_port *port,
 mstc->connector.funcs->reset(&mstc->connector);
 nouveau_conn_attach_properties(&mstc->connector);

 -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
 +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
>>>
>>> Ben will have to rule on which way is correct, but another
>>> interpretation is that it should be
>>>
>>> for (...; i < ARRAY_SIZE; i++)
>>>   if (mstm->msto[i])
>>> do_stuff()
>>
>> Yes, I suspect that is a better generic solution top cope with potential
>> "holes".
>>>
>>> I haven't the faintest clue whether the msto array can have "holes" or not.
>>
>> Indeed. Let's see what Ben says.
> No, there can't be holes here.  I believe the V2 patch to be correct.
Also, I've taken the patch in my tree, and will get it to Dave at some
point.

Thank you!
Ben.

> 
> Ben.
>>
>>
>>>
 drm_mode_connector_attach_encoder(&mstc->connector, 
 &mstm->msto[i]->encoder);

 drm_object_attach_property(&mstc->connector.base, 
 dev->mode_config.path_property, 0);
 --
 2.11.0

>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 
>>> in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>> ___
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
>>
> 



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

2017-08-17 Thread Ben Skeggs 
On 08/18/2017 08:16 AM, Colin Ian King wrote:
> On 17/08/17 23:07, Ilia Mirkin wrote:
>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  wrote:
>>> From: Colin Ian King 
>>>
>>> The null check on the array msto is incorrect since msto is never
>>> null. The null check should be instead on msto[i] since this is
>>> being dereferenced in the call to drm_mode_connector_attach_encoder.
>>>
>>> Thanks to Emil Velikov for pointing out the mistake in my original
>>> fix and for suggesting the correct fix.
>>>
>>> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>>>
>>> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
>>> multi-stream")
>>> Signed-off-by: Colin Ian King 
>>> ---
>>>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>>> b/drivers/gpu/drm/nouveau/nv50_display.c
>>> index f7b4326a4641..ed444ecd9e85 100644
>>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>>> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
>>> drm_dp_mst_port *port,
>>> mstc->connector.funcs->reset(&mstc->connector);
>>> nouveau_conn_attach_properties(&mstc->connector);
>>>
>>> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
>>> +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
>>
>> Ben will have to rule on which way is correct, but another
>> interpretation is that it should be
>>
>> for (...; i < ARRAY_SIZE; i++)
>>   if (mstm->msto[i])
>> do_stuff()
> 
> Yes, I suspect that is a better generic solution top cope with potential
> "holes".
>>
>> I haven't the faintest clue whether the msto array can have "holes" or not.
> 
> Indeed. Let's see what Ben says.
No, there can't be holes here.  I believe the V2 patch to be correct.

Ben.
> 
> 
>>
>>> drm_mode_connector_attach_encoder(&mstc->connector, 
>>> &mstm->msto[i]->encoder);
>>>
>>> drm_object_attach_property(&mstc->connector.base, 
>>> dev->mode_config.path_property, 0);
>>> --
>>> 2.11.0
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
> 



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

2017-08-17 Thread Colin Ian King 
On 17/08/17 23:07, Ilia Mirkin wrote:
> On Thu, Aug 17, 2017 at 6:03 PM, Colin King  wrote:
>> From: Colin Ian King 
>>
>> The null check on the array msto is incorrect since msto is never
>> null. The null check should be instead on msto[i] since this is
>> being dereferenced in the call to drm_mode_connector_attach_encoder.
>>
>> Thanks to Emil Velikov for pointing out the mistake in my original
>> fix and for suggesting the correct fix.
>>
>> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>>
>> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
>> multi-stream")
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>> b/drivers/gpu/drm/nouveau/nv50_display.c
>> index f7b4326a4641..ed444ecd9e85 100644
>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
>> drm_dp_mst_port *port,
>> mstc->connector.funcs->reset(&mstc->connector);
>> nouveau_conn_attach_properties(&mstc->connector);
>>
>> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
>> +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
> 
> Ben will have to rule on which way is correct, but another
> interpretation is that it should be
> 
> for (...; i < ARRAY_SIZE; i++)
>   if (mstm->msto[i])
> do_stuff()

Yes, I suspect that is a better generic solution top cope with potential
"holes".
> 
> I haven't the faintest clue whether the msto array can have "holes" or not.

Indeed. Let's see what Ben says.


> 
>> drm_mode_connector_attach_encoder(&mstc->connector, 
>> &mstm->msto[i]->encoder);
>>
>> drm_object_attach_property(&mstc->connector.base, 
>> dev->mode_config.path_property, 0);
>> --
>> 2.11.0
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

2017-08-17 Thread Ilia Mirkin 
On Thu, Aug 17, 2017 at 6:03 PM, Colin King  wrote:
> From: Colin Ian King 
>
> The null check on the array msto is incorrect since msto is never
> null. The null check should be instead on msto[i] since this is
> being dereferenced in the call to drm_mode_connector_attach_encoder.
>
> Thanks to Emil Velikov for pointing out the mistake in my original
> fix and for suggesting the correct fix.
>
> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>
> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
> multi-stream")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index f7b4326a4641..ed444ecd9e85 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
> drm_dp_mst_port *port,
> mstc->connector.funcs->reset(&mstc->connector);
> nouveau_conn_attach_properties(&mstc->connector);
>
> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
> +   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)

Ben will have to rule on which way is correct, but another
interpretation is that it should be

for (...; i < ARRAY_SIZE; i++)
  if (mstm->msto[i])
do_stuff()

I haven't the faintest clue whether the msto array can have "holes" or not.

> drm_mode_connector_attach_encoder(&mstc->connector, 
> &mstm->msto[i]->encoder);
>
> drm_object_attach_property(&mstc->connector.base, 
> dev->mode_config.path_property, 0);
> --
> 2.11.0
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

2017-08-17 Thread Colin King 
From: Colin Ian King 

The null check on the array msto is incorrect since msto is never
null. The null check should be instead on msto[i] since this is
being dereferenced in the call to drm_mode_connector_attach_encoder.

Thanks to Emil Velikov for pointing out the mistake in my original
fix and for suggesting the correct fix.

Detected by CoverityScan, CID#1375915 ("Array compared against 0")

Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 
multi-stream")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index f7b4326a4641..ed444ecd9e85 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
drm_dp_mst_port *port,
mstc->connector.funcs->reset(&mstc->connector);
nouveau_conn_attach_properties(&mstc->connector);
 
-   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
+   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
drm_mode_connector_attach_encoder(&mstc->connector, 
&mstm->msto[i]->encoder);
 
drm_object_attach_property(&mstc->connector.base, 
dev->mode_config.path_property, 0);
-- 
2.11.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] nvc0: fix handling of inverted render condition

2017-08-17 Thread Ilia Mirkin 
So ... how do you handle the case of a query that hasn't completed yet
and one of the no-wait enums is passed in?

On Thu, Aug 17, 2017 at 4:43 PM, Tobias Klausmann
 wrote:
> Wether we wait on an inverted rendering condition or not, we should not render
> on a passed query.
>
> This fixes the CTS test case 
> 'KHR-GL45.conditional_render_inverted.functional'.
>
> Signed-off-by: Tobias Klausmann 
> ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
> index e92695bd6a..e6c7d5a3ad 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
> @@ -132,7 +132,7 @@ nvc0_render_condition(struct pipe_context *pipe,
>  else
> cond = NVC0_3D_COND_MODE_RES_NON_ZERO;
>   } else {
> -cond = wait ? NVC0_3D_COND_MODE_EQUAL : NVC0_3D_COND_MODE_ALWAYS;
> +cond = NVC0_3D_COND_MODE_EQUAL;
>   }
>   break;
>default:
> --
> 2.14.0
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] nvc0: fix handling of inverted render condition

2017-08-17 Thread Tobias Klausmann 
Wether we wait on an inverted rendering condition or not, we should not render
on a passed query.

This fixes the CTS test case 'KHR-GL45.conditional_render_inverted.functional'.

Signed-off-by: Tobias Klausmann 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_query.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
index e92695bd6a..e6c7d5a3ad 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query.c
@@ -132,7 +132,7 @@ nvc0_render_condition(struct pipe_context *pipe,
 else
cond = NVC0_3D_COND_MODE_RES_NON_ZERO;
  } else {
-cond = wait ? NVC0_3D_COND_MODE_EQUAL : NVC0_3D_COND_MODE_ALWAYS;
+cond = NVC0_3D_COND_MODE_EQUAL;
  }
  break;
   default:
-- 
2.14.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 102275] Laptop bootup and suspend and wake issues

2017-08-17 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102275

Rhys Kidd  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Rhys Kidd  ---
Hi Eric,
Thanks for the report. This looks to be a duplicate of bz#100228.

nouveau has difficulties with the GTX 1050 Mobile (GP107/NV137) around power
state up/down. I'd suggest you continue to follow that bug report for further
updates.

Whilst nouveau.runpm=0 assists a little bit, for now, to improve the experience
on the XPS 9560 you should use nouveau.modeset=0 (although that does mean the
Nvidia GPU is unavailable for use). This suggestion might change with future
kernel releases.

*** This bug has been marked as a duplicate of bug 100228 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 100228] [NV137] bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ]

2017-08-17 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100228

Rhys Kidd  changed:

   What|Removed |Added

 CC||majzo...@umsl.edu

--- Comment #15 from Rhys Kidd  ---
*** Bug 102275 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 102275] New: Laptop bootup and suspend and wake issues

2017-08-17 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102275

Bug ID: 102275
   Summary: Laptop bootup and suspend and wake issues
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: majzo...@umsl.edu
QA Contact: nouveau@lists.freedesktop.org

Created attachment 133577
  --> https://bugs.freedesktop.org/attachment.cgi?id=133577&action=edit
output of journalctl -b -1 booting into 4.12.5-300

I don't know exactly where to post this bug. Initially I posted on RedHat
bugzilla #1481510, but it appears perhaps I should be posting it here. The
problem started on upgrading from kernel 4.11.11-300 to 4.12.5-300.

Description of problem:

15-30 seconds of black screen and unresponsive mouse, trackpad, keyboard on
bootup and suspend and wake.

Version-Release number of selected component (if applicable):

kernel 4.12.5-300

How reproducible:

Every time booting up or suspending and waking laptop

Steps to Reproduce:
1. Boot up and wait for login screen
2. suspend laptop by closing lid with AC power on
3. wake computer by opening lid 

Actual results:


Expected results:


Additional info:
I was having lots of trouble with suspend and wake issues. See Bug 1470473.
Resolved all issues after setting boot parameters and updating Dell XPS BIOS
firmware and everything was working well with kernel 4.11.11-300.

Current boot sequence that works with 4.11.11-300 is:

load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  46985d35-b7e3-41f9-9bc0-8ae6c11bc84c
else
  search --no-floppy --fs-uuid --set=root 46985d35-b7e3-41f9-9bc0-8ae6c11bc84c
fi
linuxefi /vmlinuz-4.11.11-300.fc26.x86_64 root=/dev/mapper/fedora-root ro
rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap nouveau.runpm=0 rhgb quiet
resume=/dev/dm-1
initrdefi /initramfs-4.11.11-300.fc26.x86_64.img
=

Using the same boot sequence with 4.12.5-300 is problematic with bootup and
suspend and wake.


Hardware: XPS 15 9560
Fedora 26: all the latest updates current as of 14 Aug 2017

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 08/13] drm/nouveau/imem/gk20a: Use sychronized interface of the IOMMU-API

2017-08-17 Thread Joerg Roedel 
From: Joerg Roedel 

The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.

To make conversion easier, new synchronized functions have
been introduced which give these guarantees again until the
code is converted to use the new TLB-flush interface of the
IOMMU-API, which allows certain optimizations.

But for now, just convert this code to use the synchronized
functions so that it will behave as before.

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Signed-off-by: Joerg Roedel 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index cd5adbe..3f0de47 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -322,8 +322,9 @@ gk20a_instobj_dtor_iommu(struct nvkm_memory *memory)
 
/* Unmap pages from GPU address space and free them */
for (i = 0; i < node->base.mem.size; i++) {
-   iommu_unmap(imem->domain,
-   (r->offset + i) << imem->iommu_pgshift, PAGE_SIZE);
+   iommu_unmap_sync(imem->domain,
+(r->offset + i) << imem->iommu_pgshift,
+PAGE_SIZE);
dma_unmap_page(dev, node->dma_addrs[i], PAGE_SIZE,
   DMA_BIDIRECTIONAL);
__free_page(node->pages[i]);
@@ -458,14 +459,15 @@ gk20a_instobj_ctor_iommu(struct gk20a_instmem *imem, u32 
npages, u32 align,
for (i = 0; i < npages; i++) {
u32 offset = (r->offset + i) << imem->iommu_pgshift;
 
-   ret = iommu_map(imem->domain, offset, node->dma_addrs[i],
-   PAGE_SIZE, IOMMU_READ | IOMMU_WRITE);
+   ret = iommu_map_sync(imem->domain, offset, node->dma_addrs[i],
+PAGE_SIZE, IOMMU_READ | IOMMU_WRITE);
if (ret < 0) {
nvkm_error(subdev, "IOMMU mapping failure: %d\n", ret);
 
while (i-- > 0) {
offset -= PAGE_SIZE;
-   iommu_unmap(imem->domain, offset, PAGE_SIZE);
+   iommu_unmap_sync(imem->domain, offset,
+PAGE_SIZE);
}
goto release_area;
}
-- 
2.7.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: remove redundant null check on array mstm->msto

2017-08-17 Thread Colin Ian King 
On 17/08/17 13:21, Emil Velikov wrote:
> On 17 August 2017 at 11:37, Colin King  wrote:
>> From: Colin Ian King 
>>
>> The check to see if mstm->msto is null is redundant because it is
>> an array and hence can never be null.  Remove the redundant check.
>>
>> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
>> b/drivers/gpu/drm/nouveau/nv50_display.c
>> index f7b4326a4641..51e9081b95a0 100644
>> --- a/drivers/gpu/drm/nouveau/nv50_display.c
>> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
>> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
>> drm_dp_mst_port *port,
>> mstc->connector.funcs->reset(&mstc->connector);
>> nouveau_conn_attach_properties(&mstc->connector);
>>
>> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
>> +   for (i = 0; i < ARRAY_SIZE(mstm->msto); i++)
> I think that should be mstm->msto[i]. After all we are dereferencing
> the pointer, so we don't want to crash.

Yes, that makes far more sense. I'll send a V2. Thanks Emil.

> 
>> drm_mode_connector_attach_encoder(&mstc->connector, 
>> &mstm->msto[i]->encoder);
> 
> -Emil
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: remove redundant null check on array mstm->msto

2017-08-17 Thread Emil Velikov 
On 17 August 2017 at 11:37, Colin King  wrote:
> From: Colin Ian King 
>
> The check to see if mstm->msto is null is redundant because it is
> an array and hence can never be null.  Remove the redundant check.
>
> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index f7b4326a4641..51e9081b95a0 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
> drm_dp_mst_port *port,
> mstc->connector.funcs->reset(&mstc->connector);
> nouveau_conn_attach_properties(&mstc->connector);
>
> -   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
> +   for (i = 0; i < ARRAY_SIZE(mstm->msto); i++)
I think that should be mstm->msto[i]. After all we are dereferencing
the pointer, so we don't want to crash.

> drm_mode_connector_attach_encoder(&mstc->connector, 
> &mstm->msto[i]->encoder);

-Emil
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] drm/nouveau: remove redundant null check on array mstm->msto

2017-08-17 Thread Colin King 
From: Colin Ian King 

The check to see if mstm->msto is null is redundant because it is
an array and hence can never be null.  Remove the redundant check.

Detected by CoverityScan, CID#1375915 ("Array compared against 0")

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index f7b4326a4641..51e9081b95a0 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -3141,7 +3141,7 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct 
drm_dp_mst_port *port,
mstc->connector.funcs->reset(&mstc->connector);
nouveau_conn_attach_properties(&mstc->connector);
 
-   for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto; i++)
+   for (i = 0; i < ARRAY_SIZE(mstm->msto); i++)
drm_mode_connector_attach_encoder(&mstc->connector, 
&mstm->msto[i]->encoder);
 
drm_object_attach_property(&mstc->connector.base, 
dev->mode_config.path_property, 0);
-- 
2.11.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 101322] GM108/NV118: 0 MiB DDR3 and boot crash in gf100_ltc_oneinit_tag_ram

2017-08-17 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101322

--- Comment #8 from Daniel Drake  ---
Sorry for the slow response.
We tested the patch against 4.13.rc5 and the issue is still there.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau