[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #20 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Did you power cycle your platform between attempts? 

By latest upstream you mean tip of the git devel? I did update to the last
release of Mesa, libdrm, llvm, xorg-amdgpu around two weeks ago.

Since there are many components involved, would be an option to send you a root
file system? Maybe we are hunting a bios or hw error.

Please be patient,I will be in the Embedded World the whole next week.

Thanks!

-- 
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 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

[bugzilla-daemon]

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

nixscrip...@gmail.com changed:

   What|Removed |Added

 Attachment #137519|0   |1
is obsolete||

--- Comment #8 from nixscrip...@gmail.com ---
Created attachment 137573
  --> https://bugs.freedesktop.org/attachment.cgi?id=137573&action=edit
clover debug imagemagick.cl

And finally (sorry for the e-mail spam) here is the .cl file.

Sidenote: the last file was gzip'd, because trying to attach it directly
resulted in a 500 Internal Server Error for some crazy reason... but that's a
bug for an entirely different tracker.

-- 
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 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

[bugzilla-daemon]

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

--- Comment #7 from nixscrip...@gmail.com ---
Created attachment 137572
  --> https://bugs.freedesktop.org/attachment.cgi?id=137572&action=edit
clover debug imagemagick.link-0.ll

My GPU is:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Juniper PRO [Radeon HD 6750]

(Which is an Evergreen chipset, if I remember correctly.)

And I am pretty sure ImageMagick does not have an OpenCL cache. For better or
worse, it has one giant blob of OpenCL, and re-compiles it when OpenCL is
enabled -- whether you actually use any of it or not. I did try deleting the
files, though, just in case.

-- 
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 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

[bugzilla-daemon]

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

--- Comment #6 from nixscrip...@gmail.com ---
Created attachment 137571
  --> https://bugs.freedesktop.org/attachment.cgi?id=137571&action=edit
clover debug imagemagick.ll

-- 
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 2/2] drm/ttm: cleanup ttm_tt_create

[He, Roger]

Series is:  Reviewed-by: Roger He 


-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Friday, February 23, 2018 8:25 PM
To: dri-devel@lists.freedesktop.org
Subject: [PATCH 2/2] drm/ttm: cleanup ttm_tt_create

Cleanup ttm_tt_create a bit.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index 
917942d03047..0ee3b8f11605 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -53,11 +53,9 @@
 int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc)  {
struct ttm_bo_device *bdev = bo->bdev;
-   int ret = 0;
uint32_t page_flags = 0;
 
reservation_object_assert_held(bo->resv);
-   bo->ttm = NULL;
 
if (bdev->need_dma32)
page_flags |= TTM_PAGE_FLAG_DMA32;
@@ -69,28 +67,27 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
case ttm_bo_type_device:
if (zero_alloc)
page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
+   break;
case ttm_bo_type_kernel:
-   bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << 
PAGE_SHIFT,
- page_flags);
-   if (unlikely(bo->ttm == NULL))
-   ret = -ENOMEM;
break;
case ttm_bo_type_sg:
-   bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << 
PAGE_SHIFT,
- page_flags | 
TTM_PAGE_FLAG_SG);
-   if (unlikely(bo->ttm == NULL)) {
-   ret = -ENOMEM;
-   break;
-   }
-   bo->ttm->sg = bo->sg;
+   page_flags |= TTM_PAGE_FLAG_SG;
break;
default:
+   bo->ttm = NULL;
pr_err("Illegal buffer object type\n");
-   ret = -EINVAL;
-   break;
+   return -EINVAL;
}
 
-   return ret;
+   bo->ttm = bdev->driver->ttm_tt_create(bdev, bo->num_pages << PAGE_SHIFT,
+ page_flags);
+   if (unlikely(bo->ttm == NULL))
+   return -ENOMEM;
+
+   if (bo->type == ttm_bo_type_sg)
+   bo->ttm->sg = bo->sg;
+
+   return 0;
 }
 
 /**
--
2.14.1

___
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

RE: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

[He, Roger]

I missed the Per-VM-BO share the reservation object with root bo. So context is 
not NULL here.
So,  this patch is:

Reviewed-by: Roger He 

Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Friday, February 23, 2018 8:06 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and 
swapout.

Am 23.02.2018 um 10:46 schrieb He, Roger:
>
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
> Behalf Of Christian K?nig
> Sent: Tuesday, February 20, 2018 8:58 PM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> linux-ker...@vger.kernel.org
> Subject: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and 
> swapout.
>
> This solves the problem that when we swapout a BO from a domain we sometimes 
> couldn't make room for it because holding the lock blocks all other BOs with 
> this reservation object.
>
> Signed-off-by: Christian König 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 33 -
>   1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> b/drivers/gpu/drm/ttm/ttm_bo.c index d90b1cf10b27..3a44c2ee4155 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -713,31 +713,30 @@ bool ttm_bo_eviction_valuable(struct 
> ttm_buffer_object *bo,  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>   
>   /**
> - * Check the target bo is allowable to be evicted or swapout, including 
> cases:
> - *
> - * a. if share same reservation object with ctx->resv, have 
> assumption
> - * reservation objects should already be locked, so not lock again 
> and
> - * return true directly when either the opreation 
> allow_reserved_eviction
> - * or the target bo already is in delayed free list;
> - *
> - * b. Otherwise, trylock it.
> + * Check if the target bo is allowed to be evicted or swapedout.
>*/
>   static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
> - struct ttm_operation_ctx *ctx, bool *locked)
> +struct ttm_operation_ctx *ctx,
> +bool *locked)
>   {
> - bool ret = false;
> + /* First check if we can lock it */
> + *locked = reservation_object_trylock(bo->resv);
> + if (*locked)
> + return true;
>   
> - *locked = false;
> + /* Check if it's locked because it is part of the current operation 
> +*/
>   if (bo->resv == ctx->resv) {
>   reservation_object_assert_held(bo->resv);
> - if (ctx->allow_reserved_eviction || !list_empty(&bo->ddestroy))
> - ret = true;
> - } else {
> - *locked = reservation_object_trylock(bo->resv);
> - ret = *locked;
> + return ctx->allow_reserved_eviction ||
> + !list_empty(&bo->ddestroy);
>   }
>   
> - return ret;
> + /* Check if it's locked because it was already evicted */
> + if (ww_mutex_is_owned_by(&bo->resv->lock, NULL))
> + return true;
>
> For the special case: when command submission with Per-VM-BO enabled, 
> All BOs  a/b/c are always valid BO. After the validation of BOs a and 
> b, when validation of BO c, is it possible to return true and then evict BO a 
> and b by mistake ?
> Because a/b/c share same task_struct.

No, that's why I check the context as well. BOs explicitly reserved 
have a non NULL context while BOs trylocked for swapout havea NULL 
context.

BOs have a non NULL context only when command submission and reserved 
by ttm_eu_re6serve_buffers  .
But for Per-VM-BO a/b/c they always are not in BO list, so they will be 
not reserved and have always NULL context.
So above case also can happen. Anything missing here?  

>
> + /* Some other thread is using it, don't touch it */
> + return false;
>   }
>   
>   static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> --
> 2.14.1
>
> ___
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[radeon-alex:amd-staging-drm-next 85/495] sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of function 'devm_ioremap'; did you mean 'of_ioremap'?

[kbuild test robot]

Hi Maruthi,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   82beba2883b2556ce896b08cb4dde76383192484
commit: 4ab7d004f9ff2e877caa267887360e1804b4edcf [85/495] ASoC: AMD: enable 
ACP3x drivers build
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4ab7d004f9ff2e877caa267887360e1804b4edcf
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
   sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
   sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 
'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
 return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
   sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
   sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function 
'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
 writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
 ^~
 vwrite
   sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of 
>> function 'devm_ioremap'; did you mean 'of_ioremap'? 
>> [-Werror=implicit-function-declaration]
 adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
 ^~~~
 of_ioremap
   sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
 adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
   ^
   cc1: some warnings being treated as errors

vim +638 sound/soc/amd/raven/acp3x-pcm-dma.c

023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  616  
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  617  static int 
acp3x_audio_probe(struct platform_device *pdev)
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  618  {
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  619   int status;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  620   struct resource *res;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  621   struct i2s_dev_data 
*adata;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  622   unsigned int irqflags;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  623  
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  624   if 
(pdev->dev.platform_data == NULL) {
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  625   
dev_err(&pdev->dev, "platform_data not retrieved\n");
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  626   return -ENODEV;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  627   }
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  628   irqflags = *((unsigned 
int *)(pdev->dev.platform_data));
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  629  
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  630   adata = 
devm_kzalloc(&pdev->dev, sizeof(struct i2s_dev_data),
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  631   
GFP_KERNEL);
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  632   res = 
platform_get_resource(pdev, IORESOURCE_MEM, 0);
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  633   if (!res) {
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  634   
dev_err(&pdev->dev, "IORESOURCE_IRQ FAILED\n");
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  635   return 
-ENODEV;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  636   }
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  637  
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 @638   adata->acp3x_base = 
devm_ioremap(&pdev->dev, res->start,
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  639   
resource_size(res));
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  640  
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  641   res = 
platform_get_resource(pdev, IORESOURCE_IRQ, 0);
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  642   if (!res) {
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  643   
dev_err(&pdev->dev, "IORESOURCE_IRQ FAILED\n");
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  644   return -ENODEV;
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  645   }
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  646  
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30  647   adata->i2s_irq = 
res->start;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  648   adata->play_stream = 
NULL;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  649   adata->capture_stream = 
NULL;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29  650  
023ab7b3 Maruthi Srinivas Bayyavarapu 2017

RE: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and swapout.

[He, Roger]

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Friday, February 23, 2018 8:06 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and 
swapout.

Am 23.02.2018 um 10:46 schrieb He, Roger:
>
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
> Behalf Of Christian K?nig
> Sent: Tuesday, February 20, 2018 8:58 PM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> linux-ker...@vger.kernel.org
> Subject: [PATCH 3/4] drm/ttm: handle already locked BOs during eviction and 
> swapout.
>
> This solves the problem that when we swapout a BO from a domain we sometimes 
> couldn't make room for it because holding the lock blocks all other BOs with 
> this reservation object.
>
> Signed-off-by: Christian König 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c | 33 -
>   1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
> b/drivers/gpu/drm/ttm/ttm_bo.c index d90b1cf10b27..3a44c2ee4155 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -713,31 +713,30 @@ bool ttm_bo_eviction_valuable(struct 
> ttm_buffer_object *bo,  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>   
>   /**
> - * Check the target bo is allowable to be evicted or swapout, including 
> cases:
> - *
> - * a. if share same reservation object with ctx->resv, have 
> assumption
> - * reservation objects should already be locked, so not lock again 
> and
> - * return true directly when either the opreation 
> allow_reserved_eviction
> - * or the target bo already is in delayed free list;
> - *
> - * b. Otherwise, trylock it.
> + * Check if the target bo is allowed to be evicted or swapedout.
>*/
>   static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
> - struct ttm_operation_ctx *ctx, bool *locked)
> +struct ttm_operation_ctx *ctx,
> +bool *locked)
>   {
> - bool ret = false;
> + /* First check if we can lock it */
> + *locked = reservation_object_trylock(bo->resv);
> + if (*locked)
> + return true;
>   
> - *locked = false;
> + /* Check if it's locked because it is part of the current operation 
> +*/
>   if (bo->resv == ctx->resv) {
>   reservation_object_assert_held(bo->resv);
> - if (ctx->allow_reserved_eviction || !list_empty(&bo->ddestroy))
> - ret = true;
> - } else {
> - *locked = reservation_object_trylock(bo->resv);
> - ret = *locked;
> + return ctx->allow_reserved_eviction ||
> + !list_empty(&bo->ddestroy);
>   }
>   
> - return ret;
> + /* Check if it's locked because it was already evicted */
> + if (ww_mutex_is_owned_by(&bo->resv->lock, NULL))
> + return true;
>
> For the special case: when command submission with Per-VM-BO enabled, 
> All BOs  a/b/c are always valid BO. After the validation of BOs a and 
> b, when validation of BO c, is it possible to return true and then evict BO a 
> and b by mistake ?
> Because a/b/c share same task_struct.

No, that's why I check the context as well. BOs explicitly reserved 
have a non NULL context while BOs trylocked for swapout have a NULL context.

When BOs have a non NULL context only when command submission and reserved by 
ttm_eu_re6serve_buffers  .
But for Per-VM-BO a/b/c they always are not in BO list, so they will be not 
reserved and have always NULL context.
So above case also can happen. Anything missing here?  

Thanks
Roger(Hongbo.He)
>
> + /* Some other thread is using it, don't touch it */
> + return false;
>   }
>   
>   static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
> --
> 2.14.1
>
> ___
> 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

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #13 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Is there something that plain AMDGPU is doing that Display Core isn't, perhaps?
Is there a way to find what the difference could be?

-- 
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

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Jason Ekstrand]

On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard  wrote:

> Jason Ekstrand  writes:
>
> > I think I like option 1 (KEITHP_kms_display).  If the client knows the
> > difference between render and primary for 2, then they are most likely
> > already opening the master node themselves or at least have access to
> > the FD.
>
> Ok, I'll work on cleaning up that extension and renaming it. I have no
> idea how to get new words into the Vulkan spec, but it would be good to
> have that done too.
>

Once we're sure that's what we want, create an MR against the spec that
just adds enough to the XML to reserve your extension number.  That will
get merged almost immediately.  Then make a second one with the actual
extension text and we'll iterate on that either in Khronos gitlab or, if
you prefer, you can send it as a patch to mesa-dev and then make a Khrons
MR once it's baked.


> I guess the question is whether I should bother to leave the current
> try-to-open-primary kludge in place. In good news, under X, both radv
> and anv "fail" to use the primary device as another master is already
> running, so at least we aren't running with a primary FD open?
>

See also my comments about GEM handle ownership.


> > Sorry, I'm just not feeling all that opinionated about this at the
> moment.
> > :-)
>
> No more than I; either way is fine with me, if you're happy to use
> something like the existing code I've got, that's even nicer.
>
> > Clearly, we need systemd-edidd. :-)
>
> A library would be nice; we have the edid data everywhere, we just don't
> have it in a useful form except inside the X server and kernel.
>

Yeah, in the scary new world of Wayland compositors, having an edid library
would be a very good thing.  No sense in having everyone fail to handle it
properly themselves.


> > Yes, *if* it has a preferred resolution, we should return that one.  If
> it
> > doesn't, we should walk the list and return the largest instead of just
> > defaulting to 1024x768.  At least that's what the spec seems to say to
> > me.
>
> Oh. I totally missed that part. Yeah, that's just wrong. I've just
> pushed a patch that finds the largest mode when there isn't a preferred
> one. Oddly, I have no devices here which don't specify a preferred mode,
> so it will be somewhat difficult to test...
>
> > Yup.  Let's just drop INHERIT and only advertise OPAQUE.
>
> Done.
>
> I've updated my drm-lease branch with all of these changes merged into
> the existing patches (and so noted), plus the new patch described above
> which looks for the largest mode when no preferred mode is specified.
>
> Thanks again for all of your careful review; while we haven't changed
> any significant semantics, we have found a bunch of outright bugs in the
> code.
>

Glad to help. :-)  I figure I should learn something about KMS one day and
reviewing this is as good an opportunity as any.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/21] vulkan: Add KHR_display extension using DRM

[Jason Ekstrand]

Continuing on the new version of the patch...

On Tue, Feb 13, 2018 at 4:31 PM, Keith Packard  wrote:

> +enum wsi_image_state {
> +   wsi_image_idle,
> +   wsi_image_drawing,
> +   wsi_image_queued,
> +   wsi_image_flipping,
> +   wsi_image_displaying
> +};
>

With the exception of NIR (which is a bit odd), we usually use ALL_CAPS for
enum values.


> +
> +static const VkPresentModeKHR available_present_modes[] = {
> +   VK_PRESENT_MODE_FIFO_KHR,
>

Yes, this does seem like the only reasonable mode for now.  I suppose you
could check to see if the platform supports ASYNC_FLIP and advertise
IMMEDIATE in that case.  I know intel doesn't advertise it but I thought
amdgpu does.


> +};
> +
> +static VkResult
> +wsi_display_surface_get_present_modes(VkIcdSurfaceBase  *surface,
> +  uint32_t
> *present_mode_count,
> +  VkPresentModeKHR  *present_modes)
> +{
> +   if (present_modes == NULL) {
> +  *present_mode_count = ARRAY_SIZE(available_present_modes);
> +  return VK_SUCCESS;
> +   }
> +
> +   *present_mode_count = MIN2(*present_mode_count,
> ARRAY_SIZE(available_present_modes));
> +   typed_memcpy(present_modes, available_present_modes,
> *present_mode_count);
> +
> +   if (*present_mode_count < ARRAY_SIZE(available_present_modes))
> +  return VK_INCOMPLETE;
> +   return VK_SUCCESS;
>

vk_outarray, though I suppose you've probably already made that change.


> +}
> +
> +static VkResult
> +wsi_display_image_init(VkDevice device_h,
> +   struct wsi_swapchain *drv_chain,
> +   const VkSwapchainCreateInfoKHR   *create_info,
> +   const VkAllocationCallbacks  *allocator,
> +   struct wsi_display_image *image)
> +{
> +   struct wsi_display_swapchain *chain = (struct wsi_display_swapchain *)
> drv_chain;
> +   struct wsi_display   *wsi = chain->wsi;
> +   VkResult result;
> +   int  ret;
> +   uint32_t image_handle;
> +
> +   if (chain->base.use_prime_blit)
> +  result = wsi_create_prime_image(&chain->base, create_info,
> &image->base);
>

I don't see use_prime_blit being set anywhere.  Perhaps that comes in a
later patch?  The line is obviously correct, so I'm fine with leaving it.


> +   else
> +  result = wsi_create_native_image(&chain->base, create_info,
> &image->base);
>

This will have to be updated for modifiers.  I'm reasonably happy for it to
be the no-op update for now though KHR_display supporting real modifiers
would be nice. :-)


> +   if (result != VK_SUCCESS)
> +  return result;
> +
> +   ret = drmPrimeFDToHandle(wsi->master_fd, image->base.fd,
> &image_handle);
>

This opens up some interesting questions.  GEM handles are not reference
counted by the kernel.  If the driver that we're running on is using
master_fd, then we shouldn't close our handle because that would close the
handle for the driver as well.  If it's not using master_fd, we should
close the handle to avoid leaking it.  The later is only a worry in the
prime case but given that I saw a line above about use_prime_blit, you have
me scared. :-)

One solution to this connundrum would be to simply never use the master FD
for the Vulkan driver itself and always open a render node.  If handed a
master FD, you could check if it matches your render node and set
use_prime_blit accordingly.  Then the driver and WSI would have separate
handle domains and this problem would be solved.  You could also just open
the master FD twice, once for WSI and once for the driver.


> +
> +   close(image->base.fd);
> +   image->base.fd = -1;
> +
> +   if (ret < 0)
> +  goto fail_handle;
> +
> +   image->chain = chain;
> +   image->state = wsi_image_idle;
> +   image->fb_id = 0;
> +
> +   /* XXX extract depth and bpp from image somehow */
>

You have the format in create_info.  We could add some generic VkFormat
introspection or we can just handle the 2-4 cases we care about directly.


> +   ret = drmModeAddFB(wsi->master_fd, create_info->imageExtent.width,
> create_info->imageExtent.height,
> +  24, 32, image->base.row_pitch, image_handle,
> &image->fb_id);
>

What happens if we close the handle immediately after calling
drmModeAddFB?  Does the FB become invalid?  If so, then we probably want to
stash the handle so we can clean it up when we destroy the swapchain.
Unless, of course, we're willing to make the assumption (as stated above)
that the driver and WSI are always using the same FD.


> +
> +   if (ret)
> +  goto fail_fb;
> +
> +   return VK_SUCCESS;
> +
> +fail_fb:
> +   /* fall through */
> +
> +fail_handle:
> +   wsi_destroy_image(&chain->base, &image->base);
> +
> +   return VK_ERROR_OUT_OF_HOST_MEMORY;
> +}
> +
> +static void
> +wsi_display_image_finish(struct wsi_swapchain   *drv_chain,
> + con

Re: [PATCH 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Keith Packard]

Jason Ekstrand  writes:

> I think I like option 1 (KEITHP_kms_display).  If the client knows the
> difference between render and primary for 2, then they are most likely
> already opening the master node themselves or at least have access to
> the FD.

Ok, I'll work on cleaning up that extension and renaming it. I have no
idea how to get new words into the Vulkan spec, but it would be good to
have that done too.

I guess the question is whether I should bother to leave the current
try-to-open-primary kludge in place. In good news, under X, both radv
and anv "fail" to use the primary device as another master is already
running, so at least we aren't running with a primary FD open?

> Sorry, I'm just not feeling all that opinionated about this at the moment.
> :-)

No more than I; either way is fine with me, if you're happy to use
something like the existing code I've got, that's even nicer.

> Clearly, we need systemd-edidd. :-)

A library would be nice; we have the edid data everywhere, we just don't
have it in a useful form except inside the X server and kernel.

> Yes, *if* it has a preferred resolution, we should return that one.  If it
> doesn't, we should walk the list and return the largest instead of just
> defaulting to 1024x768.  At least that's what the spec seems to say to
> me.

Oh. I totally missed that part. Yeah, that's just wrong. I've just
pushed a patch that finds the largest mode when there isn't a preferred
one. Oddly, I have no devices here which don't specify a preferred mode,
so it will be somewhat difficult to test...

> Yup.  Let's just drop INHERIT and only advertise OPAQUE.

Done.

I've updated my drm-lease branch with all of these changes merged into
the existing patches (and so noted), plus the new patch described above
which looks for the largest mode when no preferred mode is specified.

