[PATCH 3/3] drm/ttm: enable eviction for Per-VM-BO

[Roger He]

Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 098b22e..e7438b0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-  struct reservation_object *resv,
   uint32_t mem_type,
   const struct ttm_place *place,
   struct ttm_operation_ctx *ctx)
@@ -722,10 +721,8 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
-   if (bo->resv == resv) {
-   if (list_empty(&bo->ddestroy))
-   continue;
-   } else {
+   if (!ctx->allow_reserved_eviction ||
+   bo->resv != ctx->resv) {
locked = reservation_object_trylock(bo->resv);
if (!locked)
continue;
@@ -835,7 +832,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, ctx);
+   ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
if (unlikely(ret != 0))
return ret;
} while (1);
@@ -1332,8 +1329,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
-   ret = ttm_mem_evict_first(bdev, NULL, mem_type,
- NULL, &ctx);
+   ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/amd/amdgpu: init allow_reserved_eviction and resv when create a new bo

[Roger He]

Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e
Signed-off-by: Roger He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index dc0a8be..7c7f56f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -327,7 +327,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
   uint64_t init_value,
   struct amdgpu_bo **bo_ptr)
 {
-   struct ttm_operation_ctx ctx = { !kernel, false };
+   struct ttm_operation_ctx ctx = { !kernel, false, true, resv };
struct amdgpu_bo *bo;
enum ttm_bo_type type;
unsigned long page_align;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/ttm: add allow_reserved_eviction and resv into ttm_operation_ctx

[Roger He]

allow_reserved_eviction: Allow eviction of reserved BOs
resv: Reservation object to allow reserved evictions with

Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
Signed-off-by: Roger He 
---
 include/drm/ttm/ttm_bo_api.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 368eb02..c126330 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -263,6 +263,8 @@ struct ttm_bo_kmap_obj {
  *
  * @interruptible: Sleep interruptible if sleeping.
  * @no_wait_gpu: Return immediately if the GPU is busy.
+ * @allow_reserved_eviction: Allow eviction of reserved BOs.
+ * @resv: Reservation object to allow reserved evictions with.
  *
  * Context for TTM operations like changing buffer placement or general memory
  * allocation.
@@ -270,6 +272,8 @@ struct ttm_bo_kmap_obj {
 struct ttm_operation_ctx {
bool interruptible;
bool no_wait_gpu;
+   bool allow_reserved_eviction;
+   struct reservation_object *resv;
uint64_t bytes_moved;
 };
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 5/6] drm/ttm: enable eviction for Per-VM-BO

[He, Roger]

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Tuesday, December 12, 2017 6:40 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 5/6] drm/ttm: enable eviction for Per-VM-BO

Am 12.12.2017 um 10:33 schrieb Roger He:
> Change-Id: I491d4ceb8c98bb3d8e6e0ddef2330284ce2fe5f6
> Signed-off-by: Roger He 

I would squash this one with patch #6.

> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
>   1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> b/drivers/gpu/drm/ttm/ttm_bo.c index eb8c568..22b6ca5 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -722,10 +722,9 @@ static int ttm_mem_evict_first(struct ttm_bo_device 
> *bdev,
>   spin_lock(&glob->lru_lock);
>   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>   list_for_each_entry(bo, &man->lru[i], lru) {
> - if (bo->resv == resv) {
> - if (list_empty(&bo->ddestroy))
> - continue;
> - } else {
> + if (!ctx ||
> + !(ctx->on_alloc_stage &&
> + bo->resv == ctx->resv)) {

Coding style: The lines stating with "!(ctx" and "bo->resv" are to far 
to the right.

Additional to that I think ctx is mandatory and doesn't need a check 
(but might be wrong). If it isn't it's probably time to make itmandatory.

And I would use (ctx->on_alloc_stage || list_empty(&bo->ddestroy)) as 
check, we probably still want to be able to handledeleted BOs here 
during CS.

Change that as below, I think it can cover the case you described. No matter 
the Bo is in deleted list or not.
if (!ctx->allow_reserved_eviction || bo->resv != ctx->resv) {
locked = 
kcl_reservation_object_trylock(bo->resv);
if (!locked)
continue;
}

Thanks
Roger(Hongbo.He)



Christian.

>   locked = reservation_object_trylock(bo->resv);
>   if (!locked)
>   continue;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info

[Hyun Kwon]

Hi Laurent,

Thanks for the comment.

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Monday, December 11, 2017 6:02 AM
> To: Hyun Kwon 
> Cc: Daniel Vetter ; Jani Nikula
> ; Sean Paul ; David
> Airlie ; dri-devel@lists.freedesktop.org;
> mon...@monstr.eu; Jeff Mouroux ; Satish Kumar
> Nagireddy ; Satish Kumar Nagireddy
> 
> Subject: Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor
> to drm_format_info
> 
> Hi Hyun,
> 
> Thank you for the patch.
> 
> On Tuesday, 28 November 2017 04:27:31 EET Hyun Kwon wrote:
> > From: Satish Kumar Nagireddy 
> >
> > 'cpp_scale' can be used as a multiplying factor to calculate
> > bytes per component based on color format.
> > For eg. scaling factor of YUV420 8 bit format is 1
> > so multiplying factor is 1 (8/8)
> > scaling factor of YUV420 10 bit format is 1.25 (10/8)
> >
> > 'padding_scale' can be used as a multiplying factor to calculate
> > actual width of video according to color format.
> > For eg. padding factor of YUV420 8 bit format: 8 bits per 1 component
> > no padding bits here, so multiplying factor is 1
> > padding factor of YUV422 10 bit format: 32 bits per 3 components
> > each component is 10 bit and the factor is 32/30
> >
> > Signed-off-by: Satish Kumar Nagireddy 
> > Signed-off-by: Hyun Kwon 
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 136 ++-
> -
> >  include/drm/drm_fourcc.h |   9 +++
> >  2 files changed, 77 insertions(+), 68 deletions(-)
> 
> [snip]
> 
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index 6942e84..0202d19 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -36,16 +36,25 @@ struct drm_mode_fb_cmd2;
> >   * use in new code and set to 0 for new formats.
> >   * @num_planes: Number of color planes (1 to 3)
> >   * @cpp: Number of bytes per pixel (per plane)
> > + * @cpp_scale: { numerator, denominator }. Scaling factor for
> > + * non 8bit aligned formats. For instance, { 10, 8 } can be used for
> > + * 10 bit component / pixel formats.
> 
> Stupid question, wouldn't it be better to replace cpp with a number of bits
> per pixel then ? Or possibly supplement it if we need both. A scaling factor
> seems difficult to use.

Bits per pixel would work. I was hesitant to modify other drivers, but I can 
still make it that way.

> 
> >   * @hsub: Horizontal chroma subsampling factor
> >   * @vsub: Vertical chroma subsampling factor
> > + * @padding_scale: { numerator, denominator }. Scaling factor for
> > + * padding. This can be used for formats with padding bits after
> > + * multiple pixels / components. For instance, if there are 2 bit
> > + * padding after 3 10bit components, the value should be { 32, 30 }.
> 
> Similarly, why don't you instead specify the number of padding bits directly ?

I don't see how to model this with the number of padding bits. There can be 
arbitrary number of padding bits in every arbitrary number of components with 
arbitrary bpp. Just for example, 2 bits padding after 3 - 10bit components or 8 
bit padding after 4 - 14bit components.

The currently expected usage is:

bytes_per_line = width * info->cpp[i] * info->cpp_scale[0] / 
info->cpp_scale[1] * info->padding_scale[0] / info->padding_scale[1];

cpp_scale[] can be replaced with bpp / 8 per your suggestion. Let me know if 
you see any better way.

Thanks,
-hyun

> 
> >   */
> >  struct drm_format_info {
> > u32 format;
> > u8 depth;
> > u8 num_planes;
> > u8 cpp[3];
> > +   u8 cpp_scale[2];
> > u8 hsub;
> > u8 vsub;
> > +   u8 padding_scale[2];
> >  };
> >
> >  /**
> 
> 
> --
> Regards,
> 
> Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v7,2/7] drm: Add panel orientation quirks, v6.

[David Lechner]

On 11/25/2017 01:35 PM, Hans de Goede wrote:

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
new file mode 100644
index ..b8765e2ed1d6
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c


This file taints the kernel when it is compiled as a module. It needs a 
MODULE_LICENSE().

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_lease: Do not call drm_master_put() twice in case drm_lease_create() fails

[Marius-cristian Vlad]

drm_mode_create_lease_ioctl() -> drm_lease_create()

drm_lease_create() -> fails and drm_master_put() is called
twice: once in drm_lease_create() and once in
drm_mode_create_lease_ioctl().

From drm_mode_create_lease_ioctl():

lessee = drm_lease_create(lessor, &leases);
if (IS_ERR(lessee)) {
ret = PTR_ERR(lessee);
goto out_leases;
}

out_lessee:
drm_master_put(&lessee); <- but we already done this in
drm_lease_create().


On Tue, 2017-12-12 at 16:30 +0100, Daniel Vetter wrote:
> On Tue, Dec 12, 2017 at 02:04:14PM +0200, Marius Vlad wrote:
> > This case can been seen when creating the lease with same objects
> > passed.
> > 
> > Signed-off-by: Marius Vlad 
> > ---
> >  drivers/gpu/drm/drm_lease.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_lease.c
> > b/drivers/gpu/drm/drm_lease.c
> > index d1eb56a..ae57f33 100644
> > --- a/drivers/gpu/drm/drm_lease.c
> > +++ b/drivers/gpu/drm/drm_lease.c
> > @@ -254,8 +254,6 @@ static struct drm_master
> > *drm_lease_create(struct drm_master *lessor, struct idr
> >     return lessee;
> >  
> >  out_lessee:
> > -   drm_master_put(&lessee);
> 
> I'm not really following here ... the lessee reference we're dropping
> here
> is created in drm_master_create. We're only calling drm_master_put if
> that
> succeeded. Removing this line here looks like now we're leaking.
> 
> Where is the double-free? I don't see the 2nd drm_master_put()
> anywhere
> ... drm_mode_create_lease_ioctl also seems to be doing the right
> thing
> from just staring at it.
> -Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 4/6] drm/ttm: init locked again to prevent incorrect unlock

[He, Roger]

That is a bug fix, isn't it? If yes maybe add CC:stable and commit it 
first before all other patches.

Fortunately so far there is no issue directly resulted from that.

Thanks
Roger(Hongbo.He)

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Tuesday, December 12, 2017 6:37 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/6] drm/ttm: init locked again to prevent incorrect unlock

Am 12.12.2017 um 10:33 schrieb Roger He:
> Change-Id: I8db51d843955f5db14bb4bbff892eaedbd9f0abe
> Signed-off-by: Roger He 

Reviewed-by: Christian König 

That is a bug fix, isn't it? If yes maybe add CC:stable and commit it first 
before all other patches.

Christian.

> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> b/drivers/gpu/drm/ttm/ttm_bo.c index 17fe8be..eb8c568 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -735,6 +735,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> place)) {
>   if (locked)
>   reservation_object_unlock(bo->resv);
> + locked = false;
>   continue;
>   }
>   break;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 3/6] drm/ttm: use an ttm operation ctx for ttm_bo_move_xxx

[He, Roger]

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Tuesday, December 12, 2017 6:34 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/6] drm/ttm: use an ttm operation ctx for ttm_bo_move_xxx

Am 12.12.2017 um 10:33 schrieb Roger He:
> include ttm_bo_move_memcpy and ttm_bo_move_ttm
>
> Change-Id: I160b2fe1da3200405810d0215c4521b5f0d3615a
> Signed-off-by: Roger He 

Reviewed-by: Christian König 

   But please separate that out and wait for a few days before 
committing, maybe some nouveau devs have objections.

Ok.

Thanks
Roger(Hongbo.He)

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
>   drivers/gpu/drm/nouveau/nouveau_bo.c| 7 +++
>   drivers/gpu/drm/qxl/qxl_ttm.c   | 3 +--
>   drivers/gpu/drm/radeon/radeon_ttm.c | 7 +++
>   drivers/gpu/drm/ttm/ttm_bo.c| 6 ++
>   drivers/gpu/drm/ttm/ttm_bo_util.c   | 8 
>   include/drm/ttm/ttm_bo_driver.h | 4 ++--
>   7 files changed, 18 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 7db9556..c307a7d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -505,7 +505,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object 
> *bo, bool evict,
>   if (unlikely(r)) {
>   goto out_cleanup;
>   }
> - r = ttm_bo_move_ttm(bo, ctx->interruptible, ctx->no_wait_gpu, new_mem);
> + r = ttm_bo_move_ttm(bo, ctx, new_mem);
>   out_cleanup:
>   ttm_bo_mem_put(bo, &tmp_mem);
>   return r;
> @@ -536,7 +536,7 @@ static int amdgpu_move_ram_vram(struct ttm_buffer_object 
> *bo, bool evict,
>   if (unlikely(r)) {
>   return r;
>   }
> - r = ttm_bo_move_ttm(bo, ctx->interruptible, ctx->no_wait_gpu, &tmp_mem);
> + r = ttm_bo_move_ttm(bo, ctx, &tmp_mem);
>   if (unlikely(r)) {
>   goto out_cleanup;
>   }
> @@ -597,8 +597,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object 
> *bo, bool evict,
>   
>   if (r) {
>   memcpy:
> - r = ttm_bo_move_memcpy(bo, ctx->interruptible,
> -ctx->no_wait_gpu, new_mem);
> + r = ttm_bo_move_memcpy(bo, ctx, new_mem);
>   if (r) {
>   return r;
>   }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 949bf6b..6b6fb20 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1226,7 +1226,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, 
> bool evict, bool intr,
>   if (ret)
>   goto out;
>   
> - ret = ttm_bo_move_ttm(bo, intr, no_wait_gpu, new_reg);
> + ret = ttm_bo_move_ttm(bo, &ctx, new_reg);
>   out:
>   ttm_bo_mem_put(bo, &tmp_reg);
>   return ret;
> @@ -1255,7 +1255,7 @@ nouveau_bo_move_flips(struct ttm_buffer_object *bo, 
> bool evict, bool intr,
>   if (ret)
>   return ret;
>   
> - ret = ttm_bo_move_ttm(bo, intr, no_wait_gpu, &tmp_reg);
> + ret = ttm_bo_move_ttm(bo, &ctx, &tmp_reg);
>   if (ret)
>   goto out;
>   
> @@ -1380,8 +1380,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
> evict,
>   /* Fallback to software copy. */
>   ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
>   if (ret == 0)
> - ret = ttm_bo_move_memcpy(bo, ctx->interruptible,
> -  ctx->no_wait_gpu, new_reg);
> + ret = ttm_bo_move_memcpy(bo, ctx, new_reg);
>   
>   out:
>   if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA) { 
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c 
> b/drivers/gpu/drm/qxl/qxl_ttm.c index d866f32..78ce118 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -357,8 +357,7 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool 
> evict,
>   qxl_move_null(bo, new_mem);
>   return 0;
>   }
> - return ttm_bo_move_memcpy(bo, ctx->interruptible, ctx->no_wait_gpu,
> -   new_mem);
> + return ttm_bo_move_memcpy(bo, ctx, new_mem);
>   }
>   
>   static void qxl_bo_move_notify(struct ttm_buffer_object *bo, diff 
> --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 98e30d7..557fd79 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -347,7 +347,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
> *bo,
>   if (unlikely(r)) {
>   goto out_cleanup;
>   }
> - r = ttm_bo_move_ttm(bo, interruptible, no_wait_gpu, new_mem);
> + r = ttm_bo_move_ttm(bo, &ctx, new_mem);
>   out_cleanup:
>   ttm_bo_mem_put(bo, &tmp_mem);
>   return r;
> @@ -

[Bug 101881] [regression] 32bit steam games segfault when launched with DRI_PRIME=1

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #23 from Mike Lothian  ---
This was GCC related I think

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

[Bug 100685] [bisected] X Won't Start on Skylake/Tonga

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-daemon]

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

--- Comment #78 from Andrew  ---
Kelly,
 Maybe RADV would work?
https://www.phoronix.com/scan.php?page=article&item=amd-open-vulkan&num=1
Also. Is a new amd driver out already?
// sorry im traveling at the moment

On Dec 11, 2017 11:24 AM,  wrote:

> *Comment # 77  on
> bug 95306  from Kelly
> Anderson  *
>
> 4.15rc3 also seems to be fine with respect to this problem.
>
> --
> You are receiving this mail because:
>
>- You are on the CC list for the bug.
>
>

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #7 from Deposite Pirate (dpir...@metalpunks.info) ---
Thanks for the explanation. I think I understand how this works now. I was
afraid I would not be able to use the Arch PKGBUILD for the kernel together
with git bisect. But it turns out I can, which makes things way simpler for me.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #9 from dwagner  ---
Bad news: Tried amd-staging-drm-next as of commit
367a3d2bdc27fd1d23be9ea75cec34b52297184d, which does include the commit
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=c2a899da6d8c0658c6f8493cb6b5ca4e890a15b7
referenced by Alex above, but the result is still the same as in the original
description of this bug report.

I tested "echo "mem" >/sys/power/state" both without starting X and from an
Xterm, in both cases no picture comes up at resume from S3, and the computer
does not react on input.

The test scenario Jerry Zuo described above does not mention whether the
display was connected via DP or HDMI - could this be of relevance for
reproduction?

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

Thunderbolt 3, USB-C, and MST: Could we determine link bw more accurately?

[Lyude Paul]

Hi! So, a while ago I got myself a nice Caldigit TS3 Thunderbolt 3 dock for my
new laptop. It's awesome, and has lots of ports! But unfortunately one of the
biggest issues I've encountered with this is that the DP port is rather
unreliable when it comes to running a DP MST hub over it. To start, a diagram of
the setup I've got

Laptop's USB-C TB3 port
|- Caldigit TS3 hub (40 GBit/s)
|- USB-C TB3 port (5.4 GBit/s)
|- DP++ port (2.7 GBit/s)
|- EVGA MST hub (5.4 GBit/s)
|- 1920x1080 display
|- 1920x1200 display
|- 

As a note: i915 doesn't manage to train this correctly for reasons that are
understandable (this is a very, very uncommon setup with some far more uncommon
limitations that at least from all the hw I've personally seen, I haven't ever
run across before). Moving the MST hub to the USB-C TB3 port works just fine
though. I'm hoping to write some patches up for this myself already so i915 can
do link retraining with fallback link rates on both SST and MST, but that's
going to take a good bit of work to integrate cleanly with atomic.

So, onto the actual problem here: DRM has absolutely no way of knowing about the
DP++ port's capabilities. As far as I can tell there's nothing in any of the DP
specs that would be appropriate for reporting this. Sometimes the dock will
modify the DPCD from the MST hub so that it reads 2.7 GBit/s instead of 5.4, but
the hub does not do this consistently and I haven't yet figured out why.

While link fallback is always an option we should be supporting, it seems like a
rather hacky method of something that seems like should be much easier to do.
Additionally, the amount of time we already spend with trial and error modesets
with MST hubs, specifically problematic ones (which is a LOT of them), is not
great. On this EVGA hub, it messes up some of the DP AUX responses at times
causing it to report devices that aren't actually there, which makes i915 have
to redo the whole modesetting process from the start. It works, but it's a lot
slower then it needs to be.

This has been making me ponder the question: is there any possible way, through
USB-C and/or Thunderbolt 3 protocols, that we could actually teach DRM to query
the capabilities of the DP++ port so it knows ahead of time to limit the link
rate it tries to train with regardless of what the MST hub says? This would
speed up the whole process a heck of a lot, and seems like it shouldn't be super
difficult to implement. I've been looking through all of the docs I can get my
hands on to try to figure something out. I've gone through the USB 3.2 docs and
the UCSI specification from intel. The only lead I've managed to find thus far
for determining the link bandwidth is the GET_CABLE_PROPERTY UCSI command which
seems to have a bitfield indicating the maximum link rate supported. That being
said, I'm assuming "cable" is just referring to the cable connecting us to the
hub and not the individual downstream ports, so I'm not sure if we could
actually derive any details about the DP++ port from there.

So, I figured I've been talking about this enough on IRC that it's about time I
poke the whole mailing list to see if anyone knows anything more about this that
I don't yet. I'm completely open to other ideas on solving this issue as well,
so don't be shy!
-- 
Lyude Paul 
Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #8 from dwagner  ---
Thanks, Alex.
Just in order to be able to help myself next time: How does one get from
knowing the string "95539e2be57" to the commits you linked?

(Will try amd-staging-drm-next right now and follow up with the result after
rebooting.)

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #6 from Felix Schwarz (felix.schw...@oss.schwarz.eu) ---
Ideally you use Linus' git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

As you mentioned in your first post you experienced problems when upgrading
from 4.13.16 -> 4.14.3 so most likely something changed in the main development
period of 4.14 for you. The merge commit 2040c473 you found supports that
theory.

Now you need to start actually bisecting. Just google for "git bisect". There
is a lot of blog posts, tutorials etc for it. (Maybe
https://stackoverflow.com/a/4714297/138526 helps you)

As a start you can mark the merge commit and its predecessor as bad/good and
git will take you from there. You will need to compile quite a few kernels and
test them (way more than 2, usually 10-20 kernels).

A common mistake is to mark a non-bootable or otherwise broken version as
"bad". Only mark kernels as "bad" if they clearly have the problem you
described in your report. If you can't test a specific version, use "git bisect
skip". Use "good" if you are sure that a version is ok.

Oh, btw: I recommend testing the most recent 4.15 rc (or even git master) to
check the problem is still present. If it is fixed in a the current development
version probably the easiest way for you is to ride the leading edge. Of course
you can bisect anyway, maybe the patch can be backported to 4.14.

Happy compiling.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #5 from Deposite Pirate (dpir...@metalpunks.info) ---
I just cloned linux-stable, did git log, searched for "radeon" and built the
revision before this commit, tested it and then I built the revision with this
commit and tested it. Is there another linux repository I need to clone where
this commit is broken into smaller pieces? I don't have bisect log.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

Felix Schwarz (felix.schw...@oss.schwarz.eu) changed:

   What|Removed |Added

 CC||felix.schwarz@oss.schwarz.e
   ||u

--- Comment #4 from Felix Schwarz (felix.schw...@oss.schwarz.eu) ---
Unfortunately a merge commit is almost never the right bisection result. Did
you use git for bisecting? Can you share your bisect log? Probably you need to
go on, marking commit 2040c473 as "bad" and git bisect will give you more
commits to try.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
or for drm-next:
https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=ce1b1b66cd5ec60927c575858430c099b8b4bceb

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

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #6 from Alex Deucher  ---
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=c2a899da6d8c0658c6f8493cb6b5ca4e890a15b7

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #3 from Deposite Pirate (dpir...@metalpunks.info) ---
Ok, I found the commit:

commit 2040c47361646d18b9832fd930d2a025da002a57 (HEAD -> master)
Merge: 3154b133711f 37899a525491
Author: Dave Airlie 
Date:   Fri Aug 18 05:30:53 2017 +1000

Merge branch 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux
into drm-next

More features for 4.14.  Nothing too major here.  I have a few more
additional
patches for large page support in vega10 among other things, but they
require
some resevation object patches from drm-misc-next, so I'll send that
request
once you've pulled the latest drm-misc-next.  Highlights:
- Fixes for ACP audio on stoney
- SR-IOV fixes for vega10
- various powerplay fixes
- lots of code clean up

* 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux: (62
commits)
  drm/amdgpu/gfx7: fix function name
  drm/amd/amdgpu: Disabling Power Gating for Stoney platform
  drm/amd/amdgpu: Added a quirk for Stoney platform
  drm/amdgpu: jt_size was wrongly counted twice
  drm/amdgpu: fix missing endian-safe guard
  drm/amdgpu: ignore digest_size when loading sdma fw for raven
  drm/amdgpu: Uninitialized variable in amdgpu_ttm_backend_bind()
  drm/amd/powerplay: fix coding style in hwmgr.c
  drm/amd/powerplay: refine dmesg info under powerplay.
  drm/amdgpu: don't finish the ring if not initialized
  drm/radeon: Fix preferred typo
  drm/amdgpu: Fix preferred typo
  drm/radeon: Fix stolen typo
  drm/amdgpu: Fix stolen typo
  drm/amd/powerplay: fix coccinelle warnings in vega10_hwmgr.c
  drm/amdgpu: set gfx_v9_0_ip_funcs as static
  drm/radeon: switch to drm_*{get,put} helpers
  drm/amdgpu: switch to drm_*{get,put} helpers
  drm/amd/powerplay: add CZ profile support
  drm/amd/powerplay: fix PSI not enabled by kmd

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

[bugzilla-daemon]

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

--- Comment #5 from dwagner  ---
(In reply to Jerry Zuo from comment #4)
> S3 starts working since commit 95539e2be57. 
> 
> Test is performed on the following condition:
> Commit: c6f284d9888
> Asic: Baffin
> 4K display: Acer H277HK
> S3 passed in 10 runs
> 
> Please verify at your side as well. Thanks.

I would love to verify this - but where can I find commit 95539e2be57 ?

It is not included in any branch of the
https://cgit.freedesktop.org/~agd5f/linux/ repository as of this moment - can
you point me to a repository that includes it?

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

Re: UDL's fbdev doesn't work for user-space apps

[Noralf Trønnes]

Den 04.12.2017 12.32, skrev Alexey Brodkin:

Hello,

I'm trying to use DisplayLink USB2.0-to-HDMI adapter as the one and only
video output and I want to get Xserver working on top of that.

I'm not very familiar with all the parts of Linux GPU/video stack
(especially its user-space counterpart) so my assumptions might be wrong
in that case please correct me.

My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
and it cannot use DRI video card natively. Is that correct?

So to get /ded/fb0 with UDL I just enabled CONFIG_DRM_UDL & 
CONFIG_DRM_FBDEV_EMULATION.
That gave me boot console on HDMI screen and I was full of expectations.
But when I tried to use /dev/fb0 from whatever user-space app nothing got
displayed on the screen... as well as no error messages appeared.

After eyeballing at UDL code (especially in comparison with QXC which uses 
deferredio
as well) I noticed that in UDL fb_deferred_io_init() is called from 
udl_fb_open(),
i.e. .fb_open call-back (in other words every time user-space app opens 
/dev/fb0)
while in QXC this is done only once and much earlier in qxlfb_create(), which is
called with .fb_probe call-back. So moved fb_deferred_io_init() in UDL driver 
from
udl_fb_open() to udlfb_create() which is also called from .fb_probe.

With that change I finally got video output via fbdev from user-space app,
but only on the first run. The next attempt to run inevitably ends with
kernel crash showing the following stack-trace (having half of the new screen
rendered on display):
>8-
Stack Trace:
   udl_handle_damage+0x48/0x210
   udl_crtc_mode_set+0x6ee/0x754
   drm_crtc_helper_set_mode+0x25e/0x438
   drm_crtc_helper_set_config+0x6d6/0x814
   __drm_mode_set_config_internal+0x48/0xc8
   drm_mode_setcrtc+0x320/0x478
   drm_ioctl+0x22c/0x3e4
   SyS_ioctl+0xa4/0x8cc
   EV_Trap+0x108/0x10c
random: crng init done
>8-

I'm wondering if UDL driver (its DRM flavor) was ever tested for
fbdev in user-space? If so and it really works for somebody
maybe I'm doing something terribly wrong - in that case any comments
are very welcome.


udl uses shmem buffers which doesn't work with fbdev deferred io.
They fight over page->lru and page->mapping. See this commit:
drm/udl: disable fb_defio by default
677d23b70bf949f75746c80cbae92c233c6b5e2a

Noralf.


One interesting note: it seems like pure DRI stuff works like a charm.
I may run kmscube perfectly fine without any changes whatsoever and do it
many times in a row.

Thanks in advance,
Alexey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/3] etnaviv: perfmon support

[Christian Gmeiner]

Add some basic functions to query performance monitor domains and
signals. Also add support to submit performance monitor requests (pmrs).

I have planed to push this series by the end of the week. The original
series was on the ml for some weeks now and got no review so this is
your last chance :)

Christian Gmeiner (3):
  etnaviv: sync uapi header
  etnaviv: add permon support
  etnaviv: support performance monitor requests

 etnaviv/Makefile.sources |   1 +
 etnaviv/etnaviv-symbol-check |   5 ++
 etnaviv/etnaviv_cmd_stream.c |  20 +
 etnaviv/etnaviv_drm.h|  43 +-
 etnaviv/etnaviv_drmif.h  |  23 ++
 etnaviv/etnaviv_perfmon.c| 189 +++
 etnaviv/etnaviv_priv.h   |  25 ++
 7 files changed, 305 insertions(+), 1 deletion(-)
 create mode 100644 etnaviv/etnaviv_perfmon.c

-- 
2.14.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] etnaviv: add permon support

[Christian Gmeiner]

Query all domains and their signals and provide it this information
via struct etna_perfmon and the corresponding api functions.

v2:
 - code style changes
 - etna_perfmon_create(..): add missing clean up in error case

Signed-off-by: Christian Gmeiner 
---
 etnaviv/Makefile.sources |   1 +
 etnaviv/etnaviv-symbol-check |   4 +
 etnaviv/etnaviv_drmif.h  |  11 +++
 etnaviv/etnaviv_perfmon.c| 189 +++
 etnaviv/etnaviv_priv.h   |  21 +
 5 files changed, 226 insertions(+)
 create mode 100644 etnaviv/etnaviv_perfmon.c

diff --git a/etnaviv/Makefile.sources b/etnaviv/Makefile.sources
index 52580567..0eb73783 100644
--- a/etnaviv/Makefile.sources
+++ b/etnaviv/Makefile.sources
@@ -3,6 +3,7 @@ LIBDRM_ETNAVIV_FILES := \
etnaviv_gpu.c \
etnaviv_bo.c \
etnaviv_bo_cache.c \
+   etnaviv_perfmon.c \
etnaviv_pipe.c \
etnaviv_cmd_stream.c \
etnaviv_drm.h \
diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index 0e2030e4..bd95b459 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -42,6 +42,10 @@ etna_cmd_stream_flush
 etna_cmd_stream_flush2
 etna_cmd_stream_finish
 etna_cmd_stream_reloc
+etna_perfmon_create
+etna_perfmon_del
+etna_perfmon_get_dom_by_name
+etna_perfmon_get_sig_by_name
 EOF
 done)
 
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 87704acd..949b9b62 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -35,6 +35,9 @@ struct etna_pipe;
 struct etna_gpu;
 struct etna_device;
 struct etna_cmd_stream;
+struct etna_perfmon;
+struct etna_perfmon_domain;
+struct etna_perfmon_signal;
 
 enum etna_pipe_id {
ETNA_PIPE_3D = 0,
@@ -190,4 +193,12 @@ struct etna_reloc {
 
 void etna_cmd_stream_reloc(struct etna_cmd_stream *stream, const struct 
etna_reloc *r);
 
+/* performance monitoring functions:
+ */
+
+struct etna_perfmon *etna_perfmon_create(struct etna_pipe *pipe);
+void etna_perfmon_del(struct etna_perfmon *perfmon);
+struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct etna_perfmon 
*pm, const char *name);
+struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct 
etna_perfmon_domain *dom, const char *name);
+
 #endif /* ETNAVIV_DRMIF_H_ */
diff --git a/etnaviv/etnaviv_perfmon.c b/etnaviv/etnaviv_perfmon.c
new file mode 100644
index ..aa5130a6
--- /dev/null
+++ b/etnaviv/etnaviv_perfmon.c
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2017 Etnaviv Project
+ * Copyright (C) 2017 Zodiac Inflight Innovations
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ *Christian Gmeiner 
+ */
+
+#ifdef HAVE_CONFIG_H
+# include 
+#endif
+
+#include "etnaviv_priv.h"
+
+static int etna_perfmon_query_signals(struct etna_perfmon *pm, struct 
etna_perfmon_domain *dom)
+{
+   struct etna_device *dev = pm->pipe->gpu->dev;
+   struct drm_etnaviv_pm_signal req = {
+   .pipe = pm->pipe->id,
+   .domain = dom->id
+   };
+
+   do {
+   struct etna_perfmon_signal *sig;
+   int ret;
+
+   ret = drmCommandWriteRead(dev->fd, DRM_ETNAVIV_PM_QUERY_SIG, 
&req, sizeof(req));
+   if (ret)
+   break;
+
+   sig = calloc(1, sizeof(*sig));
+   if (!sig)
+   return -ENOMEM;
+
+   INFO_MSG("perfmon signal:");
+   INFO_MSG("id = %d", req.id);
+   INFO_MSG("name   = %s", req.name);
+
+   sig->domain = dom;
+   sig->signal = req.id;
+   strncpy(sig->name, req.name, sizeof(sig->name));
+   list_addtail(&sig->head, &dom->signals);
+   } while (req.iter != 0x);
+
+   return 0;
+}
+
+static int etna_perfmon_query_domains(struct etna_perfmon *pm)
+{
+   struct etna_device *dev = pm->pipe->gpu->dev;

[PATCH v2 1/3] etnaviv: sync uapi header

[Christian Gmeiner]

Import the etnaviv header changes from kernel commit 05916bed1 (drm-next)

The drm_etnaviv_gem_submit structure was extended to include performance
monitor requests. Also two new ioctls got added to be able to readout
performance monitor domains and their signals.

Signed-off-by: Christian Gmeiner 
---
 etnaviv/etnaviv_drm.h | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/etnaviv/etnaviv_drm.h b/etnaviv/etnaviv_drm.h
index 76f6f78a..110cc73b 100644
--- a/etnaviv/etnaviv_drm.h
+++ b/etnaviv/etnaviv_drm.h
@@ -150,6 +150,19 @@ struct drm_etnaviv_gem_submit_bo {
__u64 presumed;   /* in/out, presumed buffer address */
 };
 
+/* performance monitor request (pmr) */
+#define ETNA_PM_PROCESS_PRE 0x0001
+#define ETNA_PM_PROCESS_POST0x0002
+struct drm_etnaviv_gem_submit_pmr {
+   __u32 flags;  /* in, when to process request 
(ETNA_PM_PROCESS_x) */
+   __u8  domain; /* in, pm domain */
+   __u8  pad;
+   __u16 signal; /* in, pm signal */
+   __u32 sequence;   /* in, sequence number */
+   __u32 read_offset;/* in, offset from read_bo */
+   __u32 read_idx;   /* in, index of read_bo buffer */
+};
+
 /* Each cmdstream submit consists of a table of buffers involved, and
  * one or more cmdstream buffers.  This allows for conditional execution
  * (context-restore), and IB buffers needed for per tile/bin draw cmds.
@@ -175,6 +188,9 @@ struct drm_etnaviv_gem_submit {
__u64 stream; /* in, ptr to cmdstream */
__u32 flags;  /* in, mask of ETNA_SUBMIT_x */
__s32 fence_fd;   /* in/out, fence fd (see ETNA_SUBMIT_FENCE_FD_x) 
*/
+   __u64 pmrs;   /* in, ptr to array of submit_pmr's */
+   __u32 nr_pmrs;/* in, number of submit_pmr's */
+   __u32 pad;
 };
 
 /* The normal way to synchronize with the GPU is just to CPU_PREP on
@@ -210,6 +226,27 @@ struct drm_etnaviv_gem_wait {
struct drm_etnaviv_timespec timeout;/* in */
 };
 