Thanks again for all of your careful review; while we haven't changed
any significant semantics, we have found a bunch of outright bugs in the
code.

-- 
-keith


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

[Bug 101475] Max Core Profile for OpenGL showing 0.0

[bugzilla-daemon]

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

vinf...@gmail.com 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

[Bug 101475] Max Core Profile for OpenGL showing 0.0

[bugzilla-daemon]

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

--- Comment #16 from vinf...@gmail.com ---
OK, it worked now. Using --enable-texture-float now returns a version Max core
profile version of 3.3. Don't know why it didn't work before, but it is working
now. Thank you for all the help.

-- 
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: [v2,03/10] drm/sun4i: Protect the TCON pixel clocks

[Giulio Benetti]

Il 21/02/2018 10:20, Maxime Ripard ha scritto:

From: Maxime Ripard 

Both TCON clocks are very sensitive to clock changes, since any change
might lead to improper timings.

Make sure our rate is never changed.

Signed-off-by: Maxime Ripard 

Tested-by: Giulio Benetti 

Tested on A20-LiNova1-4_3i-ctp with Mali r6p2 installed.
Before Mali changed dotclock, now it doesn't anymore.


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

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b73acab74867..cbe87cee13d1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -261,7 +261,7 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon 
*tcon,
const struct drm_display_mode *mode)
  {
/* Configure the dot clock */
-   clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
+   clk_set_rate_exclusive(tcon->dclk, mode->crtc_clock * 1000);
  
  	/* Set the resolution */

regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
@@ -419,7 +419,7 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
WARN_ON(!tcon->quirks->has_channel_1);
  
  	/* Configure the dot clock */

-   clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
+   clk_set_rate_exclusive(tcon->sclk1, mode->crtc_clock * 1000);
  
  	/* Adjust clock delay */

clk_delay = sun4i_tcon_get_clk_delay(mode, 1);


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

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

--- Comment #20 from Ainola  ---
I've been using this patchset on linux 4.15.3 and 4.14.4 and haven't had a
problem since.

-- 
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 101475] Max Core Profile for OpenGL showing 0.0

[bugzilla-daemon]

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

--- Comment #15 from Ilia Mirkin  ---
You appear to be missing GL_ARB_texture_float, which in turn means you won't
get GL 3.0.

This happens when you haven't built mesa with --enable-texture-float, as you
were told earlier.

How sure are you that you've done this?

-- 
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 101475] Max Core Profile for OpenGL showing 0.0

[bugzilla-daemon]

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

--- Comment #14 from vinf...@gmail.com ---
Created attachment 137569
  --> https://bugs.freedesktop.org/attachment.cgi?id=137569&action=edit
Full output of glxinfo

Here's the full output.

-- 
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 1/7] vulkan: Add KHR_display extension to anv and radv using DRM

[Jason Ekstrand]

On Thu, Feb 15, 2018 at 9:46 AM, Keith Packard  wrote:

> Jason Ekstrand  writes:
>
> > It seems a little odd to me to default to opening the master node and
> then
> > fall back to the render node if it doesn't work.  I suppose that's
> probably
> > ok so long as we ensure that vkGetPhysicalDeviceDisplayPropertiesKHR
> > returns no displays if we're on the render node.
> >
> > We could always go back to the DRM fd extension idea but I'm not coming
> up
> > with something nice and clean in the 60 seconds I've thought about it.
>
> As I said in the last comments about this section, Dave Airlie and I
> added this code only recently so that we could test this extension
> without also needing the kernel and X leasing changes.
>
> I think we should decide how to enable this functionality "for real",
> and I have two easy options:
>
>  1) Use my KEITHP_kms_display extension (presumably renamed MESA), which
> exposes a way to pass the DRM fd from the application into the
> driver. This makes it possible for the application to get the FD
> through any mechanism at all (including RandR or the new Wayland
> extension) and leave that out of the Vulkan code entirely.
>
>  2) Add a new extension which passes a new data structure that directs
> the driver to open either the Render or Primary nodes.
>
> When this is done, we can switch from the current code which tries to
> open the Primary node whenever the KHR_display extension is requested.
>

I think I like option 1.  If the client knows the difference between render
and primary for 2, then they are most likely already opening the master
node themselves or at least have access to the FD.

For an application that just wants to draw some stuff on the screen and is
ok with letting Vulkan fully handle KMS for it, the current code may be a
fine solution.

Sorry, I'm just not feeling all that opinionated about this at the moment.
:-)


> > Would it make anything easier if we just storred the DRM struct here?
> "No"
> > is a perfectly valid answer.
>
> Nope -- once we add the acquire_xlib extension, we get modes through
> either X or DRM, depending on whether we're pre-lease or post-lease.
>

Sounds good.


> > Any particular reason why the list of modes is global and not in the
> > connector?  It seems like it would be a tiny bit more efficient and
> > convenient to put the list in the connector.
>
> I think you're right. I have some vague memory of a lifetime issue with
> connectors, but can't think of what it might be, even after reviewing
> the relevant parts of the Vulkan spec. I've gone ahead and changed it;
> seems to work fine.
>
> >> +   LIST_FOR_EACH_ENTRY(display_mode, &wsi->display_modes, list)
> >> +  if (display_mode->connector == connector)
> >> + display_mode->valid = false;
> >>
> >
> > Please use braces for loops containing more than one line.
>
> Well, that was easy to fix -- the condition is now gone :-)
>

Even better!


> > Since we're allocating these in a physical device query, we need to use
> the
> > INSTANCE scope.  the OBJECT scope is intended for vkCreate functions to
> > allocated data that will live no longer than the associated vkDestroy
> > function.
>
> Thanks! The whole Vulkan memory model remains a mystery to me.
>
> I've changed allocation of wsi_display_mode and wsi_display_connector to
> use SCOPE_INSTANCE. VkIceSurfaceDisplay, wsi_display_fence and
> wsi_display_swapchain remain using SCOPE_OBJECT.
>

That sounds correct to me.


> I've also changed *all* instances of vk_alloc to use
> vk_zalloc. These are all small data structures allocated only during
> application startup, so I think the benefit of known memory contents is
> worth the cost of memset.
>
> > Hooray for obviously false fixed constants!
> >
> > I know the answer to this will be "EDIDs lie, never trust them!" but can
> we
> > get the real value somehow?  As someone who has a 13" laptop with a
> > 3200x1800 display, I know that number isn't always right. :-)
>
> Yes, we could dig the real value out of the EDID, but we'd have to parse
> the entire EDID to manage that. I don't want to stick an EDID parser
> directly in Mesa, so I'm kinda waiting for someone to create a separate
> EDID parsing library that the X server, Mesa and others can share. Until
> then, I'd prefer to just lie here.
>

Clearly, we need systemd-edidd. :-)


> > double-;;
>
> Thx. I remember seeing this while reviewing patches and forgot all about
> it...
>
> > From the Vulkan spec:
> >
> > Note:
> > For devices which have no natural value to return here,
> implementations
> > *should* return the maximum resolution supported.
> >
> > We should walk the list and pick the biggest one.
>
> I did this intentionally -- most monitors have a preferred resolution,
> which is their native pixel size. And, we want to tell applications to
> use that size, even if the monitor offers a larger (presumabl scaled)
> resolution in their mode list.
>

Yes, *if* it has a preferred r

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #19 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
I tried on my Ubuntu multiple times with both starting and stopping desktop
manager and just xinint. Didn't observe any hang, 

this is relevant SW info from my glxinfo

OenGL renderer string: AMD Radeon R7 Graphics (CARRIZO / DRM 3.25.0 /
4.15.0-rc4.main+, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel
(git-b494ed168c)

So I have same kernel as you but use LLVM 7 while you have LLVM 5. 
We also differ in MESA and probably libdrm.

I wonder if you can try update you MESA and libdrm to latest upstream and try
switch to  LLVM 7 ?

Thanks,
Andrey

-- 
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 101475] Max Core Profile for OpenGL showing 0.0

[bugzilla-daemon]

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

--- Comment #13 from Emil Velikov  ---
vinf...@gmail.com instead of pasting multiple partial copies of the output,
simply attach (as plain text) the complete thing - glxinfo &> glxinfo-output

There are multiple things that can go wrong and most can be deducted from ^^
info.

Note: MESA_GL_VERSION_OVERRIDE is more of a hack. In 90%+ of the cases you
should not be touching it.

Also, please stop fiddling with the bug severity. Thanks

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #18 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Ricardo Ribalda from comment #17)
> -able to login remotely via ssh.
> 
> -I tried to reset the gpu by using /sys/kernel/debug/dri/0/amdgpu_gpu_reset,
> and the result is a NULL pointer dereference in the kernel. (I did that and
> had almost the same result)

That could happen with any GPU hang, no matter what caused it.


> This is definitely out of my expertise :), I just dont want to waste 2x
> developers time.

Then it's better to assume for the time being that they're separate issues.

-- 
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 105213] [SUMO][TURKS] Alien: Isolation rendering artifacts

[bugzilla-daemon]

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

russianneuroman...@ya.ru changed:

   What|Removed |Added

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

--- Comment #5 from russianneuroman...@ya.ru ---
I retested game on Mesa build 4562a7b0e82bf664, this time with
"MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430 %command%" launch
option in Steam settings - issue is no longer reproducible.

-- 
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 v6 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

Hi Frank,

On Friday, 23 February 2018 21:43:17 EET Frank Rowand wrote:
> On 02/23/18 01:00, Laurent Pinchart wrote:
> > On Friday, 23 February 2018 04:38:06 EET Frank Rowand wrote:
> >> On 02/22/18 14:10, Frank Rowand wrote:
> >>> Hi Laurent, Rob,
> >>> 
> >>> Thanks for the prompt spin to address my concerns.  There are some small
> >>> technical issues.
> >>> 
> >>> I did not read the v3 patch until today.  v3 through v6 are still using
> >>> the old overlay apply method which uses an expanded device tree as
> >>> input.
> >>> 
> >>> Rob, I don't see my overlay patches in you for-next branch, and I have
> >>> not seen an "Applied" message from you.  What is the status of the
> >>> overlay patches?
> >>> 
> >>> Comments in the patch below.
> >>> 
> >>> On 02/22/18 05:13, Laurent Pinchart wrote:
>  The internal LVDS encoders now have their own DT bindings. Before
>  switching the driver infrastructure to those new bindings, implement
>  backward-compatibility through live DT patching.
>  
>  Patching is disabled and will be enabled along with support for the new
>  DT bindings in the DU driver.
>  
>  Signed-off-by: Laurent Pinchart
>  
>  ---
>  Changes since v5:
>  
>  - Use a private copy of rcar_du_of_changeset_add_property()
>  
>  Changes since v3:
>  
>  - Use the OF changeset API
>  - Use of_graph_get_endpoint_by_regs()
>  - Replace hardcoded constants by sizeof()
>  
>  Changes since v2:
>  
>  - Update the SPDX headers to use C-style comments in header files
>  - Removed the manually created __local_fixups__ node
>  - Perform manual fixups on live DT instead of overlay
>  
>  Changes since v1:
>  
>  - Select OF_FLATTREE
>  - Compile LVDS DT bindings patch code when DRM_RCAR_LVDS is selected
>  - Update the SPDX headers to use GPL-2.0 instead of GPL-2.0-only
>  - Turn __dtb_rcar_du_of_lvds_(begin|end) from u8 to char
>  - Pass void begin and end pointers to rcar_du_of_get_overlay()
>  - Use of_get_parent() instead of accessing the parent pointer directly
>  - Find the LVDS endpoints nodes based on the LVDS node instead of the
>    root of the overlay
>  - Update to the -lvds compatible string format
>  ---
>  
>   drivers/gpu/drm/rcar-du/Kconfig|   2 +
>   drivers/gpu/drm/rcar-du/Makefile   |   7 +-
>   drivers/gpu/drm/rcar-du/rcar_du_of.c   | 342 +
>   drivers/gpu/drm/rcar-du/rcar_du_of.h   |  20 ++
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts|  79 +
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts|  53 
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts|  53 
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts|  53 
>   .../gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts|  53 
>   9 files changed, 661 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dts
>   create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dts
>  
>  diff --git a/drivers/gpu/drm/rcar-du/Kconfig
>  b/drivers/gpu/drm/rcar-du/Kconfig index 5d0b4b7119af..3f83352a7313
>  100644
>  --- a/drivers/gpu/drm/rcar-du/Kconfig
>  +++ b/drivers/gpu/drm/rcar-du/Kconfig
> >> 
> >> < snip >
> >> 
> >>> becomes:
> >>>   ret = of_overlay_fdt_apply(dtb->begin, &ovcs_id);
> >>> 
> >>> If my overlay patches do not exist, there are other small errors
> >>> in the code block above.  I'll ignore them for the moment.

If you have time to not ignore them I'd appreciate your comments :-) I'd like 
to get this patch series merged in v4.17, and for that I want to be prepared 
to submit it on top of your overlay patches if they make it to mainline, or 
without them if they don't.

> >>> A quick scan of the rest of the code looks OK.  I'll read through it
> >>> more carefully, but wanted to get this reply out without further
> >>> delay.
> >> 
> >> < snip >
> >> 
> >> I was hoping to be able to convert the .dts files to use sugar syntax
> >> instead of hand coding the fragment nodes, but for this specific set
> >> of files I failed, since the labels that would have been required do
> >> not already exist in the base .dts files that that overlays would be
> >> applied against.
> > 
> > And even if they existed in the base .dts in the kernel sources, there's
> > no guarantee that the .dtb on the systems we want to patch would contain
> > symbol, so that wouldn't have been an option anyway, would 

[pull] radeon, amdgpu, ttm drm-next-4.17

[Alex Deucher]

Hi Dave,

First pull for 4.17.  Highlights:
- Expose thermal thresholds through hwmon properly
- Rework HDP flushing for rings and CPU
- Improved dual-link DVI handling in DC
- Lots of code clean up
- Additional DC clean up
- Allow scanout from system memory on CZ/BR/ST
- Improved PASID/VM integration
- Expose GPU voltage and power via hwmon
- Initial wattman-like support
- Initial power profiles for use-case optimized performance
- Rework GPUVM TLB flushing
- Rework IP offset handling for SOC15 asics
- Add CRC support in DC
- Fixes for mmhub powergating
- Initial regamma/degamma/CTM support in DC
- ttm cleanups and simplifications
- ttm OOM avoidance fixes

The following changes since commit 933519a5a269d8460450545adefcb5caec622cac:

  Merge tag 'topic/hdcp-2018-02-13' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-02-16 09:36:04 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.17

for you to fetch changes up to 9aff8b2ae71dcf7f02443821a894a736f40e4919:

  Revert "drm/radeon/pm: autoswitch power state when in balanced mode" 
(2018-02-20 16:27:16 -0500)


Alex Deucher (29):
  drm/amd/powerplay: export thermal range through temp sysfs
  drm/amdgpu: add new asic callbacks for HDP flush/invalidation
  drm/amdgpu: add HDP asic callbacks for SI
  drm/amdgpu: add HDP asic callbacks for CIK
  drm/amdgpu: add HDP asic callbacks for VI
  drm/amdgpu: add HDP asic callbacks for SOC15 (v2)
  drm/amdgpu: adjust HDP write queue flushing for tlb invalidation
  drm/amdgpu: drop extra tlb invalidation in gpuvm
  drm/amdgpu: only allow scatter/gather display with DC
  drm/amdgpu/powerplay/vega10: fix compute profile name
  drm/amdgpu: drop the drm irq pre/post/un install callbacks
  drm/amdgpu/psp: use a function pointer structure
  drm/amdgpu/soc15: don't abuse IP soft reset for adapter reset
  drm/amdgpu/pm: handle fan properly when card is powered down
  drm/amdgpu/pm: report gpu voltages via hwmon API
  drm/amdgpu/pm: report gpu average power via hwmon API
  drm/amdgpu/pm: use read_sensor API to get temperature
  drm/amdgpu/pp: remove the get_temperature API
  drm/amdgpu/pm: rework the hwmon visibility settings
  drm/amdgpu: remove DC special casing for KB/ML
  drm/amdgpu: set DRIVER_ATOMIC flag early
  drm/amdgpu/dce: fix mask in dce_v*_0_is_in_vblank
  drm/amdgpu: remove unused display_vblank_wait interface
  drm/amd/powerplay: use PP_CAP macro for 
disable_mclk_switching_for_frame_lock
  drm/amd/powerplay/vega10: allow mclk switching with no displays
  drm/amd/powerplay/smu7: allow mclk switching with no displays
  drm/amdgpu/cgs: add refresh rate checking to non-DC display code
  drm/amdgpu/powerplay/smu7: drop refresh rate checks for mclk switching
  Revert "drm/radeon/pm: autoswitch power state when in balanced mode"

Andres Rodriguez (2):
  drm/amdgpu: add high priority compute support for gfx9
  drm/amdgpu: bump version for gfx9 high priority compute

Andrew Jiang (1):
  drm/amd/display: Fix check for setting input TF

Andrey Grodzovsky (5):
  drm/ttm: Allow page allocations w/o triggering OOM..
  drm/amdgpu: Use new TTM flag to avoid OOM triggering.
  drm/amd/display: Remove unsued mutex and spinlock.
  drm/amd/display: Remove timer handler.
  Revert "drm/amdgpu/gfx8: Fix compute ring failure after resetting"

Anthony Koo (1):
  drm/amd/display: provide an interface to query firmware version

Arnd Bergmann (1):
  drm/amd/display: fix incompatible structure layouts

Arun Pandey (1):
  drm/amd/display: Define dpp1_set_cursor_position in header

Bas Nieuwenhuizen (1):
  drm/amdgpu: Fix always_valid bos multiple LRU insertions.

Charlene Liu (13):
  drm/amd/display: PME sw wa to support waking AZ D3
  drm/amd/display: disablePSR in UpdatePlanes in PassiveLevel
  drm/amd/display: fix backlight not off at resume from S4
  drm/amd/display: disable az_clock_gating for endpoint register access only
  drm/amd/display: dpms off mute az audio endpoint only.
  drm/amd/display: eDP sequence BL off first then DP blank.
  drm/amd/display: BL setting save/restore
  drm/amd/display: wait for T9 after backlight off mainlink blank.
  drm/amd/display: add eDP 1.2+ polling for T7
  drm/amd/display: resume from S3 bypass power down HW block.
  drm/amd/display: enable #PME code path for RV.
  drm/amd/display: boot up/S4 fix mainlink off before BL.
  drm/amd/display: add force_trigger even to static screen control

Christian König (78):
  drm/amdgpu: allow framebuffer in GART memory as well
  drm/amdgpu: rename pas_id to pasid
  drm/amdgpu: print the PASID with VM faults on GMC v7
  drm/amdgpu: print the PASID with VM faults on GMC v8
  drm/amdgpu: remove agp_base
  

[PATCH 2/6] drm: Remove now pointelss blob->data casts

[Ville Syrjala]

From: Ville Syrjälä 

Now that blob->data is void* again we don't need the casts anymore.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c| 3 +--
 drivers/gpu/drm/drm_atomic_helper.c | 2 +-
 drivers/gpu/drm/drm_edid.c  | 3 +--
 drivers/gpu/drm/drm_fb_helper.c | 2 +-
 drivers/gpu/drm/drm_plane.c | 2 +-
 5 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46733d534587..8945357212ba 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -391,8 +391,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state 
*state,
if (blob) {
if (blob->length != sizeof(struct drm_mode_modeinfo) ||
drm_mode_convert_umode(state->crtc->dev, &state->mode,
-  (const struct drm_mode_modeinfo *)
-   blob->data))
+  blob->data))
return -EINVAL;
 
state->mode_blob = drm_property_blob_get(blob);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ae3cbfe9e01c..6211a1b20405 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3816,7 +3816,7 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
}
 
/* Prepare GAMMA_LUT with the legacy values. */
-   blob_data = (struct drm_color_lut *) blob->data;
+   blob_data = blob->data;
for (i = 0; i < size; i++) {
blob_data[i].red = red[i];
blob_data[i].green = green[i];
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 788fee4b4bf9..134069f36482 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1575,8 +1575,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
struct edid *override = NULL;
 
if (connector->override_edid)
-   override = drm_edid_duplicate((const struct edid *)
- connector->edid_blob_ptr->data);
+   override = drm_edid_duplicate(connector->edid_blob_ptr->data);
 
if (!override)
override = drm_load_edid_firmware(connector);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 035784ddd133..0646b108030b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1351,7 +1351,7 @@ static struct drm_property_blob 
*setcmap_new_gamma_lut(struct drm_crtc *crtc,
if (IS_ERR(gamma_lut))
return gamma_lut;
 
-   lut = (struct drm_color_lut *)gamma_lut->data;
+   lut = gamma_lut->data;
if (cmap->start || cmap->len != size) {
u16 *r = crtc->gamma_store;
u16 *g = r + crtc->gamma_size;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 09de6ecb3968..9851616cf0f3 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -104,7 +104,7 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
if (IS_ERR(blob))
return -1;
 
-   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data = blob->data;
blob_data->version = FORMAT_BLOB_CURRENT;
blob_data->count_formats = plane->format_count;
blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
-- 
2.13.6

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

[PATCH 3/6] drm: Verify gamma/degamma LUT size

[Ville Syrjala]

From: Ville Syrjälä 

While we want to potentially support multiple different gamma/degamma
LUT sizes we can (and should) at least check that the blob length
is a multiple of the LUT entry size.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8945357212ba..933edec0299d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
 struct drm_property_blob **blob,
 uint64_t blob_id,
 ssize_t expected_size,
+ssize_t expected_size_mod,
 bool *replaced)
 {
struct drm_property_blob *new_blob = NULL;
@@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
if (new_blob == NULL)
return -EINVAL;
 
-   if (expected_size > 0 && expected_size != new_blob->length) {
+   if (expected_size > 0 &&
+   new_blob->length != expected_size) {
+   drm_property_blob_put(new_blob);
+   return -EINVAL;
+   }
+   if (expected_size_mod > 0 &&
+   new_blob->length % expected_size_mod != 0) {
drm_property_blob_put(new_blob);
return -EINVAL;
}
@@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->degamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
@@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->ctm,
val,
-   sizeof(struct drm_color_ctm),
+   sizeof(struct drm_color_ctm), -1,
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
@@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
&state->gamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
&replaced);
state->color_mgmt_changed |= replaced;
return ret;
-- 
2.13.6

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

[PATCH 5/6] drm/i915: Remove the blob->data casts

[Ville Syrjala]

From: Ville Syrjälä 

Now that blob->data is void* again we don't need to cast it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_color.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index a383d993b844..e8ede69754a9 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -144,8 +144,7 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state 
*crtc_state)
i9xx_load_ycbcr_conversion_matrix(intel_crtc);
return;
} else if (crtc_state->ctm) {
-   struct drm_color_ctm *ctm =
-   (struct drm_color_ctm *)crtc_state->ctm->data;
+   struct drm_color_ctm *ctm = crtc_state->ctm->data;
uint64_t input[9] = { 0, };
 
if (intel_crtc_state->limited_color_range) {
@@ -254,8 +253,7 @@ static void cherryview_load_csc_matrix(struct 
drm_crtc_state *state)
uint32_t mode;
 
if (state->ctm) {
-   struct drm_color_ctm *ctm =
-   (struct drm_color_ctm *) state->ctm->data;
+   struct drm_color_ctm *ctm = state->ctm->data;
uint16_t coeffs[9] = { 0, };
int i;
 
@@ -322,7 +320,7 @@ static void i9xx_load_luts_internal(struct drm_crtc *crtc,
}
 
if (blob) {
-   struct drm_color_lut *lut = (struct drm_color_lut *) blob->data;
+   struct drm_color_lut *lut = blob->data;
for (i = 0; i < 256; i++) {
uint32_t word =
(drm_color_lut_extract(lut[i].red, 8) << 16) |
@@ -392,8 +390,7 @@ static void bdw_load_degamma_lut(struct drm_crtc_state 
*state)
   PAL_PREC_SPLIT_MODE | PAL_PREC_AUTO_INCREMENT);
 
if (state->degamma_lut) {
-   struct drm_color_lut *lut =
-   (struct drm_color_lut *) state->degamma_lut->data;
+   struct drm_color_lut *lut = state->degamma_lut->data;
 
for (i = 0; i < lut_size; i++) {
uint32_t word =
@@ -427,8 +424,7 @@ static void bdw_load_gamma_lut(struct drm_crtc_state 
*state, u32 offset)
   offset);
 
if (state->gamma_lut) {
-   struct drm_color_lut *lut =
-   (struct drm_color_lut *) state->gamma_lut->data;
+   struct drm_color_lut *lut = state->gamma_lut->data;
 
for (i = 0; i < lut_size; i++) {
uint32_t word =
@@ -560,7 +556,7 @@ static void cherryview_load_luts(struct drm_crtc_state 
*state)
}
 
if (state->degamma_lut) {
-   lut = (struct drm_color_lut *) state->degamma_lut->data;
+   lut = state->degamma_lut->data;
lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
for (i = 0; i < lut_size; i++) {
/* Write LUT in U0.14 format. */
@@ -575,7 +571,7 @@ static void cherryview_load_luts(struct drm_crtc_state 
*state)
}
 
if (state->gamma_lut) {
-   lut = (struct drm_color_lut *) state->gamma_lut->data;
+   lut = state->gamma_lut->data;
lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size;
for (i = 0; i < lut_size; i++) {
/* Write LUT in U0.10 format. */
-- 
2.13.6

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

[PATCH 4/6] drm: Introduce drm_color_lut_size()

[Ville Syrjala]

From: Ville Syrjälä 

Provide a small helper to convert the blob length in bytes
to the number of LUT entries.

Signed-off-by: Ville Syrjälä 
---
 include/drm/drm_color_mgmt.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 03a59cbce621..7ddf4457f3c1 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -37,4 +37,9 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
 int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
 int gamma_size);
 
+static inline int drm_color_lut_size(const struct drm_property_blob *blob)
+{
+   return blob->length / sizeof(struct drm_color_lut);
+}
+
 #endif
-- 
2.13.6

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

[PATCH 6/6] drm/i915: Use drm_color_lut_size()

[Ville Syrjala]

From: Ville Syrjälä 

Avoid all the sizeof(drm_color_lut) business by using
drm_color_lut_size() to convert the blob length into
number of LUT entries.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_color.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index e8ede69754a9..029c2c931fab 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -39,7 +39,7 @@
 #define CTM_COEFF_NEGATIVE(coeff)  (((coeff) & CTM_COEFF_SIGN) != 0)
 #define CTM_COEFF_ABS(coeff)   ((coeff) & (CTM_COEFF_SIGN - 1))
 
-#define LEGACY_LUT_LENGTH  (sizeof(struct drm_color_lut) * 256)
+#define LEGACY_LUT_LENGTH  256
 
 /* Post offset values for RGB->YCBCR conversion */
 #define POSTOFF_RGB_TO_YUV_HI 0x800
@@ -79,7 +79,7 @@ static bool crtc_state_is_legacy_gamma(struct drm_crtc_state 
*state)
return !state->degamma_lut &&
!state->ctm &&
state->gamma_lut &&
-   state->gamma_lut->length == LEGACY_LUT_LENGTH;
+   drm_color_lut_size(state->gamma_lut) == LEGACY_LUT_LENGTH;
 }
 
 /*
@@ -611,19 +611,17 @@ int intel_color_check(struct drm_crtc *crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
size_t gamma_length, degamma_length;
 
-   degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size *
-   sizeof(struct drm_color_lut);
-   gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size *
-   sizeof(struct drm_color_lut);
+   degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
+   gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
 
/*
 * We allow both degamma & gamma luts at the right size or
 * NULL.
 */
if ((!crtc_state->degamma_lut ||
-crtc_state->degamma_lut->length == degamma_length) &&
+drm_color_lut_size(crtc_state->degamma_lut) == degamma_length) &&
(!crtc_state->gamma_lut ||
-crtc_state->gamma_lut->length == gamma_length))
+drm_color_lut_size(crtc_state->gamma_lut) == gamma_length))
return 0;
 
/*
-- 
2.13.6

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

[PATCH 1/6] Revert "drm: Use a flexible array member for blob property data"

[Ville Syrjala]

From: Ville Syrjälä 

Using a flexible array for the blob data was a mistake by me. It
forces all users of the blob data to cast blob->data to something
else. void* is clearly superior so let's go back to the original
scheme.

Not a clean revert as the code has moved.

This reverts commit d63f5e6bf6f2a1573ea39c9937cdf5ab0b3a4b77.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_property.c | 1 +
 include/drm/drm_property.h | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index bae50e6b819d..0f6620fea3de 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -550,6 +550,7 @@ drm_property_create_blob(struct drm_device *dev, size_t 
length,
/* This must be explicitly initialised, so we can safely call list_del
 * on it in the removal handler, even if it isn't in a file list. */
INIT_LIST_HEAD(&blob->head_file);
+   blob->data = (void *)blob + sizeof(*blob);
blob->length = length;
blob->dev = dev;
 
diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
index 8a522b4bed40..265fd1f2e112 100644
--- a/include/drm/drm_property.h
+++ b/include/drm/drm_property.h
@@ -209,7 +209,7 @@ struct drm_property_blob {
struct list_head head_global;
struct list_head head_file;
size_t length;
-   unsigned char data[];
+   void *data;
 };
 
 struct drm_prop_enum_list {
-- 
2.13.6

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

Re: [Xen-devel] [RFC PATCH v2 2/9] hyper_dmabuf: architecture specification and reference guide

[Dongwon Kim]

Thanks for your comment, Roger
I will try to polish this doc and resubmit.
(I put some comments below as well.)

On Fri, Feb 23, 2018 at 04:15:00PM +, Roger Pau Monné wrote:
> On Tue, Feb 13, 2018 at 05:50:01PM -0800, Dongwon Kim wrote:
> > Reference document for hyper_DMABUF driver
> > 
> > Documentation/hyper-dmabuf-sharing.txt
> 
> This should likely be patch 1 in order for reviewers to have the
> appropriate context.
> 
> > 
> > Signed-off-by: Dongwon Kim 
> > ---
> >  Documentation/hyper-dmabuf-sharing.txt | 734 
> > +
> >  1 file changed, 734 insertions(+)
> >  create mode 100644 Documentation/hyper-dmabuf-sharing.txt
> > 
> > diff --git a/Documentation/hyper-dmabuf-sharing.txt 
> > b/Documentation/hyper-dmabuf-sharing.txt
> > new file mode 100644
> > index ..928e411931e3
> > --- /dev/null
> > +++ b/Documentation/hyper-dmabuf-sharing.txt
> > @@ -0,0 +1,734 @@
> > +Linux Hyper DMABUF Driver
> > +
> > +--
> > +Section 1. Overview
> > +--
> > +
> > +Hyper_DMABUF driver is a Linux device driver running on multiple Virtual
> > +achines (VMs), which expands DMA-BUF sharing capability to the VM 
> > environment
> > +where multiple different OS instances need to share same physical data 
> > without
> > +data-copy across VMs.
> > +
> > +To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the
> > +exporting VM (so called, “exporter”) imports a local DMA_BUF from the 
> > original
> > +producer of the buffer,
> 
> The usage of export and import in the above sentence makes it almost
> impossible to understand.

Ok, it looks confusing. I think the problem is that those words are used for 
both
local and cross-VMs cases. I will try to clarify those. 

> 
> > then re-exports it with an unique ID, hyper_dmabuf_id
> > +for the buffer to the importing VM (so called, “importer”).
> 
> And this is even worse.
> 
> Maybe it would help to have some kind of flow diagram of all this
> import/export operations, but please read below.

I will add a diagram here.

> 
> > +
> > +Another instance of the Hyper_DMABUF driver on importer registers
> > +a hyper_dmabuf_id together with reference information for the shared 
> > physical
> > +pages associated with the DMA_BUF to its database when the export happens.
> > +
> > +The actual mapping of the DMA_BUF on the importer’s side is done by
> > +the Hyper_DMABUF driver when user space issues the IOCTL command to access
> > +the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and
> > +exporting driver as is, that is, no special configuration is required.
> > +Consequently, only a single module per VM is needed to enable cross-VM 
> > DMA_BUF
> > +exchange.
> 
> IMHO I need a more generic view of the problem you are trying to solve
> in the overview section. I've read the full overview, and I still have
> no idea why you need all this.

I will add some more paragrahs here to give some more generic view (and possibly
diagrams) of this driver.

> 
> I think the overview should contain at least:
> 
> 1. A description of the problem you are trying to solve.
> 2. A high level description of the proposed solution.
> 3. How the proposed solution deals with the problem described in 1.
> 
> This overview is not useful for people that don't know which problem
> you are trying to solve, like myself.

Thanks again.

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

Re: [RFC 4/4] drm/msm/mdp5: writeback support

[Rob Clark]

On Fri, Feb 23, 2018 at 11:30 AM, Sean Paul  wrote:
> On Fri, Feb 23, 2018 at 08:17:54AM -0500, Rob Clark wrote:
>> In a way, based on the original writeback patch from Jilai Wang, but a
>> lot has shifted around since then.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/msm/Makefile  |   1 +
>>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  23 +-
>>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  38 +++-
>>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h  |   7 +-
>>  drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c   | 367 
>> ++
>>  drivers/gpu/drm/msm/dsi/dsi_host.c|   4 +-
>>  6 files changed, 431 insertions(+), 9 deletions(-)
>>  create mode 100644 drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c
>>
>> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
>> index cd40c050b2d7..c9f50adef2db 100644
>> --- a/drivers/gpu/drm/msm/Makefile
>> +++ b/drivers/gpu/drm/msm/Makefile
>> @@ -45,6 +45,7 @@ msm-y := \
>>   disp/mdp5/mdp5_mixer.o \
>>   disp/mdp5/mdp5_plane.o \
>>   disp/mdp5/mdp5_smp.o \
>> + disp/mdp5/mdp5_wb.o \
>>   msm_atomic.o \
>>   msm_debugfs.o \
>>   msm_drv.o \
>> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
>> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
>> index 9893e43ba6c5..b00ca88b741d 100644
>> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
>> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
>> @@ -484,7 +484,11 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc 
>> *crtc,
>>   }
>>
>>   /* Restore vblank irq handling after power is enabled */
>> - drm_crtc_vblank_on(crtc);
>> +// TODO we can't ->get_scanout_pos() for wb (since virtual intf)..
>> +// perhaps drm core should be clever enough not to 
>> drm_reset_vblank_timestamp()
>> +// for virtual encoders / writeback?
>> + if (mdp5_cstate->pipeline.intf->type != INTF_WB)
>> + drm_crtc_vblank_on(crtc);
>>
>>   mdp5_crtc_mode_set_nofb(crtc);
>>
>> @@ -518,7 +522,11 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
>>   u32 caps;
>>   int ret;
>>
>> - caps = MDP_LM_CAP_DISPLAY;
>> + if (pipeline->intf->type == INTF_WB)
>> + caps = MDP_LM_CAP_WB;
>> + else
>> + caps = MDP_LM_CAP_DISPLAY;
>> +
>>   if (need_right_mixer)
>>   caps |= MDP_LM_CAP_PAIR;
>>
>> @@ -545,6 +553,7 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
>>   mdp5_cstate->err_irqmask = intf2err(intf->num);
>>   mdp5_cstate->vblank_irqmask = intf2vblank(pipeline->mixer, intf);
>>
>> +// XXX should we be treating WB as cmd_mode??
>>   if ((intf->type == INTF_DSI) &&
>>   (intf->mode == MDP5_INTF_DSI_MODE_COMMAND)) {
>>   mdp5_cstate->pp_done_irqmask = lm2ppdone(pipeline->mixer);
>> @@ -639,8 +648,12 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
>>   }
>>
>>   /* bail out early if there aren't any planes */
>> - if (!cnt)
>> - return 0;
>> + if (!cnt) {
>> + if (!state->active)
>> + return 0;
>> + dev_err(dev->dev, "%s has no planes!\n", crtc->name);
>> + return -EINVAL;
>> + }
>
> This seems unrelated?
>

hmm, yeah, kinda.  It was a case that I hit before working out all the
bugs in my kmscube writeback mode, but I guess isn't directly related
to wb.

>>
>>   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>>
>> @@ -1160,7 +1173,7 @@ void mdp5_crtc_wait_for_commit_done(struct drm_crtc 
>> *crtc)
>>
>>   if (mdp5_cstate->cmd_mode)
>>   mdp5_crtc_wait_for_pp_done(crtc);
>> - else
>> + else if (mdp5_cstate->pipeline.intf->type != INTF_WB)
>>   mdp5_crtc_wait_for_flush_done(crtc);
>>  }
>>
>> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
>> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
>> index 1f44d8f15ce1..239010905637 100644
>> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
>> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
>> @@ -427,7 +427,8 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>>* the MDP5 interfaces) than the number of layer mixers present in HW,
>>* but let's be safe here anyway
>>*/
>> - num_crtcs = min(priv->num_encoders, mdp5_kms->num_hwmixers);
>> + num_crtcs = min(priv->num_encoders + hw_cfg->wb.count,
>> + mdp5_kms->num_hwmixers);
>>
>>   /*
>>* Construct planes equaling the number of hw pipes, and CRTCs for the
>> @@ -482,6 +483,33 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>>   encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
>>   }
>>
>> + /*
>> +  * Lastly, construct writeback connectors.
>> +  */
>> + for (i = 0; i < hw_cfg->wb.count; i++) {
>> + struct drm_writeback_connector *wb_conn;
>> + struct mdp5_ctl *ctl;
>> +
>> + ctl = mdp5_ctlm_request(mdp5_kms-

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 04:48:58PM +, Liviu Dudau wrote:
> On Fri, Feb 23, 2018 at 11:43:29AM -0500, Sean Paul wrote:
> > On Fri, Feb 23, 2018 at 11:25:11AM -0500, Rob Clark wrote:
> > > On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
> > > >
> > > > Have we considered hiding writeback behind a client cap instead?
> > > 
> > > It is kinda *almost* unneeded, since the connector reports itself as
> > > disconnected.
> > > 
> > > I'm not sure what the reason was to drop the cap, but I think it would
> > > be better to have a cap so WB connectors don't show up in, for ex,
> > > xrandr
> > 
> > Yeah, the disconnected hack is kind of gross, IMO. I hate to introduce 
> > churn in
> > the patch series given that it was initially introduced with the client cap.
> 
> Haha, that's the reverse of Daniel's position:
> 
> https://lists.freedesktop.org/archives/dri-devel/2016-October/120519.html

Yeah, it happens :(. I don't think it's a dealbreaker either way, it just seems
awkward to expose a connector which is "disconnected", but available for use. I
don't think we have any other connectors which are supposed to be used in this
state.

> 
> > 
> > There are also cases where we might want to make writeback unavailable, 
> > such as
> > when content protection is enabled. In those cases, it's conceivable that we
> > might want to use disconnected as a signal to u/s. I suppose we could also 
> > just
> > fail the check, so most of this is just academic.
> 
> Not sure what other hardware out there does, but on Mali DP's case you
> would be outputing the protected content by putting the display
> processor in secure mode, which automatically disables writeback for us.
> Or to put in another way, you don't need a writeback framebuffer if you
> are in non-secure mode as you can get access to the framebuffer used for
> the plane anyway.

Yeah, I was mostly thinking about the case where you might have HDCP enabled on
the HDMI connector and be able to slurp up the content via a writeback. However
if the buffer is not secure in the first place, then it's already accessible in
userspace so I don't think that writeback presents a new security hole.

/me needs to get HDCP out of his head.

Sean


> 
> Best regards,
> Liviu
> 
> > 
> > Sean
> > 
> > 
> > > 
> > > BR,
> > > -R
> > 
> > -- 
> > Sean Paul, Software Engineer, Google / Chromium OS
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105200] [r600g] Regression: ImageMagick OpenCL kernel no longer compiles

[bugzilla-daemon]

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

--- Comment #5 from Jan Vesely  ---
(In reply to nixscripter from comment #4)
> Thanks to your quick response, I got libclc compiled successfully.
> 
> Now when I try to view an image, the OpenCL compile error is different:
> 
> :0:0: in function ResizeHorizontalFilter void (float addrspace(1)*,
> i32, i32, i32, float addrspace(1)*, i32, i32, float, i32, i32, float
> addrspace(1)*, float, float, float, float, float addrspace(3)*, i32, i32,
> i32, <4 x float> addrspace(3)*, float addrspace(3)*, float addrspace(3)*):
> unsupported call to function applyResizeFilter
> 
> I'd call that progress, certainly.
> 
> applyResizeFilter is on line 78 of the kernel, and ResizeHorizontalFilter is
> on line 81.

that's weird. Probably a separate bug. All functions should be marked as
always_inline. moreover the function in question is explicitly marked as
inline.
The only thing I can think of is that the function signature does not match
between definition and the call site
Does imagemagick use some form of kernel cache? if yes it needs to be cleaned.

what is the GPU that you're using?
Can you run CLOVER_DEBUG=llvm,clc CLOVER_DEBUG_FILE=imagick and attach the .cl
and .ll dump files?

-- 
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 v2] *-symbol-check: Don't hard-code nm executable

[Emil Velikov]

On 23 February 2018 at 15:02, Eric Engestrom  wrote:
> On Friday, 2018-02-23 00:25:27 +, Emil Velikov wrote:
>> On 19 February 2018 at 16:35, Eric Engestrom  
>> wrote:
>> > From: Heiko Becker 
>> >
>> > Helpful if your nm executable has a prefix based on the
>> > architecture, for example.
>> >
>>
>> > +env_test = environment()
>> > +env_test.set('NM', find_program('nm').path())
>> > +
>> Everything else is great, just not too sure about this hunk.
>> Are you sure it does what the commit message says?
>
> It does, I even asked the meson devs to be sure. find_program()
> respects the crossfile, unless `native: true` is added [2].
>
I was thinking of cases where a) you're doing a native build and b)
the program name has a prefix.
In reality that shouldn't happen, often, so let's worry if we get
multiple bug reports.

>>
>> I know meson needs special configuration file for cross compilation -
>> one example where nm has prefix.
>> Yet the manual [1] does not say anything about nm. I cannot find any
>> instances of nm in the docs all together :-\
>
> There's nothing special about `nm` here, it's just a program that can be
> set via the crossfile, like `cc` or `ar`.
> I guess the documentation on the cross-compilation page [1] could be
> improved to make the behaviour of find_program() more explicit; care to
> send a patch? :)
>
Great, I'll let you do the honours of tweaking Meson/its documentation.

Thank you very much for the clarification.

The patch is
Reviewed-by: Emil Velikov 

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

Re: [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Ville Syrjälä]

On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote:
> On 2018-02-22 04:42 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > The documentation for the ctm matrix suggests a two's complement
> > format, but at least the i915 implementation is using sign-magnitude
> > instead. And looks like malidp is doing the same. Change the docs
> > to match the current implementation, and change the type from __s64
> > to __u64 to drive the point home.
> > 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Mihail Atanassov 
> > Cc: Liviu Dudau 
> > Cc: Brian Starkey 
> > Cc: Mali DP Maintainers 
> > Cc: Johnson Lin 
> > Cc: Uma Shankar 
> > Cc: Shashank Sharma 
> > Signed-off-by: Ville Syrjälä 
> 
> Good clarification. Our new CTM implementation (1) actually assumed two's 
> complement but nobody's using it yet, so we'll patch it to convert.

Nice. Looks like we caught this just in time.

> 
> Reviewed-by: Harry Wentland 
> 
> (1) https://patchwork.freedesktop.org/patch/204005/
> 
> Harry
> 
> > ---
> >  include/uapi/drm/drm_mode.h | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 2c575794fb52..b5d7d9e0eff5 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
> >  };
> >  
> >  struct drm_color_ctm {
> > -   /* Conversion matrix in S31.32 format. */
> > -   __s64 matrix[9];
> > +   /*
> > +* Conversion matrix in S31.32 sign-magnitude
> > +* (not two's complement!) format.
> > +*/
> > +   __u64 matrix[9];
> >  };
> >  
> >  struct drm_color_lut {
> > 

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #14 from Dmitry  ---
Because "tearfree true" is also not loaded Arch further, it literally
immediately after removing the line. The problem is a bit similar.

-- 
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: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 11:39:06AM -0500, Sean Paul wrote:
> On Fri, Feb 23, 2018 at 04:21:05PM +, Liviu Dudau wrote:
> > On Fri, Feb 23, 2018 at 10:59:35AM -0500, Sean Paul wrote:
> > > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> > > > From: Brian Starkey 
> > > > 
> > > > Writeback connectors represent writeback engines which can write the
> > > > CRTC output to a memory framebuffer. Add a writeback connector type and
> > > > related support functions.
> > > > 
> > > > Drivers should initialize a writeback connector with
> > > > drm_writeback_connector_init() which takes care of setting up all the
> > > > writeback-specific details on top of the normal functionality of
> > > > drm_connector_init().
> > > > 
> > > > Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> > > > output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose 
> > > > the
> > > > supported writeback formats to userspace.
> > > > 
> > > > When a framebuffer is attached to a writeback connector with the
> > > > WRITEBACK_FB_ID property, it is used only once (for the commit in which
> > > > it was included), and userspace can never read back the value of
> > > > WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> > > > attached to a CRTC.
> > > > 
> > > > Changes since v1:
> > > >  - Added drm_writeback.c + documentation
> > > >  - Added helper to initialize writeback connector in one go
> > > >  - Added core checks
> > > >  - Squashed into a single commit
> > > >  - Dropped the client cap
> > > >  - Writeback framebuffers are no longer persistent
> > > > 
> > > > Changes since v2:
> > > >  Daniel Vetter:
> > > >  - Subclass drm_connector to drm_writeback_connector
> > > >  - Relax check to allow CRTC to be set without an FB
> > > >  - Add some writeback_ prefixes
> > > >  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
> > > >  Gustavo Padovan:
> > > >  - Add drm_writeback_job to handle writeback signalling centrally
> > > > 
> > > > Changes since v3:
> > > >  - Rebased
> > > >  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> > > > 
> > > > Changes since v4:
> > > >  - Added atomic_commit() vfunc to connector helper funcs, so that
> > > >writeback jobs are committed from atomic helpers
> > > > 
> > > > Signed-off-by: Brian Starkey 
> > > > [rebased and fixed conflicts]
> > > > Signed-off-by: Mihail Atanassov 
> > > > Signed-off-by: Liviu Dudau 
> > > > [rebased and added atomic_commit() vfunc for writeback jobs]
> > > > Signed-off-by: Rob Clark 
> > > > ---
> > > >  Documentation/gpu/drm-kms.rst|   9 ++
> > > >  drivers/gpu/drm/Makefile |   2 +-
> > > >  drivers/gpu/drm/drm_atomic.c | 130 
> > > >  drivers/gpu/drm/drm_atomic_helper.c  |  30 
> > > >  drivers/gpu/drm/drm_connector.c  |   4 +-
> > > >  drivers/gpu/drm/drm_writeback.c  | 257 
> > > > +++
> > > >  include/drm/drm_atomic.h |   3 +
> > > >  include/drm/drm_connector.h  |  13 ++
> > > >  include/drm/drm_mode_config.h|  14 ++
> > > >  include/drm/drm_modeset_helper_vtables.h |  11 ++
> > > >  include/drm/drm_writeback.h  |  89 +++
> > > >  include/uapi/drm/drm_mode.h  |   1 +
> > > >  12 files changed, 561 insertions(+), 2 deletions(-)
> > > >  create mode 100644 drivers/gpu/drm/drm_writeback.c
> > > >  create mode 100644 include/drm/drm_writeback.h
> > > > 
> > > > diff --git a/Documentation/gpu/drm-kms.rst 
> > > > b/Documentation/gpu/drm-kms.rst
> > > > index 2dcf5b42015d..e7590dd2f71e 100644
> > > > --- a/Documentation/gpu/drm-kms.rst
> > > > +++ b/Documentation/gpu/drm-kms.rst
> > > > @@ -370,6 +370,15 @@ Connector Functions Reference
> > > >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > > :export:
> > > >  
> > > > +Writeback Connectors
> > > > +
> > > > +
> > > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > > +  :doc: overview
> > > > +
> > > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > > +  :export:
> > > > +
> > > >  Encoder Abstraction
> > > >  ===
> > > >  
> > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > index 50093ff4479b..3d708959b224 100644
> > > > --- a/drivers/gpu/drm/Makefile
> > > > +++ b/drivers/gpu/drm/Makefile
> > > > @@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o 
> > > > drm_cache.o \
> > > > drm_encoder.o drm_mode_object.o drm_property.o \
> > > > drm_plane.o drm_color_mgmt.o drm_print.o \
> > > > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > > > -   drm_syncobj.o drm_lease.o
> > > > +   drm_syncobj.o drm_lease.o drm_writeback.o
> > > >  
> > > >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> > > >  drm-$(CONFIG_DRM_VM) += drm_vm.o
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/driv

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 11:43:29AM -0500, Sean Paul wrote:
> On Fri, Feb 23, 2018 at 11:25:11AM -0500, Rob Clark wrote:
> > On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
> > >
> > > Have we considered hiding writeback behind a client cap instead?
> > 
> > It is kinda *almost* unneeded, since the connector reports itself as
> > disconnected.
> > 
> > I'm not sure what the reason was to drop the cap, but I think it would
> > be better to have a cap so WB connectors don't show up in, for ex,
> > xrandr
> 
> Yeah, the disconnected hack is kind of gross, IMO. I hate to introduce churn 
> in
> the patch series given that it was initially introduced with the client cap.

Haha, that's the reverse of Daniel's position:

https://lists.freedesktop.org/archives/dri-devel/2016-October/120519.html

> 
> There are also cases where we might want to make writeback unavailable, such 
> as
> when content protection is enabled. In those cases, it's conceivable that we
> might want to use disconnected as a signal to u/s. I suppose we could also 
> just
> fail the check, so most of this is just academic.

Not sure what other hardware out there does, but on Mali DP's case you
would be outputing the protected content by putting the display
processor in secure mode, which automatically disables writeback for us.
Or to put in another way, you don't need a writeback framebuffer if you
are in non-secure mode as you can get access to the framebuffer used for
the plane anyway.

Best regards,
Liviu

> 
> Sean
> 
> 
> > 
> > BR,
> > -R
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 11:25:11AM -0500, Rob Clark wrote:
> On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
> >
> > Have we considered hiding writeback behind a client cap instead?
> 
> It is kinda *almost* unneeded, since the connector reports itself as
> disconnected.
> 
> I'm not sure what the reason was to drop the cap, but I think it would
> be better to have a cap so WB connectors don't show up in, for ex,
> xrandr

Yeah, the disconnected hack is kind of gross, IMO. I hate to introduce churn in
the patch series given that it was initially introduced with the client cap.

There are also cases where we might want to make writeback unavailable, such as
when content protection is enabled. In those cases, it's conceivable that we
might want to use disconnected as a signal to u/s. I suppose we could also just
fail the check, so most of this is just academic.

Sean


> 
> BR,
> -R

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 04:21:05PM +, Liviu Dudau wrote:
> On Fri, Feb 23, 2018 at 10:59:35AM -0500, Sean Paul wrote:
> > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> > > From: Brian Starkey 
> > > 
> > > Writeback connectors represent writeback engines which can write the
> > > CRTC output to a memory framebuffer. Add a writeback connector type and
> > > related support functions.
> > > 
> > > Drivers should initialize a writeback connector with
> > > drm_writeback_connector_init() which takes care of setting up all the
> > > writeback-specific details on top of the normal functionality of
> > > drm_connector_init().
> > > 
> > > Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> > > output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> > > supported writeback formats to userspace.
> > > 
> > > When a framebuffer is attached to a writeback connector with the
> > > WRITEBACK_FB_ID property, it is used only once (for the commit in which
> > > it was included), and userspace can never read back the value of
> > > WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> > > attached to a CRTC.
> > > 
> > > Changes since v1:
> > >  - Added drm_writeback.c + documentation
> > >  - Added helper to initialize writeback connector in one go
> > >  - Added core checks
> > >  - Squashed into a single commit
> > >  - Dropped the client cap
> > >  - Writeback framebuffers are no longer persistent
> > > 
> > > Changes since v2:
> > >  Daniel Vetter:
> > >  - Subclass drm_connector to drm_writeback_connector
> > >  - Relax check to allow CRTC to be set without an FB
> > >  - Add some writeback_ prefixes
> > >  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
> > >  Gustavo Padovan:
> > >  - Add drm_writeback_job to handle writeback signalling centrally
> > > 
> > > Changes since v3:
> > >  - Rebased
> > >  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> > > 
> > > Changes since v4:
> > >  - Added atomic_commit() vfunc to connector helper funcs, so that
> > >writeback jobs are committed from atomic helpers
> > > 
> > > Signed-off-by: Brian Starkey 
> > > [rebased and fixed conflicts]
> > > Signed-off-by: Mihail Atanassov 
> > > Signed-off-by: Liviu Dudau 
> > > [rebased and added atomic_commit() vfunc for writeback jobs]
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  Documentation/gpu/drm-kms.rst|   9 ++
> > >  drivers/gpu/drm/Makefile |   2 +-
> > >  drivers/gpu/drm/drm_atomic.c | 130 
> > >  drivers/gpu/drm/drm_atomic_helper.c  |  30 
> > >  drivers/gpu/drm/drm_connector.c  |   4 +-
> > >  drivers/gpu/drm/drm_writeback.c  | 257 
> > > +++
> > >  include/drm/drm_atomic.h |   3 +
> > >  include/drm/drm_connector.h  |  13 ++
> > >  include/drm/drm_mode_config.h|  14 ++
> > >  include/drm/drm_modeset_helper_vtables.h |  11 ++
> > >  include/drm/drm_writeback.h  |  89 +++
> > >  include/uapi/drm/drm_mode.h  |   1 +
> > >  12 files changed, 561 insertions(+), 2 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/drm_writeback.c
> > >  create mode 100644 include/drm/drm_writeback.h
> > > 
> > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > > index 2dcf5b42015d..e7590dd2f71e 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -370,6 +370,15 @@ Connector Functions Reference
> > >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > :export:
> > >  
> > > +Writeback Connectors
> > > +
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > +  :doc: overview
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > > +  :export:
> > > +
> > >  Encoder Abstraction
> > >  ===
> > >  
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 50093ff4479b..3d708959b224 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -18,7 +18,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
> > >   drm_encoder.o drm_mode_object.o drm_property.o \
> > >   drm_plane.o drm_color_mgmt.o drm_print.o \
> > >   drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > > - drm_syncobj.o drm_lease.o
> > > + drm_syncobj.o drm_lease.o drm_writeback.o
> > >  
> > >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> > >  drm-$(CONFIG_DRM_VM) += drm_vm.o
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 46733d534587..019f131fe8be 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -30,6 +30,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  
> > >  #include "drm_crtc_internal.h"
> > > @@ -638,6 +639,46 @@ s

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

[Christian König]

Hi Ben,


I mentioned the HD 5450 purely as a matter of archeological interest.
Ok, in that case looking at the lspci -tv output doesn't tell us 
anything new.



I suspected, but couldn't prove, that the problem might have something
to do with the bridge (IBM POWER8 Host Bridge (PHB3)).


In that case you would see the problem with the caicos as well.

Or are there issues random enough that there could actually be some 
problem with the caicos as well and we haven't noticed it so far?


See it is really really odd that this should only happen with the cedar. 
On the other hand if it works for now, I don't see much issue having 
this workaround.


Regards,
Christian.

Am 23.02.2018 um 17:02 schrieb Ben Crocker:

Hi Christian, Michel, Alex, et al.,

I mentioned the HD 5450 purely as a matter of archeological interest.

Back to the FirePro 2270 and Embedded Radeon E6465:

I've attached text from both "lspci -tv" and "lspci -v."
Actually I'm attaching a couple of different "lspci -v" outputs, one
with the FirePro 2270 in place and one with the E6465 in (the same) place.

I suspected, but couldn't prove, that the problem might have something
to do with the bridge (IBM POWER8 Host Bridge (PHB3)).

But I want to reiterate:

  * Cedar GPU -> problem (before patch, that is);
  * Caicos GPU in the same slot -> no problem


-- Ben

P.S.  Alex, thanks for applying the patch so expeditiously!


On Fri, Feb 23, 2018 at 2:45 AM, Christian König 
> wrote:


Am 22.02.2018 um 18:56 schrieb Michel Dänzer:

On 2018-02-22 06:37 PM, Ben Crocker wrote:

One of my colleagues did discover a "Radeon HG 5450 PCI"
from February
2010 which did, apparently, have a Cedar GPU and very
definitely had a
(plain old) PCI connector.

There must be a PCIe-to-PCI bridge on that board. The GPU
itself is
always PCIe, and treated accordingly by the driver.


Ben, just an educated guess but is this one the one which is
failing to work correctly?

Cause the PCIe bus interface is pretty much identical over all
generations of the last decade or so. Only the newest Vega10
generation is a bit different.

So I strongly thing that this isn't related to the device being a
Cedar at all, but rather that you have a bridge above it which
doesn't correctly handle 64bit transfers.

Can you please send and "lspci -t" of both the working and the
problematic devices?

Thanks,
Christian.




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

Re: [RFC 3/4] drm/msm/mdp5: add config for writeback pipes

[Sean Paul]

On Fri, Feb 23, 2018 at 08:17:53AM -0500, Rob Clark wrote:
> Note there seems to be a slight disagreement between public 8x16 HRD
> (which claims WB2 has offset of 0x65000, relative to start of MDP), and
> reality (which claims WB2 has offset of 0x64800).  I sided with reality.
> 
> There should also be a WB0 attached to LM0 (which routes to DSI
> interface).  It isn't clear if this can be used at the same time as
> output to DSI, which would be hugely useful.  I was unable to get this
> to work (with HDMI bridge chip on db410c, so DSI in video mode).
> 
> This will be needed to implement writeback support, but also useful
> to remove a manual hack to the generated headers (since rnndb register
> docs for WB had been merged long ago).
> 
> Also fixes LM3 offset.
> 
> Signed-off-by: Rob Clark 

I'm not familiar with the hw, but I don't see any programming errors, so:

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h |  2 --
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 17 +++--
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h | 11 +++
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  1 +
>  4 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h
> index d9c10e02ee41..bebcbabb1fe4 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h
> @@ -1391,13 +1391,11 @@ static inline uint32_t 
> REG_MDP5_PP_FBC_LOSSY_MODE(uint32_t i0) { return 0x00
>  static inline uint32_t __offset_WB(uint32_t idx)
>  {
>   switch (idx) {
> -#if 0  /* TEMPORARY until patch that adds wb.base[] is merged */
>   case 0: return (mdp5_cfg->wb.base[0]);
>   case 1: return (mdp5_cfg->wb.base[1]);
>   case 2: return (mdp5_cfg->wb.base[2]);
>   case 3: return (mdp5_cfg->wb.base[3]);
>   case 4: return (mdp5_cfg->wb.base[4]);
> -#endif
>   default: return INVALID_IDX(idx);
>   }
>  }
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> index 824067d2d427..f92e68cdeeef 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
> @@ -300,8 +300,8 @@ const struct mdp5_cfg_hw msm8x16_config = {
>   },
>   },
>   .ctl = {
> - .count = 5,
> - .base = { 0x01000, 0x01200, 0x01400, 0x01600, 0x01800 },
> + .count = 3,
> + .base = { 0x01000, 0x01200, 0x01400 },
>   .flush_hw_mask = 0x4003,
>   },
>   .pipe_vig = {
> @@ -324,7 +324,7 @@ const struct mdp5_cfg_hw msm8x16_config = {
>   },
>   .lm = {
>   .count = 2, /* LM0 and LM3 */
> - .base = { 0x44000, 0x47000 },
> + .base = { [0] = 0x44000, [3] = 0x47000 },
>   .instances = {
>   { .id = 0, .pp = 0, .dspp = 0,
> .caps = MDP_LM_CAP_DISPLAY, },
> @@ -338,12 +338,17 @@ const struct mdp5_cfg_hw msm8x16_config = {
>   .dspp = {
>   .count = 1,
>   .base = { 0x54000 },
> -
> + },
> + .wb = {
> + .count = 1,
> + .base = { [0] = 0x64000, [2] = 0x64800 },
> + .instances = {
> + { .id = 2, .lm = 3 },
> + },
>   },
>   .intf = {
> - .base = { 0x0, 0x6a800 },
> + .base = { 0x6a000, 0x6a800, 0x6b000, 0x6b800 },
>   .connect = {
> - [0] = INTF_DISABLED,
>   [1] = INTF_DSI,
>   },
>   },
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
> index 75910d0f2f4c..2e529fb2f9ee 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h
> @@ -77,6 +77,16 @@ struct mdp5_mdp_block {
>   uint32_t caps;  /* MDP capabilities: MDP_CAP_xxx bits */
>  };
>  
> +struct mdp5_wb_instance {
> + int id;
> + int lm;
> +};
> +
> +struct mdp5_wb_block {
> + MDP5_SUB_BLOCK_DEFINITION;
> + struct mdp5_wb_instance instances[MAX_BASES];
> +};
> +
>  #define MDP5_INTF_NUM_MAX5
>  
>  struct mdp5_intf_block {
> @@ -100,6 +110,7 @@ struct mdp5_cfg_hw {
>   struct mdp5_sub_block pp;
>   struct mdp5_sub_block dsc;
>   struct mdp5_sub_block cdm;
> + struct mdp5_wb_block wb;
>   struct mdp5_intf_block intf;
>  
>   uint32_t max_clk;
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 6d8e3a9a6fc0..1f44d8f15ce1 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -652,6 +652,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
>   pm_runtime_get_sync(&pdev->dev);
>   for (i = 0; i < MDP5_INTF_NUM_M

Re: [RFC 4/4] drm/msm/mdp5: writeback support

[Sean Paul]

On Fri, Feb 23, 2018 at 08:17:54AM -0500, Rob Clark wrote:
> In a way, based on the original writeback patch from Jilai Wang, but a
> lot has shifted around since then.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/Makefile  |   1 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  23 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  38 +++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h  |   7 +-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c   | 367 
> ++
>  drivers/gpu/drm/msm/dsi/dsi_host.c|   4 +-
>  6 files changed, 431 insertions(+), 9 deletions(-)
>  create mode 100644 drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c
> 
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index cd40c050b2d7..c9f50adef2db 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -45,6 +45,7 @@ msm-y := \
>   disp/mdp5/mdp5_mixer.o \
>   disp/mdp5/mdp5_plane.o \
>   disp/mdp5/mdp5_smp.o \
> + disp/mdp5/mdp5_wb.o \
>   msm_atomic.o \
>   msm_debugfs.o \
>   msm_drv.o \
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> index 9893e43ba6c5..b00ca88b741d 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> @@ -484,7 +484,11 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc 
> *crtc,
>   }
>  
>   /* Restore vblank irq handling after power is enabled */
> - drm_crtc_vblank_on(crtc);
> +// TODO we can't ->get_scanout_pos() for wb (since virtual intf)..
> +// perhaps drm core should be clever enough not to 
> drm_reset_vblank_timestamp()
> +// for virtual encoders / writeback?
> + if (mdp5_cstate->pipeline.intf->type != INTF_WB)
> + drm_crtc_vblank_on(crtc);
>  
>   mdp5_crtc_mode_set_nofb(crtc);
>  
> @@ -518,7 +522,11 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
>   u32 caps;
>   int ret;
>  
> - caps = MDP_LM_CAP_DISPLAY;
> + if (pipeline->intf->type == INTF_WB)
> + caps = MDP_LM_CAP_WB;
> + else
> + caps = MDP_LM_CAP_DISPLAY;
> +
>   if (need_right_mixer)
>   caps |= MDP_LM_CAP_PAIR;
>  
> @@ -545,6 +553,7 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
>   mdp5_cstate->err_irqmask = intf2err(intf->num);
>   mdp5_cstate->vblank_irqmask = intf2vblank(pipeline->mixer, intf);
>  
> +// XXX should we be treating WB as cmd_mode??
>   if ((intf->type == INTF_DSI) &&
>   (intf->mode == MDP5_INTF_DSI_MODE_COMMAND)) {
>   mdp5_cstate->pp_done_irqmask = lm2ppdone(pipeline->mixer);
> @@ -639,8 +648,12 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
>   }
>  
>   /* bail out early if there aren't any planes */
> - if (!cnt)
> - return 0;
> + if (!cnt) {
> + if (!state->active)
> + return 0;
> + dev_err(dev->dev, "%s has no planes!\n", crtc->name);
> + return -EINVAL;
> + }

This seems unrelated?

>  
>   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>  
> @@ -1160,7 +1173,7 @@ void mdp5_crtc_wait_for_commit_done(struct drm_crtc 
> *crtc)
>  
>   if (mdp5_cstate->cmd_mode)
>   mdp5_crtc_wait_for_pp_done(crtc);
> - else
> + else if (mdp5_cstate->pipeline.intf->type != INTF_WB)
>   mdp5_crtc_wait_for_flush_done(crtc);
>  }
>  
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 1f44d8f15ce1..239010905637 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -427,7 +427,8 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>* the MDP5 interfaces) than the number of layer mixers present in HW,
>* but let's be safe here anyway
>*/
> - num_crtcs = min(priv->num_encoders, mdp5_kms->num_hwmixers);
> + num_crtcs = min(priv->num_encoders + hw_cfg->wb.count,
> + mdp5_kms->num_hwmixers);
>  
>   /*
>* Construct planes equaling the number of hw pipes, and CRTCs for the
> @@ -482,6 +483,33 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>   encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
>   }
>  
> + /*
> +  * Lastly, construct writeback connectors.
> +  */
> + for (i = 0; i < hw_cfg->wb.count; i++) {
> + struct drm_writeback_connector *wb_conn;
> + struct mdp5_ctl *ctl;
> +
> + ctl = mdp5_ctlm_request(mdp5_kms->ctlm, -1);
> + if (!ctl) {
> + dev_err(dev->dev,
> + "failed to allocate ctl for writeback %d\n", i);
> + continue;
> + }
> +
> + wb_conn = mdp5_wb_connector_init(dev, ctl,
> +   

Re: [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Harry Wentland]

On 2018-02-22 04:42 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> The documentation for the ctm matrix suggests a two's complement
> format, but at least the i915 implementation is using sign-magnitude
> instead. And looks like malidp is doing the same. Change the docs
> to match the current implementation, and change the type from __s64
> to __u64 to drive the point home.
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Mihail Atanassov 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Cc: Johnson Lin 
> Cc: Uma Shankar 
> Cc: Shashank Sharma 
> Signed-off-by: Ville Syrjälä 

Good clarification. Our new CTM implementation (1) actually assumed two's 
complement but nobody's using it yet, so we'll patch it to convert.

Reviewed-by: Harry Wentland 

(1) https://patchwork.freedesktop.org/patch/204005/

Harry

> ---
>  include/uapi/drm/drm_mode.h | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 2c575794fb52..b5d7d9e0eff5 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
>  };
>  
>  struct drm_color_ctm {
> - /* Conversion matrix in S31.32 format. */
> - __s64 matrix[9];
> + /*
> +  * Conversion matrix in S31.32 sign-magnitude
> +  * (not two's complement!) format.
> +  */
> + __u64 matrix[9];
>  };
>  
>  struct drm_color_lut {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 1/4] drm: Add writeback connector type

[Rob Clark]

On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul  wrote:
>
> Have we considered hiding writeback behind a client cap instead?

It is kinda *almost* unneeded, since the connector reports itself as
disconnected.

I'm not sure what the reason was to drop the cap, but I think it would
be better to have a cap so WB connectors don't show up in, for ex,
xrandr

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

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 10:59:35AM -0500, Sean Paul wrote:
> On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> > From: Brian Starkey 
> > 
> > Writeback connectors represent writeback engines which can write the
> > CRTC output to a memory framebuffer. Add a writeback connector type and
> > related support functions.
> > 
> > Drivers should initialize a writeback connector with
> > drm_writeback_connector_init() which takes care of setting up all the
> > writeback-specific details on top of the normal functionality of
> > drm_connector_init().
> > 
> > Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> > output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> > supported writeback formats to userspace.
> > 
> > When a framebuffer is attached to a writeback connector with the
> > WRITEBACK_FB_ID property, it is used only once (for the commit in which
> > it was included), and userspace can never read back the value of
> > WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> > attached to a CRTC.
> > 
> > Changes since v1:
> >  - Added drm_writeback.c + documentation
> >  - Added helper to initialize writeback connector in one go
> >  - Added core checks
> >  - Squashed into a single commit
> >  - Dropped the client cap
> >  - Writeback framebuffers are no longer persistent
> > 
> > Changes since v2:
> >  Daniel Vetter:
> >  - Subclass drm_connector to drm_writeback_connector
> >  - Relax check to allow CRTC to be set without an FB
> >  - Add some writeback_ prefixes
> >  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
> >  Gustavo Padovan:
> >  - Add drm_writeback_job to handle writeback signalling centrally
> > 
> > Changes since v3:
> >  - Rebased
> >  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> > 
> > Changes since v4:
> >  - Added atomic_commit() vfunc to connector helper funcs, so that
> >writeback jobs are committed from atomic helpers
> > 
> > Signed-off-by: Brian Starkey 
> > [rebased and fixed conflicts]
> > Signed-off-by: Mihail Atanassov 
> > Signed-off-by: Liviu Dudau 
> > [rebased and added atomic_commit() vfunc for writeback jobs]
> > Signed-off-by: Rob Clark 
> > ---
> >  Documentation/gpu/drm-kms.rst|   9 ++
> >  drivers/gpu/drm/Makefile |   2 +-
> >  drivers/gpu/drm/drm_atomic.c | 130 
> >  drivers/gpu/drm/drm_atomic_helper.c  |  30 
> >  drivers/gpu/drm/drm_connector.c  |   4 +-
> >  drivers/gpu/drm/drm_writeback.c  | 257 
> > +++
> >  include/drm/drm_atomic.h |   3 +
> >  include/drm/drm_connector.h  |  13 ++
> >  include/drm/drm_mode_config.h|  14 ++
> >  include/drm/drm_modeset_helper_vtables.h |  11 ++
> >  include/drm/drm_writeback.h  |  89 +++
> >  include/uapi/drm/drm_mode.h  |   1 +
> >  12 files changed, 561 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/gpu/drm/drm_writeback.c
> >  create mode 100644 include/drm/drm_writeback.h
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> > index 2dcf5b42015d..e7590dd2f71e 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -370,6 +370,15 @@ Connector Functions Reference
> >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > :export:
> >  
> > +Writeback Connectors
> > +
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > +  :doc: overview
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> > +  :export:
> > +
> >  Encoder Abstraction
> >  ===
> >  
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 50093ff4479b..3d708959b224 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> > drm_encoder.o drm_mode_object.o drm_property.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > -   drm_syncobj.o drm_lease.o
> > +   drm_syncobj.o drm_lease.o drm_writeback.o
> >  
> >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> >  drm-$(CONFIG_DRM_VM) += drm_vm.o
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 46733d534587..019f131fe8be 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -30,6 +30,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  
> >  #include "drm_crtc_internal.h"
> > @@ -638,6 +639,46 @@ static void drm_atomic_crtc_print_state(struct 
> > drm_printer *p,
> > crtc->funcs->atomic_print_state(p, state);
> >  }
> >  
> > +/**
> > + * drm_atomic_connector_check - check connector state
> > + * @connector: connector to check
> > + * @state: connector state to chec

[Bug 105228] Blank screen after loading screen in Shadow of Mordor

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #2 from Gregor Münch  ---


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

-- 
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 105042] [LLVM Regression] Shadow of Mordor stucks at intro video

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 CC||0xe2.0x9a.0...@gmail.com

--- Comment #7 from Gregor Münch  ---
*** Bug 105228 has been marked as a duplicate of this 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

Re: [RFC 2/4] drm: writeback: Add out-fences for writeback connectors

[Sean Paul]

On Fri, Feb 23, 2018 at 08:17:52AM -0500, Rob Clark wrote:
> From: Brian Starkey 
> 
> Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
> enable userspace to get a fence which will signal once the writeback is
> complete. It is not allowed to request an out-fence without a
> framebuffer attached to the connector.
> 
> A timeline is added to drm_writeback_connector for use by the writeback
> out-fences.
> 
> In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
> is set to -1.
> 
> Changes from v2:
>  - Rebase onto Gustavo Padovan's v9 explicit sync series
>  - Change out_fence_ptr type to s32 __user *
>  - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
>  - Store fence in drm_writeback_job
>  Gustavo Padovan:
>  - Move out_fence_ptr out of connector_state
>  - Signal fence from drm_writeback_signal_completion instead of
>in driver directly
> 
> Changes from v3:
>  - Rebase onto 7e9081c5aac7 drm/fence: fix memory overwrite when setting 
> out_fence fd
>(change out_fence_ptr to s32 __user *, for real this time.)
>  - Update documentation around WRITEBACK_OUT_FENCE_PTR
> 
> Signed-off-by: Brian Starkey 
> [rebased and fixed conflicts]
> Signed-off-by: Mihail Atanassov 
> Signed-off-by: Liviu Dudau 
> Signed-off-by: Rob Clark 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_atomic.c|  99 
>  drivers/gpu/drm/drm_writeback.c | 109 
> +++-
>  include/drm/drm_atomic.h|   8 +++
>  include/drm/drm_connector.h |   8 +--
>  include/drm/drm_mode_config.h   |   8 +++
>  include/drm/drm_writeback.h |  41 ++-
>  6 files changed, 257 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 019f131fe8be..fc8c4da409ff 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -318,6 +318,35 @@ static s32 __user *get_out_fence_for_crtc(struct 
> drm_atomic_state *state,
>   return fence_ptr;
>  }
>  
> +static int set_out_fence_for_connector(struct drm_atomic_state *state,
> + struct drm_connector *connector,
> + s32 __user *fence_ptr)
> +{
> + unsigned int index = drm_connector_index(connector);
> +
> + if (!fence_ptr)
> + return 0;
> +
> + if (put_user(-1, fence_ptr))
> + return -EFAULT;
> +
> + state->connectors[index].out_fence_ptr = fence_ptr;
> +
> + return 0;
> +}
> +
> +static s32 __user *get_out_fence_for_connector(struct drm_atomic_state 
> *state,
> +struct drm_connector *connector)
> +{
> + unsigned int index = drm_connector_index(connector);
> + s32 __user *fence_ptr;
> +
> + fence_ptr = state->connectors[index].out_fence_ptr;
> + state->connectors[index].out_fence_ptr = NULL;
> +
> + return fence_ptr;
> +}
> +
>  /**
>   * drm_atomic_set_mode_for_crtc - set mode for CRTC
>   * @state: the CRTC whose incoming state to update
> @@ -676,6 +705,12 @@ static int drm_atomic_connector_check(struct 
> drm_connector *connector,
>   return -EINVAL;
>   }
>  
> + if (writeback_job->out_fence && !writeback_job->fb) {
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence 
> without framebuffer\n",
> +  connector->base.id, connector->name);
> + return -EINVAL;
> + }
> +
>   return 0;
>  }
>  
> @@ -1277,6 +1312,11 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   if (fb)
>   drm_framebuffer_unreference(fb);
>   return ret;
> + } else if (property == config->writeback_out_fence_ptr_property) {
> + s32 __user *fence_ptr = u64_to_user_ptr(val);
> +
> + return set_out_fence_for_connector(state->state, connector,
> +fence_ptr);
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1361,6 +1401,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   } else if (property == config->writeback_fb_id_property) {
>   /* Writeback framebuffer is one-shot, write and forget */
>   *val = 0;
> + } else if (property == config->writeback_out_fence_ptr_property) {
> + *val = 0;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> @@ -2221,7 +2263,7 @@ static int setup_out_fence(struct drm_out_fence_state 
> *fence_state,
>   return 0;
>  }
>  
> -static int prepare_crtc_signaling(struct drm_device *dev,
> +static int prepare_signa

[Bug 198885] amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or "echo".

[bugzilla-daemon]

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

--- Comment #5 from Przemek (sop...@gmail.com) ---
(In reply to Harry Wentland from comment #4)
> Thanks for reporting this. It's currently not hooked up for ASICs older than
> Carrizo. We'll take a look. 
> 
> You're right that it clashes with the kernel's 'no regressions' policy
> should we change pre-VEGA ASIC support with DC to enabled by default.

Hi Harry,

I am glad to hear that the reason is already known, and we are not searching it
blindly.

There is still time till 4.17 merge window ends, so if you would like me to try
out some patches, please do not hesitate.

Thanks,
Przemek.

-- 
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

Re: [PATCH] drm/radeon: insist on 32-bit DMA for Cedar on PPC64/PPC64LE

[Ben Crocker]

Hi Christian, Michel, Alex, et al.,

I mentioned the HD 5450 purely as a matter of archeological interest.

Back to the FirePro 2270 and Embedded Radeon E6465:

I've attached text from both "lspci -tv" and "lspci -v."
Actually I'm attaching a couple of different "lspci -v" outputs, one
with the FirePro 2270 in place and one with the E6465 in (the same) place.

I suspected, but couldn't prove, that the problem might have something
to do with the bridge (IBM POWER8 Host Bridge (PHB3)).

But I want to reiterate:

   - Cedar GPU -> problem (before patch, that is);
   - Caicos GPU in the same slot -> no problem


-- Ben

P.S.  Alex, thanks for applying the patch so expeditiously!


On Fri, Feb 23, 2018 at 2:45 AM, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:

> Am 22.02.2018 um 18:56 schrieb Michel Dänzer:
>
>> On 2018-02-22 06:37 PM, Ben Crocker wrote:
>>
>>> One of my colleagues did discover a "Radeon HG 5450 PCI" from February
>>> 2010 which did, apparently, have a Cedar GPU and very definitely had a
>>> (plain old) PCI connector.
>>>
>> There must be a PCIe-to-PCI bridge on that board. The GPU itself is
>> always PCIe, and treated accordingly by the driver.
>>
>
> Ben, just an educated guess but is this one the one which is failing to
> work correctly?
>
> Cause the PCIe bus interface is pretty much identical over all generations
> of the last decade or so. Only the newest Vega10 generation is a bit
> different.
>
> So I strongly thing that this isn't related to the device being a Cedar at
> all, but rather that you have a bridge above it which doesn't correctly
> handle 64bit transfers.
>
> Can you please send and "lspci -t" of both the working and the problematic
> devices?
>
> Thanks,
> Christian.
>
-+-[0045:00]---00.0-[01]00.0  Texas Instruments TUSB73x0 SuperSpeed USB 3.0 
xHCI Host Controller
 +-[0044:00]---00.0-[01]--
 +-[0040:00]---00.0-[01]--
 +-[0005:00]---00.0-[01-0f]00.0-[02-0f]--+-01.0-[03]00.0  Texas 
Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller
 |   +-08.0-[04]00.0  IBM PCI-E IPR 
SAS Adapter (ASIC)
 |   +-09.0-[05]--+-00.0  Broadcom 
Limited NetXtreme BCM5719 Gigabit Ethernet PCIe
 |   |+-00.1  Broadcom 
Limited NetXtreme BCM5719 Gigabit Ethernet PCIe
 |   |+-00.2  Broadcom 
Limited NetXtreme BCM5719 Gigabit Ethernet PCIe
 |   |\-00.3  Broadcom 
Limited NetXtreme BCM5719 Gigabit Ethernet PCIe
 |   +-10.0-[06-0a]--
 |   \-11.0-[0b-0f]--
 +-[0004:00]---00.0-[01]--+-00.0  Advanced Micro Devices, Inc. [AMD/ATI] Cedar 
GL [FirePro 2270]
 |\-00.1  Advanced Micro Devices, Inc. [AMD/ATI] Cedar 
HDMI Audio [Radeon HD 5400/6300/7300 Series]
 +-[0001:00]---00.0-[01-0d]00.0-[02-0d]--+-01.0-[03-07]--
 |   +-08.0-[08]00.0  IBM PCI-E IPR 
SAS Adapter (ASIC)
 |   \-09.0-[09-0d]--
 \-[:00]---00.0-[01]--
:00:00.0 PCI bridge: IBM POWER8 Host Bridge (PHB3) (prog-if 00 [Normal 
decode])
Flags: bus master, fast devsel, latency 0, NUMA node 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: None
Memory behind bridge: None
Prefetchable memory behind bridge: None
Capabilities: [40] Power Management version 3
Capabilities: [48] Express Root Port (Slot-), MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] #19
Kernel modules: shpchp

0001:00:00.0 PCI bridge: IBM POWER8 Host Bridge (PHB3) (prog-if 00 [Normal 
decode])
Flags: bus master, fast devsel, latency 0, NUMA node 0
Bus: primary=00, secondary=01, subordinate=0d, sec-latency=0
I/O behind bridge: None
Memory behind bridge: 8000-ffef [size=2047M]
Prefetchable memory behind bridge: 2100-21fd 
[size=1016G]
Capabilities: [40] Power Management version 3
Capabilities: [48] Express Root Port (Slot-), MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] #19
Kernel modules: shpchp

0001:01:00.0 PCI bridge: PLX Technology, Inc. PEX 8732 32-lane, 8-Port PCI 
Express Gen 3 (8.0 GT/s) Switch (rev ca) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 493, NUMA node 0
Memory at 3fe08280 (32-bit, non-prefetchable) [size=256K]
Bus: primary=01, secondary=02, subordinate=0d, sec-latency=0
I/O behind bridge: None
Memory behind bridge: 8000-ffef [size=2047M]
Prefetchable memory behind bridge: 2100-21fd 
[size=1016G]
Capabilities: [40] Power

Re: [RFC 1/4] drm: Add writeback connector type

[Sean Paul]

On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> From: Brian Starkey 
> 
> Writeback connectors represent writeback engines which can write the
> CRTC output to a memory framebuffer. Add a writeback connector type and
> related support functions.
> 
> Drivers should initialize a writeback connector with
> drm_writeback_connector_init() which takes care of setting up all the
> writeback-specific details on top of the normal functionality of
> drm_connector_init().
> 
> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> supported writeback formats to userspace.
> 
> When a framebuffer is attached to a writeback connector with the
> WRITEBACK_FB_ID property, it is used only once (for the commit in which
> it was included), and userspace can never read back the value of
> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> attached to a CRTC.
> 
> Changes since v1:
>  - Added drm_writeback.c + documentation
>  - Added helper to initialize writeback connector in one go
>  - Added core checks
>  - Squashed into a single commit
>  - Dropped the client cap
>  - Writeback framebuffers are no longer persistent
> 
> Changes since v2:
>  Daniel Vetter:
>  - Subclass drm_connector to drm_writeback_connector
>  - Relax check to allow CRTC to be set without an FB
>  - Add some writeback_ prefixes
>  - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
>  Gustavo Padovan:
>  - Add drm_writeback_job to handle writeback signalling centrally
> 
> Changes since v3:
>  - Rebased
>  - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS
> 
> Changes since v4:
>  - Added atomic_commit() vfunc to connector helper funcs, so that
>writeback jobs are committed from atomic helpers
> 
> Signed-off-by: Brian Starkey 
> [rebased and fixed conflicts]
> Signed-off-by: Mihail Atanassov 
> Signed-off-by: Liviu Dudau 
> [rebased and added atomic_commit() vfunc for writeback jobs]
> Signed-off-by: Rob Clark 
> ---
>  Documentation/gpu/drm-kms.rst|   9 ++
>  drivers/gpu/drm/Makefile |   2 +-
>  drivers/gpu/drm/drm_atomic.c | 130 
>  drivers/gpu/drm/drm_atomic_helper.c  |  30 
>  drivers/gpu/drm/drm_connector.c  |   4 +-
>  drivers/gpu/drm/drm_writeback.c  | 257 
> +++
>  include/drm/drm_atomic.h |   3 +
>  include/drm/drm_connector.h  |  13 ++
>  include/drm/drm_mode_config.h|  14 ++
>  include/drm/drm_modeset_helper_vtables.h |  11 ++
>  include/drm/drm_writeback.h  |  89 +++
>  include/uapi/drm/drm_mode.h  |   1 +
>  12 files changed, 561 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_writeback.c
>  create mode 100644 include/drm/drm_writeback.h
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 2dcf5b42015d..e7590dd2f71e 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -370,6 +370,15 @@ Connector Functions Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :export:
>  
> +Writeback Connectors
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> +  :doc: overview
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_writeback.c
> +  :export:
> +
>  Encoder Abstraction
>  ===
>  
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 50093ff4479b..3d708959b224 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -18,7 +18,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>   drm_encoder.o drm_mode_object.o drm_property.o \
>   drm_plane.o drm_color_mgmt.o drm_print.o \
>   drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> - drm_syncobj.o drm_lease.o
> + drm_syncobj.o drm_lease.o drm_writeback.o
>  
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
>  drm-$(CONFIG_DRM_VM) += drm_vm.o
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 46733d534587..019f131fe8be 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "drm_crtc_internal.h"
> @@ -638,6 +639,46 @@ static void drm_atomic_crtc_print_state(struct 
> drm_printer *p,
>   crtc->funcs->atomic_print_state(p, state);
>  }
>  
> +/**
> + * drm_atomic_connector_check - check connector state
> + * @connector: connector to check
> + * @state: connector state to check
> + *
> + * Provides core sanity checks for connector state.
> + *
> + * RETURNS:
> + * Zero on success, error code on failure
> + */
> +static int drm_atomic_connector_check(struct drm_connector *connector,
> + struct drm_connector_state *state)
> +{
> + struct drm_crtc_state

Re: [PATCH 3/5] drm/armada: Construct a temporary crtc state for plane checks

[Ville Syrjälä]

On Fri, Feb 02, 2018 at 05:10:54PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 02, 2018 at 04:10:39PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 23, 2018 at 09:02:35PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 23, 2018 at 06:42:00PM +, Russell King - ARM Linux wrote:
> > > > On Tue, Jan 23, 2018 at 07:08:55PM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä 
> > > > > 
> > > > > As armada isn't an atomic driver trying to pass a non-populated
> > > > > crtc->state to drm_atomic_helper_check_plane_state() will end in 
> > > > > tears.
> > > > > Construct a temporary crtc state a la drm_plane_helper_check_update()
> > > > > and pass that instead. For now we just really need crtc_state->enable
> > > > > to be there.
> > > > 
> > > > Would it be possible to solve this by having the atomic state setup
> > > > for non-atomic drivers instead, so we're not unwinding some of the
> > > > work that's already been done to try and convert drivers /to/
> > > > atomic modeset?
> > > 
> > > Dunno. Feels like a wasted effort adding more code that'll just get
> > > ripped out as soon as the atomic conversion happens. And I'd rather
> > > not have to worry about potentially stale states hanging around, in
> > > case you forgot to update something somewhere.
> > > 
> > > In any case, I don't think this is unwinding anything. Once you have
> > > the atomic conversion done sufficiently you can just drop these
> > > temporary states. We already have the temp state for the plane here
> > > anyway, and pairing that with a crtc state seems rather logical.
> > 
> > So yea or nay on these armada patches?
> 
> Also cc:ing Lucas since apparently armada is somehow related to
> etnaviv...
> 
> I have my doubts about the current code working at all (due to
> the conflict resolution between my refactoring and rmk's work).

Ping. I'd like to get the final piece merged at some point. armada
is holding that back.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #17 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
The description of what/how it happens and the backtraces:


-able to login remotely via ssh.

-I tried to reset the gpu by using /sys/kernel/debug/dri/0/amdgpu_gpu_reset,
and the result is a NULL pointer dereference in the kernel. (I did that and had
almost the same result)


This is definitely out of my expertise :), I just dont want to waste 2x
developers time.

Thanks again

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #16 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Ricardo Ribalda from comment #14)
> Please bare in mind that #151341 seems very related, [...]

What makes you think so? If it's that the backtraces look similar, that's just
a generic symptom of a GPU hang, which can be caused by lots of different
things.

-- 
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

Re: [Freedreno] [PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

[Jordan Crouse]

On Fri, Feb 23, 2018 at 04:06:39PM +0530, Vivek Gautam wrote:
> On Fri, Feb 23, 2018 at 5:22 AM, Jordan Crouse  wrote:
> > On Wed, Feb 07, 2018 at 04:01:19PM +0530, Vivek Gautam wrote:
> >> From: Sricharan R 
> >>
> >> The smmu device probe/remove and add/remove master device callbacks
> >> gets called when the smmu is not linked to its master, that is without
> >> the context of the master device. So calling runtime apis in those places
> >> separately.
> >>
> >> Signed-off-by: Sricharan R 
> >> [vivek: Cleanup pm runtime calls]
> >> Signed-off-by: Vivek Gautam 
> >> ---
> >>  drivers/iommu/arm-smmu.c | 42 ++
> >>  1 file changed, 38 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >> index 9e2f917e16c2..c024f69c1682 100644
> >> --- a/drivers/iommu/arm-smmu.c
> >> +++ b/drivers/iommu/arm-smmu.c
> >> @@ -913,11 +913,15 @@ static void arm_smmu_destroy_domain_context(struct 
> >> iommu_domain *domain)
> >>   struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> >>   struct arm_smmu_device *smmu = smmu_domain->smmu;
> >>   struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
> >> - int irq;
> >> + int ret, irq;
> >>
> >>   if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
> >>   return;
> >>
> >> + ret = pm_runtime_get_sync(smmu->dev);
> >> + if (ret)
> >> + return;
> >> +
> >>   /*
> >>* Disable the context bank and free the page tables before freeing
> >>* it.
> >> @@ -932,6 +936,8 @@ static void arm_smmu_destroy_domain_context(struct 
> >> iommu_domain *domain)
> >>
> >>   free_io_pgtable_ops(smmu_domain->pgtbl_ops);
> >>   __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
> >> +
> >> + pm_runtime_put_sync(smmu->dev);
> >>  }
> >>
> >>  static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> >> @@ -1407,14 +1413,22 @@ static int arm_smmu_add_device(struct device *dev)
> >>   while (i--)
> >>   cfg->smendx[i] = INVALID_SMENDX;
> >>
> >> - ret = arm_smmu_master_alloc_smes(dev);
> >> + ret = pm_runtime_get_sync(smmu->dev);
> >>   if (ret)
> >>   goto out_cfg_free;
> >
> > Hey Vivek, I just hit a problem with this on sdm845. It turns out that
> > pm_runtime_get_sync() returns a positive 1 if the device is already active.
> >
> > I hit this in the GPU code. The a6xx has two platform devices that each use 
> > a
> > different sid on the iommu. The GPU is probed normally from a platform 
> > driver
> > and it in turn initializes the GMU device by way of a phandle.
> >
> > Because the GMU isn't probed with a platform driver we need to call
> > of_dma_configure() on the device to set up the IOMMU for the device which 
> > ends
> > up calling through this path and we discover that the smmu->dev is already
> > powered (pm_runtime_get_sync returns 1).
> >
> > I'm not immediately sure if this is a bug on sdm845 or not because a cursory
> > inspection says that the SMMU device shouldn't be powered at this time but 
> > there
> > might be a connection that I'm not seeing. Obviously if the SMMU was left
> > powered thats a bad thing. But putting that aside it is obvious that this
> > code should be accommodating of the possibility that the device is already
> > powered, and so this should be
> >
> > if (ret < 0)
> > goto out_cfg_free;
> 
> Right, as Tomasz also pointed, we should surely check the negative value of
> pm_runtime_get_sync().

Sorry, I didn't notice that Tomasz had pointed it out as well. I wanted to
quickly get it on the mailing list so you could catch it in your time zone.

> From your description, it may be that the GPU has turned on the smmu, and
> then once if goes and probes the GMU, the GMU device also wants to turn-on
> the same smmu device. But that's already active. So pm_runtime_get_sync()
> returns 1.
> Am i making sense?

My concern is that this is happening during the probe and we shouldn't be
energizing the GPU at this point. But it is entirely possible that the
bus is on for other reasons. I'll do a bit of digging today and see exactly
which device is at fault.


Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #15 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Yep, I noticed the other bug.

Thanks,
Andrey

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #14 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Thanks Andrey

Please bare in mind that #151341 seems very related, so this bug might be
happening in more platforms.

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #13 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Thanks for all the info, I will later try to reproduce it on my CZ setup.

Andrey

-- 
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 105228] Blank screen after loading screen in Shadow of Mordor

[bugzilla-daemon]

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

Jan Ziak <0xe2.0x9a.0...@gmail.com> changed:

   What|Removed |Added

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

--- Comment #1 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
Unable to reproduce. Maybe a Shadow of Mordor update fixed this.

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #12 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 274401
  --> https://bugzilla.kernel.org/attachment.cgi?id=274401&action=edit
glxinfo

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #11 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Distro
I am using Yocto Project

Launching X with:

/etc/init.d/xserver-nodm start
that launches
su -l -c '/etc/xserver-nodm/Xserver &' $USER
that calls xinit internally.


Attaching glxinfo

-- 
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

Re: [PATCH 2/2] drm/ttm: cleanup ttm_tt_create

[Michel Dänzer]

On 2018-02-23 01:25 PM, Christian König wrote:
> Cleanup ttm_tt_create a bit.
> 
> Signed-off-by: Christian König 

Thanks for splitting up the patches! Both are

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #10 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Are you starting X with xstart or xinit or some desktop manager ? Can you also
provide output of glxinfo ? BTW what distro are you running ?

-- 
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

Re: [PATCH v2 0/3] backlight: document sysfs interfaces

[Jonathan Corbet]

On Tue, 6 Feb 2018 13:08:41 +0530
Aishwarya Pant  wrote:

> Patchset contains documentation of the sysfs interfaces for the
> following five backlight drivers-
> 1) lm3639
> 2) adp5520
> 3) adp8860
> 
> It was compiled from data sheets, reading code and git history logs. In v2 of
> the patches, documentation for lp8788 and lp855x devices was dropped as the
> attributes contained debug information.

I've applied the set to the docs tree, thanks.

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

[Bug 105228] Blank screen after loading screen in Shadow of Mordor

[bugzilla-daemon]

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

Bug ID: 105228
   Summary: Blank screen after loading screen in Shadow of Mordor
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: 0xe2.0x9a.0...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Blank screen after [the loading screen which shows the text "Shadow of
Mordor"].

$ glversion
4.5 (Core Profile) Mesa 18.0.0-rc4
AMD Radeon (TM) R9 390 Series (HAWAII / DRM 3.23.0 / 4.15.0, LLVM 5.0.1)

Also, from
https://www.phoronix.com/scan.php?page=article&item=radeon-win10-feb18&num=4 :
"Currently the game hangs on the loading screen"

-- 
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 6/9] drm/xen-front: Introduce DRM/KMS virtual display driver

[Oleksandr Andrushchenko]

On 02/23/2018 05:12 PM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:


+
+struct drm_driver xen_drm_driver = {
+   .driver_features   = DRIVER_GEM | DRIVER_MODESET |
+DRIVER_PRIME | DRIVER_ATOMIC,
+   .lastclose = lastclose,
+   .gem_free_object_unlocked  = free_object,
+   .gem_vm_ops= &xen_drm_vm_ops,
+   .prime_handle_to_fd= drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle= drm_gem_prime_fd_to_handle,
+   .gem_prime_import  = drm_gem_prime_import,
+   .gem_prime_export  = drm_gem_prime_export,
+   .gem_prime_get_sg_table= prime_get_sg_table,
+   .gem_prime_import_sg_table = prime_import_sg_table,
+   .gem_prime_vmap= prime_vmap,
+   .gem_prime_vunmap  = prime_vunmap,
+   .gem_prime_mmap= prime_mmap,
+   .dumb_create   = dumb_create,
+   .fops  = &xendrm_fops,
+   .name  = "xendrm-du",
+   .desc  = "Xen PV DRM Display Unit",
+   .date  = "20161109",

You must have been working on this for a while ;-)

yes, this is true ;)


I assume this needs to be updated.

It can be, but I would either stick to the current value
for historical reasons or would update it in the final version
of the driver, so it reflects the date of issuing ;)

+bool xen_drm_front_drv_is_used(struct platform_device *pdev)
+{
+   struct xen_drm_front_drm_info *drm_info = platform_get_drvdata(pdev);
+   struct drm_device *dev;
+
+   if (!drm_info)
+   return false;
+
+   dev = drm_info->drm_dev;
+   if (!dev)
+   return false;
+
+   /*
+* FIXME: the code below must be protected by drm_global_mutex,
+* but it is not accessible to us. Anyways there is a race condition,
+* but we will re-try.
+*/
+   return dev->open_count != 0;

Would it be a problem, given the race, if you report that the frontend
is not in use, while it actually is?

no, backend will not be able to activate us again

-boris


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

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #9 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
I just have to start up the system and around 1 out of 10 times X will crash
with no human intervention.

X manages to render some of the screen, like the window decorator or the
cursor, but the content of the xterm is missing.

It is more likely to happen when the system is cold :S. I have rarely seen this
happening after a hot reboot.

Not that often: a system that seems to be working fine crashes X after running
dmesg  (or any other command with a lot of text) inside xterm. 

Once the system is frozen, there is no change on the screen and I cannot
alt+ctrl+f1.

-- 
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 99678] [All drivers] Avoid sending unnecessary DVI/HDMI/DisplayPort commands when switching between X11 and Linux console

[bugzilla-daemon]

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

Jan Ziak <0xe2.0x9a.0...@gmail.com> changed:

   What|Removed |Added

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

--- Comment #1 from Jan Ziak <0xe2.0x9a.0...@gmail.com> ---
Fixed (on R9 390 at least).

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #8 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
How you reproduce it and how often does it happen ?

Andrey

-- 
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

Re: [RESEND PATCH v2] Documentation/ABI: add sysfs interface for s6e63m0 lcd driver

[Jonathan Corbet]

On Fri, 23 Feb 2018 18:53:52 +0530
Aishwarya Pant  wrote:

> Document sysfs attributes of s6e63m0 lcd panel driver by looking through
> git logs and reading code.
> 
> Signed-off-by: Aishwarya Pant 

Applied, thanks.

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

Re: [PATCH libdrm v2] *-symbol-check: Don't hard-code nm executable

[Eric Engestrom]

On Friday, 2018-02-23 15:02:44 +, Eric Engestrom wrote:
> On Friday, 2018-02-23 00:25:27 +, Emil Velikov wrote:
> > On 19 February 2018 at 16:35, Eric Engestrom  
> > wrote:
> > > From: Heiko Becker 
> > >
> > > Helpful if your nm executable has a prefix based on the
> > > architecture, for example.
> > >
> > 
> > > +env_test = environment()
> > > +env_test.set('NM', find_program('nm').path())
> > > +
> > Everything else is great, just not too sure about this hunk.
> > Are you sure it does what the commit message says?
> 
> It does, I even asked the meson devs to be sure. find_program()
> respects the crossfile, unless `native: true` is added [2].
> 
> > 
> > I know meson needs special configuration file for cross compilation -
> > one example where nm has prefix.
> > Yet the manual [1] does not say anything about nm. I cannot find any
> > instances of nm in the docs all together :-\
> 
> There's nothing special about `nm` here, it's just a program that can be
> set via the crossfile, like `cc` or `ar`.
> I guess the documentation on the cross-compilation page [1] could be
> improved to make the behaviour of find_program() more explicit; care to
> send a patch? :)
> 
> > 
> > If Meson does not handle it currently, please open a bug and add a
> > comment with the bug number/link.
> > 
> > Thanks
> > Emil
> > [1] http://mesonbuild.com/Cross-compilation.html
> 
> [2] http://mesonbuild.com/Reference-manual.html#find_program

Oh btw, I'm making the same change on Mesa right now, I'll send it out
in a bit, or next week if I don't have enough spare time today.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #7 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Traces obtained with trace-cmd record -e dma_fence:* -e amdgpu:* -e gpu_sched:*

-- 
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

Re: [PATCH libdrm v2] *-symbol-check: Don't hard-code nm executable

[Eric Engestrom]

On Friday, 2018-02-23 00:25:27 +, Emil Velikov wrote:
> On 19 February 2018 at 16:35, Eric Engestrom  
> wrote:
> > From: Heiko Becker 
> >
> > Helpful if your nm executable has a prefix based on the
> > architecture, for example.
> >
> 
> > +env_test = environment()
> > +env_test.set('NM', find_program('nm').path())
> > +
> Everything else is great, just not too sure about this hunk.
> Are you sure it does what the commit message says?

It does, I even asked the meson devs to be sure. find_program()
respects the crossfile, unless `native: true` is added [2].

> 
> I know meson needs special configuration file for cross compilation -
> one example where nm has prefix.
> Yet the manual [1] does not say anything about nm. I cannot find any
> instances of nm in the docs all together :-\

There's nothing special about `nm` here, it's just a program that can be
set via the crossfile, like `cc` or `ar`.
I guess the documentation on the cross-compilation page [1] could be
improved to make the behaviour of find_program() more explicit; care to
send a patch? :)

> 
> If Meson does not handle it currently, please open a bug and add a
> comment with the bug number/link.
> 
> Thanks
> Emil
> [1] http://mesonbuild.com/Cross-compilation.html

[2] http://mesonbuild.com/Reference-manual.html#find_program
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #6 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 274399
  --> https://bugzilla.kernel.org/attachment.cgi?id=274399&action=edit
trace.txt

-- 
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 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

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

--- Comment #5 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Created attachment 274397
  --> https://bugzilla.kernel.org/attachment.cgi?id=274397&action=edit
trace.dat

-- 
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

Re: [PATCH v5 8/9] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Thu, Feb 15, 2018 at 05:51:01PM +0530, Nautiyal, Ankit K wrote:
> From: "Sharma, Shashank" 
> 
> Current DRM layer functions don't parse aspect ratio information
> while converting a user mode->kernel mode or vice versa. This
> causes modeset to pick mode with wrong aspect ratio, eventually
> causing failures in HDMI compliance test cases, due to wrong VIC.
> 
> This patch adds aspect ratio information in DRM's mode conversion
> and mode comparision functions, to make sure kernel picks mode
> with right aspect ratio (as per the VIC).
> 
> Background:
> This patch was once reviewed and merged, and later reverted due to
> lack of DRM cap protection. This is a re-spin of this patch, this
> time with DRM cap protection, to avoid aspect ratio information, when
> the client doesn't request for it.
> 
> Review link: https://pw-emeril.freedesktop.org/patch/104068/
> Background discussion: https://patchwork.kernel.org/patch/9379057/
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lin, Jia 
> Signed-off-by: Akashdeep Sharma 
> Reviewed-by: Jim Bride  (V2)
> Reviewed-by: Jose Abreu  (V4)
> 
> Cc: Ville Syrjala 
> Cc: Jim Bride 
> Cc: Jose Abreu 
> Cc: Ankit Nautiyal 
> 
> V3: modified the aspect-ratio check in drm_mode_equal as per new flags
> provided by Ville. https://patchwork.freedesktop.org/patch/188043/
> V4: rebase
> V5: rebase
> ---
>  drivers/gpu/drm/drm_modes.c | 33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ca4c5cc..25140b9 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1050,7 +1050,8 @@ bool drm_mode_equal(const struct drm_display_mode 
> *mode1,
> DRM_MODE_MATCH_TIMINGS |
> DRM_MODE_MATCH_CLOCK |
> DRM_MODE_MATCH_FLAGS |
> -   DRM_MODE_MATCH_3D_FLAGS);
> +   DRM_MODE_MATCH_3D_FLAGS|
> +   DRM_MODE_MATCH_ASPECT_RATIO);

Hmm. I wonder if all the users are expecting this. Based on a cursory
examination drm_fb_helper might want to ignore the aspect ratio since
it's just looking to clone the same mode on multiple outputs. The other
cases don't look to me like they should suffer badly from this.

>  }
>  EXPORT_SYMBOL(drm_mode_equal);
>  
> @@ -1649,6 +1650,21 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
>   out->vrefresh = in->vrefresh;
>   out->flags = in->flags;
>   out->type = in->type;
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;

This looks redundant. The internal mode should not have the aspect ratio
flags set. Or are we changing that?

> +
> + switch (in->picture_aspect_ratio) {
> + case HDMI_PICTURE_ASPECT_4_3:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> + break;
> + case HDMI_PICTURE_ASPECT_16_9:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> + break;
> + case HDMI_PICTURE_ASPECT_RESERVED:
> + default:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> + break;
> + }
> +
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  }
> @@ -1693,6 +1709,21 @@ int drm_mode_convert_umode(struct drm_device *dev,
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  
> + /* Clearing picture aspect ratio bits from out flags */

What the code is doing is obvious so this comment is redundant.
The non-obvious part (ie. the "why?") is what the comment
should contain.

> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> + case DRM_MODE_FLAG_PIC_AR_4_3:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
> + break;
> + case DRM_MODE_FLAG_PIC_AR_16_9:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> + break;
> + default:
> + out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + break;
> + }
> +
>   out->status = drm_mode_validate_driver(dev, out);
>   if (out->status != MODE_OK)
>   goto out;
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 02/23/2018 04:39 PM, Boris Ostrovsky wrote:

On 02/23/2018 01:37 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 12:23 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+static struct xenbus_driver xen_driver = {
+.ids = xen_drv_ids,
+.probe = xen_drv_probe,
+.remove = xen_drv_remove,
+.otherend_changed = backend_on_changed,

What does "_on_" stand for?

Well, it is somewhat like a hint that this is called "on" event,
e.g. event when the other end state has changed, backend in this
case. It could be something like "backend_on_state_changed"

If you look at other xenbus_drivers none of the uses this so I think we
should stick to conventional naming. (and the same applies to other
backend_on_* routines).

ok, no problem. will rename to be aligned with other frontends


-boris


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

Re: [PATCH 4/9] drm/xen-front: Implement Xen event channel handling

[Oleksandr Andrushchenko]

On 02/23/2018 04:44 PM, Boris Ostrovsky wrote:

On 02/23/2018 02:00 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+
+static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
+{
+struct xen_drm_front_evtchnl *evtchnl = dev_id;
+struct xen_drm_front_info *front_info = evtchnl->front_info;
+struct xendispl_resp *resp;
+RING_IDX i, rp;
+unsigned long flags;
+
+spin_lock_irqsave(&front_info->io_lock, flags);
+
+if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED))
+goto out;

Do you need to check the state under lock? (in other routines too).

not really, will move out of the lock in interrupt handlers
other places (I assume you refer to be_stream_do_io)


I was mostly referring to evtchnl_interrupt_evt().

ah, then we are on the same page: I will move the check
in interrupt handlers

-boris



it is set under lock as a part of atomic operation, e.g.
we get a new request pointer from the ring and reset completion
So, those places still seem to be ok


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

[PATCH] drm/amdgpu: replace iova debugfs file with iomem (v3)

[Tom St Denis]

This allows access to pages allocated through the driver with optional
IOMMU mapping.

v2: Fix number of bytes copied and add write method
v3: drop check for kmap return

Original-by: Christian König 
Signed-off-by: Tom St Denis 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 102 +---
 1 file changed, 81 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b372d8d650a5..1338c908056f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,98 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
 
 #endif
 
-static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
-  size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+size_t size, loff_t *pos)
 {
struct amdgpu_device *adev = file_inode(f)->i_private;
-   int r;
-   uint64_t phys;
struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
 
-   // always return 8 bytes
-   if (size != 8)
-   return -EINVAL;
+   dom = iommu_get_domain_for_dev(adev->dev);
 
-   // only accept page addresses
-   if (*pos & 0xFFF)
-   return -EINVAL;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
+
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
+
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   r = copy_to_user(buf, ptr, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
+}
+
+static ssize_t amdgpu_iomem_write(struct file *f, const char __user *buf,
+size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
 
dom = iommu_get_domain_for_dev(adev->dev);
-   if (dom)
-   phys = iommu_iova_to_phys(dom, *pos);
-   else
-   phys = *pos;
 
-   r = copy_to_user(buf, &phys, 8);
-   if (r)
-   return -EFAULT;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
+
+   bytes = bytes < size ? bytes : size;
 
-   return 8;
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
+
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   r = copy_from_user(ptr, buf, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
+
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
 }
 
-static const struct file_operations amdgpu_ttm_iova_fops = {
+static const struct file_operations amdgpu_ttm_iomem_fops = {
.owner = THIS_MODULE,
-   .read = amdgpu_iova_to_phys_read,
+   .read = amdgpu_iomem_read,
+   .write = amdgpu_iomem_write,
.llseek = default_llseek
 };
 
@@ -1973,7 +2033,7 @@ static const struct {
 #ifdef CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", &amdgpu_ttm_gtt_fops, TTM_PL_TT },
 #endif
-   { "amdgpu_iova", &amdgpu_ttm_iova_fops, TTM_PL_SYSTEM },
+   { "amdgpu_iomem", &amdgpu_ttm_iomem_fops, TTM_PL_SYSTEM },
 };
 
 #endif
-- 
2.14.3

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

Re: [PATCH 5/9] drm/xen-front: Implement handling of shared display buffers

[Oleksandr Andrushchenko]

On 02/23/2018 04:36 PM, Boris Ostrovsky wrote:

On 02/23/2018 02:53 AM, Oleksandr Andrushchenko wrote:

On 02/23/2018 02:25 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

 static int __init xen_drv_init(void)
   {
+/* At the moment we only support case with XEN_PAGE_SIZE ==
PAGE_SIZE */
+BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);

Why BUILD_BUG_ON? This should simply not load if page sizes are
different.

   

This is a compile time check, so if kernel/Xen is configured
to use page size combination which is not supported by the
driver it will fail during compilation. This seems correct to me,
because you shouldn't even try to load the driver which
cannot handle different page sizes to not make any harm.


This will prevent whole kernel from building. So, for example,
randconfig builds will fail.


makes a lot of sense, thank you
will rework so I reject to load if the requirement is not met




+ret = gnttab_map_refs(map_ops, NULL, buf->pages, buf->num_pages);
+BUG_ON(ret);

We should try not to BUG*(). There are a few in this patch (and possibly
others) that I think can be avoided.


I will rework BUG_* for map/unmap code to handle errors,
but will still leave
 /* either pages or sgt, not both */
 BUG_ON(cfg->pages && cfg->sgt);
which is a real driver bug and must not happen

Why not return an error?

In fact, AFAICS you only call it in patch 9 where both of these can be
tested, in which case something like -EINVAL would look reasonable.

ok, will remove BUG_ON as well

-boris


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

[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled

[bugzilla-daemon]

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

--- Comment #12 from Harry Wentland (harry.wentl...@amd.com) ---
It looks like we detect no display. We haven't yet had a chance to repro the
problem. I'll see if I can find this display in the office.

It'd be difficult debugging this remotely but if I can't repro this I might
send you some extra logging patches in the hopes of getting more info.

-- 
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

Re: [PATCH v5 7/9] drm: Expose modes with aspect ratio, only if requested

[Ville Syrjälä]

On Thu, Feb 15, 2018 at 05:51:00PM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> We parse the EDID and add all the modes in the connector's modelist.
> This adds CEA modes with aspect ratio information too, regadless of
> whether user space requested this information or not.
> 
> This patch prunes the modes with aspect-ratio information, from a
> connector's modelist, if the user-space has not set the aspect ratio
> DRM client cap.
> 
> Cc: Ville Syrjala 
> Cc: Shashank Sharma 
> Cc: Jose Abreu 
> 
> Signed-off-by: Ankit Nautiyal 
> 
> V3: As suggested by Ville, modified the mechanism of pruning of modes
> with aspect-ratio, if the aspect-ratio is not supported. Instead
> of straight away pruning such a mode, the mode is retained with
> aspect ratio bits set to zero, provided it is unique.
> V4: rebase
> V5: Addressed review comments from Ville:
> -used a pointer to store last valid mode.
> -avoided, modifying of picture_aspect_ratio in kernel mode,
>  instead only flags bits of user mode are reset (if aspect-ratio
>  is not supported).
> ---
>  drivers/gpu/drm/drm_connector.c | 45 
> -
>  1 file changed, 40 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 16b9c38..49778e8 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1507,8 +1507,10 @@ static struct drm_encoder 
> *drm_connector_get_encoder(struct drm_connector *conne
>   return connector->encoder;
>  }
>  
> -static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
> -  const struct drm_file *file_priv)
> +static bool
> +drm_mode_expose_to_userspace(const struct drm_display_mode *last_mode,
> +  const struct drm_display_mode *mode,

I would put the 'mode' argument first since that's the "main" object
we're operating on.

> +  const struct drm_file *file_priv)
>  {
>   /*
>* If user-space hasn't configured the driver to expose the stereo 3D
> @@ -1516,6 +1518,23 @@ static bool drm_mode_expose_to_userspace(const struct 
> drm_display_mode *mode,
>*/
>   if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
>   return false;
> + /*
> +  * If user-space hasn't configured the driver to expose the modes
> +  * with aspect-ratio, don't expose them. But in case of a unique
> +  * mode, let the mode be passed, so that it can be enumerated with
> +  * aspect ratio bits erased.

Might want to note that we expect the list to be sorted such that modes
that have different aspect ratio but are otherwise identical are back to
back.

> +  */
> + if (!file_priv->aspect_ratio_allowed &&
> + mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE) {
> + if (last_mode && !drm_mode_match(mode, last_mode,
> +  DRM_MODE_MATCH_TIMINGS |
> +  DRM_MODE_MATCH_CLOCK |
> +  DRM_MODE_MATCH_FLAGS |
> +  DRM_MODE_MATCH_3D_FLAGS))
> + return true;
> + else
> + return false;

How does that even work? It'll return false as long as
last_mode==NULL, and last_mode never becomes non-NULL unless
we return true.

To me it looks like the correct logic would be:
if (last_mode && drm_mode_match(...))
return false;

> + }
>  
>   return true;
>  }
> @@ -1527,6 +1546,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
>   struct drm_connector *connector;
>   struct drm_encoder *encoder;
>   struct drm_display_mode *mode;
> + struct drm_display_mode *last_valid_mode;
>   int mode_count = 0;
>   int encoders_count = 0;
>   int ret = 0;
> @@ -1582,9 +1602,13 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
>   out_resp->connection = connector->status;
>  
>   /* delayed so we get modes regardless of pre-fill_modes state */
> + last_valid_mode = NULL;
>   list_for_each_entry(mode, &connector->modes, head)
> - if (drm_mode_expose_to_userspace(mode, file_priv))
> + if (drm_mode_expose_to_userspace(last_valid_mode, mode,
> +  file_priv)) {
>   mode_count++;
> + last_valid_mode = mode;
> + }
>  
>   /*
>* This ioctl is called twice, once to determine how much space is
> @@ -1593,11 +1617,21 @@ int drm_mode_getconnector(struct drm_device *dev, 
> void *data,
>   if ((out_resp->count_modes >= mode_count) && mode_count) {
>   copied = 0;
>   mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
> long)out_resp->modes_ptr;
> + l

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

[Stefan Schake]

Hey Eric,

On Thu, Feb 22, 2018 at 9:47 PM, Eric Anholt  wrote:
> Stefan Schake  writes:
>
>> Android assumes an implicit black background layer is always present
>> behind all layers it specifies for composition. drm_hwcomposer currently
>> punts responsibility for this to the kernel/DRM platform and puts layers
>> with per-pixel alpha content on the primary plane when requested.
>>
>> On some platforms (e.g. VC4) a background color fill has a cycle cost for
>> the hardware composer and is not enabled by default. Instead, userland can
>> request a background color through a CRTC property. Use this property to
>> specify the implicit black background Android expects.
>>
>> Signed-off-by: Stefan Schake 
>> ---
>> Kernel changes for this (background_color) are available here:
>>
>> https://github.com/stschake/linux/commits/background-upstream
>>
>> Sending as RFC because I'm not entirely clear on whose responsibility
>> this should be, on most DRM drivers it seems to be implicit. I think
>> a case could also be made that VC4 should not accept alpha formats on
>> the lowest layer or enable background color fill when given one anyway.
>> On the other hand, userland control over background color seems desirable
>> regardless and is a feature of multiple hardware composers (i915, vc4, omap).
>
> Couldn't we just ignore the alpha channel on the primary plane, on the
> assumption that it's supposed to be all zeroes below it?  Or are we not
> premultiplied, so we do still need to multiply the primary plane's
> colors by the alpha value?  I couldn't find any obvious DRM
> documentation about whether alpha is premultiplied.

That would work, too (for a black background anyway). Though the easiest place
to spoof this is presumably in the kernel. From what I have seen, everything in
Android is already premultiplied, but technically it can specify
either. Not sure if this
is correctly handled in drm_hwcomposer yet.

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

[Bug 105227] [SUMO][TURKS] observer game cause GPU lockup

[bugzilla-daemon]

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

--- Comment #1 from russianneuroman...@ya.ru ---
Created attachment 137558
  --> https://bugs.freedesktop.org/attachment.cgi?id=137558&action=edit
dmesg from launch on Radeon HD 6620G

-- 
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 105227] [SUMO][TURKS] observer game cause GPU lockup

[bugzilla-daemon]

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

Bug ID: 105227
   Summary: [SUMO][TURKS] observer game cause GPU lockup
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: russianneuroman...@ya.ru
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137557
  --> https://bugs.freedesktop.org/attachment.cgi?id=137557&action=edit
dmesg from launch on Radeon HD 6650M

Hi!

Game "observer" cause GPU lockup on Radeon HD 6620G and 6650M GPUs with Mesa
18.1 4562a7b0e82bf664 - dmesg from two launch attempts is attached. Graphical
settings is all set to minimal, all visual effects is disabled.

[  386.552620] radeon :01:00.0: ring 0 stalled for more than 10288msec
[  386.552638] radeon :01:00.0: GPU lockup (current fence id
0x147b last fence id 0x1487 on ring 0)
[  387.064666] radeon :01:00.0: ring 0 stalled for more than 10800msec
[  387.064683] radeon :01:00.0: GPU lockup (current fence id
0x147b last fence id 0x1487 on ring 0)
[  387.416749] radeon :01:00.0: ring 3 stalled for more than 10036msec
[  387.416765] radeon :01:00.0: GPU lockup (current fence id
0x1001 last fence id 0x1002 on ring 3)
[  387.576741] radeon :01:00.0: ring 0 stalled for more than 11312msec
[  387.576758] radeon :01:00.0: GPU lockup (current fence id
0x147b last fence id 0x1487 on ring 0)
[  387.928798] radeon :01:00.0: ring 3 stalled for more than 10548msec
[  387.928814] radeon :01:00.0: GPU lockup (current fence id
0x1001 last fence id 0x1002 on ring 3)

To reproduce GPU lockup:
1. Launch game like this: MESA_GL_VERSION_OVERRIDE=4.3
MESA_GLSL_VERSION_OVERRIDE=430 %command% (otherwise it crash before launch)
2. Select New game, wait until loading completed.
3. After loading completed press space or left mouse button.

Hardware: 
Acer Aspire 7560G, AMD A8-3500M
AMD Radeon HD 6620G iGPU, AMD Radeon HD 6650M dGPU.

Software:
Kubuntu 17.10 x86_64, Linux 4.15.5, Mesa 18.1 4562a7b0e82bf664

-- 
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 v5 6/9] drm: Handle aspect ratio info in legacy and atomic modeset paths

[Ville Syrjälä]

On Thu, Feb 15, 2018 at 05:50:59PM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> If the user-space does not support aspect-ratio, and requests for a
> modeset with mode having aspect ratio bits set, then the given
> user-mode must be rejected. Secondly, while preparing a user-mode from
> kernel mode, the aspect-ratio info must not be given, if aspect-ratio
> is not supported by the user.
> 
> This patch:
> 1. passes the file_priv structure from the drm_mode_atomic_ioctl till
>the drm_mode_crtc_set_mode_prop, to get the user capability.
> 2. rejects the modes with aspect-ratio info, during modeset, if the
>user does not support aspect ratio.
> 3. does not load the aspect-ratio info in user-mode structure, if
>aspect ratio is not supported.
> 
> Signed-off-by: Ankit Nautiyal 
> 
> V3: Addressed review comments from Ville:
> Do not corrupt the current crtc state by updating aspect ratio on
> the fly.
> V4: rebase
> V5: As suggested by Ville, rejected the modeset calls for modes with
> aspect ratio, if the user does not set aspect ratio cap.
> ---
>  drivers/gpu/drm/drm_atomic.c| 30 ++
>  drivers/gpu/drm/drm_atomic_helper.c |  6 +++---
>  drivers/gpu/drm/drm_crtc.c  | 15 +++
>  drivers/gpu/drm/drm_crtc_internal.h |  3 ++-
>  drivers/gpu/drm/drm_mode_object.c   |  9 ++---
>  drivers/gpu/drm/drm_modes.c |  1 +
>  include/drm/drm_atomic.h|  5 +++--
>  7 files changed, 52 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 86b483e..7e78305 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -368,6 +368,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
>   * drm_atomic_set_mode_prop_for_crtc - set mode for CRTC
>   * @state: the CRTC whose incoming state to update
>   * @blob: pointer to blob property to use for mode
> + * @file_priv: file priv structure, to get the userspace capabilities
>   *
>   * Set a mode (originating from a blob property) on the desired CRTC state.
>   * This function will take a reference on the blob property for the CRTC 
> state,
> @@ -378,7 +379,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
>   * Zero on success, error code on failure. Cannot return -EDEADLK.
>   */
>  int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
> -  struct drm_property_blob *blob)
> +   struct drm_property_blob *blob,
> +   struct drm_file *file_priv)
>  {
>   if (blob == state->mode_blob)
>   return 0;
> @@ -389,10 +391,20 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
> drm_crtc_state *state,
>   memset(&state->mode, 0, sizeof(state->mode));
>  
>   if (blob) {
> + struct drm_mode_modeinfo *u_mode;
> +
> + u_mode = (struct drm_mode_modeinfo *) blob->data;
> + if (!file_priv->aspect_ratio_allowed &&
> + (u_mode->flags & DRM_MODE_FLAG_PIC_AR_MASK) !=
> + DRM_MODE_FLAG_PIC_AR_NONE) {
> + DRM_DEBUG_ATOMIC("Unexpected aspect-ratio flag bits\n");
> + return -EINVAL;
> + }

We should probably pull this logic into a small helper so that we don't
have to duplicate it in both the setprop and setcrtc code paths.

> +
>   if (blob->length != sizeof(struct drm_mode_modeinfo) ||

The blob length check has to be done before you access the data.

>   drm_mode_convert_umode(state->crtc->dev, &state->mode,
> -(const struct drm_mode_modeinfo *)
> - blob->data))
> +(const struct drm_mode_modeinfo *)
> +u_mode))
>   return -EINVAL;
>  
>   state->mode_blob = drm_property_blob_get(blob);
> @@ -441,6 +453,7 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_device *dev,
>   * @state: the state object to update with the new property value
>   * @property: the property to set
>   * @val: the new property value
> + * @file_priv: the file private structure, to get the user capabilities
>   *
>   * This function handles generic/core properties and calls out to driver's
>   * &drm_crtc_funcs.atomic_set_property for driver properties. To ensure
> @@ -452,7 +465,7 @@ drm_atomic_replace_property_blob_from_id(struct 
> drm_device *dev,
>   */
>  int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   struct drm_crtc_state *state, struct drm_property *property,
> - uint64_t val)
> + uint64_t val, struct drm_file *file_priv)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_mode_config *config = &dev->mode_config;
> @@ -465,7 +478,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

On Fri, Feb 23, 2018 at 09:24:10AM -0500, Rob Clark wrote:
> On Fri, Feb 23, 2018 at 9:00 AM, Liviu Dudau  wrote:
> > Hi Rob,
> >
> > On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> >> From: Brian Starkey 
> >>
> >> Writeback connectors represent writeback engines which can write the
> >> CRTC output to a memory framebuffer. Add a writeback connector type and
> >> related support functions.
> >>
> >> Drivers should initialize a writeback connector with
> >> drm_writeback_connector_init() which takes care of setting up all the
> >> writeback-specific details on top of the normal functionality of
> >> drm_connector_init().
> >>
> >> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> >> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> >> supported writeback formats to userspace.
> >>
> >> When a framebuffer is attached to a writeback connector with the
> >> WRITEBACK_FB_ID property, it is used only once (for the commit in which
> >> it was included), and userspace can never read back the value of
> >> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> >> attached to a CRTC.
> >
> > [snip]
> >
> >> +static bool create_writeback_properties(struct drm_device *dev)
> >> +{
> >> + struct drm_property *prop;
> >> +
> >> + if (!dev->mode_config.writeback_fb_id_property) {
> >> + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> >> +   "WRITEBACK_FB_ID",
> >> +   DRM_MODE_OBJECT_FB);
> >> + if (!prop)
> >> + return false;
> >> + dev->mode_config.writeback_fb_id_property = prop;
> >> + }
> >> +
> >> + if (!dev->mode_config.writeback_pixel_formats_property) {
> >> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> >> DRM_MODE_PROP_IMMUTABLE,
> >> +"WRITEBACK_PIXEL_FORMATS", 0);
> >> + if (!prop)
> >> + return false;
> >> + dev->mode_config.writeback_pixel_formats_property = prop;
> >> + }
> >> +
> >> + return true;
> >> +}
> >
> > based on a buildbot warning and the fact that the next patch starts
> > returning -ENOMEM inside the above function, I have this variant in my
> > internal tree that I was preparing to send out once I've got my i-g-t
> > tests in better shape:
> >
> > +static int create_writeback_properties(struct drm_device *dev)
> > +{
> > +   struct drm_property *prop;
> > +
> > +   if (!dev->mode_config.writeback_fb_id_property) {
> > +   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> > + "WRITEBACK_FB_ID",
> > + DRM_MODE_OBJECT_FB);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +   dev->mode_config.writeback_fb_id_property = prop;
> > +   }
> > +
> > +   if (!dev->mode_config.writeback_pixel_formats_property) {
> > +   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> > DRM_MODE_PROP_IMMUTABLE,
> > +  "WRITEBACK_PIXEL_FORMATS", 0);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +   dev->mode_config.writeback_pixel_formats_property = prop;
> > +   }
> > +
> > +   return 0;
> > +}
> >
> >
> > Feel free to use this version in the next update if you're going to send
> > one, otherwise I guess we could be patching it later.
> >
> 
> hmm, I meant to keep my addition of funcs->atomic_commit() as a
> separate fixup patch so it would be easier for you to fold back into
> your patchset, but accidentally squashed it at some point and was too
> lazy to split it out again.  Sorry about that.