+/*
+ * Performance Monitor (PM):
+ */
+
+struct drm_etnaviv_pm_domain {
+   __u32 pipe;   /* in */
+   __u8  iter;   /* in/out, select pm domain at index iter */
+   __u8  id; /* out, id of domain */
+   __u16 nr_signals; /* out, how many signals does this domain provide */
+   char  name[64];   /* out, name of domain */
+};
+
+struct drm_etnaviv_pm_signal {
+   __u32 pipe;   /* in */
+   __u8  domain; /* in, pm domain index */
+   __u8  pad;
+   __u16 iter;   /* in/out, select pm source at index iter */
+   __u16 id; /* out, id of signal */
+   char  name[64];   /* out, name of domain */
+};
+
 #define DRM_ETNAVIV_GET_PARAM  0x00
 /* placeholder:
 #define DRM_ETNAVIV_SET_PARAM  0x01
@@ -222,7 +259,9 @@ struct drm_etnaviv_gem_wait {
 #define DRM_ETNAVIV_WAIT_FENCE 0x07
 #define DRM_ETNAVIV_GEM_USERPTR0x08
 #define DRM_ETNAVIV_GEM_WAIT   0x09
-#define DRM_ETNAVIV_NUM_IOCTLS 0x0a
+#define DRM_ETNAVIV_PM_QUERY_DOM   0x0a
+#define DRM_ETNAVIV_PM_QUERY_SIG   0x0b
+#define DRM_ETNAVIV_NUM_IOCTLS 0x0c
 
 #define DRM_IOCTL_ETNAVIV_GET_PARAMDRM_IOWR(DRM_COMMAND_BASE + 
DRM_ETNAVIV_GET_PARAM, struct drm_etnaviv_param)
 #define DRM_IOCTL_ETNAVIV_GEM_NEW  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_ETNAVIV_GEM_NEW, struct drm_etnaviv_gem_new)
@@ -233,6 +272,8 @@ struct drm_etnaviv_gem_wait {
 #define DRM_IOCTL_ETNAVIV_WAIT_FENCE   DRM_IOW(DRM_COMMAND_BASE + 
DRM_ETNAVIV_WAIT_FENCE, struct drm_etnaviv_wait_fence)
 #define DRM_IOCTL_ETNAVIV_GEM_USERPTR  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_ETNAVIV_GEM_USERPTR, struct drm_etnaviv_gem_userptr)
 #define DRM_IOCTL_ETNAVIV_GEM_WAIT DRM_IOW(DRM_COMMAND_BASE + 
DRM_ETNAVIV_GEM_WAIT, struct drm_etnaviv_gem_wait)
+#define DRM_IOCTL_ETNAVIV_PM_QUERY_DOM DRM_IOWR(DRM_COMMAND_BASE + 
DRM_ETNAVIV_PM_QUERY_DOM, struct drm_etnaviv_pm_domain)
+#define DRM_IOCTL_ETNAVIV_PM_QUERY_SIG DRM_IOWR(DRM_COMMAND_BASE + 
DRM_ETNAVIV_PM_QUERY_SIG, struct drm_etnaviv_pm_signal)
 
 #if defined(__cplusplus)
 }
-- 
2.14.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/3] etnaviv: support performance monitor requests

[Christian Gmeiner]

Add etna_cmd_stream_perf(..) to submit perform requests.
Userspace can submit pmrs via submit ioctl to sample perfmon
signals.

Signed-off-by: Christian Gmeiner 
---
 etnaviv/etnaviv-symbol-check |  1 +
 etnaviv/etnaviv_cmd_stream.c | 20 
 etnaviv/etnaviv_drmif.h  | 12 
 etnaviv/etnaviv_priv.h   |  4 
 4 files changed, 37 insertions(+)

diff --git a/etnaviv/etnaviv-symbol-check b/etnaviv/etnaviv-symbol-check
index bd95b459..bc509615 100755
--- a/etnaviv/etnaviv-symbol-check
+++ b/etnaviv/etnaviv-symbol-check
@@ -41,6 +41,7 @@ etna_cmd_stream_timestamp
 etna_cmd_stream_flush
 etna_cmd_stream_flush2
 etna_cmd_stream_finish
+etna_cmd_stream_perf
 etna_cmd_stream_reloc
 etna_perfmon_create
 etna_perfmon_del
diff --git a/etnaviv/etnaviv_cmd_stream.c b/etnaviv/etnaviv_cmd_stream.c
index 8d0e8135..d6f26a88 100644
--- a/etnaviv/etnaviv_cmd_stream.c
+++ b/etnaviv/etnaviv_cmd_stream.c
@@ -105,6 +105,7 @@ void etna_cmd_stream_del(struct etna_cmd_stream *stream)
 
free(stream->buffer);
free(priv->submit.relocs);
+   free(priv->submit.pmrs);
free(priv);
 }
 
@@ -115,6 +116,7 @@ static void reset_buffer(struct etna_cmd_stream *stream)
stream->offset = 0;
priv->submit.nr_bos = 0;
priv->submit.nr_relocs = 0;
+   priv->submit.nr_pmrs = 0;
priv->nr_bos = 0;
 
if (priv->reset_notify)
@@ -191,6 +193,8 @@ static void flush(struct etna_cmd_stream *stream, int 
in_fence_fd,
.nr_bos = priv->submit.nr_bos,
.relocs = VOID2U64(priv->submit.relocs),
.nr_relocs = priv->submit.nr_relocs,
+   .pmrs = VOID2U64(priv->submit.pmrs),
+   .nr_pmrs = priv->submit.nr_pmrs,
.stream = VOID2U64(stream->buffer),
.stream_size = stream->offset * 4, /* in bytes */
};
@@ -260,3 +264,19 @@ void etna_cmd_stream_reloc(struct etna_cmd_stream *stream, 
const struct etna_rel
 
etna_cmd_stream_emit(stream, addr);
 }
+
+void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const struct 
etna_perf *p)
+{
+   struct etna_cmd_stream_priv *priv = etna_cmd_stream_priv(stream);
+   struct drm_etnaviv_gem_submit_pmr *pmr;
+   uint32_t idx = APPEND(&priv->submit, pmrs);
+
+   pmr = &priv->submit.pmrs[idx];
+
+   pmr->flags = p->flags;
+   pmr->sequence = p->sequence;
+   pmr->read_offset = p->offset;
+   pmr->read_idx = bo2idx(stream, p->bo, ETNA_SUBMIT_BO_READ);
+   pmr->domain = p->signal->domain->id;
+   pmr->signal = p->signal->signal;
+}
diff --git a/etnaviv/etnaviv_drmif.h b/etnaviv/etnaviv_drmif.h
index 949b9b62..5a6bef8d 100644
--- a/etnaviv/etnaviv_drmif.h
+++ b/etnaviv/etnaviv_drmif.h
@@ -201,4 +201,16 @@ void etna_perfmon_del(struct etna_perfmon *perfmon);
 struct etna_perfmon_domain *etna_perfmon_get_dom_by_name(struct etna_perfmon 
*pm, const char *name);
 struct etna_perfmon_signal *etna_perfmon_get_sig_by_name(struct 
etna_perfmon_domain *dom, const char *name);
 