I'm not too fussed about who pushes Brian's framework patches into
drm-next so I don't mind at all you merging your addition. Just wanted
to make sure we're on the same page (didn't know you're going to send
your series this week).

I also feel I need to appologise for my delay in getting the i-g-t
patches into shape, I've been splitting myself between various other
tasks, not all kernel related.

Best regards,
Liviu

> 
> BR,
> -R
> 
> > Best regards,
> > Liviu
> >
> >
> >> +
> >> +static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
> >> + .destroy = drm_encoder_cleanup,
> >> +};
> >> +
> >> +/**
> >> + * drm_writeback_connector_init - Initialize a writeback connector and 
> >> its properties
> >> + * @dev: DRM device
> >> + * @wb_connector: Writeback connector to initialize
> >> + * @con_funcs: Connector funcs vtable
> >> + * @enc_helper_funcs: Encoder helper funcs vtable to be used by the 
> >> internal encoder
> >> + * @formats: Array of supported pixel formats for the writeback engine
> >> + * @n_formats: Length of the formats array
> >> + *
> >> + * This

[Bug 198885] amdgpu.dc=1 on CIK (R4 Mullins APU) brightness impossible to change. by Fn or "echo".

[bugzilla-daemon]

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

--- Comment #4 from Harry Wentland (harry.wentl...@amd.com) ---
Thanks for reporting this. It's currently not hooked up for ASICs older than
Carrizo. We'll take a look. 

You're right that it clashes with the kernel's 'no regressions' policy should
we change pre-VEGA ASIC support with DC to enabled by default.

-- 
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

Re: [RFC 1/4] drm: Add writeback connector type

[Rob Clark]

On Fri, Feb 23, 2018 at 9:00 AM, Liviu Dudau  wrote:
> Hi Rob,
>
> On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
>> From: Brian Starkey 
>>
>> Writeback connectors represent writeback engines which can write the
>> CRTC output to a memory framebuffer. Add a writeback connector type and
>> related support functions.
>>
>> Drivers should initialize a writeback connector with
>> drm_writeback_connector_init() which takes care of setting up all the
>> writeback-specific details on top of the normal functionality of
>> drm_connector_init().
>>
>> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
>> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
>> supported writeback formats to userspace.
>>
>> When a framebuffer is attached to a writeback connector with the
>> WRITEBACK_FB_ID property, it is used only once (for the commit in which
>> it was included), and userspace can never read back the value of
>> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
>> attached to a CRTC.
>
> [snip]
>
>> +static bool create_writeback_properties(struct drm_device *dev)
>> +{
>> + struct drm_property *prop;
>> +
>> + if (!dev->mode_config.writeback_fb_id_property) {
>> + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
>> +   "WRITEBACK_FB_ID",
>> +   DRM_MODE_OBJECT_FB);
>> + if (!prop)
>> + return false;
>> + dev->mode_config.writeback_fb_id_property = prop;
>> + }
>> +
>> + if (!dev->mode_config.writeback_pixel_formats_property) {
>> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
>> DRM_MODE_PROP_IMMUTABLE,
>> +"WRITEBACK_PIXEL_FORMATS", 0);
>> + if (!prop)
>> + return false;
>> + dev->mode_config.writeback_pixel_formats_property = prop;
>> + }
>> +
>> + return true;
>> +}
>
> based on a buildbot warning and the fact that the next patch starts
> returning -ENOMEM inside the above function, I have this variant in my
> internal tree that I was preparing to send out once I've got my i-g-t
> tests in better shape:
>
> +static int create_writeback_properties(struct drm_device *dev)
> +{
> +   struct drm_property *prop;
> +
> +   if (!dev->mode_config.writeback_fb_id_property) {
> +   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> + "WRITEBACK_FB_ID",
> + DRM_MODE_OBJECT_FB);
> +   if (!prop)
> +   return -ENOMEM;
> +   dev->mode_config.writeback_fb_id_property = prop;
> +   }
> +
> +   if (!dev->mode_config.writeback_pixel_formats_property) {
> +   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> DRM_MODE_PROP_IMMUTABLE,
> +  "WRITEBACK_PIXEL_FORMATS", 0);
> +   if (!prop)
> +   return -ENOMEM;
> +   dev->mode_config.writeback_pixel_formats_property = prop;
> +   }
> +
> +   return 0;
> +}
>
>
> Feel free to use this version in the next update if you're going to send
> one, otherwise I guess we could be patching it later.
>

hmm, I meant to keep my addition of funcs->atomic_commit() as a
separate fixup patch so it would be easier for you to fold back into
your patchset, but accidentally squashed it at some point and was too
lazy to split it out again.  Sorry about that.

BR,
-R

> Best regards,
> Liviu
>
>
>> +
>> +static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
>> + .destroy = drm_encoder_cleanup,
>> +};
>> +
>> +/**
>> + * drm_writeback_connector_init - Initialize a writeback connector and its 
>> properties
>> + * @dev: DRM device
>> + * @wb_connector: Writeback connector to initialize
>> + * @con_funcs: Connector funcs vtable
>> + * @enc_helper_funcs: Encoder helper funcs vtable to be used by the 
>> internal encoder
>> + * @formats: Array of supported pixel formats for the writeback engine
>> + * @n_formats: Length of the formats array
>> + *
>> + * This function creates the writeback-connector-specific properties if they
>> + * have not been already created, initializes the connector as
>> + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
>> + * values. It will also create an internal encoder associated with the
>> + * drm_writeback_connector and set it to use the @enc_helper_funcs vtable 
>> for
>> + * the encoder helper.
>> + *
>> + * Drivers should always use this function instead of drm_connector_init() 
>> to
>> + * set up writeback connectors.
>> + *
>> + * Returns: 0 on success, or a negative error code
>> + */
>> +int drm_writeback_connector_init(struct drm_device *dev,
>> +  struct drm_wri

Re: [PATCH 5/7] vga_switcheroo: Use device link for HDA controller

[Bjorn Helgaas]

[+cc George]

On Fri, Feb 23, 2018 at 10:51:47AM +0100, Lukas Wunner wrote:
> On Tue, Feb 20, 2018 at 04:20:59PM -0600, Bjorn Helgaas wrote:
> > On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> > > The device link is added in a PCI quirk rather than in hda_intel.c.
> > > It is therefore legal for the GPU to runtime suspend to D3cold even if
> > > the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
> > > is not enabled, for accesses to the HDA controller will cause the GPU to
> > > wake up regardless if they're occurring outside of hda_intel.c (think
> > > config space readout via sysfs).
> > 
> > I guess this GPU wakeup happens *if* the path accessing the HDA
> > controller calls pm_runtime_get_sync() or similar, right?
> 
> Right.
> 
> > We do have
> > that in the sysfs config accessors via pci_config_pm_runtime_get(),
> > but not in the sysfs mmap paths.  I think that's a latent PCI core
> > defect independent of this series.
> 
> Yes, there may be a few places where the parent of the device is
> erroneously not runtime resumed when sysfs files are accessed.
> I've never used the sysfs mmap feature, so never witnessed issues
> with it.
> 
> > We also don't have that in PCI core config accessors.  That maybe
> > doesn't matter because the core probably shouldn't be touching devices
> > after enumeration (although there might be holes there for things like
> > ASPM where a sysfs file can cause reconfiguration of several devices).
> 
> I assume with PCI core config accessors you're referring to
> pci_read_config_word() and friends?  Those are arguably hotpaths
> where we wouldn't want the overhead to check runtime PM status
> everytime.  They might also be called from atomic context, I'm
> not sure, and the runtime PM callbacks may sleep by default
> (unless pm_runtime_irq_safe() was called).