+struct etna_perf {
+#define ETNA_PM_PROCESS_PRE 0x0001
+#define ETNA_PM_PROCESS_POST0x0002
+   uint32_t flags;
+   uint32_t sequence;
+   struct etna_perfmon_signal *signal;
+   struct etna_bo *bo;
+   uint32_t offset;
+};
+
+void etna_cmd_stream_perf(struct etna_cmd_stream *stream, const struct 
etna_perf *p);
+
 #endif /* ETNAVIV_DRMIF_H_ */
diff --git a/etnaviv/etnaviv_priv.h b/etnaviv/etnaviv_priv.h
index 7b289b61..e45d364c 100644
--- a/etnaviv/etnaviv_priv.h
+++ b/etnaviv/etnaviv_priv.h
@@ -140,6 +140,10 @@ struct etna_cmd_stream_priv {
/* reloc's table: */
struct drm_etnaviv_gem_submit_reloc *relocs;
uint32_t nr_relocs, max_relocs;
+
+   /* perf's table: */
+   struct drm_etnaviv_gem_submit_pmr *pmrs;
+   uint32_t nr_pmrs, max_pmrs;
} submit;
 
/* should have matching entries in submit.bos: */
-- 
2.14.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: UDL's fbdev doesn't work for user-space apps

[Pavel Machek]

On Tue 2017-12-12 19:48:05, Alexey Brodkin wrote:
> Hi Pavel,
> 
> On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote:
> > On Mon 2017-12-04 11:50:40, Jose Abreu wrote:
> > > 
> > > Hi Alexey,
> > > 
> > > On 04-12-2017 11:32, Alexey Brodkin wrote:
> > > > 
> > > > My first [probably incorrect] assumption is Xserver requires fbdev 
> > > > (/dev/fbX)
> > > > and it cannot use DRI video card natively. Is that correct?
> > > > 
> > > > 
> > > 
> > > Xserver can use DRI directly, you need to enable modesetting
> > > driver in Xorg config or use the designated driver for your card
> > > (if there is any).
> > 
> > Still, dev/fb1 should work.
> 
> Agree, but it doesn't :)
> Even on completely different architectures (ARC and ARM).

Yeah, would be nice to get it fixed :-). I remember it did not work
for me, either, and .. that's some time ago.

Architecture probably plays no role there.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #11 from Sol  ---
Added another crashlog

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

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #10 from Sol  ---
Created attachment 136122
  --> https://bugs.freedesktop.org/attachment.cgi?id=136122&action=edit
crashlog for kwin

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

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

--- Comment #9 from Sol  ---
Created attachment 136121
  --> https://bugs.freedesktop.org/attachment.cgi?id=136121&action=edit
modinfo radeon for my version

Output for modinfo modinfo

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

[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Gregor Münch  ---
Ive tested Shadow of Mordor and something in the last two weeks made it faster,
either Kernel or Mesa or LLVM. Basically it went from 61/63 fps to 66 fps. With
Mesa from today, performance is restored to 68 fps.

Ive also ran my test suite again:
https://openbenchmarking.org/result/1712125-AL-GAMETEST346

Especially Unigine Superposition saw great benefit and went from 40 to 49 fps.
Dota 2 vulkan is still in a regressed state.

Ive also made a trace file with Shadow of Mordor with older kernel and good
performance some days ago: https://uploadfiles.io/ktjmx
I still struggle to compress the trace with the "bad" performance, if you guys
are interested I try to provide it.

Marking resolved for now.

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

[Bug 98974] Can't see borders/empires in Stellaris

[bugzilla-daemon]

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

--- Comment #14 from Gert Wollny  ---
Could you check whether the bug persists in 17.3.0? It includes patches  that
improve the register allocation on r600. 

If this doesn't fix the bug, could you post an apitrace?

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

[Bug 104192] [amdgpu][VEGA10] regular lockups with VM_L2_PROTECTION_FAULT_STATUS

[bugzilla-daemon]

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

Tom Englund  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Bug 104159] llvm 6.0svn: firefox GPU fault/hang with r319975

[bugzilla-daemon]

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

Tom Englund  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Tom Englund  ---
sorry had wrong bug, open and changed it to resolved.

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

[Bug 104159] llvm 6.0svn: firefox GPU fault/hang with r319975

[bugzilla-daemon]

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

Tom Englund  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

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

Re: [PATCH libdrm] amdgpu: Remove dummy CU_ASSERT_EQUAL.

[Yu, Qiang]

Reviewed-by: Qiang Yu 

Regards,
Qiang


From: Andrey Grodzovsky 
Sent: Tuesday, December 12, 2017 9:36:53 PM
To: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org; Yu, Qiang; Ma, Le; Huan, Alvin; Jin, Anna; 
Grodzovsky, Andrey
Subject: [PATCH libdrm] amdgpu: Remove dummy CU_ASSERT_EQUAL.

Fixes test failure on rhel.

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/basic_tests.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index a78cf52..474a679 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -1459,8 +1459,6 @@ static void amdgpu_sync_dependency_test(void)
static uint32_t *ptr;
uint64_t seq_no;

-   CU_ASSERT_EQUAL(r, 0);
-
r = amdgpu_cs_ctx_create(device_handle, &context_handle[0]);
CU_ASSERT_EQUAL(r, 0);
r = amdgpu_cs_ctx_create(device_handle, &context_handle[1]);
--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/41] drm/rockchip: Respect page offset for PRIME mmap calls

[Heiko Stuebner]

Hi,

Am Donnerstag, 9. März 2017, 23:32:19 CET schrieb Sean Paul:
> From: Ørjan Eide 
> 
> When mapping external DMA-bufs through the PRIME mmap call, we might be
> given an offset which has to be respected. However for the internal DRM
> GEM mmap path, we have to ignore the fake mmap offset used to identify
> the buffer only. Currently the code always zeroes out vma->vm_pgoff,
> which breaks the former.
> 
> This patch fixes the problem by moving the vm_pgoff assignment to a
> function that is used only for GEM mmap path, so that the PRIME path
> retains the original offset.
> 
> BUG=chrome-os-partner:56615
> TEST=graphics_GLBench

Unneeded chromeos-cruft.

> Cc: Daniel Kurtz 
> Signed-off-by: Ørjan Eide 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Sean Paul 

With the same testas patch 3  (rk3328 + lima)
Tested-by: Heiko Stuebner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104192] [amdgpu][VEGA10] regular lockups with VM_L2_PROTECTION_FAULT_STATUS

[bugzilla-daemon]

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

--- Comment #12 from Tom Englund  ---
the commit causing this have been reverted upstream, see
https://reviews.llvm.org/rL320466 . so from 320466 and up. things work again.

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

Re: [PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Markus Heiser]

> Am 12.12.2017 um 16:23 schrieb Daniel Vetter :
> 
>>> Thanks for your patch, but similar fix is already merged here [1]
>>> 
>>> Michal
>>> 
>>> [1] 
>>> https://cgit.freedesktop.org/drm-tip/commit/?id=006c23327f8de8575508c458131b304188d426f7
>> 
>> 
>> Thanks for pointing out. I miss the ":doc: GuC-specific firmware loader"
>> fix in that patch (doc section was removed in d9e2e0143c).  Can you or
>> someone else from @intel fix this also?
> 
> I've rebased the patch from you to only take that remaining part.
> 
> Thanks for fixing this.
> -Daniel

Thanks for picking this up [1].

[1] https://cgit.freedesktop.org/drm/drm-intel/commit/?id=0132a1a5

-- Markus --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_lease: Do not call drm_master_put() twice in case drm_lease_create() fails

[Daniel Vetter]

On Tue, Dec 12, 2017 at 02:04:14PM +0200, Marius Vlad wrote:
> This case can been seen when creating the lease with same objects passed.
> 
> Signed-off-by: Marius Vlad 
> ---
>  drivers/gpu/drm/drm_lease.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index d1eb56a..ae57f33 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -254,8 +254,6 @@ static struct drm_master *drm_lease_create(struct 
> drm_master *lessor, struct idr
>   return lessee;
>  
>  out_lessee:
> - drm_master_put(&lessee);

I'm not really following here ... the lessee reference we're dropping here
is created in drm_master_create. We're only calling drm_master_put if that
succeeded. Removing this line here looks like now we're leaking.

Where is the double-free? I don't see the 2nd drm_master_put() anywhere
... drm_mode_create_lease_ioctl also seems to be doing the right thing
from just staring at it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Daniel Vetter]

On Tue, Dec 12, 2017 at 01:11:43PM +0100, Markus Heiser wrote:
> 
> > Am 12.12.2017 um 13:05 schrieb Michal Wajdeczko 
> > :
> > 
> > On Tue, 12 Dec 2017 12:38:37 +0100, Markus Heiser 
> >  wrote:
> > 
> >> With commit d9e2e0143c the 'GuC-specific firmware loader' doc
> >> section was removed from intel_guc_loader.c without a
> >> replacement.  So lets remove it from the Kernel-doc::
> >> 
> >>  .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
> >> :doc: GuC-specific firmware loader
> >> 
> >> With commit e8668bbcb0 intel_guc_loader.c was renamed to to
> >> intel_guc_fw.c and to name just one, intel_guc_init_hw() was
> >> renamed to intel_guc_fw_upload(). Since we get errors in the
> >> Sphinx build like:
> >> 
> >> - Error: Cannot open file ./drivers/gpu/drm/i915/intel_guc_loader.c
> >> 
> >> Change the kernel-doc directive from intel_guc_loader.c to
> >> intel_guc_fw.c
> >> 
> >> Signed-off-by: Markus Heiser 
> >> ---
> > 
> > Thanks for your patch, but similar fix is already merged here [1]
> > 
> > Michal
> > 
> > [1] 
> > https://cgit.freedesktop.org/drm-tip/commit/?id=006c23327f8de8575508c458131b304188d426f7
> 
> 
> Thanks for pointing out. I miss the ":doc: GuC-specific firmware loader"
> fix in that patch (doc section was removed in d9e2e0143c).  Can you or
> someone else from @intel fix this also?

I've rebased the patch from you to only take that remaining part.

Thanks for fixing this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

[Daniel Vetter]

On Tue, Dec 12, 2017 at 11:19:47AM +, Tvrtko Ursulin wrote:
> 
> On 11/12/2017 21:05, Daniel Vetter wrote:
> > On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> > > On 11/12/2017 10:50, Joonas Lahtinen wrote:
> > > > + Daniel, Chris
> > > > 
> > > > On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
> > > > > On 04/12/2017 15:02, Lionel Landwerlin wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > After discussion with Chris, Joonas & Tvrtko, this series adds an
> > > > > > additional commit to link the render node back to the card through a
> > > > > > symlink. Making it obvious from an application using a render node 
> > > > > > to
> > > > > > know where to get the information it needs.
> > > > > 
> > > > > Important thing to mention as well is that it is trivial to get from 
> > > > > the
> > > > > master drm fd to the sysfs root, via fstat and opendir
> > > > > /sys/dev/char/:. With the addition of the card symlink 
> > > > > to
> > > > > render nodes it is trivial for render node fd as well.
> > > > > 
> > > > > I am happy with this approach - it is extensible, flexible and avoids
> > > > > issues with ioctl versioning or whatnot. With one value per file it is
> > > > > trivial for userspace to access.
> > > > > 
> > > > > So for what I'm concerned, given how gputop would use all of this and 
> > > > > so
> > > > > be the userspace, if everyone else is happy, I think we could do a
> > > > > detailed review and prehaps also think about including gputop in some
> > > > > distribution to make the case 100% straightforward.
> > > > 
> > > > For the GPU topology I agree this is the right choice, it's going to be
> > > > about topology after all, and directory tree is the perfect candidate.
> > > > And if a new platform appears, then it's a new platform and may change
> > > > the topology well the hardware topology has changed.
> > > > 
> > > > For the engine enumeration, I'm not equally sold for sysfs exposing it.
> > > > It's a "linear list of engine instances with flags" how the userspace
> > > > is going to be looking at them. And it's also information about what to
> > > > pass to an IOCTL as arguments after decision has been made, and then
> > > > you already have the FD you know you'll be dealing with, at hand. So
> > > > another IOCTL for that seems more convenient.
> > > 
> > > Apart from more flexibility and easier to extend, sysfs might be a better
> > > fit for applications which do not otherwise need a drm fd. Say a top-like
> > > tool which shows engine utilization, or those patches I RFC-ed recently
> > > which do the same but per DRM client.
> > > 
> > > Okay, these stats are now available also via PMU so the argument is not 
> > > the
> > > strongest I admit, but I still find it quite neat. It also might allow us 
> > > to
> > > define our own policy with regards to needed privilege to access these
> > > stats, and not be governed by the perf API rules.
> > 
> > How exactly is sysfs easier to extend than ioctl? There's lots of
> 
> Easier as in no need to version, add has_this/has_that markers, try to guess
> today how big a field for something might be needed in the future and
> similar.

You can e.g. return a per-generation structure easily from ioctl to, if
that's what you want. And sysfs also needs some kind of versioning, it's
just much more implicit: Instead of has_foo you check for the existence of
the file. But fundamentally it's all the same, and all the same fun with
backwards compatibility, forever, applies.

> > serializing and deserializing going on, ime that's more boilerplate. Imo
> > the only reason for sysfs is when you _must_ access it without having an
> > fd to the gpu. The inverse is generally not true (i.e. using sysfs when
> > you have the fd already), and as soon as you add a writeable field here
> > you're screwed (because sysfs can't be passed to anyone else but root,
> > compared to drm fd - viz the backlight fiasco).
> 
> I would perhaps expand the "must access without having a drm fd" to "more
> convenient to access without a drm fd". My use case here was the per-client
> engine usage stats. Equivalence with /proc//stat, or even /proc/stat if
> you want. So I was interested in creating a foothold in sysfs for that
> purpose.
> 
> No writable fields were imagined in all these two to three use cases.

Yeah that's definitely a requirement for sysfs.

> > But even without writeable fields: Think of highly contained
> > containers/clients which only get the drm fd to render. If sysfs is gone,
> > will they fall on their faces? Atm "drm fd is all you need" is very deeply
> > ingrained into our various OS stacks.
> 
> Okay, this is something which was mentioned but I think the answer was
> unclear. If current stacks do work without sysfs then this is a good
> argument to keep that ability.
> 
> As I said I am OK to drop the engine info bits from this series. Question
> for Lionel, gpu-top and Mesa then is whether sysfs works for them, for the
> 

Re: [PATCH v2 2/7] drm/i2c: tda998x: move CEC device initialisation later

[Hans Verkuil]

Hi Russell,

On 08/12/17 12:59, Russell King - ARM Linux wrote:
> On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote:
>> On 12/06/17 13:35, Russell King wrote:
>>> We no longer use the CEC client to access the CEC part itself, so we can
>>> move this later in the initialisation sequence.
>>>
>>> Signed-off-by: Russell King 
>>> ---
>>>  drivers/gpu/drm/i2c/tda998x_drv.c | 7 ---
>>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
>>> b/drivers/gpu/drm/i2c/tda998x_drv.c
>>> index 7f4dbca7f7f4..4aeac2127974 100644
>>> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
>>> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
>>> @@ -1490,9 +1490,6 @@ static int tda998x_create(struct i2c_client *client, 
>>> struct tda998x_priv *priv)
>>> priv->cec_addr = 0x34 + (client->addr & 0x03);
>>> priv->current_page = 0xff;
>>> priv->hdmi = client;
>>> -   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
>>> -   if (!priv->cec)
>>> -   return -ENODEV;
>>>  
>>> /* wake up the device: */
>>> cec_write(priv, REG_CEC_ENAMODS,
>>> @@ -1546,6 +1543,10 @@ static int tda998x_create(struct i2c_client *client, 
>>> struct tda998x_priv *priv)
>>> CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
>>> CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
>>>  
>>> /* initialize the optional IRQ */
>>> +   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
>>> +   if (!priv->cec)
>>> +   return -ENODEV;
>>> +
>>
>> I'd move this up to before the 'initialize the optional IRQ' comment, since
>> that should stay with the 'if (client->irq) {' line below.
> 
> I've swapped the order of patches 2 and 3, and moved this further down
> near where we add the real cec device in a later patch.  This is
> starting to get quite different from the patch series that I've tested,
> and as I've already mentioned, testing is not going to happen for a
> while.
> 

I added support for this to am335x-boneblack-common.dtsi (see patch below), but
it doesn't work. I suspect the calibration since I see these messages:

gpio-57 (nxp,calib): gpiod_direction_output: tried to set a GPIO tied to an IRQ 
as output

Which makes sense. I had a similar case in my cec-gpio driver and I had to 
completely
free the interrupt before I could set the direction to output.

I do get nice interrupts when a transmit is done, so the interrupt works 
correctly.
And it correctly detects Ack/Nack.

I looked a bit closer and I see that even without calibration the timings are 
reasonably
OK: 2.3 ms for a bit period instead of the recommended 2.4 ms. Slightly off but 
within
margins.

But receiving messages fails: I get no interrupt at all. Not sure if the lack of
calibration is the cause of that, or if it is something else. I can take 
another look
once the calibration is fixed.

Regards,

Hans

Signed-off-by: Hans Verkuil 
---
diff --git a/arch/arm/boot/dts/am335x-boneblack-common.dtsi 
b/arch/arm/boot/dts/am335x-boneblack-common.dtsi
index 325daae40278..07e6b36d17c4 100644
--- a/arch/arm/boot/dts/am335x-boneblack-common.dtsi
+++ b/arch/arm/boot/dts/am335x-boneblack-common.dtsi
@@ -7,6 +7,7 @@
  */

 #include 
+#include 

 &ldo3_reg {
regulator-min-microvolt = <180>;
@@ -91,6 +92,8 @@
tda19988: tda19988 {
compatible = "nxp,tda998x";
reg = <0x70>;
+   nxp,calib-gpios = <&gpio1 25 0>;
+   interrupts-extended = <&gpio1 25 IRQ_TYPE_LEVEL_LOW>;

pinctrl-names = "default", "off";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

[Lionel Landwerlin]

On 12/12/17 11:19, Tvrtko Ursulin wrote:


On 11/12/2017 21:05, Daniel Vetter wrote:

On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:

On 11/12/2017 10:50, Joonas Lahtinen wrote:

+ Daniel, Chris

On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:

On 04/12/2017 15:02, Lionel Landwerlin wrote:

Hi,

After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card through a
symlink. Making it obvious from an application using a render 
node to

know where to get the information it needs.


Important thing to mention as well is that it is trivial to get 
from the

master drm fd to the sysfs root, via fstat and opendir
/sys/dev/char/:. With the addition of the card 
symlink to

render nodes it is trivial for render node fd as well.

I am happy with this approach - it is extensible, flexible and avoids
issues with ioctl versioning or whatnot. With one value per file 
it is

trivial for userspace to access.

So for what I'm concerned, given how gputop would use all of this 
and so

be the userspace, if everyone else is happy, I think we could do a
detailed review and prehaps also think about including gputop in some
distribution to make the case 100% straightforward.


For the GPU topology I agree this is the right choice, it's going 
to be

about topology after all, and directory tree is the perfect candidate.
And if a new platform appears, then it's a new platform and may change
the topology well the hardware topology has changed.

For the engine enumeration, I'm not equally sold for sysfs exposing 
it.

It's a "linear list of engine instances with flags" how the userspace
is going to be looking at them. And it's also information about 
what to

pass to an IOCTL as arguments after decision has been made, and then
you already have the FD you know you'll be dealing with, at hand. So
another IOCTL for that seems more convenient.


Apart from more flexibility and easier to extend, sysfs might be a 
better
fit for applications which do not otherwise need a drm fd. Say a 
top-like

tool which shows engine utilization, or those patches I RFC-ed recently
which do the same but per DRM client.

Okay, these stats are now available also via PMU so the argument is 
not the
strongest I admit, but I still find it quite neat. It also might 
allow us to

define our own policy with regards to needed privilege to access these
stats, and not be governed by the perf API rules.


How exactly is sysfs easier to extend than ioctl? There's lots of


Easier as in no need to version, add has_this/has_that markers, try to 
guess today how big a field for something might be needed in the 
future and similar.



serializing and deserializing going on, ime that's more boilerplate. Imo
the only reason for sysfs is when you _must_ access it without having an
fd to the gpu. The inverse is generally not true (i.e. using sysfs when
you have the fd already), and as soon as you add a writeable field here
you're screwed (because sysfs can't be passed to anyone else but root,
compared to drm fd - viz the backlight fiasco).


I would perhaps expand the "must access without having a drm fd" to 
"more convenient to access without a drm fd". My use case here was the 
per-client engine usage stats. Equivalence with /proc//stat, or 
even /proc/stat if you want. So I was interested in creating a 
foothold in sysfs for that purpose.


No writable fields were imagined in all these two to three use cases.


But even without writeable fields: Think of highly contained
containers/clients which only get the drm fd to render. If sysfs is 
gone,
will they fall on their faces? Atm "drm fd is all you need" is very 
deeply

ingrained into our various OS stacks.


Okay, this is something which was mentioned but I think the answer was 
unclear. If current stacks do work without sysfs then this is a good 
argument to keep that ability.


As I said I am OK to drop the engine info bits from this series. 
Question for Lionel, gpu-top and Mesa then is whether sysfs works for 
them, for the remaining topology information. Attractiveness of sysfs 
there was that it looked easier to be future proof for more or less 
hypothetical future topologies.


We did a couple of versions with ioctls :

https://patchwork.freedesktop.org/patch/185959/ (through GET_PARAM)
https://patchwork.freedesktop.org/series/33436/ (though a new discovery 
uAPI initially targeted at the engine discovery)


Eventually Chris suggested sysfs (which I find kind of convenient), even 
though you Daniel raised a valid point with sandboxed processes.


I personally don't care much in which way this should be implemented.
Just give me some direction :)

Daniel: Would something in the style of 
https://patchwork.freedesktop.org/series/33436/ work? If yes, what would 
you recommend to change?


Thanks!

-
Lionel



Regards,

Tvrtko



-Daniel

So I'd say for the GPU topology part, we go forward with the review 
and

make sure we do

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

[Joonas Lahtinen]

Hi,

I sent this individual i915 patch to our CI, and it is passing on all platforms:

https://patchwork.freedesktop.org/series/34822/

Is it ok if I merge this to drm-tip already?

Regards, Joonas

On Mon, 2017-11-27 at 13:50 -0500, Sinan Kaya wrote:
> +dri-devel@lists.freedesktop.org
> 
> On 11/27/2017 11:57 AM, Sinan Kaya wrote:
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
> > 
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> > 
> > Extract the domain number from drm_device and pass it into
> > pci_get_domain_bus_and_slot() function.
> > 
> > Signed-off-by: Sinan Kaya 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 9f45cfe..5a8cb79 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -419,7 +419,10 @@ static int i915_getparam(struct drm_device *dev, void 
> > *data,
> >  
> >  static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
> >  {
> > -   dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> > +   int domain = pci_domain_nr(dev_priv->drm.pdev->bus);
> > +
> > +   dev_priv->bridge_dev =
> > +   pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
> > if (!dev_priv->bridge_dev) {
> > DRM_ERROR("bridge device not found\n");
> > return -1;
> > 
> 
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] amdgpu: Remove dummy CU_ASSERT_EQUAL.

[Andrey Grodzovsky]

Fixes test failure on rhel.

Signed-off-by: Andrey Grodzovsky 
---
 tests/amdgpu/basic_tests.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index a78cf52..474a679 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -1459,8 +1459,6 @@ static void amdgpu_sync_dependency_test(void)
static uint32_t *ptr;
uint64_t seq_no;
 
-   CU_ASSERT_EQUAL(r, 0);
-
r = amdgpu_cs_ctx_create(device_handle, &context_handle[0]);
CU_ASSERT_EQUAL(r, 0);
r = amdgpu_cs_ctx_create(device_handle, &context_handle[1]);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103100] Performance regression with various games in drm-next-amd-staging Kernel

[bugzilla-daemon]

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

--- Comment #11 from Andy Furniss  ---
For my test case - UnrealTournament alpha + not quite enough vram, looks like
mesa commit

winsys/amdgpu: disable local BOs again due to worse performance
https://cgit.freedesktop.org/mesa/mesa/commit/?id=bf0904e31fb7d9cd8932d582076c8d7beb02ba89

works around the issue.

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

[PATCH] drm/drm_lease: Do not call drm_master_put() twice in case drm_lease_create() fails

[Marius Vlad]

This case can been seen when creating the lease with same objects passed.

Signed-off-by: Marius Vlad 
---
 drivers/gpu/drm/drm_lease.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index d1eb56a..ae57f33 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -254,8 +254,6 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
return lessee;
 
 out_lessee:
-   drm_master_put(&lessee);
-
mutex_unlock(&dev->mode_config.idr_mutex);
 
return ERR_PTR(error);
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/41] drm/rockchip: support prime import sg table

[Heiko Stuebner]

Am Donnerstag, 9. März 2017, 23:32:18 CET schrieb Sean Paul:
> From: Haixia Shi 
> 
> The prime fd to handle ioctl was not used with rockchip before. Support
> was added in order to pass graphics_Gbm and to support potential uses
> within Chrome OS (e.g. zero-copy video decode, camera).
> 
> Signed-off-by: Haixia Shi 

missing a further Signed-off from Sean Paul as the sender.

I've tested this on the rk3328 together with the wip Lima driver and my wip
Mesa Rockchip Pipe and the kmscube improved from a failure about importing
the buffer to producing actual output, so

Tested-by: Heiko Stuebner 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/41] drm/rockchip: Get rid of some unnecessary code

[Heiko Stuebner]