Yes, I was thinking of pci_read_config_word(), etc.  They're used by
the core during enumeration and occasionally by drivers, and both
cases already pay attention to PM.  I think we have a few holes in the
runtime sysfs area, but I think it's reasonable to deal with those in
the callers.

So I don't think those need to actually *do* anything with PM status,
although it might be interesting to add some (optional) checking
there.  George Cherian is turning up some issues in this area because
he has a root port that reports errors with an exception instead of
silently synthesizing all ones data like most hardware does [1].

Bjorn

[1] 
https://lkml.kernel.org/r/1517554846-16703-1-git-send-email-george.cher...@cavium.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 5/9] drm: Handle aspect-ratio info in getblob

[Ville Syrjälä]

On Thu, Feb 15, 2018 at 05:50:58PM +0530, Nautiyal, Ankit K wrote:
> From: Ankit Nautiyal 
> 
> If the user space  does not support aspect-ratio, then getblob called
> with the blob id of a user mode, should clear the aspect ratio
> information in the blob data.
> 
> Currently for a given blob id, there is no way to determine if the
> blob stores user mode or not. This can only be ascertained when the
> blob is used for an atomic modeset call.
> 
> This patch:
> -adds a new field 'is_video_mode' in drm_property_blob to
>  differentiate between the video mode blobs and the other blobs.
> -sets the field 'is_video_mode' when the blob is used for modeset.
> -removes the aspect-ratio info from the mode data if aspect ratio is
>  not supported by the user, while returning the blob to the user, in
>  getblob ioctl.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/drm_atomic.c   | 1 +
>  drivers/gpu/drm/drm_property.c | 6 ++
>  include/drm/drm_property.h | 2 ++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 46733d5..86b483e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -464,6 +464,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   else if (property == config->prop_mode_id) {
>   struct drm_property_blob *mode =
>   drm_property_lookup_blob(dev, val);
> + mode->is_video_mode = true;
>   ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
>   drm_property_blob_put(mode);
>   return ret;
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index bae50e6..639787c 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -746,6 +746,12 @@ int drm_mode_getblob_ioctl(struct drm_device *dev,
>   if (!blob)
>   return -ENOENT;
>  
> + if (blob->is_video_mode && !file_priv->aspect_ratio_allowed) {
> + struct drm_mode_modeinfo *mode =
> + (struct drm_mode_modeinfo *) blob->data;
> + mode->flags &= (~DRM_MODE_FLAG_PIC_AR_MASK);

This is still clobbering the internal state. If another client with
the aspect ratio cap comes in later and asks for the same blob we 
can no longer tell it what the aspect ratio was. So I think we have
to make a temporary copy of the mode here.

Also pointless parens.

> + }
> +
>   if (out_resp->length == blob->length) {
>   if (copy_to_user(u64_to_user_ptr(out_resp->data),
>blob->data,
> diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
> index 8a522b4..95e6e32 100644
> --- a/include/drm/drm_property.h
> +++ b/include/drm/drm_property.h
> @@ -194,6 +194,7 @@ struct drm_property {
>   * @head_global: entry on the global blob list in
>   *   &drm_mode_config.property_blob_list.
>   * @head_file: entry on the per-file blob list in &drm_file.blobs list.
> + * @is_video_mode: flag to mark the blobs that contain drm_mode_modeinfo.
>   * @length: size of the blob in bytes, invariant over the lifetime of the 
> object
>   * @data: actual data, embedded at the end of this structure
>   *
> @@ -208,6 +209,7 @@ struct drm_property_blob {
>   struct drm_device *dev;
>   struct list_head head_global;
>   struct list_head head_file;
> + bool is_video_mode;
>   size_t length;
>   unsigned char data[];
>  };
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale()

[Sean Paul]

On Fri, Feb 23, 2018 at 02:22:50PM +0800, Jeffy Chen wrote:
> Currently we are calling scl_vop_cal_scale() to get vskiplines for yrgb
> and cbcr. So the cbcr's vskiplines might be an unexpected value if the
> second scl_vop_cal_scale() didn't update it.
> 
> Init vskiplines in scl_vop_cal_scale() to avoid that.
> 
> Signed-off-by: Jeffy Chen 

Reviewed-by: Sean Paul 

> ---
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 7715853ef90a..9b03c51903ab 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -259,6 +259,9 @@ static uint16_t scl_vop_cal_scale(enum scale_mode mode, 
> uint32_t src,
>  {
>   uint16_t val = 1 << SCL_FT_DEFAULT_FIXPOINT_SHIFT;
>  
> + if (vskiplines)
> + *vskiplines = 0;
> +
>   if (is_horizontal) {
>   if (mode == SCALE_UP)
>   val = GET_SCL_FT_BIC(src, dst);
> @@ -299,7 +302,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
> struct vop_win_data *win,
>   uint16_t vsu_mode;
>   uint16_t lb_mode;
>   uint32_t val;
> - int vskiplines = 0;
> + int vskiplines;
>  
>   if (dst_w > 3840) {
>   DRM_DEV_ERROR(vop->dev, "Maximum dst width (3840) exceeded\n");
> -- 
> 2.11.0
> 
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2,03/10] drm/sun4i: Protect the TCON pixel clocks

[Giulio Benetti]

From: Maxime Ripard 

Both TCON clocks are very sensitive to clock changes, since any change
might lead to improper timings.

Make sure our rate is never changed.

Tested-by: Giulio Benetti 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c

index b73acab74867..cbe87cee13d1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -261,7 +261,7 @@ static void sun4i_tcon0_mode_set_common(struct 
sun4i_tcon *tcon,

const struct drm_display_mode *mode)
 {
/* Configure the dot clock */
-   clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
+   clk_set_rate_exclusive(tcon->dclk, mode->crtc_clock * 1000);

/* Set the resolution */
regmap_write(tcon->regs, SUN4I_TCON0_BASIC0_REG,
@@ -419,7 +419,7 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon 
*tcon,

WARN_ON(!tcon->quirks->has_channel_1);

/* Configure the dot clock */
-   clk_set_rate(tcon->sclk1, mode->crtc_clock * 1000);
+   clk_set_rate_exclusive(tcon->sclk1, mode->crtc_clock * 1000);

/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Ville Syrjälä]

On Fri, Feb 23, 2018 at 01:52:22PM +, Brian Starkey wrote:
> Hi Ville,
> 
> On Thu, Feb 22, 2018 at 11:42:29PM +0200, Ville Syrjala wrote:
> >From: Ville Syrjälä 
> >
> >The documentation for the ctm matrix suggests a two's complement
> >format, but at least the i915 implementation is using sign-magnitude
> >instead. And looks like malidp is doing the same. Change the docs
> >to match the current implementation, and change the type from __s64
> >to __u64 to drive the point home.
> 
> I totally agree that this is a good idea, but...
> 
> >
> >Cc: dri-devel@lists.freedesktop.org
> >Cc: Mihail Atanassov 
> >Cc: Liviu Dudau 
> >Cc: Brian Starkey 
> >Cc: Mali DP Maintainers 
> >Cc: Johnson Lin 
> >Cc: Uma Shankar 
> >Cc: Shashank Sharma 
> >Signed-off-by: Ville Syrjälä 
> >---
> > include/uapi/drm/drm_mode.h | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> >diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >index 2c575794fb52..b5d7d9e0eff5 100644
> >--- a/include/uapi/drm/drm_mode.h
> >+++ b/include/uapi/drm/drm_mode.h
> >@@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
> > };
> >
> > struct drm_color_ctm {
> >-/* Conversion matrix in S31.32 format. */
> >-__s64 matrix[9];
> >+/*
> >+ * Conversion matrix in S31.32 sign-magnitude
> >+ * (not two's complement!) format.
> >+ */
> >+__u64 matrix[9];
> 
> Isn't changing the type liable to break something for someone?

I hope not. Renaming the member would be a no no, but just changing the
type should be mostly safe I think. I suppose if someone is building
something with very strict compiler -W flags and -Werror it might cause
a build failure, so I guess one might label it as a minor api break but
not an abi break.

If people think that's a serious concern I guess we can keep the
__s64, but I'd rather not give people that much rope to hang
themselves by interpreting it as 2's complement.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 1/4] drm: Add writeback connector type

[Liviu Dudau]

Hi Rob,

On Fri, Feb 23, 2018 at 08:17:51AM -0500, Rob Clark wrote:
> From: Brian Starkey 
> 
> Writeback connectors represent writeback engines which can write the
> CRTC output to a memory framebuffer. Add a writeback connector type and
> related support functions.
> 
> Drivers should initialize a writeback connector with
> drm_writeback_connector_init() which takes care of setting up all the
> writeback-specific details on top of the normal functionality of
> drm_connector_init().
> 
> Writeback connectors have a WRITEBACK_FB_ID property, used to set the
> output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
> supported writeback formats to userspace.
> 
> When a framebuffer is attached to a writeback connector with the
> WRITEBACK_FB_ID property, it is used only once (for the commit in which
> it was included), and userspace can never read back the value of
> WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
> attached to a CRTC.

[snip]

> +static bool create_writeback_properties(struct drm_device *dev)
> +{
> + struct drm_property *prop;
> +
> + if (!dev->mode_config.writeback_fb_id_property) {
> + prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
> +   "WRITEBACK_FB_ID",
> +   DRM_MODE_OBJECT_FB);
> + if (!prop)
> + return false;
> + dev->mode_config.writeback_fb_id_property = prop;
> + }
> +
> + if (!dev->mode_config.writeback_pixel_formats_property) {
> + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
> DRM_MODE_PROP_IMMUTABLE,
> +"WRITEBACK_PIXEL_FORMATS", 0);
> + if (!prop)
> + return false;
> + dev->mode_config.writeback_pixel_formats_property = prop;
> + }
> +
> + return true;
> +}

based on a buildbot warning and the fact that the next patch starts
returning -ENOMEM inside the above function, I have this variant in my
internal tree that I was preparing to send out once I've got my i-g-t
tests in better shape:

+static int create_writeback_properties(struct drm_device *dev)
+{
+   struct drm_property *prop;
+
+   if (!dev->mode_config.writeback_fb_id_property) {
+   prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
+ "WRITEBACK_FB_ID",
+ DRM_MODE_OBJECT_FB);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.writeback_fb_id_property = prop;
+   }
+
+   if (!dev->mode_config.writeback_pixel_formats_property) {
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB | 
DRM_MODE_PROP_IMMUTABLE,
+  "WRITEBACK_PIXEL_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.writeback_pixel_formats_property = prop;
+   }
+
+   return 0;
+}


Feel free to use this version in the next update if you're going to send
one, otherwise I guess we could be patching it later.

Best regards,
Liviu


> +
> +static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +/**
> + * drm_writeback_connector_init - Initialize a writeback connector and its 
> properties
> + * @dev: DRM device
> + * @wb_connector: Writeback connector to initialize
> + * @con_funcs: Connector funcs vtable
> + * @enc_helper_funcs: Encoder helper funcs vtable to be used by the internal 
> encoder
> + * @formats: Array of supported pixel formats for the writeback engine
> + * @n_formats: Length of the formats array
> + *
> + * This function creates the writeback-connector-specific properties if they
> + * have not been already created, initializes the connector as
> + * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the property
> + * values. It will also create an internal encoder associated with the
> + * drm_writeback_connector and set it to use the @enc_helper_funcs vtable for
> + * the encoder helper.
> + *
> + * Drivers should always use this function instead of drm_connector_init() to
> + * set up writeback connectors.
> + *
> + * Returns: 0 on success, or a negative error code
> + */
> +int drm_writeback_connector_init(struct drm_device *dev,
> +  struct drm_writeback_connector *wb_connector,
> +  const struct drm_connector_funcs *con_funcs,
> +  const struct drm_encoder_helper_funcs 
> *enc_helper_funcs,
> +  const u32 *formats, int n_formats)
> +{
> + int ret;
> + struct drm_property_blob *blob;
> + struct drm_connector *connector = &wb_connector->base;
> + struct drm_mode_config *config = &dev->mode_config;
> +
> + if 

Re: [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

[Brian Starkey]

Hi Ville,

On Thu, Feb 22, 2018 at 11:42:29PM +0200, Ville Syrjala wrote:

From: Ville Syrjälä 

The documentation for the ctm matrix suggests a two's complement
format, but at least the i915 implementation is using sign-magnitude
instead. And looks like malidp is doing the same. Change the docs
to match the current implementation, and change the type from __s64
to __u64 to drive the point home.


I totally agree that this is a good idea, but...



Cc: dri-devel@lists.freedesktop.org
Cc: Mihail Atanassov 
Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: Mali DP Maintainers 
Cc: Johnson Lin 
Cc: Uma Shankar 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
include/uapi/drm/drm_mode.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 2c575794fb52..b5d7d9e0eff5 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -598,8 +598,11 @@ struct drm_mode_crtc_lut {
};

struct drm_color_ctm {
-   /* Conversion matrix in S31.32 format. */
-   __s64 matrix[9];
+   /*
+* Conversion matrix in S31.32 sign-magnitude
+* (not two's complement!) format.
+*/
+   __u64 matrix[9];


Isn't changing the type liable to break something for someone?

Thanks,
-Brian


};

struct drm_color_lut {
--
2.16.1


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

[RFC 4/4] drm/msm/mdp5: writeback support

[Rob Clark]

In a way, based on the original writeback patch from Jilai Wang, but a
lot has shifted around since then.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  23 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  38 +++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h  |   7 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c   | 367 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c|   4 +-
 6 files changed, 431 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/mdp5/mdp5_wb.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c050b2d7..c9f50adef2db 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -45,6 +45,7 @@ msm-y := \
disp/mdp5/mdp5_mixer.o \
disp/mdp5/mdp5_plane.o \
disp/mdp5/mdp5_smp.o \
+   disp/mdp5/mdp5_wb.o \
msm_atomic.o \
msm_debugfs.o \
msm_drv.o \
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 9893e43ba6c5..b00ca88b741d 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -484,7 +484,11 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
}
 
/* Restore vblank irq handling after power is enabled */
-   drm_crtc_vblank_on(crtc);
+// TODO we can't ->get_scanout_pos() for wb (since virtual intf)..
+// perhaps drm core should be clever enough not to drm_reset_vblank_timestamp()
+// for virtual encoders / writeback?
+   if (mdp5_cstate->pipeline.intf->type != INTF_WB)
+   drm_crtc_vblank_on(crtc);
 
mdp5_crtc_mode_set_nofb(crtc);
 
@@ -518,7 +522,11 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
u32 caps;
int ret;
 
-   caps = MDP_LM_CAP_DISPLAY;
+   if (pipeline->intf->type == INTF_WB)
+   caps = MDP_LM_CAP_WB;
+   else
+   caps = MDP_LM_CAP_DISPLAY;
+
if (need_right_mixer)
caps |= MDP_LM_CAP_PAIR;
 
@@ -545,6 +553,7 @@ int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
mdp5_cstate->err_irqmask = intf2err(intf->num);
mdp5_cstate->vblank_irqmask = intf2vblank(pipeline->mixer, intf);
 
+// XXX should we be treating WB as cmd_mode??
if ((intf->type == INTF_DSI) &&
(intf->mode == MDP5_INTF_DSI_MODE_COMMAND)) {
mdp5_cstate->pp_done_irqmask = lm2ppdone(pipeline->mixer);
@@ -639,8 +648,12 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
}
 
/* bail out early if there aren't any planes */
-   if (!cnt)
-   return 0;
+   if (!cnt) {
+   if (!state->active)
+   return 0;
+   dev_err(dev->dev, "%s has no planes!\n", crtc->name);
+   return -EINVAL;
+   }
 
hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
 
@@ -1160,7 +1173,7 @@ void mdp5_crtc_wait_for_commit_done(struct drm_crtc *crtc)
 
if (mdp5_cstate->cmd_mode)
mdp5_crtc_wait_for_pp_done(crtc);
-   else
+   else if (mdp5_cstate->pipeline.intf->type != INTF_WB)
mdp5_crtc_wait_for_flush_done(crtc);
 }
 
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 1f44d8f15ce1..239010905637 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -427,7 +427,8 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
 * the MDP5 interfaces) than the number of layer mixers present in HW,
 * but let's be safe here anyway
 */
-   num_crtcs = min(priv->num_encoders, mdp5_kms->num_hwmixers);
+   num_crtcs = min(priv->num_encoders + hw_cfg->wb.count,
+   mdp5_kms->num_hwmixers);
 
/*
 * Construct planes equaling the number of hw pipes, and CRTCs for the
@@ -482,6 +483,33 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
}
 
+   /*
+* Lastly, construct writeback connectors.
+*/
+   for (i = 0; i < hw_cfg->wb.count; i++) {
+   struct drm_writeback_connector *wb_conn;
+   struct mdp5_ctl *ctl;
+
+   ctl = mdp5_ctlm_request(mdp5_kms->ctlm, -1);
+   if (!ctl) {
+   dev_err(dev->dev,
+   "failed to allocate ctl for writeback %d\n", i);
+   continue;
+   }
+
+   wb_conn = mdp5_wb_connector_init(dev, ctl,
+   hw_cfg->wb.instances[i].id);
+   if (IS_ERR(wb_conn)) {
+   ret = PTR_ERR(wb_conn);
+   dev_err(dev->dev,
+   "failed t