Am Donnerstag, 9. März 2017, 23:32:17 CET schrieb Sean Paul:
> From: Tomasz Figa 
> 
> Current code implements prepare_fb and cleanup_fb callbacks only to
> grab/release fb references, which is already done by atomic framework
> when creating/destryoing plane state. Also there are some unused fields
> vop and vop_win structs. Let's remove these unused bits.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Sean Paul 

There seems to be a slight discrepancy between patch message and code.
The commit message talks about *_fb-callbacks, while the patch removes
a seemingly unsused mutex, which I guess falls under the "some unused fields"
part.

In any case, I didn't see any ill effects when testing this patch, so
Tested-by: Heiko Stuebner 

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 2151e1cee4b4..0539afb6b7c8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -108,9 +108,6 @@ struct vop {
>   struct drm_device *drm_dev;
>   bool is_enabled;
>  
> - /* mutex vsync_ work */
> - struct mutex vsync_mutex;
> - bool vsync_work_pending;
>   struct completion dsp_hold_completion;
>  
>   /* protected by dev->event_lock */
> @@ -1592,8 +1589,6 @@ static int vop_bind(struct device *dev, struct device 
> *master, void *data)
>   spin_lock_init(&vop->reg_lock);
>   spin_lock_init(&vop->irq_lock);
>  
> - mutex_init(&vop->vsync_mutex);
> -
>   ret = devm_request_irq(dev, vop->irq, vop_isr,
>  IRQF_SHARED, dev_name(dev), vop);
>   if (ret)
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Markus Heiser]

> Am 12.12.2017 um 13:05 schrieb Michal Wajdeczko :
> 
> On Tue, 12 Dec 2017 12:38:37 +0100, Markus Heiser  
> wrote:
> 
>> With commit d9e2e0143c the 'GuC-specific firmware loader' doc
>> section was removed from intel_guc_loader.c without a
>> replacement.  So lets remove it from the Kernel-doc::
>> 
>>  .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
>> :doc: GuC-specific firmware loader
>> 
>> With commit e8668bbcb0 intel_guc_loader.c was renamed to to
>> intel_guc_fw.c and to name just one, intel_guc_init_hw() was
>> renamed to intel_guc_fw_upload(). Since we get errors in the
>> Sphinx build like:
>> 
>> - Error: Cannot open file ./drivers/gpu/drm/i915/intel_guc_loader.c
>> 
>> Change the kernel-doc directive from intel_guc_loader.c to
>> intel_guc_fw.c
>> 
>> Signed-off-by: Markus Heiser 
>> ---
> 
> Thanks for your patch, but similar fix is already merged here [1]
> 
> Michal
> 
> [1] 
> https://cgit.freedesktop.org/drm-tip/commit/?id=006c23327f8de8575508c458131b304188d426f7


Thanks for pointing out. I miss the ":doc: GuC-specific firmware loader"
fix in that patch (doc section was removed in d9e2e0143c).  Can you or
someone else from @intel fix this also?

Thanks!

 -- Markus --



> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Michal Wajdeczko]

On Tue, 12 Dec 2017 12:38:37 +0100, Markus Heiser  
 wrote:



With commit d9e2e0143c the 'GuC-specific firmware loader' doc
section was removed from intel_guc_loader.c without a
replacement.  So lets remove it from the Kernel-doc::

  .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
 :doc: GuC-specific firmware loader

With commit e8668bbcb0 intel_guc_loader.c was renamed to to
intel_guc_fw.c and to name just one, intel_guc_init_hw() was
renamed to intel_guc_fw_upload(). Since we get errors in the
Sphinx build like:

- Error: Cannot open file ./drivers/gpu/drm/i915/intel_guc_loader.c

Change the kernel-doc directive from intel_guc_loader.c to
intel_guc_fw.c

Signed-off-by: Markus Heiser 
---


Thanks for your patch, but similar fix is already merged here [1]

Michal

[1]  
https://cgit.freedesktop.org/drm-tip/commit/?id=006c23327f8de8575508c458131b304188d426f7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: Fix error value in exynos_drm_crtc_get_by_type()

[Marek Szyprowski]

EPERM is not the correct error value when the driver is not able to get
its resources. Change it to ENODEV.

Reported-by: Russell King - ARM Linux 
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index dc01342e759a..eea90251808f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -228,7 +228,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct 
drm_device *drm_dev,
if (to_exynos_crtc(crtc)->type == out_type)
return to_exynos_crtc(crtc);
 
-   return ERR_PTR(-EPERM);
+   return ERR_PTR(-ENODEV);
 }
 
 int exynos_drm_set_possible_crtcs(struct drm_encoder *encoder,
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c

[Markus Heiser]

With commit d9e2e0143c the 'GuC-specific firmware loader' doc
section was removed from intel_guc_loader.c without a
replacement.  So lets remove it from the Kernel-doc::

  .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
 :doc: GuC-specific firmware loader

With commit e8668bbcb0 intel_guc_loader.c was renamed to to
intel_guc_fw.c and to name just one, intel_guc_init_hw() was
renamed to intel_guc_fw_upload(). Since we get errors in the
Sphinx build like:

- Error: Cannot open file ./drivers/gpu/drm/i915/intel_guc_loader.c

Change the kernel-doc directive from intel_guc_loader.c to
intel_guc_fw.c

Signed-off-by: Markus Heiser 
---
 Documentation/gpu/i915.rst | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee03..e94d3ac 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,7 @@ GuC
 GuC-specific firmware loader
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
-   :doc: GuC-specific firmware loader
-
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
 
 GuC-based command submission
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: analogix: Remove unreachable code from analogic_dp_core.c

[Sylwester Nawrocki]

This patch removes an unreachable code found by the SVACE static
analysis:

UNREACHABLE_CODE: This statement in the source code might be unreachable during 
program execution.
[unreachable] unreachable at 
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:787
retval != 0 is always false because at this program point the variable retval
is always equal to 0 at drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:786

Signed-off-by: Sylwester Nawrocki 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5dd3f1cd074a..263e8215b3de 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -727,7 +727,6 @@ static int analogix_dp_set_link_train(struct 
analogix_dp_device *dp,
 
 static int analogix_dp_config_video(struct analogix_dp_device *dp)
 {
-   int retval = 0;
int timeout_loop = 0;
int done_count = 0;
 
@@ -783,10 +782,7 @@ static int analogix_dp_config_video(struct 
analogix_dp_device *dp)
usleep_range(1000, 1001);
}
 
-   if (retval != 0)
-   dev_err(dp->dev, "Video stream is not detected!\n");
-
-   return retval;
+   return 0;
 }
 
 static void analogix_dp_enable_scramble(struct analogix_dp_device *dp,
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

[Tvrtko Ursulin]

On 11/12/2017 21:05, Daniel Vetter wrote:

On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:

On 11/12/2017 10:50, Joonas Lahtinen wrote:

+ Daniel, Chris

On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:

On 04/12/2017 15:02, Lionel Landwerlin wrote:

Hi,

After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card through a
symlink. Making it obvious from an application using a render node to
know where to get the information it needs.


Important thing to mention as well is that it is trivial to get from the
master drm fd to the sysfs root, via fstat and opendir
/sys/dev/char/:. With the addition of the card symlink to
render nodes it is trivial for render node fd as well.

I am happy with this approach - it is extensible, flexible and avoids
issues with ioctl versioning or whatnot. With one value per file it is
trivial for userspace to access.

So for what I'm concerned, given how gputop would use all of this and so
be the userspace, if everyone else is happy, I think we could do a
detailed review and prehaps also think about including gputop in some
distribution to make the case 100% straightforward.


For the GPU topology I agree this is the right choice, it's going to be
about topology after all, and directory tree is the perfect candidate.
And if a new platform appears, then it's a new platform and may change
the topology well the hardware topology has changed.

For the engine enumeration, I'm not equally sold for sysfs exposing it.
It's a "linear list of engine instances with flags" how the userspace
is going to be looking at them. And it's also information about what to
pass to an IOCTL as arguments after decision has been made, and then
you already have the FD you know you'll be dealing with, at hand. So
another IOCTL for that seems more convenient.


Apart from more flexibility and easier to extend, sysfs might be a better
fit for applications which do not otherwise need a drm fd. Say a top-like
tool which shows engine utilization, or those patches I RFC-ed recently
which do the same but per DRM client.

Okay, these stats are now available also via PMU so the argument is not the
strongest I admit, but I still find it quite neat. It also might allow us to
define our own policy with regards to needed privilege to access these
stats, and not be governed by the perf API rules.


How exactly is sysfs easier to extend than ioctl? There's lots of


Easier as in no need to version, add has_this/has_that markers, try to 
guess today how big a field for something might be needed in the future 
and similar.



serializing and deserializing going on, ime that's more boilerplate. Imo
the only reason for sysfs is when you _must_ access it without having an
fd to the gpu. The inverse is generally not true (i.e. using sysfs when
you have the fd already), and as soon as you add a writeable field here
you're screwed (because sysfs can't be passed to anyone else but root,
compared to drm fd - viz the backlight fiasco).


I would perhaps expand the "must access without having a drm fd" to 
"more convenient to access without a drm fd". My use case here was the 
per-client engine usage stats. Equivalence with /proc//stat, or 
even /proc/stat if you want. So I was interested in creating a foothold 
in sysfs for that purpose.


No writable fields were imagined in all these two to three use cases.


But even without writeable fields: Think of highly contained
containers/clients which only get the drm fd to render. If sysfs is gone,
will they fall on their faces? Atm "drm fd is all you need" is very deeply
ingrained into our various OS stacks.


Okay, this is something which was mentioned but I think the answer was 
unclear. If current stacks do work without sysfs then this is a good 
argument to keep that ability.


As I said I am OK to drop the engine info bits from this series. 
Question for Lionel, gpu-top and Mesa then is whether sysfs works for 
them, for the remaining topology information. Attractiveness of sysfs 
there was that it looked easier to be future proof for more or less 
hypothetical future topologies.


Regards,

Tvrtko



-Daniel


So I'd say for the GPU topology part, we go forward with the review and
make sure we don't expose driver internal bits that could break when
refactoring code. If the exposed N bits of information are strictly
tied to the underlying hardware, we should have no trouble maintaining
that for the foreseeable future.

Then we can continue on about the engine discovery in parallel, not
blocking GPU topology discovery.


I can live with that, but would like to keep the gt/engines/ namespace
reserved for the eventuality with go with engine info in sysfs at a later
stage then.

Also, Lionel, did you have plans to use the engine info straight away in gpu
top, or you only needed topology? I think you were drawing a nice block
diagram of a GPU so do you need it for that?

Regards,

Tvrtko



__

[Bug 104216] Firefox quirks (black and/or white squares)

[bugzilla-daemon]

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

--- Comment #4 from Germano Massullo  ---
(In reply to Michel Dänzer from comment #3)
> Unless this doesn't happen with the modesetting driver, it's more likely a
> Mesa issue than a Xorg driver one.

dmesg says that kernel modesetting is enabled


# dmesg | grep amdgpu
[1.841902] [drm] amdgpu kernel modesetting enabled.
[1.878816] amdgpu :01:00.0: Invalid PCI ROM header signature: expecting
0xaa55, got 0x
[1.879313] amdgpu :01:00.0: VRAM: 8192M 0x -
0x0001 (8192M used)
[1.879315] amdgpu :01:00.0: GTT: 8192M 0x0002 -
0x0003
[1.879657] [drm] amdgpu: 8192M of VRAM memory ready
[1.879658] [drm] amdgpu: 8192M of GTT memory ready.
[1.880899] amdgpu :01:00.0: amdgpu: using MSI.
[1.880915] [drm] amdgpu: irq initialized.
[2.037947] amdgpu: [powerplay] amdgpu: powerplay sw initialized
[2.038628] amdgpu :01:00.0: fence driver on ring 0 use gpu addr
0x00020008, cpu addr 0x8f75269ff008
[2.038678] amdgpu :01:00.0: fence driver on ring 1 use gpu addr
0x00020018, cpu addr 0x8f75269ff018
[2.038712] amdgpu :01:00.0: fence driver on ring 2 use gpu addr
0x00020028, cpu addr 0x8f75269ff028
[2.038751] amdgpu :01:00.0: fence driver on ring 3 use gpu addr
0x00020038, cpu addr 0x8f75269ff038
[2.038785] amdgpu :01:00.0: fence driver on ring 4 use gpu addr
0x00020048, cpu addr 0x8f75269ff048
[2.038821] amdgpu :01:00.0: fence driver on ring 5 use gpu addr
0x00020058, cpu addr 0x8f75269ff058
[2.038855] amdgpu :01:00.0: fence driver on ring 6 use gpu addr
0x00020068, cpu addr 0x8f75269ff068
[2.038892] amdgpu :01:00.0: fence driver on ring 7 use gpu addr
0x00020078, cpu addr 0x8f75269ff078
[2.038926] amdgpu :01:00.0: fence driver on ring 8 use gpu addr
0x00020088, cpu addr 0x8f75269ff088
[2.038946] amdgpu :01:00.0: fence driver on ring 9 use gpu addr
0x0002009c, cpu addr 0x8f75269ff09c
[2.039097] amdgpu :01:00.0: fence driver on ring 10 use gpu addr
0x000200ac, cpu addr 0x8f75269ff0ac
[2.039139] amdgpu :01:00.0: fence driver on ring 11 use gpu addr
0x000200bc, cpu addr 0x8f75269ff0bc
[2.039657] amdgpu :01:00.0: fence driver on ring 12 use gpu addr
0x0122d420, cpu addr 0xbab80285a420
[2.039830] amdgpu :01:00.0: fence driver on ring 13 use gpu addr
0x000200dc, cpu addr 0x8f75269ff0dc
[2.039864] amdgpu :01:00.0: fence driver on ring 14 use gpu addr
0x000200ec, cpu addr 0x8f75269ff0ec
[2.079285] amdgpu: [powerplay] [AVFS] Something is broken. See log!
[2.081178] amdgpu: [powerplay] Can't find requested voltage id in
vdd_dep_on_sclk table!
[2.907923] fbcon: amdgpudrmfb (fb0) is primary device
[3.211243] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device
[3.219422] [drm] Initialized amdgpu 3.18.0 20150101 for :01:00.0 on
minor 0


# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-4.13.16-302.fc27.x86_64 root=UUID=*removed* ro rd.md=0
rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=it LANG=en_US.UTF-8 rhgb quiet

# lsmod 
Module  Size  Used by
bnep   20480  2
xfs  1187840  0
btrfs1101824  0
xor24576  1 btrfs
raid6_pq  118784  1 btrfs
vfat   20480  0
fat65536  1 vfat
bluetooth 516096  7 bnep
ecdh_generic   24576  1 bluetooth
rfkill 28672  4 bluetooth
fuse  102400  3
dm_crypt   36864  2
uas24576  0
usb_storage69632  1 uas
xt_CHECKSUM16384  1
ipt_MASQUERADE 16384  3
nf_nat_masquerade_ipv416384  1 ipt_MASQUERADE
tun32768  1
ip6t_rpfilter  16384  1
ip6t_REJECT16384  2
nf_reject_ipv6 16384  1 ip6t_REJECT
xt_conntrack   16384  40
ip_set 36864  0
nfnetlink  16384  1 ip_set
ebtable_nat16384  1
ebtable_broute 16384  1
bridge143360  1 ebtable_broute
stp16384  1 bridge
llc16384  2 bridge,stp
ip6table_nat   16384  1
nf_conntrack_ipv6  20480  21
nf_defrag_ipv6 36864  1 nf_conntrack_ipv6
nf_nat_ipv616384  1 ip6table_nat
ip6table_mangle16384  1
ip6table_raw   16384  1
ip6table_security  16384  1
iptable_nat16384  1
nf_conntrack_ipv4  16384  24
nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
nf_nat_ipv416384  1 iptable_nat
nf_nat 28672  3 nf_nat_ipv6,nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack  131072  8
nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_ipv6,nf_nat_masq

[Bug 104216] Firefox quirks (black and/or white squares)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 QA Contact|xorg-t...@lists.x.org   |dri-devel@lists.freedesktop
   ||.org
Version|unspecified |17.2
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
  Component|Driver/AMDgpu   |Drivers/Gallium/radeonsi
Product|xorg|Mesa

--- Comment #3 from Michel Dänzer  ---
Unless this doesn't happen with the modesetting driver, it's more likely a Mesa
issue than a Xorg driver one.

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

Re: [PATCH 5/6] drm/ttm: enable eviction for Per-VM-BO

[Christian König]

Am 12.12.2017 um 10:33 schrieb Roger He:

Change-Id: I491d4ceb8c98bb3d8e6e0ddef2330284ce2fe5f6
Signed-off-by: Roger He 


I would squash this one with patch #6.


---
  drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index eb8c568..22b6ca5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -722,10 +722,9 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
-   if (bo->resv == resv) {
-   if (list_empty(&bo->ddestroy))
-   continue;
-   } else {
+   if (!ctx ||
+   !(ctx->on_alloc_stage &&
+   bo->resv == ctx->resv)) {


Coding style: The lines stating with "!(ctx" and "bo->resv" are to far 
to the right.


Additional to that I think ctx is mandatory and doesn't need a check 
(but might be wrong). If it isn't it's probably time to make it mandatory.


And I would use (ctx->on_alloc_stage || list_empty(&bo->ddestroy)) as 
check, we probably still want to be able to handle deleted BOs here 
during CS.


Christian.


locked = reservation_object_trylock(bo->resv);
if (!locked)
continue;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/6] drm/ttm: init locked again to prevent incorrect unlock

[Christian König]

Am 12.12.2017 um 10:33 schrieb Roger He:

Change-Id: I8db51d843955f5db14bb4bbff892eaedbd9f0abe
Signed-off-by: Roger He 


Reviewed-by: Christian König 

That is a bug fix, isn't it? If yes maybe add CC:stable and commit it 
first before all other patches.


Christian.


---
  drivers/gpu/drm/ttm/ttm_bo.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 17fe8be..eb8c568 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -735,6 +735,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
  place)) {
if (locked)
reservation_object_unlock(bo->resv);
+   locked = false;
continue;
}
break;


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/6] drm/ttm: use an ttm operation ctx for ttm_bo_move_xxx

[Christian König]

Am 12.12.2017 um 10:33 schrieb Roger He:

include ttm_bo_move_memcpy and ttm_bo_move_ttm

Change-Id: I160b2fe1da3200405810d0215c4521b5f0d3615a
Signed-off-by: Roger He 


Reviewed-by: Christian König 

But please separate that out and wait for a few days before committing, 
maybe some nouveau devs have objections.


Christian.


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
  drivers/gpu/drm/nouveau/nouveau_bo.c| 7 +++
  drivers/gpu/drm/qxl/qxl_ttm.c   | 3 +--
  drivers/gpu/drm/radeon/radeon_ttm.c | 7 +++
  drivers/gpu/drm/ttm/ttm_bo.c| 6 ++
  drivers/gpu/drm/ttm/ttm_bo_util.c   | 8 
  include/drm/ttm/ttm_bo_driver.h | 4 ++--
  7 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7db9556..c307a7d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -505,7 +505,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object 
*bo, bool evict,
if (unlikely(r)) {
goto out_cleanup;
}
-   r = ttm_bo_move_ttm(bo, ctx->interruptible, ctx->no_wait_gpu, new_mem);
+   r = ttm_bo_move_ttm(bo, ctx, new_mem);
  out_cleanup:
ttm_bo_mem_put(bo, &tmp_mem);
return r;
@@ -536,7 +536,7 @@ static int amdgpu_move_ram_vram(struct ttm_buffer_object 
*bo, bool evict,
if (unlikely(r)) {
return r;
}
-   r = ttm_bo_move_ttm(bo, ctx->interruptible, ctx->no_wait_gpu, &tmp_mem);
+   r = ttm_bo_move_ttm(bo, ctx, &tmp_mem);
if (unlikely(r)) {
goto out_cleanup;
}
@@ -597,8 +597,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
  
  	if (r) {

  memcpy:
-   r = ttm_bo_move_memcpy(bo, ctx->interruptible,
-  ctx->no_wait_gpu, new_mem);
+   r = ttm_bo_move_memcpy(bo, ctx, new_mem);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 949bf6b..6b6fb20 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1226,7 +1226,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool 
evict, bool intr,
if (ret)
goto out;
  
-	ret = ttm_bo_move_ttm(bo, intr, no_wait_gpu, new_reg);

+   ret = ttm_bo_move_ttm(bo, &ctx, new_reg);
  out:
ttm_bo_mem_put(bo, &tmp_reg);
return ret;
@@ -1255,7 +1255,7 @@ nouveau_bo_move_flips(struct ttm_buffer_object *bo, bool 
evict, bool intr,
if (ret)
return ret;
  
-	ret = ttm_bo_move_ttm(bo, intr, no_wait_gpu, &tmp_reg);

+   ret = ttm_bo_move_ttm(bo, &ctx, &tmp_reg);
if (ret)
goto out;
  
@@ -1380,8 +1380,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,

/* Fallback to software copy. */
ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
if (ret == 0)
-   ret = ttm_bo_move_memcpy(bo, ctx->interruptible,
-ctx->no_wait_gpu, new_reg);
+   ret = ttm_bo_move_memcpy(bo, ctx, new_reg);
  
  out:

if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA) {
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index d866f32..78ce118 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -357,8 +357,7 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool 
evict,
qxl_move_null(bo, new_mem);
return 0;
}
-   return ttm_bo_move_memcpy(bo, ctx->interruptible, ctx->no_wait_gpu,
- new_mem);
+   return ttm_bo_move_memcpy(bo, ctx, new_mem);
  }
  
  static void qxl_bo_move_notify(struct ttm_buffer_object *bo,

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 98e30d7..557fd79 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -347,7 +347,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
*bo,
if (unlikely(r)) {
goto out_cleanup;
}
-   r = ttm_bo_move_ttm(bo, interruptible, no_wait_gpu, new_mem);
+   r = ttm_bo_move_ttm(bo, &ctx, new_mem);
  out_cleanup:
ttm_bo_mem_put(bo, &tmp_mem);
return r;
@@ -380,7 +380,7 @@ static int radeon_move_ram_vram(struct ttm_buffer_object 
*bo,
if (unlikely(r)) {
return r;
}
-   r = ttm_bo_move_ttm(bo, interruptible, no_wait_gpu, &tmp_mem);
+   r = ttm_bo_move_ttm(bo, &ctx, &tmp_mem);
if (unlikely(r)) {
goto out_cleanup;
}
@@ -445,8 +445,7 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
  
  	if (r) {

  memcpy:
-   r = 

Re: [PATCH 2/6] drm/ttm: when create a new ttm bo init on_alloc_stage and resv for ttm_operation_ctx

[Christian König]

Am 12.12.2017 um 10:33 schrieb Roger He:

Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e
Signed-off-by: Roger He 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
  drivers/gpu/drm/ttm/ttm_bo.c   | 1 +
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index dc0a8be..eb42782 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -327,7 +327,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
   uint64_t init_value,
   struct amdgpu_bo **bo_ptr)
  {
-   struct ttm_operation_ctx ctx = { !kernel, false };
+   struct ttm_operation_ctx ctx = { !kernel, false, true };
struct amdgpu_bo *bo;
enum ttm_bo_type type;
unsigned long page_align;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 97c3da6..70b2673 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1208,6 +1208,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
WARN_ON(!locked);
}
  
+	ctx->resv = resv;


That is something amdgpu specific, don't put that into TTM code.

Christian.


if (likely(!ret))
ret = ttm_bo_validate(bo, placement, ctx);
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx

[Christian König]

Am 12.12.2017 um 10:33 schrieb Roger He:

on_alloc_stage: is this operation on allocation stage
resv: reservation bo used of this operation

Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
Signed-off-by: Roger He 
---
  include/drm/ttm/ttm_bo_api.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 368eb02..25de597 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -263,6 +263,8 @@ struct ttm_bo_kmap_obj {
   *
   * @interruptible: Sleep interruptible if sleeping.
   * @no_wait_gpu: Return immediately if the GPU is busy.
+ * @on_alloc_stage: is this operation on allocation stage
+ * @resv: resvation bo used
   *
   * Context for TTM operations like changing buffer placement or general memory
   * allocation.
@@ -270,6 +272,8 @@ struct ttm_bo_kmap_obj {
  struct ttm_operation_ctx {
bool interruptible;
bool no_wait_gpu;
+   bool on_alloc_stage;


The name describes how amdgpu want to use the flag and not what effect 
it has.


How about "allow_reserved_eviction"?

And also please update the documentation with something like:
* @allow_reserved_eviction: Allow eviction of reserved BOs.
* @resv: Reservation object to allow reserved evictions with.

Alternative we could put the ww_mutex context in here as Daniel 
suggested, but I think we should stick with what we have for now and 
make that change when we find another use case for this.


Christian.


+   struct reservation_object *resv;
uint64_t bytes_moved;
  };
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/7] drm/ttm:fix incorrect calculate on shrink_pages

[He, Roger]

Reviewed-by: Roger He 

Thanks
Roger(Hongbo.He)
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Monk 
Liu
Sent: Tuesday, December 12, 2017 5:47 PM
To: amd-...@lists.freedesktop.org
Cc: Liu, Monk 
Subject: [PATCH 1/7] drm/ttm:fix incorrect calculate on shrink_pages

shrink_pages is in unit of Order after ttm_page_pool_free, but it is used by 
nr_free in next round so need change it into native page unit

Change-Id: I33b77ac1616e24b1b881eee54c3bd7342cfa9ab8
Signed-off-by: Monk Liu 
---
 drivers/gpu/drm/ttm/ttm_page_alloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 44343a2..71945cc 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -455,6 +455,7 @@ ttm_pool_shrink_scan(struct shrinker *shrink, struct 
shrink_control *sc)
freed += (nr_free_pool - shrink_pages) << pool->order;
if (freed >= sc->nr_to_scan)
break;
+   shrink_pages <<= pool->order;
}
mutex_unlock(&lock);
return freed;
--
2.7.4

___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/6] drm/ttm: remove parameter reservation since it is moved into ttm context

[Roger He]

Change-Id: I83ac6a77f24e14698aa386a497a262e24c5bbdb6
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 22b6ca5..f138e95 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -707,7 +707,6 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-  struct reservation_object *resv,
   uint32_t mem_type,
   const struct ttm_place *place,
   struct ttm_operation_ctx *ctx)
@@ -834,7 +833,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, ctx);
+   ret = ttm_mem_evict_first(bdev, mem_type, place, ctx);
if (unlikely(ret != 0))
return ret;
} while (1);
@@ -1332,8 +1331,7 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(&man->lru[i])) {
spin_unlock(&glob->lru_lock);
-   ret = ttm_mem_evict_first(bdev, NULL, mem_type,
- NULL, &ctx);
+   ret = ttm_mem_evict_first(bdev, mem_type, NULL, &ctx);
if (ret)
return ret;
spin_lock(&glob->lru_lock);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/6] drm/ttm: enable eviction for Per-VM-BO

[Roger He]

Change-Id: I491d4ceb8c98bb3d8e6e0ddef2330284ce2fe5f6
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index eb8c568..22b6ca5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -722,10 +722,9 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(&glob->lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, &man->lru[i], lru) {
-   if (bo->resv == resv) {
-   if (list_empty(&bo->ddestroy))
-   continue;
-   } else {
+   if (!ctx ||
+   !(ctx->on_alloc_stage &&
+   bo->resv == ctx->resv)) {
locked = reservation_object_trylock(bo->resv);
if (!locked)
continue;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/6] drm/ttm: init locked again to prevent incorrect unlock

[Roger He]

Change-Id: I8db51d843955f5db14bb4bbff892eaedbd9f0abe
Signed-off-by: Roger He 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 17fe8be..eb8c568 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -735,6 +735,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
  place)) {
if (locked)
reservation_object_unlock(bo->resv);
+   locked = false;
continue;
}
break;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/6] drm/ttm: use an ttm operation ctx for ttm_bo_move_xxx

[Roger He]

include ttm_bo_move_memcpy and ttm_bo_move_ttm

Change-Id: I160b2fe1da3200405810d0215c4521b5f0d3615a
Signed-off-by: Roger He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
 drivers/gpu/drm/nouveau/nouveau_bo.c| 7 +++
 drivers/gpu/drm/qxl/qxl_ttm.c   | 3 +--
 drivers/gpu/drm/radeon/radeon_ttm.c | 7 +++
 drivers/gpu/drm/ttm/ttm_bo.c| 6 ++
 drivers/gpu/drm/ttm/ttm_bo_util.c   | 8 
 include/drm/ttm/ttm_bo_driver.h | 4 ++--
 7 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7db9556..c307a7d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -505,7 +505,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object 
*bo, bool evict,
if (unlikely(r)) {
goto out_cleanup;
}
-   r = ttm_bo_move_ttm(bo, ctx->interruptible, ctx->no_wait_gpu, new_mem);
+   r = ttm_bo_move_ttm(bo, ctx, new_mem);
 out_cleanup:
ttm_bo_mem_put(bo, &tmp_mem);
return r;
@@ -536,7 +536,7 @@ static int amdgpu_move_ram_vram(struct ttm_buffer_object 
*bo, bool evict,
if (unlikely(r)) {
return r;
}
-   r = ttm_bo_move_ttm(bo, ctx->interruptible, ctx->no_wait_gpu, &tmp_mem);
+   r = ttm_bo_move_ttm(bo, ctx, &tmp_mem);
if (unlikely(r)) {
goto out_cleanup;
}
@@ -597,8 +597,7 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
 
if (r) {
 memcpy:
-   r = ttm_bo_move_memcpy(bo, ctx->interruptible,
-  ctx->no_wait_gpu, new_mem);
+   r = ttm_bo_move_memcpy(bo, ctx, new_mem);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 949bf6b..6b6fb20 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1226,7 +1226,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool 
evict, bool intr,
if (ret)
goto out;
 
-   ret = ttm_bo_move_ttm(bo, intr, no_wait_gpu, new_reg);
+   ret = ttm_bo_move_ttm(bo, &ctx, new_reg);
 out:
ttm_bo_mem_put(bo, &tmp_reg);
return ret;
@@ -1255,7 +1255,7 @@ nouveau_bo_move_flips(struct ttm_buffer_object *bo, bool 
evict, bool intr,
if (ret)
return ret;
 
-   ret = ttm_bo_move_ttm(bo, intr, no_wait_gpu, &tmp_reg);
+   ret = ttm_bo_move_ttm(bo, &ctx, &tmp_reg);
if (ret)
goto out;
 
@@ -1380,8 +1380,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
/* Fallback to software copy. */
ret = ttm_bo_wait(bo, ctx->interruptible, ctx->no_wait_gpu);
if (ret == 0)
-   ret = ttm_bo_move_memcpy(bo, ctx->interruptible,
-ctx->no_wait_gpu, new_reg);
+   ret = ttm_bo_move_memcpy(bo, ctx, new_reg);
 
 out:
if (drm->client.device.info.family < NV_DEVICE_INFO_V0_TESLA) {
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index d866f32..78ce118 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -357,8 +357,7 @@ static int qxl_bo_move(struct ttm_buffer_object *bo, bool 
evict,
qxl_move_null(bo, new_mem);
return 0;
}
-   return ttm_bo_move_memcpy(bo, ctx->interruptible, ctx->no_wait_gpu,
- new_mem);
+   return ttm_bo_move_memcpy(bo, ctx, new_mem);
 }
 
 static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 98e30d7..557fd79 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -347,7 +347,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
*bo,
if (unlikely(r)) {
goto out_cleanup;
}
-   r = ttm_bo_move_ttm(bo, interruptible, no_wait_gpu, new_mem);
+   r = ttm_bo_move_ttm(bo, &ctx, new_mem);
 out_cleanup:
ttm_bo_mem_put(bo, &tmp_mem);
return r;
@@ -380,7 +380,7 @@ static int radeon_move_ram_vram(struct ttm_buffer_object 
*bo,
if (unlikely(r)) {
return r;
}
-   r = ttm_bo_move_ttm(bo, interruptible, no_wait_gpu, &tmp_mem);
+   r = ttm_bo_move_ttm(bo, &ctx, &tmp_mem);
if (unlikely(r)) {
goto out_cleanup;
}
@@ -445,8 +445,7 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
 
if (r) {
 memcpy:
-   r = ttm_bo_move_memcpy(bo, ctx->interruptible,
-  ctx->no_wait_gpu, new_mem);
+   r = ttm_bo_move_memcpy(bo, ctx, new_mem);
if (r) {

[PATCH 2/6] drm/ttm: when create a new ttm bo init on_alloc_stage and resv for ttm_operation_ctx

[Roger He]

Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e
Signed-off-by: Roger He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index dc0a8be..eb42782 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -327,7 +327,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
   uint64_t init_value,
   struct amdgpu_bo **bo_ptr)
 {
-   struct ttm_operation_ctx ctx = { !kernel, false };
+   struct ttm_operation_ctx ctx = { !kernel, false, true };
struct amdgpu_bo *bo;
enum ttm_bo_type type;
unsigned long page_align;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 97c3da6..70b2673 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1208,6 +1208,7 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
WARN_ON(!locked);
}
 
+   ctx->resv = resv;
if (likely(!ret))
ret = ttm_bo_validate(bo, placement, ctx);
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx

[Roger He]

on_alloc_stage: is this operation on allocation stage
resv: reservation bo used of this operation

Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
Signed-off-by: Roger He 
---
 include/drm/ttm/ttm_bo_api.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 368eb02..25de597 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -263,6 +263,8 @@ struct ttm_bo_kmap_obj {
  *
  * @interruptible: Sleep interruptible if sleeping.
  * @no_wait_gpu: Return immediately if the GPU is busy.
+ * @on_alloc_stage: is this operation on allocation stage
+ * @resv: resvation bo used
  *
  * Context for TTM operations like changing buffer placement or general memory
  * allocation.
@@ -270,6 +272,8 @@ struct ttm_bo_kmap_obj {
 struct ttm_operation_ctx {
bool interruptible;
bool no_wait_gpu;
+   bool on_alloc_stage;
+   struct reservation_object *resv;
uint64_t bytes_moved;
 };
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/7] drm/i2c: tda9950: add CEC driver

[Russell King - ARM Linux]

On Wed, Dec 06, 2017 at 03:11:43PM +0100, Hans Verkuil wrote:
> Hi Russell,
> 
> Some small comments below:
> 
> On 12/06/17 13:35, Russell King wrote:
> > +   /*
> > +* This should never happen: the data sheet says that there will
> > +* always be a valid message if the interrupt line is asserted.
> > +*/
> > +   if (buf[0] == 0) {
> 
> Checking for <= 2 is safer. See also my comment below.
> 
> > +   dev_warn(&priv->client->dev, "interrupt pending, but no 
> > message?\n");
> > +   return IRQ_NONE;
> > +   }
> > +
> > +   switch (buf[1]) {
> > +   case CDR1_CNF: /* transmit result */
> > +   arb_lost_cnt = nack_cnt = err_cnt = 0;
> > +   switch (buf[2]) {
> > +   case CDR2_CNF_SUCCESS:
> > +   tx_status = CEC_TX_STATUS_OK;
> > +   break;
> > +
> > +   case CDR2_CNF_ARB_ERROR:
> > +   tx_status = CEC_TX_STATUS_ARB_LOST;
> > +   arb_lost_cnt = cconr;
> > +   break;
> > +
> > +   case CDR2_CNF_NACK_ADDR:
> > +   tx_status = CEC_TX_STATUS_NACK;
> > +   nack_cnt = cconr;
> > +   break;
> > +
> > +   default: /* some other error, refer to TDA9950 docs */
> > +   dev_err(&priv->client->dev, "CNF reply error 0x%02x\n",
> > +   buf[2]);
> > +   tx_status = CEC_TX_STATUS_ERROR;
> > +   err_cnt = cconr;
> > +   break;
> > +   }
> > +   /* TDA9950 executes all retries for us */
> > +   tx_status |= CEC_TX_STATUS_MAX_RETRIES;
> > +   cec_transmit_done(priv->adap, tx_status, arb_lost_cnt,
> > + nack_cnt, 0, err_cnt);
> > +   break;
> > +
> > +   case CDR1_IND:
> > +   priv->rx_msg.len = buf[0] - 2;
> 
> Does the datasheet give any guarantees that buf[0] is always between 3 and 18?

"When reading, values are read starting at the register currently
addressed by the Address Pointer Register. The pointer auto-increments
after each read. If the host should read past register 19h, or read more
bytes than indicated by the FrameByteCount in register CDR[0] (address
07h), the value FFh will be returned.

...

Notes on reading the CEC Data Registers
• The CEC Data Registers only contain a valid message when the INT line
  is set and the INT bit in the TDA9950 Status Register is set.
• If CEC Data Registers are read when the INT line is not set, the first
  CEC Data Register will contain 0, indicating that there are no bytes
  to read. Any further reads before a STOP condition will return the
  value FFh.

...

The maximum length of a frame is 19 bytes."

> Note: it is possible for devices to send more than 16 bytes in a CEC message.
> Not allowed, mind you, but it can be done and I suspect some do in certain
> situations. So if the hardware just keeps counting you can get a rx_msg.len > 
> 16
> and then the memcpy below would overwrite memory. You want to clamp the length
> to max 16.

Clamping to 16 is probably a good idea in any case, and actually ends up
catching the case where buf[0] < 2 - since priv->rx_msg.len is unsigned,
it'll become a very large positive number in that case.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

[Russell King - ARM Linux]

On Mon, Dec 11, 2017 at 09:54:02PM +0100, Daniel Vetter wrote:
> On Fri, Dec 08, 2017 at 12:31:08PM +, Russell King wrote:
> > Add the defacto-standard "iturbt_709" property to the overlay plane to
> > control the YUV to RGB colorspace conversion.  This is mutually
> > exclusive with the CSC_YUV CRTC property - the last property to be set
> > determines the resulting colorspace conversion.
> > 
> > Signed-off-by: Russell King 
> 
> Can you pls provide a link to the corresponding userspace code using this?

http://git.armlinux.org.uk/cgit/xf86-video-armada.git/commit/?h=unstable-devel&id=7282633efd1c702a770b046505d7330fed028de0

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[Tony Lindgren]

* Tomi Valkeinen  [171201 02:03]:
> On 01/12/17 11:48, H. Nikolaus Schaller wrote:
> 
> > Just a note: there is no toppoly->tpo change for *this* panel and
> > Pandora board. Just omapdss removal.
> > 
> > The GTA04 needs a toppoly->tpo change but no omapdss, removal.
> > 
> > So they solve different problems and are independent of each other.
> > 
> > GTA04: change vendor string
> > Pandora: remove omapdss, prefix
> 
> Oh, right, I totally missed that. I thought they were changes to the
> same file...
> 
> In that case, Tony, can you pick this one as a fix? I'll pick the
> toppoly->tpo patch and merge via drm tree, if you give the ack.
> 
> For this:
> 
> Acked-by: Tomi Valkeinen 

Sorry I've lost track of this thread and what if anything is really
needed as a fix for v4.16. And now there's newer version of the two
dts patches in thread "[PATCH v4 0/2] Fixes for omapdrm on
OpenPandora and GTA04" so let's move the discussion there.

Regards,

Tony
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: mali-dp: Uninitialized variable in malidp_se_check_scaling()

[Mihail Atanassov]

On 09/12/17 11:46, Dan Carpenter wrote:


We use "mc" without initializing it if scaling is not necessary.

Fixes: 28ce675b7474 ("drm: mali-dp: Add plane upscaling support")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 33c5ef96ced0..82f9eaa5ee33 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -148,6 +148,8 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
if (!crtc_state)
return -EINVAL;
 
+	mc = to_malidp_crtc_state(crtc_state);

+
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip,
@@ -166,8 +168,6 @@ static int malidp_se_check_scaling(struct malidp_plane *mp,
if (mp->layer->id & (DE_SMART | DE_GRAPHICS2))
return -EINVAL;
 
-	mc = to_malidp_crtc_state(crtc_state);

-
mc->scaled_planes_mask |= mp->layer->id;
/* Defer scaling requirements calculation to the crtc check. */
return 0;




Reviewed-by: Mihail Atanassov 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/2] DTS: GTA04: improve panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller  [171201 07:44]:
> Official vendor string is now "tpo" and not "toppoly".
> 
> Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
> so that the driver understands both.

Tomi, so what's the plan with the dependency patch, is that for v4.16
or for the v4.15-rc cycle?

Regards,

Tony



> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..ec27ed67a22a 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -86,7 +86,7 @@
>  
>   /* lcd panel */
>   lcd: td028ttec1@0 {
> - compatible = "toppoly,td028ttec1";
> + compatible = "tpo,td028ttec1";
>   reg = <0>;
>   spi-max-frequency = <10>;
>   spi-cpol;
> -- 
> 2.12.2
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel