Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

[Dave Airlie]

On 14 March 2017 at 13:30, zhoucm1  wrote:
>
>
> On 2017年03月14日 10:52, Dave Airlie wrote:
>>
>> On 14 March 2017 at 12:00, zhoucm1  wrote:
>>>
>>> Hi Dave,
>>>
>>> Could you tell me why you create your new one patch? I remember I send
>>> out
>>> our the whole implementation, Why not directly review our patches?
>>
>> This is patch review, I'm not sure what you are expecting in terms of
>> direct review.
>>
>> The patches you sent out were reviewed by Christian, he stated he
>> thinks this should
>> use sync_file, I was interested to see if this was actually possible,
>> so I just adapted
>> the patches to check if it was possible to avoid adding a lot of amd
>> specific code
>> for something that isn't required to be. Hence why I've sent this as
>> an rfc, as I want
>> to see if others think using sync_file is a good or bad idea. We may
>> end up going
>> back to the non-sync_file based patches if this proves to be a bad
>> idea, so far it
>> doesn't look like one.
>>
>> I also reviewed the patches and noted it shouldn't add the wait/signal
>> interfaces,
>> that it should use the chunks on command submission, so while I was in
>> there I re
>> wrote that as well.
>
> Yeah, then I'm ok with this, just our internal team has used this
> implementation, they find some gaps between yours and previous, they could
> need to change their's again, they are annoyance for this.

This is unfortunate, but the more internal development done, the more
this will happen,
especially in areas where you might interact with the kernel. I'd
suggest trying to
develop stuff in the open much earlier (don't start anything in-house).

Now that we have an open vulkan driver it might be that most features
the internal
vulkan driver requires will eventually be wanted by us,

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

Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

[zhoucm1]

On 2017年03月14日 10:52, Dave Airlie wrote:

On 14 March 2017 at 12:00, zhoucm1  wrote:

Hi Dave,

Could you tell me why you create your new one patch? I remember I send out
our the whole implementation, Why not directly review our patches?

This is patch review, I'm not sure what you are expecting in terms of
direct review.

The patches you sent out were reviewed by Christian, he stated he
thinks this should
use sync_file, I was interested to see if this was actually possible,
so I just adapted
the patches to check if it was possible to avoid adding a lot of amd
specific code
for something that isn't required to be. Hence why I've sent this as
an rfc, as I want
to see if others think using sync_file is a good or bad idea. We may
end up going
back to the non-sync_file based patches if this proves to be a bad
idea, so far it
doesn't look like one.

I also reviewed the patches and noted it shouldn't add the wait/signal
interfaces,
that it should use the chunks on command submission, so while I was in
there I re
wrote that as well.
Yeah, then I'm ok with this, just our internal team has used this 
implementation, they find some gaps between yours and previous, they 
could need to change their's again, they are annoyance for this.


Regards,
David Zhou


Dave.


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

Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

[Dave Airlie]

On 14 March 2017 at 12:00, zhoucm1  wrote:
> Hi Dave,
>
> Could you tell me why you create your new one patch? I remember I send out
> our the whole implementation, Why not directly review our patches?

This is patch review, I'm not sure what you are expecting in terms of
direct review.

The patches you sent out were reviewed by Christian, he stated he
thinks this should
use sync_file, I was interested to see if this was actually possible,
so I just adapted
the patches to check if it was possible to avoid adding a lot of amd
specific code
for something that isn't required to be. Hence why I've sent this as
an rfc, as I want
to see if others think using sync_file is a good or bad idea. We may
end up going
back to the non-sync_file based patches if this proves to be a bad
idea, so far it
doesn't look like one.

I also reviewed the patches and noted it shouldn't add the wait/signal
interfaces,
that it should use the chunks on command submission, so while I was in
there I re
wrote that as well.

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

Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

[zhoucm1]

Hi Dave,

Could you tell me why you create your new one patch? I remember I send 
out our the whole implementation, Why not directly review our patches?


Thanks,
David Zhou

On 2017年03月14日 08:50, Dave Airlie wrote:

From: Dave Airlie 

This adds the corresponding code for libdrm to use the new
kernel interfaces for semaphores.

This will be used by radv to implement shared semaphores.

TODO: Version checks.

Signed-off-by: Dave Airlie 
---
  amdgpu/amdgpu.h  |  28 +
  amdgpu/amdgpu_cs.c   | 161 ---
  include/drm/amdgpu_drm.h |  28 +
  3 files changed, 208 insertions(+), 9 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 7b26a04..747e248 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -129,6 +129,8 @@ typedef struct amdgpu_va *amdgpu_va_handle;
   */
  typedef struct amdgpu_semaphore *amdgpu_semaphore_handle;
  
+typedef uint32_t amdgpu_sem_handle;

+
  /*--*/
  /* -- Structures -- */
  /*--*/
@@ -365,6 +367,16 @@ struct amdgpu_cs_request {
struct amdgpu_cs_fence_info fence_info;
  };
  
+struct amdgpu_cs_request_sem {

+   /*
+*
+*/
+   uint32_t number_of_wait_sem;
+   uint32_t *wait_sems;
+   uint32_t number_of_signal_sem;
+   uint32_t *signal_sems;
+};
+
  /**
   * Structure which provide information about GPU VM MC Address space
   * alignments requirements
@@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
 struct amdgpu_cs_request *ibs_request,
 uint32_t number_of_requests);
  
+int amdgpu_cs_submit_sem(amdgpu_context_handle context,

+uint64_t flags,
+struct amdgpu_cs_request *ibs_request,
+struct amdgpu_cs_request_sem *ibs_sem,
+uint32_t number_of_requests);
+
  /**
   *  Query status of Command Buffer Submission
   *
@@ -1255,4 +1273,14 @@ int amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle 
sem);
  */
  const char *amdgpu_get_marketing_name(amdgpu_device_handle dev);
  
+int amdgpu_cs_create_sem(amdgpu_device_handle dev,

+amdgpu_sem_handle *sem);
+int amdgpu_cs_export_sem(amdgpu_device_handle dev,
+ amdgpu_sem_handle sem,
+int *shared_handle);
+int amdgpu_cs_import_sem(amdgpu_device_handle dev,
+ int shared_handle,
+amdgpu_sem_handle *sem);
+int amdgpu_cs_destroy_sem(amdgpu_device_handle dev,
+ amdgpu_sem_handle sem);
  #endif /* #ifdef _AMDGPU_H_ */
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index fb5b3a8..7283327 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -170,7 +170,8 @@ int amdgpu_cs_query_reset_state(amdgpu_context_handle 
context,
   * \sa amdgpu_cs_submit()
  */
  static int amdgpu_cs_submit_one(amdgpu_context_handle context,
-   struct amdgpu_cs_request *ibs_request)
+   struct amdgpu_cs_request *ibs_request,
+   struct amdgpu_cs_request_sem *sem_request)
  {
union drm_amdgpu_cs cs;
uint64_t *chunk_array;
@@ -178,9 +179,11 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
struct drm_amdgpu_cs_chunk_data *chunk_data;
struct drm_amdgpu_cs_chunk_dep *dependencies = NULL;
struct drm_amdgpu_cs_chunk_dep *sem_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *wait_sem_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *signal_sem_dependencies = NULL;
struct list_head *sem_list;
amdgpu_semaphore_handle sem, tmp;
-   uint32_t i, size, sem_count = 0;
+   uint32_t i, j, size, sem_count = 0;
bool user_fence;
int r = 0;
  
@@ -196,7 +199,7 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle context,

}
user_fence = (ibs_request->fence_info.handle != NULL);
  
-	size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1;

+   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1 + 
(sem_request ? 2 : 0);
  
  	chunk_array = alloca(sizeof(uint64_t) * size);

chunks = alloca(sizeof(struct drm_amdgpu_cs_chunk) * size);
@@ -308,6 +311,45 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
chunks[i].chunk_data = (uint64_t)(uintptr_t)sem_dependencies;
}
  
+	if (sem_request) {

+   if (sem_request->number_of_wait_sem) {
+   wait_sem_dependencies = malloc(sizeof(struct 
drm_amdgpu_cs_chunk_sem) * sem_request->number_of_wait_sem);
+   if (!wait_sem_dependencies) {
+   r = -ENOMEM;
+   

[Bug 99841] Switching to VT freezes X only on a dual screen

[bugzilla-daemon]

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

--- Comment #13 from Michel Dänzer  ---
Created attachment 130207
  --> https://bugs.freedesktop.org/attachment.cgi?id=130207&action=edit
Only reject if FBINFO_MISC_USEREVENT is set

Does this patch (only compile tested) 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: [PATCH v2 00/12] drm/exynos: rework vblank handling

[Inki Dae]

Hi Andrzej,

Thanks for fixing this.

As you mentioned, this patch set depends on Shawn patch set[1].
So can you separate this patch series into two sets?

One includes only the patch set related to fixing page fault issue and other 
includes cleanup code based on Shawn patchset.

I'd like to merge fixup series to -fixes and for other one to -next.

[1] http://www.spinics.net/lists/dri-devel/msg131903.html

Thanks.

2017년 03월 08일 23:58에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
> 
> This patchset fixes long standing issue with occassional page faults
> or vblank event timeouts on TM2 targets due to delayed vblank handling.
> DECON driver should now handle properly all scenarios described in drm
> docs [1][2], at least it was my intention.
> 
> The patchset also:
> - adds frame counter callback,
> - fixes VBLANK interrupt trigger time,
> - fixes soft-trigger mask,
> - removes redundant pipe related fields.
> 
> The patch is based on todays linux-next, the real dependency is on the Shawn 
> patchset
> 'Add vblank hooks to struct drm_crtc_funcs'.
> 
> I have successfully tested it on TM2 panel, TV and both.
> 
> [1]: 
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html?highlight=drm_crtc_state#c.drm_crtc_arm_vblank_event
> [2]: 
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html?highlight=drm_crtc_state#c.drm_crtc_state
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (12):
>   drm/exynos: move crtc event handling to drivers callbacks
>   drm/exynos: simplify completion event handling
>   drm/exynos/decon5433: fix vblank event handling
>   drm/exynos/decon5433: implement frame counter
>   drm/exynos/decon5433: signal frame done interrupt at front porch
>   drm/exynos/fimd: signal frame done interrupt at front porch
>   drm/exynos/decon5433: fix software trigger mask
>   drm/exynos: kill exynos_drm_crtc::pipe
>   drm/exynos: kill exynos_drm_private::pipe
>   drm/exynos: set plane possible_crtcs in exynos_plane_init
>   drm/exynos: kill pipe field from drivers contexts
>   drm/exynos: kill mode_set_nofb callback
> 
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 119 
> +-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c|  20 ++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  65 +++---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   3 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  14 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  28 ++
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |   5 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  23 +
>  drivers/gpu/drm/exynos/exynos_mixer.c |  14 +--
>  include/video/exynos5433_decon.h  |  12 +++
>  11 files changed, 166 insertions(+), 138 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND] drm/exynos: Remove support for Exynos4415 (SoC not supported anymore)

[Inki Dae]

Merged.

Thanks.

2017년 03월 12일 03:04에 Krzysztof Kozlowski 이(가) 쓴 글:
> Support for Exynos4415 is going away because there are no internal nor
> external users.
> 
> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
> the platform cannot be instantiated so remove also the drivers.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Acked-by: Kukjin Kim 
> Acked-by: Rob Herring 
> ---
>  .../devicetree/bindings/display/exynos/exynos_dsim.txt |  1 -
>  .../bindings/display/exynos/samsung-fimd.txt   |  1 -
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 15 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 18 
> ++
>  4 files changed, 3 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> index a78265993665..ca5204b3bc21 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
> @@ -4,7 +4,6 @@ Required properties:
>- compatible: value should be one of the following
>   "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */
>   "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
> - "samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
>   "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
> */
>   "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
>   "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
> diff --git 
> a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt 
> b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> index 18645e0228b0..5837402c3ade 100644
> --- a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt
> @@ -11,7 +11,6 @@ Required properties:
>   "samsung,s5pv210-fimd"; /* for S5PV210 SoC */
>   "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */
>   "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
> - "samsung,exynos4415-fimd"; /* for Exynos4415 SoC */
>   "samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */
>   "samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 812e2ec0761d..ef6f9c6de098 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -86,7 +86,7 @@
>  #define DSIM_SYNC_INFORM (1 << 27)
>  #define DSIM_EOT_DISABLE (1 << 28)
>  #define DSIM_MFLUSH_VS   (1 << 29)
> -/* This flag is valid only for exynos3250/3472/4415/5260/5430 */
> +/* This flag is valid only for exynos3250/3472/5260/5430 */
>  #define DSIM_CLKLANE_STOP(1 << 30)
>  
>  /* DSIM_ESCMODE */
> @@ -473,17 +473,6 @@ static const struct exynos_dsi_driver_data 
> exynos4_dsi_driver_data = {
>   .reg_values = reg_values,
>  };
>  
> -static const struct exynos_dsi_driver_data exynos4415_dsi_driver_data = {
> - .reg_ofs = exynos_reg_ofs,
> - .plltmr_reg = 0x58,
> - .has_clklane_stop = 1,
> - .num_clks = 2,
> - .max_freq = 1000,
> - .wait_for_reset = 1,
> - .num_bits_resol = 11,
> - .reg_values = reg_values,
> -};
> -
>  static const struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
>   .reg_ofs = exynos_reg_ofs,
>   .plltmr_reg = 0x58,
> @@ -521,8 +510,6 @@ static const struct of_device_id exynos_dsi_of_match[] = {
> .data = &exynos3_dsi_driver_data },
>   { .compatible = "samsung,exynos4210-mipi-dsi",
> .data = &exynos4_dsi_driver_data },
> - { .compatible = "samsung,exynos4415-mipi-dsi",
> -   .data = &exynos4415_dsi_driver_data },
>   { .compatible = "samsung,exynos5410-mipi-dsi",
> .data = &exynos5_dsi_driver_data },
>   { .compatible = "samsung,exynos5422-mipi-dsi",
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index a9fa444c6053..661b9fe049e2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -71,10 +71,10 @@
>  #define TRIGCON  0x1A4
>  #define TRGMODE_ENABLE   (1 << 0)
>  #define SWTRGCMD_ENABLE  (1 << 1)
> -/* Exynos3250, 3472, 4415, 5260 5410, 5420 and 5422 only supported. */
> +/* Exynos3250, 3472, 5260 5410, 5420 and 5422 only supported. */
>  #define HWTRGEN_ENABLE   (1 << 3)
>  #define HWTRGMASK_ENABLE (1 << 4)
> -/* Exynos3250, 3472, 4415, 5260, 5420 and 5422 only supported. */
> +/* Exynos3250, 3472, 5260, 5420 and 5422 only supported. */
>  #define HWTRIGEN_PER_ENABLE

[PATCH 3/4] amdgpu/cs: split out fence dependency checking

[Dave Airlie]

From: Dave Airlie 

This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 86 +++---
 1 file changed, 48 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 99424cb..4671432 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -963,56 +963,66 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return 0;
 }
 
-static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
- struct amdgpu_cs_parser *p)
+static int amdgpu_process_fence_dep(struct amdgpu_device *adev,
+   struct amdgpu_cs_parser *p,
+   struct amdgpu_cs_chunk *chunk)
 {
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
-   int i, j, r;
-
-   for (i = 0; i < p->nchunks; ++i) {
-   struct drm_amdgpu_cs_chunk_dep *deps;
-   struct amdgpu_cs_chunk *chunk;
-   unsigned num_deps;
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_dep *deps;
 
-   chunk = &p->chunks[i];
+   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_dep);
 
-   if (chunk->chunk_id != AMDGPU_CHUNK_ID_DEPENDENCIES)
-   continue;
+   for (i = 0; i < num_deps; ++i) {
+   struct amdgpu_ring *ring;
+   struct amdgpu_ctx *ctx;
+   struct dma_fence *fence;
 
-   deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
-   num_deps = chunk->length_dw * 4 /
-   sizeof(struct drm_amdgpu_cs_chunk_dep);
+   r = amdgpu_cs_get_ring(adev, deps[i].ip_type,
+  deps[i].ip_instance,
+  deps[i].ring, &ring);
+   if (r)
+   return r;
 
-   for (j = 0; j < num_deps; ++j) {
-   struct amdgpu_ring *ring;
-   struct amdgpu_ctx *ctx;
-   struct dma_fence *fence;
+   ctx = amdgpu_ctx_get(fpriv, deps[i].ctx_id);
+   if (ctx == NULL)
+   return -EINVAL;
 
-   r = amdgpu_cs_get_ring(adev, deps[j].ip_type,
-  deps[j].ip_instance,
-  deps[j].ring, &ring);
+   fence = amdgpu_ctx_get_fence(ctx, ring,
+deps[i].handle);
+   if (IS_ERR(fence)) {
+   r = PTR_ERR(fence);
+   amdgpu_ctx_put(ctx);
+   return r;
+   } else if (fence) {
+   r = amdgpu_sync_fence(adev, &p->job->sync,
+ fence);
+   dma_fence_put(fence);
+   amdgpu_ctx_put(ctx);
if (r)
return r;
+   }
+   }
+   return 0;
+}
 
-   ctx = amdgpu_ctx_get(fpriv, deps[j].ctx_id);
-   if (ctx == NULL)
-   return -EINVAL;
+static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
+ struct amdgpu_cs_parser *p)
+{
+   int i, r;
 
-   fence = amdgpu_ctx_get_fence(ctx, ring,
-deps[j].handle);
-   if (IS_ERR(fence)) {
-   r = PTR_ERR(fence);
-   amdgpu_ctx_put(ctx);
-   return r;
+   for (i = 0; i < p->nchunks; ++i) {
+   struct amdgpu_cs_chunk *chunk;
 
-   } else if (fence) {
-   r = amdgpu_sync_fence(adev, &p->job->sync,
- fence);
-   dma_fence_put(fence);
-   amdgpu_ctx_put(ctx);
-   if (r)
-   return r;
-   }
+   chunk = &p->chunks[i];
+
+   if (chunk->chunk_id == AMDGPU_CHUNK_ID_DEPENDENCIES) {
+   r = amdgpu_process_fence_dep(adev, p, chunk);
+   if (r)
+   return r;
}
}
 
-- 
2.7.4

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

[PATCH 4/4] amdgpu: use sync file for shared semaphores

[Dave Airlie]

From: Dave Airlie 

This creates a new interface for amdgpu with ioctls to
create/destroy/import and export shared semaphores using
sem object backed by the sync_file code. The semaphores
are not installed as fd (except for export), but rather
like other driver internal objects in an idr. The idr
holds the initial reference on the sync file.

The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for semaphore signalling
and just takes a list of handles for each.

This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.

NOTE: this interface addition needs a version bump to expose
it to userspace.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/Makefile |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  12 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  70 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   8 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c | 204 
 include/uapi/drm/amdgpu_drm.h   |  28 +
 6 files changed, 322 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 2814aad..404bcba 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -24,7 +24,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
-   amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
+   amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_sem.o
 
 # add asic specific block
 amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c1b9135..4ed8811 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -702,6 +702,8 @@ struct amdgpu_fpriv {
struct mutexbo_list_lock;
struct idr  bo_list_handles;
struct amdgpu_ctx_mgr   ctx_mgr;
+   spinlock_t  sem_handles_lock;
+   struct idr  sem_handles;
 };
 
 /*
@@ -1814,5 +1816,15 @@ amdgpu_cs_find_mapping(struct amdgpu_cs_parser *parser,
   uint64_t addr, struct amdgpu_bo **bo);
 int amdgpu_cs_sysvm_access_required(struct amdgpu_cs_parser *parser);
 
+int amdgpu_sem_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
+void amdgpu_sem_destroy(struct amdgpu_fpriv *fpriv, u32 handle);
+int amdgpu_sem_lookup_and_signal(struct amdgpu_fpriv *fpriv,
+uint32_t handle,
+struct dma_fence *fence);
+int amdgpu_sem_lookup_and_sync(struct amdgpu_device *adev,
+  struct amdgpu_fpriv *fpriv,
+  struct amdgpu_sync *sync,
+  uint32_t handle);
 #include "amdgpu_object.h"
 #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4671432..80fc94b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -217,6 +217,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
break;
 
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+   case AMDGPU_CHUNK_ID_SEM_WAIT:
+   case AMDGPU_CHUNK_ID_SEM_SIGNAL:
break;
 
default:
@@ -1009,6 +1011,28 @@ static int amdgpu_process_fence_dep(struct amdgpu_device 
*adev,
return 0;
 }
 
+static int amdgpu_process_sem_wait_dep(struct amdgpu_device *adev,
+  struct amdgpu_cs_parser *p,
+  struct amdgpu_cs_chunk *chunk)
+{
+   struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
+   unsigned num_deps;
+   int i, r;
+   struct drm_amdgpu_cs_chunk_sem *deps;
+
+   deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+   for (i = 0; i < num_deps; ++i) {
+   r = amdgpu_sem_lookup_and_sync(adev, fpriv, &p->job->sync,
+  deps[i].handle);
+   if (r)
+   return r;
+   }
+   return 0;
+}
+
 static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
  struct amdgpu_cs_parser *p)
 {
@@ -1023,12 +1047,56 @@ static int amdgpu_cs_dependencies(struct amdgpu_device 
*adev,
r = amdgpu_process_fence_dep(adev, p, chunk);
if (r)
return r;
+   } 

[PATCH 1/4] sync_file: add a mutex to protect fence and callback members.

[Dave Airlie]

From: Dave Airlie 

This isn't needed currently, but to reuse sync file for Vulkan
permanent shared semaphore semantics, we need to be able to swap
the fence backing a sync file. This patch adds a mutex to the
sync file and uses to protect accesses to the fence and cb members.

Signed-off-by: Dave Airlie 
---
 drivers/dma-buf/sync_file.c | 23 +++
 include/linux/sync_file.h   |  3 +++
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 2321035..105f48c 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -47,6 +47,7 @@ static struct sync_file *sync_file_alloc(void)
 
INIT_LIST_HEAD(&sync_file->cb.node);
 
+   mutex_init(&sync_file->lock);
return sync_file;
 
 err:
@@ -204,10 +205,13 @@ static struct sync_file *sync_file_merge(const char 
*name, struct sync_file *a,
if (!sync_file)
return NULL;
 
+   mutex_lock(&a->lock);
+   mutex_lock(&b->lock);
a_fences = get_fences(a, &a_num_fences);
b_fences = get_fences(b, &b_num_fences);
-   if (a_num_fences > INT_MAX - b_num_fences)
-   return NULL;
+   if (a_num_fences > INT_MAX - b_num_fences) {
+   goto unlock;
+   }
 
num_fences = a_num_fences + b_num_fences;
 
@@ -268,11 +272,17 @@ static struct sync_file *sync_file_merge(const char 
*name, struct sync_file *a,
goto err;
}
 
+   mutex_unlock(&b->lock);
+   mutex_unlock(&a->lock);
+
strlcpy(sync_file->name, name, sizeof(sync_file->name));
return sync_file;
 
 err:
fput(sync_file->file);
+unlock:
+   mutex_unlock(&b->lock);
+   mutex_unlock(&a->lock);
return NULL;
 
 }
@@ -299,16 +309,20 @@ static int sync_file_release(struct inode *inode, struct 
file *file)
 static unsigned int sync_file_poll(struct file *file, poll_table *wait)
 {
struct sync_file *sync_file = file->private_data;
+   unsigned int ret_val;
 
poll_wait(file, &sync_file->wq, wait);
 
+   mutex_lock(&sync_file->lock);
if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
if (dma_fence_add_callback(sync_file->fence, &sync_file->cb,
   fence_check_cb_func) < 0)
wake_up_all(&sync_file->wq);
}
+   ret_val = dma_fence_is_signaled(sync_file->fence) ? POLLIN : 0;
+   mutex_unlock(&sync_file->lock);
 
-   return dma_fence_is_signaled(sync_file->fence) ? POLLIN : 0;
+   return ret_val;
 }
 
 static long sync_file_ioctl_merge(struct sync_file *sync_file,
@@ -393,6 +407,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
if (info.flags || info.pad)
return -EINVAL;
 
+   mutex_lock(&sync_file->lock);
fences = get_fences(sync_file, &num_fences);
 
/*
@@ -433,7 +448,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
 
 out:
kfree(fence_info);
-
+   mutex_unlock(&sync_file->lock);
return ret;
 }
 
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index 3e3ab84..5aef17f 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -30,6 +30,7 @@
  * @wq:wait queue for fence signaling
  * @fence: fence with the fences in the sync_file
  * @cb:fence callback information
+ * @lock:   mutex to protect fence/cb - used for semaphores
  */
 struct sync_file {
struct file *file;
@@ -43,6 +44,8 @@ struct sync_file {
 
struct dma_fence*fence;
struct dma_fence_cb cb;
+   /* protects the fence pointer and cb */
+   struct mutex lock;
 };
 
 #define POLL_ENABLED DMA_FENCE_FLAG_USER_BITS
-- 
2.7.4

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

[rfc] amdgpu/sync_file shared semaphores

[Dave Airlie]

This contains one libdrm patch and 4 kernel patches.

The goal is to implement the Vulkan KHR_external_semaphore_fd interface
for permanent semaphore behaviour for radv.

This code tries to enhance sync file to add the required behaviour
(which is mostly being able to replace the fence backing the sync file),
it also introduces new API to amdgpu to create/destroy/export/import the
sync_files which we store in an idr there, rather than fds.

There is a possibility we should share the amdgpu_sem object tracking
code for other drivers, maybe we should move that to sync_file as well,
but I'm open to suggestions for whether this is a useful approach for
other drivers.

Dave.

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

[PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

[Dave Airlie]

From: Dave Airlie 

This adds the corresponding code for libdrm to use the new
kernel interfaces for semaphores.

This will be used by radv to implement shared semaphores.

TODO: Version checks.

Signed-off-by: Dave Airlie 
---
 amdgpu/amdgpu.h  |  28 +
 amdgpu/amdgpu_cs.c   | 161 ---
 include/drm/amdgpu_drm.h |  28 +
 3 files changed, 208 insertions(+), 9 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 7b26a04..747e248 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -129,6 +129,8 @@ typedef struct amdgpu_va *amdgpu_va_handle;
  */
 typedef struct amdgpu_semaphore *amdgpu_semaphore_handle;
 
+typedef uint32_t amdgpu_sem_handle;
+
 /*--*/
 /* -- Structures -- */
 /*--*/
@@ -365,6 +367,16 @@ struct amdgpu_cs_request {
struct amdgpu_cs_fence_info fence_info;
 };
 
+struct amdgpu_cs_request_sem {
+   /*
+*
+*/
+   uint32_t number_of_wait_sem;
+   uint32_t *wait_sems;
+   uint32_t number_of_signal_sem;
+   uint32_t *signal_sems;
+};
+
 /**
  * Structure which provide information about GPU VM MC Address space
  * alignments requirements
@@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
 struct amdgpu_cs_request *ibs_request,
 uint32_t number_of_requests);
 
+int amdgpu_cs_submit_sem(amdgpu_context_handle context,
+uint64_t flags,
+struct amdgpu_cs_request *ibs_request,
+struct amdgpu_cs_request_sem *ibs_sem,
+uint32_t number_of_requests);
+
 /**
  *  Query status of Command Buffer Submission
  *
@@ -1255,4 +1273,14 @@ int amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle 
sem);
 */
 const char *amdgpu_get_marketing_name(amdgpu_device_handle dev);
 
+int amdgpu_cs_create_sem(amdgpu_device_handle dev,
+amdgpu_sem_handle *sem);
+int amdgpu_cs_export_sem(amdgpu_device_handle dev,
+ amdgpu_sem_handle sem,
+int *shared_handle);
+int amdgpu_cs_import_sem(amdgpu_device_handle dev,
+ int shared_handle,
+amdgpu_sem_handle *sem);
+int amdgpu_cs_destroy_sem(amdgpu_device_handle dev,
+ amdgpu_sem_handle sem);
 #endif /* #ifdef _AMDGPU_H_ */
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index fb5b3a8..7283327 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -170,7 +170,8 @@ int amdgpu_cs_query_reset_state(amdgpu_context_handle 
context,
  * \sa amdgpu_cs_submit()
 */
 static int amdgpu_cs_submit_one(amdgpu_context_handle context,
-   struct amdgpu_cs_request *ibs_request)
+   struct amdgpu_cs_request *ibs_request,
+   struct amdgpu_cs_request_sem *sem_request)
 {
union drm_amdgpu_cs cs;
uint64_t *chunk_array;
@@ -178,9 +179,11 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
struct drm_amdgpu_cs_chunk_data *chunk_data;
struct drm_amdgpu_cs_chunk_dep *dependencies = NULL;
struct drm_amdgpu_cs_chunk_dep *sem_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *wait_sem_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *signal_sem_dependencies = NULL;
struct list_head *sem_list;
amdgpu_semaphore_handle sem, tmp;
-   uint32_t i, size, sem_count = 0;
+   uint32_t i, j, size, sem_count = 0;
bool user_fence;
int r = 0;
 
@@ -196,7 +199,7 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
}
user_fence = (ibs_request->fence_info.handle != NULL);
 
-   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1;
+   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1 + 
(sem_request ? 2 : 0);
 
chunk_array = alloca(sizeof(uint64_t) * size);
chunks = alloca(sizeof(struct drm_amdgpu_cs_chunk) * size);
@@ -308,6 +311,45 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
chunks[i].chunk_data = (uint64_t)(uintptr_t)sem_dependencies;
}
 
+   if (sem_request) {
+   if (sem_request->number_of_wait_sem) {
+   wait_sem_dependencies = malloc(sizeof(struct 
drm_amdgpu_cs_chunk_sem) * sem_request->number_of_wait_sem);
+   if (!wait_sem_dependencies) {
+   r = -ENOMEM;
+   goto error_unlock;
+   }
+   for (j = 0; j < sem_request->number_of_wait_sem; j++) {
+   struct drm_amdgpu_cs_chunk_sem *dep = 
&wait_sem_dependencies[

[PATCH 2/4] sync_file: add replace and export some functionality

[Dave Airlie]

From: Dave Airlie 

Using sync_file to back vulkan semaphores means need to replace
the fence underlying the sync file. This replace function removes
the callback, swaps the fence, and returns the old one. This
also exports the alloc and fdget functionality for the semaphore
wrapper code.

Signed-off-by: Dave Airlie 
---
 drivers/dma-buf/sync_file.c | 46 +
 include/linux/sync_file.h   |  5 -
 2 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 105f48c..df7bb37 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -28,7 +28,14 @@
 
 static const struct file_operations sync_file_fops;
 
-static struct sync_file *sync_file_alloc(void)
+/**
+ * sync_file_alloc() - allocate an unfenced sync file
+ *
+ * Creates a sync_file.
+ * The sync_file can be released with fput(sync_file->file).
+ * Returns the sync_file or NULL in case of error.
+ */
+struct sync_file *sync_file_alloc(void)
 {
struct sync_file *sync_file;
 
@@ -54,6 +61,7 @@ static struct sync_file *sync_file_alloc(void)
kfree(sync_file);
return NULL;
 }
+EXPORT_SYMBOL(sync_file_alloc);
 
 static void fence_check_cb_func(struct dma_fence *f, struct dma_fence_cb *cb)
 {
@@ -92,7 +100,7 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
 }
 EXPORT_SYMBOL(sync_file_create);
 
-static struct sync_file *sync_file_fdget(int fd)
+struct sync_file *sync_file_fdget(int fd)
 {
struct file *file = fget(fd);
 
@@ -108,6 +116,7 @@ static struct sync_file *sync_file_fdget(int fd)
fput(file);
return NULL;
 }
+EXPORT_SYMBOL(sync_file_fdget);
 
 /**
  * sync_file_get_fence - get the fence related to the sync_file fd
@@ -125,13 +134,40 @@ struct dma_fence *sync_file_get_fence(int fd)
if (!sync_file)
return NULL;
 
+   mutex_lock(&sync_file->lock);
fence = dma_fence_get(sync_file->fence);
+   mutex_unlock(&sync_file->lock);
fput(sync_file->file);
 
return fence;
 }
 EXPORT_SYMBOL(sync_file_get_fence);
 
+/**
+ * sync_file_replace_fence - replace the fence related to the sync_file
+ * @sync_file:  sync file to replace fence in
+ * @fence: fence to replace with (or NULL for no fence).
+ * Returns previous fence.
+ */
+struct dma_fence *sync_file_replace_fence(struct sync_file *sync_file,
+ struct dma_fence *fence)
+{
+   struct dma_fence *ret_fence = NULL;
+   mutex_lock(&sync_file->lock);
+   if (sync_file->fence) {
+   if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
+   dma_fence_remove_callback(sync_file->fence, 
&sync_file->cb);
+   ret_fence = sync_file->fence;
+   }
+   if (fence)
+   sync_file->fence = dma_fence_get(fence);
+   else
+   sync_file->fence = NULL;
+   mutex_unlock(&sync_file->lock);
+   return ret_fence;
+}
+EXPORT_SYMBOL(sync_file_replace_fence);
+
 static int sync_file_set_fence(struct sync_file *sync_file,
   struct dma_fence **fences, int num_fences)
 {
@@ -292,8 +328,10 @@ static void sync_file_free(struct kref *kref)
struct sync_file *sync_file = container_of(kref, struct sync_file,
 kref);
 
-   if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
-   dma_fence_remove_callback(sync_file->fence, &sync_file->cb);
+   if (sync_file->fence) {
+   if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
+   dma_fence_remove_callback(sync_file->fence, 
&sync_file->cb);
+   }
dma_fence_put(sync_file->fence);
kfree(sync_file);
 }
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index 5aef17f..9511a54 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -50,7 +50,10 @@ struct sync_file {
 
 #define POLL_ENABLED DMA_FENCE_FLAG_USER_BITS
 
+struct sync_file *sync_file_alloc(void);
 struct sync_file *sync_file_create(struct dma_fence *fence);
 struct dma_fence *sync_file_get_fence(int fd);
-
+struct sync_file *sync_file_fdget(int fd);
+struct dma_fence *sync_file_replace_fence(struct sync_file *sync_file,
+ struct dma_fence *fence);
 #endif /* _LINUX_SYNC_H */
-- 
2.7.4

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

[Bug 100189] segfault at 234 error 4 in i915_dri.so

[bugzilla-daemon]

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

--- Comment #2 from Emil Velikov  ---
Hi Javi, I don't think we have many devs looking at the i915 driver.

If you can track down the commit that introduced the regression (considering it
is one) or write a simple test program that will be appreciated.

-- 
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] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

[Jose Abreu]

Hi Russell,


On 13-03-2017 13:10, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 12:55:58PM +, Jose Abreu wrote:
>> Hi,
>>
>>
>> On 13-03-2017 09:36, Russell King - ARM Linux wrote:
>>> On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote:
 On 03/10/2017 10:35 AM, Romain Perier wrote:
> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
> step E. and is kept enabled for later use. This clock should be enabled
> and disabled along with the actual audio stream and not always on (that
> is bad for PM). Futhermore, this might cause sound glitches with some
> HDMI devices, as the CTS+N is forced to zero when the stream is disabled
> while the audio clock is still running.
>
> This commit adds a parameter to hdmi_audio_enable_clk() that controls
> when the audio sample clock must be enabled or disabled. Then, it moves
> the call to this function into dw_hdmi_audio_enable() and
> dw_hdmi_audio_disable().
>
> Signed-off-by: Romain Perier 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
 Hi Romain, Russell, Jose,

 This is a little out of scope, but I was wondering why the CTS calculation
 was not left in AUTO mode in the dw-hdmi driver ?
>>> There is no indication in the iMX6 manuals that the iMX6 supports
>>> automatic CTS calculation.  Bits 7:4 of the AUD_CTS3 register are
>>> marked as "reserved".
>>>
>>> We're reliant on the information in the iMX6 manuals as we don't have
>>> access to Synopsis' databooks for these parts (I understand you have
>>> to be a customer to have access to that.)
>>>
>> (Synopsis -> Synopsys :))
>>
>> Trying to catch up with the conversation:
>>
>> 1) In AHB audio mode the bits are always reserved.
>> 2) I think we should enable/disable clock instead of just forcing
>> N/CTS, though, I don't know what could be the implications for
>> iMX platform. I remember at the time I tested this using I2S
>> (I've never used AHB), and HDMI protocol analyzers were
>> complaining about the N/CTS being forced to zero.
> What you're recommending is to basically ignore the published workaround,
> which, presumably, was arrived at by proper analysis of the issue both
> by Freescale engineers and Synopsys engineers, and instead try some other
> solution.
>
> I'm not sure that's a good idea.  Only those with knowledge of the IP can
> say what effect disabling the audio clock will have: will it still allow
> the FIFO to be loaded, as required by the errata?  If not, it's not a
> solution that AHB can use.  I would imagine that _if_ it was as simple as
> disabling the audio clock, that simple approach would have been documented
> in Freescale's errata documents, rather than the rather more complex
> method of zeroing the CTS/N values.

I'm just following what the user guide says: the final step of
configuration is enabling the audio clock. There is no reference
neither in datasheet neither in user guide about this behavior
but, as I said, I've never used AHB so I can't prove what is the
best solution. Could it be platform specific?

>
> I think there are two choices here:
>
> 1) get some definitive information about the IP and the errata for AHB,
>and determine whether the solution you propose would work.  (That's
>out of scope for me, I've no contacts with FSL/NXP and I'm not a
>Synopsys customer.)

This is the right thing to do but if you can't test in the
Freescale platform then we have not much else to do.

Best regards,
Jose Miguel Abreu

>
> 2) the I2S audio support stops re-using the AHB audio support functions,
>switching to their own implementation that behaves correctly for them.
>(Remember, it was I2S's choice to re-use the AHB audio support functions
>I added which we're now discussing - they didn't have to do that, and
>regressing AHB audio just for I2S is not something we should ever
>consider doing.)
>

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

[Bug 100189] segfault at 234 error 4 in i915_dri.so

[bugzilla-daemon]

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

--- Comment #1 from Javi Ballester Tomás  ---
mpv only crashes when fullscreen on start is activated in mpv.conf (fs=yes).

blender crashes also with segfault:

# Blender 2.78 (sub 0), Commit date: 2017-02-24 14:33, Hash e92f2352830

# backtrace
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(BLI_system_backtrace+0x1d)
[0x19aad1d]
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender()
[0x104e2e6]
/lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f3f49d924b0]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x4e46e8) [0x7f3f352dc6e8]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x4e4c65) [0x7f3f352dcc65]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x4d68ed) [0x7f3f352ce8ed]
/usr/lib/x86_64-linux-gnu/dri/i915_dri.so(+0x1df184) [0x7f3f34fd7184]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(_ZN13GHOST_Context11initClearGLEv+0x25)
[0x19cd185]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(_ZN16GHOST_ContextGLX24initializeDrawingContextEv+0x270)
[0x19cc490]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(_ZN15GHOST_WindowX1117newDrawingContextE25GHOST_TDrawingContextType+0x5d)
[0x19cb9cd]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(_ZN12GHOST_Window21setDrawingContextTypeE25GHOST_TDrawingContextType+0x8e)
[0x19ce33e]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(_ZN15GHOST_WindowX11C1EP15GHOST_SystemX11P9_XDisplayRK10STR_Stringiijj18GHOST_TWindowStatei25GHOST_TDrawingContextTypebbbtb+0x5b3)
[0x19cadb3]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(_ZN15GHOST_SystemX1112createWindowERK10STR_Stringiijj18GHOST_TWindowState25GHOST_TDrawingContextType16GHOST_GLSettingsbi+0xb1)
[0x19c8d71]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(GHOST_CreateWindow+0x62)
[0x19c40b2]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(wm_window_ghostwindows_ensure+0x1e1)
[0x106dbf1]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(WM_check+0x41)
[0x104eb31]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(wm_homefile_read+0x12c)
[0x105b4fc]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(WM_init+0xff)
[0x105d48f]
   
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender(main+0x264)
[0xfed4a4]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)
[0x7f3f49d7d830]
/home/javi/Downloads/blender-2.78c-linux-glibc219-x86_64/blender()
[0x104b278]

-- 
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 PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/13/2017 02:29 PM, Rob Clark wrote:
> On Mon, Mar 13, 2017 at 5:09 PM, Laura Abbott  wrote:
>>> Hm, we might want to expose all the heaps as individual
>>> /dev/ion_$heapname nodes? Should we do this from the start, since
>>> we're massively revamping the uapi anyway (imo not needed, current
>>> state seems to work too)?
>>> -Daniel
>>>
>>
>> I thought about that. One advantage with separate /dev/ion_$heap
>> is that we don't have to worry about a limit of 32 possible
>> heaps per system (32-bit heap id allocation field). But dealing
>> with an ioctl seems easier than names. Userspace might be less
>> likely to hardcode random id numbers vs. names as well.
> 
> 
> other advantage, I think, is selinux (brought up elsewhere on this
> thread).. heaps at known fixed PAs are useful for certain sorts of
> attacks so being able to restrict access more easily seems like a good
> thing
> 
> BR,
> -R
> 

Some other kind of filtering (BPF/LSM/???) might work as well
(http://kernsec.org/files/lss2015/vanderstoep.pdf ?)

The fixed PA issue is a larger problem. We're never going to
be able to get away from "this heap must exist at address X"
problems but the location of CMA in general should be
randomized. I haven't actually come up with a good proposal
to this though.

I'd like for Ion to be a framework for memory allocation and
not security exploits. Hopefully this isn't a pipe dream.

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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/13/2017 06:21 AM, Mark Brown wrote:
> On Mon, Mar 13, 2017 at 10:54:33AM +, Brian Starkey wrote:
>> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
> 
>>> Another point is how can we put secure rules (like selinux policy) on
>>> heaps since all the allocations
>>> go to the same device (/dev/ion) ? For example, until now, in Android
>>> we have to give the same
>>> access rights to all the process that use ION.
>>> It will become problem when we will add secure heaps because we won't
>>> be able to distinguish secure
>>> processes to standard ones or set specific policy per heaps.
>>> Maybe I'm wrong here but I have never see selinux policy checking an
>>> ioctl field but if that
>>> exist it could be a solution.
> 
>> I might be thinking of a different type of "secure", but...
> 
>> Should the security of secure heaps be enforced by OS-level
>> permissions? I don't know about other architectures, but at least on
>> arm/arm64 this is enforced in hardware; it doesn't matter who has
>> access to the ion heap, because only secure devices (or the CPU
>> running a secure process) is physically able to access the memory
>> backing the buffer.
> 3
>> In fact, in the use-cases I know of, the process asking for the ion
>> allocation is not a secure process, and so we wouldn't *want* to
>> restrict the secure heap to be allocated from only by secure
>> processes.
> 
> I think there's an orthogonal level of OS level security that can be
> applied here - it's reasonable for it to want to say things like "only
> processes that are supposed to be implementing functionality X should be
> able to try to allocate memory set aside for that functionality".  This
> mitigates against escallation attacks and so on, it's not really
> directly related to secure memory as such though.
> 

Ion also makes it pretty trivial to allocate large amounts of kernel
memory and possibly DoS the system. I'd like to have as little
policy in Ion as possible but more important would be a general
security review and people shouting "bad idea ahead".

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

[Bug 100189] segfault at 234 error 4 in i915_dri.so

[bugzilla-daemon]

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

Bug ID: 100189
   Summary: segfault at 234 error 4 in i915_dri.so
   Product: Mesa
   Version: 17.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: javib...@hotmail.com
QA Contact: dri-devel@lists.freedesktop.org

Lubuntu 16.04 4.4.0-38-generic x86_64
17.1~git1703131930

mpv/vo[18230]: segfault at 234 ip 7ff625ed96e8 sp 7ff6277fd7b0 error 4
in i915_dri.so[7ff6259f5000+9c8000]
glmark2[26598]: segfault at 234 ip 7f917ecb36e8 sp 7ffdf0586e30 error 4
in i915_dri.so[7f917e7cf000+9c8000]
glxgears[27933]: segfault at 234 ip 7f87f68e66e8 sp 7fff6da8a110 error
4 in i915_dri.so[7f87f6402000+9c8000]

-- 
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 PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Rob Clark]

On Mon, Mar 13, 2017 at 5:09 PM, Laura Abbott  wrote:
>> Hm, we might want to expose all the heaps as individual
>> /dev/ion_$heapname nodes? Should we do this from the start, since
>> we're massively revamping the uapi anyway (imo not needed, current
>> state seems to work too)?
>> -Daniel
>>
>
> I thought about that. One advantage with separate /dev/ion_$heap
> is that we don't have to worry about a limit of 32 possible
> heaps per system (32-bit heap id allocation field). But dealing
> with an ioctl seems easier than names. Userspace might be less
> likely to hardcode random id numbers vs. names as well.


other advantage, I think, is selinux (brought up elsewhere on this
thread).. heaps at known fixed PAs are useful for certain sorts of
attacks so being able to restrict access more easily seems like a good
thing

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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/13/2017 03:54 AM, Brian Starkey wrote:
> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
>> 2017-03-09 18:38 GMT+01:00 Laura Abbott :
>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
 2017-03-06 17:04 GMT+01:00 Daniel Vetter :
> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>
>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>> all into staging/android/. We've discussed ION a bunch of times, 
>>> recorded
>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>> series here addresses a big chunk of that.
>>
>>> This is pretty much the same approach we (gpu folks) used to de-stage 
>>> the
>>> syncpt stuff.
>>
>> Well, there's also the fact that quite a few people have issues with the
>> design (like Laurent).  It seems like a lot of them have either got more
>> comfortable with it over time, or at least not managed to come up with
>> any better ideas in the meantime.
>
> See the TODO, it has everything a really big group (look at the patch for
> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
> merge stuff because merging stuff is fun :-)
>
> Laurent was even in that group ...
> -Daniel

 For me those patches are going in the right direction.

 I still have few questions:
 - since alignment management has been remove from ion-core, should it
 be also removed from ioctl structure ?
>>>
>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>> so we don't need the compat layer and as part of that I'm also
>>> dropping the align argument.
>>>
 - can you we ride off ion_handle (at least in userland) and only
 export a dma-buf descriptor ?
>>>
>>> Yes, I think this is the right direction given we're breaking
>>> everything anyway. I was debating trying to keep the two but
>>> moving to only dma bufs is probably cleaner. The only reason
>>> I could see for keeping the handles is running out of file
>>> descriptors for dma-bufs but that seems unlikely.

 In the future how can we add new heaps ?
 Some platforms have very specific memory allocation
 requirements (just have a look in the number of gem custom allocator in 
 drm)
 Do you plan to add heap type/mask for each ?
>>>
>>> Yes, that was my thinking.
>>
>> My concern is about the policy to adding heaps, will you accept
>> "customs" heap per
>> platforms ? per devices ? or only generic ones ?
>> If you are too strict, we will have lot of out-of-tree heaps and if
>> you accept of of them
>> it will be a nightmare to maintain
>>
> 
> Are you concerned about actual heaps (e.g. a carveout at 0x8000 vs
> a carveout at 0x6000) or heap types?
> 
> For heap types, I think the policy can be strict - if it's generally
> useful then it should live in-tree in ion. Otherwise, it would be
> out-of-tree. I'd expect most "custom" heaps to be parameterisable to
> the point of being generally useful.
> 

I'm willing to be reasonably permissive in what lives in tree. A good
example would be something like a heap for the OMAP tiler which had
weird hardware requirements. The associated devices that go with the
heap should be well supported upstream though.

> For actual heap instances, I would expect them to be communicated via
> reserved-memory regions or something similar, and so the maintenance
> burden is pretty low.
> 

Yes. After the next round of review for this series I'm going to
start thinking about properties for chunk and carveout heaps if nobody
proposes something first.

> The existing query ioctl can allow heap IDs to get assigned
> dynamically at runtime, so there's no need to reserve "bit 6" for
> "CUSTOM_ACME_HEAP_1"
> 
>> Another point is how can we put secure rules (like selinux policy) on
>> heaps since all the allocations
>> go to the same device (/dev/ion) ? For example, until now, in Android
>> we have to give the same
>> access rights to all the process that use ION.
>> It will become problem when we will add secure heaps because we won't
>> be able to distinguish secure
>> processes to standard ones or set specific policy per heaps.
>> Maybe I'm wrong here but I have never see selinux policy checking an
>> ioctl field but if that
>> exist it could be a solution.
>>
> 
> I might be thinking of a different type of "secure", but...
> 
> Should the security of secure heaps be enforced by OS-level
> permissions? I don't know about other architectures, but at least on
> arm/arm64 this is enforced in hardware; it doesn't matter who has
> access to the ion heap, because only secure devices (or the CPU
> running a secure process) is physically able to access the memory
> backing the buffer.
> 
> In fact, in the use-cases I know of, the process asking for the ion
> allocation is not a secure process, and

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/12/2017 12:05 PM, Daniel Vetter wrote:
> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
>  wrote:
>> 2017-03-09 18:38 GMT+01:00 Laura Abbott :
>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
 2017-03-06 17:04 GMT+01:00 Daniel Vetter :
> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>
>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>> all into staging/android/. We've discussed ION a bunch of times, 
>>> recorded
>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>> series here addresses a big chunk of that.
>>
>>> This is pretty much the same approach we (gpu folks) used to de-stage 
>>> the
>>> syncpt stuff.
>>
>> Well, there's also the fact that quite a few people have issues with the
>> design (like Laurent).  It seems like a lot of them have either got more
>> comfortable with it over time, or at least not managed to come up with
>> any better ideas in the meantime.
>
> See the TODO, it has everything a really big group (look at the patch for
> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
> merge stuff because merging stuff is fun :-)
>
> Laurent was even in that group ...
> -Daniel

 For me those patches are going in the right direction.

 I still have few questions:
 - since alignment management has been remove from ion-core, should it
 be also removed from ioctl structure ?
>>>
>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>> so we don't need the compat layer and as part of that I'm also
>>> dropping the align argument.
>>>
 - can you we ride off ion_handle (at least in userland) and only
 export a dma-buf descriptor ?
>>>
>>> Yes, I think this is the right direction given we're breaking
>>> everything anyway. I was debating trying to keep the two but
>>> moving to only dma bufs is probably cleaner. The only reason
>>> I could see for keeping the handles is running out of file
>>> descriptors for dma-bufs but that seems unlikely.

 In the future how can we add new heaps ?
 Some platforms have very specific memory allocation
 requirements (just have a look in the number of gem custom allocator in 
 drm)
 Do you plan to add heap type/mask for each ?
>>>
>>> Yes, that was my thinking.
>>
>> My concern is about the policy to adding heaps, will you accept
>> "customs" heap per
>> platforms ? per devices ? or only generic ones ?
>> If you are too strict, we will have lot of out-of-tree heaps and if
>> you accept of of them
>> it will be a nightmare to maintain
> 
> I think ion should expose any heap that's also directly accessible to
> devices using dma_alloc(_coherent). That should leave very few things
> left, like your SMA heap.
> 
>> Another point is how can we put secure rules (like selinux policy) on
>> heaps since all the allocations
>> go to the same device (/dev/ion) ? For example, until now, in Android
>> we have to give the same
>> access rights to all the process that use ION.
>> It will become problem when we will add secure heaps because we won't
>> be able to distinguish secure
>> processes to standard ones or set specific policy per heaps.
>> Maybe I'm wrong here but I have never see selinux policy checking an
>> ioctl field but if that
>> exist it could be a solution.
> 
> Hm, we might want to expose all the heaps as individual
> /dev/ion_$heapname nodes? Should we do this from the start, since
> we're massively revamping the uapi anyway (imo not needed, current
> state seems to work too)?
> -Daniel
> 

I thought about that. One advantage with separate /dev/ion_$heap
is that we don't have to worry about a limit of 32 possible
heaps per system (32-bit heap id allocation field). But dealing
with an ioctl seems easier than names. Userspace might be less
likely to hardcode random id numbers vs. names as well.

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

Re: [PATCH] drm/rockchip: Refactor the component match logic.

[Sean Paul]

On Wed, Mar 08, 2017 at 01:58:14PM +0800, Jeffy Chen wrote:
> Currently we are adding all components from the dts, if one of their
> drivers been disabled, we would not be able to bring up others.
> 
> Refactor component match logic, follow exynos drm.
> 
> Signed-off-by: Jeffy Chen 
> 
> ---
> 
>  drivers/gpu/drm/rockchip/Kconfig|  10 +-
>  drivers/gpu/drm/rockchip/Makefile   |  16 +--
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   9 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |   8 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   8 +-
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  10 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c|  10 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 156 
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   8 +-
>  10 files changed, 133 insertions(+), 108 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0e4eb84..50c41c0 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -13,7 +13,7 @@ config DRM_ROCKCHIP
> IP found on the SoC.
>  
>  config ROCKCHIP_ANALOGIX_DP
> - tristate "Rockchip specific extensions for Analogix DP driver"
> + bool "Rockchip specific extensions for Analogix DP driver"
>   depends on DRM_ROCKCHIP
>   select DRM_ANALOGIX_DP
>   help
> @@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
> on RK3288 based SoC, you should selet this option.
>  
>  config ROCKCHIP_CDN_DP
> -tristate "Rockchip cdn DP"
> +bool "Rockchip cdn DP"
>  depends on DRM_ROCKCHIP
>   depends on EXTCON
>   select SND_SOC_HDMI_CODEC if SND_SOC
> @@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
> option.
>  
>  config ROCKCHIP_DW_HDMI
> -tristate "Rockchip specific extensions for Synopsys DW HDMI"
> +bool "Rockchip specific extensions for Synopsys DW HDMI"
>  depends on DRM_ROCKCHIP
>  select DRM_DW_HDMI
>  help
> @@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
> option.
>  
>  config ROCKCHIP_DW_MIPI_DSI
> - tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
> + bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
>   depends on DRM_ROCKCHIP
>   select DRM_MIPI_DSI
>   help
> @@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
>option.
>  
>  config ROCKCHIP_INNO_HDMI
> - tristate "Rockchip specific extensions for Innosilicon HDMI"
> + bool "Rockchip specific extensions for Innosilicon HDMI"
>   depends on DRM_ROCKCHIP
>   help
> This selects support for Rockchip SoC specific extensions
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index c931e2a..fa8dc9d 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -3,14 +3,14 @@
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
>  rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
> - rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
> + rockchip_drm_gem.o rockchip_drm_psr.o \
> + rockchip_drm_vop.o rockchip_vop_reg.o
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
> -obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
> -cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
> -obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> -obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>  
> -obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
> +obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 8548e82..91ebe5c 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -507,7 +507,7 @@ static const struct of_device_id rockchip_dp_dt_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
>  
> -static struct platform_driver rockchip_dp_driver = {
> +struct platform_driver rockchip_dp_driver = {
>   .probe = rockchip_dp_probe,
>   .remove = rockchip_dp_remove,
>   .driver = {
> @@ -516,10 +516,3 @@ static struct platform_driver rockchip_dp_driver = {
>  .of_match_table = of_match_ptr(rockchip_dp_dt_ids),
>   },
>  };
> -
> -module_platform_driver(rockchip_dp_driver);
> -
> -MODULE_AUTHOR(

Re: [PATCH 0/3] RK3399 cdd-dp patches

[Sean Paul]

On Wed, Mar 08, 2017 at 10:27:54AM +0800, Chris Zhong wrote:
> Hi all
> This series is to correct some mistakes in clk_get_rate and the register
> address. And in order to better develop, adding more prints.
> 
> 
> Chris Zhong (3):
>   drm/rockchip: cdn-dp: return error code when clk_get_rate failed
>   drm/rockchip: cdn-dp: Correct PHY register address
>   drm/rockchip: cdn-dp: add more log for video config

Hi Chris,
Thanks for sending these up, I've applied the entire series to drm-misc

Sean

> 
>  drivers/gpu/drm/rockchip/cdn-dp-core.c |  5 +++--
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  |  6 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 13 ++---
>  3 files changed, 14 insertions(+), 10 deletions(-)
> 
> -- 
> 2.6.3
> 
> ___
> 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 84663] high cpu usage, poor performance in Borderlands 2 with radeonsi, PRIME

[bugzilla-daemon]

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Olšák  ---
Closing. The shader cache should fix the pauses. glthread will improve
performance.

-- 
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 99950] Add cl_khr_int64_base_atomics to Clover and make it work on radeonsi

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Blocks||99764


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99764
[Bug 99764] Make OpenMM OpenCL support work on Clover and RadeonSI
-- 
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: [RESEND PATCH] drm/msm: adreno: fix build error without debugfs

[Sean Paul]

On Mon, Mar 13, 2017 at 06:09:17PM +, Emil Velikov wrote:
> On 13 March 2017 at 17:00, Rob Clark  wrote:
> > On Mon, Mar 13, 2017 at 12:43 PM, Arnd Bergmann  wrote:
> >> The newly added a5xx support fails to build when debugfs is diabled:
> >>
> >> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' 
> >> has no member named 'show'
> >> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' 
> >> undeclared here (not in a function); did you mean 'a5xx_irq'?
> >>
> >> This adds a missing #ifdef.
> >>
> >> Fixes: b5f103ab98c7 ("drm/msm: gpu: Add A5XX target support")
> >> Cc: sta...@vger.kernel.org
> >> Signed-off-by: Arnd Bergmann 
> >
> > I thought I had picked this one up already, but I guess my brain was
> > playing tricks on me.. I've pushed this to msm-next for now and will
> > cherry-pick this over to a -fixes branch when I send fixes for 4.11..
> >
> Sean sent a similar patch last week. I think he picked it (alongside
> others) in drm-misc-fixes.
> Haven't checked though ;-)

Indeed [1]. I pushed it to drm-misc-fixes, but I don't see it there any longer.

At any rate, I'm glad we got the fix merged somewhere.

Sean

[1]- https://lists.freedesktop.org/archives/dri-devel/2017-March/134876.html

> 
> -Emil
> ___
> 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: [Intel-gfx] [PATCH 24/24] drm/gem: Add DEFINE_DRM_GEM_FOPS

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:57PM +0100, Daniel Vetter wrote:
> Sadly there's only 1 driver which can use it, everyone else is special
> for some reason:
> 
> - gma500 has a horrible runtime PM ioctl wrapper that probably doesn't
>   really work but meh.
> - i915 needs special compat_ioctl handler because regrets.
> - arcgpu needs to fixup the pgprot because (no idea why it can't do
>   that in the fault handler like everyone else).
> - tegra does even worse stuff with pgprot
> - udl does something with vm_flags too ...
> - cma helpers, etnaviv, mtk, msm, rockchip, omap all implement some
>   variation on prefaulting.
> - exynos is exynos, I got lost in the midlayers.
> - vc4 has to reinvent half of cma helpers because those are too much
>   midlayer, plus vm_flags dances.
> - vgem also seems unhappy with the default vm_flags.

I wonder whether a todo entry to clean this up would be appropriate.

Reviewed-by: Sean Paul 
> 
> So pretty sad divergence and I'm sure we could do better, but not
> really an idea. Oh well, maybe this macro here helps to encourage more
> consistency at least going forward.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/armada/armada_drv.c | 11 +--
>  drivers/gpu/drm/drm_file.c  |  8 +++-
>  include/drm/drm_gem.h   | 26 ++
>  3 files changed, 30 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 1952e8748fea..f986e9ff093d 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -60,16 +60,7 @@ static void armada_drm_lastclose(struct drm_device *dev)
>   armada_fbdev_lastclose(dev);
>  }
>  
> -static const struct file_operations armada_drm_fops = {
> - .owner  = THIS_MODULE,
> - .llseek = no_llseek,
> - .read   = drm_read,
> - .poll   = drm_poll,
> - .unlocked_ioctl = drm_ioctl,
> - .mmap   = drm_gem_mmap,
> - .open   = drm_open,
> - .release= drm_release,
> -};
> +DEFINE_DRM_GEM_FOPS(armada_drm_fops);
>  
>  static struct drm_driver armada_drm_driver = {
>   .lastclose  = armada_drm_lastclose,
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 260a83563976..0701362dcca1 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -89,11 +89,9 @@ DEFINE_MUTEX(drm_global_mutex);
>   * .mmap = drm_gem_mmap,
>   * };
>   *
> - * For CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to make
> - * this simpler.
> - *
> - * FIXME: We should have a macro for this (and the CMA version) so that 
> drivers
> - * don't have to repeat it all the time.
> + * For plain GEM based drivers there is the DEFINE_DRM_GEM_FOPS() macro, and 
> for
> + * CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to make 
> this
> + * simpler.
>   */
>  
>  static int drm_open_helper(struct file *filp, struct drm_minor *minor);
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index b9ade75ecd82..663d80358057 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -178,6 +178,32 @@ struct drm_gem_object {
>   struct dma_buf_attachment *import_attach;
>  };
>  
> +/**
> + * DEFINE_DRM_GEM_FOPS() - macro to generate file operations for GEM drivers
> + * @name: name for the generated structure
> + *
> + * This macro autogenerates a suitable &struct file_operations for GEM based
> + * drivers, which can be assigned to &drm_driver.fops. Note that this 
> structure
> + * cannot be shared between drivers, because it contains a reference to the
> + * current module using THIS_MODULE.
> + *
> + * Note that the declaration is already marked as static - if you need a
> + * non-static version of this you're probably doing it wrong and will break 
> the
> + * THIS_MODULE reference by accident.
> + */
> +#define DEFINE_DRM_GEM_FOPS(name) \
> + static const struct file_operations name = {\
> + .owner  = THIS_MODULE,\
> + .open   = drm_open,\
> + .release= drm_release,\
> + .unlocked_ioctl = drm_ioctl,\
> + .compat_ioctl   = drm_compat_ioctl,\
> + .poll   = drm_poll,\
> + .read   = drm_read,\
> + .llseek = noop_llseek,\
> + .mmap   = drm_gem_mmap,\
> + }
> +
>  void drm_gem_object_release(struct drm_gem_object *obj);
>  void drm_gem_object_free(struct kref *kref);
>  int drm_gem_object_init(struct drm_device *dev,
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lis

Re: [Intel-gfx] [PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

[Sean Paul]

On Mon, Mar 13, 2017 at 03:31:40PM -0400, Sean Paul wrote:
> On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote:
> > Less code ftw.
> > 
> > This converts all drivers except the tinydrm helper module. That one
> > needs more work, since it gets the THIS_MODULE reference from
> > tinydrm.ko instead of the actual driver module like it should.
> > Probably needs a similar trick like I used here with generating the
> > entire struct with a macro.
> > 
> > Cc: Noralf Trønnes 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/arm/hdlcd_drv.c | 12 +---
> >  drivers/gpu/drm/arm/malidp_drv.c| 12 +---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 12 +---
> >  drivers/gpu/drm/drm_file.c  |  3 +++
> >  drivers/gpu/drm/drm_gem_cma_helper.c|  3 +++
> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 12 +---
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 12 +---
> >  drivers/gpu/drm/imx/imx-drm-core.c  | 11 +--
> >  drivers/gpu/drm/meson/meson_drv.c   | 14 +
> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c   | 14 +
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 12 +---
> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c| 12 +---
> >  drivers/gpu/drm/sti/sti_drv.c   | 11 +--
> >  drivers/gpu/drm/sun4i/sun4i_drv.c   | 12 +---
> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 12 +---
> >  drivers/gpu/drm/zte/zx_drm_drv.c| 14 +
> >  include/drm/drm_gem_cma_helper.h| 26 
> > +
> >  17 files changed, 46 insertions(+), 158 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c 
> > b/drivers/gpu/drm/arm/hdlcd_drv.c
> > index 4840dc277339..0e74880b5e94 100644
> > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> > @@ -239,17 +239,7 @@ static int hdlcd_debugfs_init(struct drm_minor *minor)
> >  }
> >  #endif
> >  
> > -static const struct file_operations fops = {
> > -   .owner  = THIS_MODULE,
> > -   .open   = drm_open,
> > -   .release= drm_release,
> > -   .unlocked_ioctl = drm_ioctl,
> > -   .compat_ioctl   = drm_compat_ioctl,
> > -   .poll   = drm_poll,
> > -   .read   = drm_read,
> > -   .llseek = noop_llseek,
> > -   .mmap   = drm_gem_cma_mmap,
> > -};
> > +DEFINE_DRM_GEM_CMA_FOPS(fops);
> >  
> >  static struct drm_driver hdlcd_driver = {
> > .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index a9608a2e5a29..ea2546f766c2 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -178,17 +178,7 @@ static void malidp_lastclose(struct drm_device *drm)
> > drm_fbdev_cma_restore_mode(malidp->fbdev);
> >  }
> >  
> > -static const struct file_operations fops = {
> > -   .owner = THIS_MODULE,
> > -   .open = drm_open,
> > -   .release = drm_release,
> > -   .unlocked_ioctl = drm_ioctl,
> > -   .compat_ioctl = drm_compat_ioctl,
> > -   .poll = drm_poll,
> > -   .read = drm_read,
> > -   .llseek = noop_llseek,
> > -   .mmap = drm_gem_cma_mmap,
> > -};
> > +DEFINE_DRM_GEM_CMA_FOPS(fops);
> >  
> >  static struct drm_driver malidp_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > index 970bd87d7cce..178acbf5f6c5 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > @@ -724,17 +724,7 @@ static void atmel_hlcdc_dc_irq_uninstall(struct 
> > drm_device *dev)
> > regmap_read(dc->hlcdc->regmap, ATMEL_HLCDC_ISR, &isr);
> >  }
> >  
> > -static const struct file_operations fops = {
> > -   .owner  = THIS_MODULE,
> > -   .open   = drm_open,
> > -   .release= drm_release,
> > -   .unlocked_ioctl = drm_ioctl,
> > -   .compat_ioctl   = drm_compat_ioctl,
> > -   .poll   = drm_poll,
> > -   .read   = drm_read,
> > -   .llseek = no_llseek,
> > -   .mmap   = drm_gem_cma_mmap,
> > -};
> > +DEFINE_DRM_GEM_CMA_FOPS(fops);
> >  
> >  static struct drm_driver atmel_hlcdc_dc_driver = {
> > .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index f8483fc6d3d7..260a83563976 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -89,6 +89,9 @@ DEFINE_MUTEX(drm_global_mutex);
> >   * .mmap = drm_gem_mmap,
> >   * };
> >   *
> > + * For CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to 
> > make
> > + * this simpler.

Re: [Intel-gfx] [PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote:
> Less code ftw.
> 
> This converts all drivers except the tinydrm helper module. That one
> needs more work, since it gets the THIS_MODULE reference from
> tinydrm.ko instead of the actual driver module like it should.
> Probably needs a similar trick like I used here with generating the
> entire struct with a macro.
> 
> Cc: Noralf Trønnes 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 12 +---
>  drivers/gpu/drm/arm/malidp_drv.c| 12 +---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 12 +---
>  drivers/gpu/drm/drm_file.c  |  3 +++
>  drivers/gpu/drm/drm_gem_cma_helper.c|  3 +++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 12 +---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 12 +---
>  drivers/gpu/drm/imx/imx-drm-core.c  | 11 +--
>  drivers/gpu/drm/meson/meson_drv.c   | 14 +
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c   | 14 +
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 12 +---
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c| 12 +---
>  drivers/gpu/drm/sti/sti_drv.c   | 11 +--
>  drivers/gpu/drm/sun4i/sun4i_drv.c   | 12 +---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 12 +---
>  drivers/gpu/drm/zte/zx_drm_drv.c| 14 +
>  include/drm/drm_gem_cma_helper.h| 26 
> +
>  17 files changed, 46 insertions(+), 158 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 4840dc277339..0e74880b5e94 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -239,17 +239,7 @@ static int hdlcd_debugfs_init(struct drm_minor *minor)
>  }
>  #endif
>  
> -static const struct file_operations fops = {
> - .owner  = THIS_MODULE,
> - .open   = drm_open,
> - .release= drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl   = drm_compat_ioctl,
> - .poll   = drm_poll,
> - .read   = drm_read,
> - .llseek = noop_llseek,
> - .mmap   = drm_gem_cma_mmap,
> -};
> +DEFINE_DRM_GEM_CMA_FOPS(fops);
>  
>  static struct drm_driver hdlcd_driver = {
>   .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index a9608a2e5a29..ea2546f766c2 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -178,17 +178,7 @@ static void malidp_lastclose(struct drm_device *drm)
>   drm_fbdev_cma_restore_mode(malidp->fbdev);
>  }
>  
> -static const struct file_operations fops = {
> - .owner = THIS_MODULE,
> - .open = drm_open,
> - .release = drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl = drm_compat_ioctl,
> - .poll = drm_poll,
> - .read = drm_read,
> - .llseek = noop_llseek,
> - .mmap = drm_gem_cma_mmap,
> -};
> +DEFINE_DRM_GEM_CMA_FOPS(fops);
>  
>  static struct drm_driver malidp_driver = {
>   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 970bd87d7cce..178acbf5f6c5 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -724,17 +724,7 @@ static void atmel_hlcdc_dc_irq_uninstall(struct 
> drm_device *dev)
>   regmap_read(dc->hlcdc->regmap, ATMEL_HLCDC_ISR, &isr);
>  }
>  
> -static const struct file_operations fops = {
> - .owner  = THIS_MODULE,
> - .open   = drm_open,
> - .release= drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl   = drm_compat_ioctl,
> - .poll   = drm_poll,
> - .read   = drm_read,
> - .llseek = no_llseek,
> - .mmap   = drm_gem_cma_mmap,
> -};
> +DEFINE_DRM_GEM_CMA_FOPS(fops);
>  
>  static struct drm_driver atmel_hlcdc_dc_driver = {
>   .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index f8483fc6d3d7..260a83563976 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -89,6 +89,9 @@ DEFINE_MUTEX(drm_global_mutex);
>   * .mmap = drm_gem_mmap,
>   * };
>   *
> + * For CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to make
> + * this simpler.
> + *
>   * FIXME: We should have a macro for this (and the CMA version) so that 
> drivers

s_(and the CMA version)__

Reviewed-by: Sean Paul 

>   * don't have to repeat it all the time.
>   */
> diff --git a/drivers/gpu/drm/drm_g

Re: [PATCH] drm/radeon: Fix GPU lockups for the R7 M270

[Alex Deucher]

On Sat, Mar 11, 2017 at 11:21 AM, Umang Raghuvanshi  wrote:
> Commit 3a69adfe5617 ("drm/radeon: drop oland quirks") removed
> quirks for Oland but also caused a regression where M270 GPUs
> would go into a lock-up when OpenGL intensive applications were used.
> This reverts the change only for the M270 and fixes the lock-ups.

Does your kernel have this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef736d394e85b1bf1fd65ba5e5257b85f6c82325

Alex

>
> Signed-off-by: Umang Raghuvanshi 
> ---
>  drivers/gpu/drm/radeon/si_dpm.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index d12b8978142f..c2c129eef3c4 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -2984,6 +2984,11 @@ static void si_apply_state_adjust_rules(struct 
> radeon_device *rdev,
> (rdev->pdev->device == 0x6667)) {
> max_sclk = 75000;
> }
> +   } else if (rdev->family == CHIP_OLAND && rdev->pdev->device == 0x6604 
> &&
> +  rdev->pdev->revision == 0) {
> +   // Fix max_sclk and max_mclk for the Radeon R7 M270
> +   max_sclk = 75000;
> +   max_mclk = 8;
> }
>
> if (rps->vce_active) {
> --
> 2.12.0
>
>
> ___
> 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: [Intel-gfx] [PATCH 22/24] drm: Nerf the preclose callback for modern drivers

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:55PM +0100, Daniel Vetter wrote:
> With all drivers converted there's only legacy dri1 drivers using it.
> Not going to touch those, instead just hide it like we've done with
> other dri1 driver hooks like firstopen.
> 
> In all this I didn't find any real reason why we'd needed 2 hooks, and
> having symmetry between open and close just appeases my OCD better.
> Yeah, someone else could do an s/postclose/close/, but that's for
> someone who understands cocci. And maybe after this series is reviewed
> and landed, to avoid patch-regen churn.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_file.c |  8 
>  include/drm/drm_drv.h  | 23 ++-
>  2 files changed, 6 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index a8813a1115dc..f8483fc6d3d7 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -350,9 +350,8 @@ void drm_lastclose(struct drm_device * dev)
>   *
>   * This function must be used by drivers as their &file_operations.release
>   * method. It frees any resources associated with the open file, and calls 
> the
> - * &drm_driver.preclose and &drm_driver.lastclose driver callbacks. If this 
> is
> - * the last open file for the DRM device also proceeds to call the
> - * &drm_driver.lastclose driver callback.
> + * &drm_driver.lastclose driver callback. If this is the last open file for 
> the

s/lastclose/postclose/

Once that's fixed,

Reviewed-by: Sean Paul 

> + * DRM device also proceeds to call the &drm_driver.lastclose driver 
> callback.
>   *
>   * RETURNS:
>   *
> @@ -372,7 +371,8 @@ int drm_release(struct inode *inode, struct file *filp)
>   list_del(&file_priv->lhead);
>   mutex_unlock(&dev->filelist_mutex);
>  
> - if (dev->driver->preclose)
> + if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> + dev->driver->preclose)
>   dev->driver->preclose(dev, file_priv);
>  
>   /* 
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8f900fb30275..fde343e0d581 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -104,23 +104,6 @@ struct drm_driver {
>   int (*open) (struct drm_device *, struct drm_file *);
>  
>   /**
> -  * @preclose:
> -  *
> -  * One of the driver callbacks when a new &struct drm_file is closed.
> -  * Useful for tearing down driver-private data structures allocated in
> -  * @open like buffer allocators, execution contexts or similar things.
> -  *
> -  * Since the display/modeset side of DRM can only be owned by exactly
> -  * one &struct drm_file (see &drm_file.is_master and &drm_device.master)
> -  * there should never be a need to tear down any modeset related
> -  * resources in this callback. Doing so would be a driver design bug.
> -  *
> -  * FIXME: It is not really clear why there's both @preclose and
> -  * @postclose. Without a really good reason, use @postclose only.
> -  */
> - void (*preclose) (struct drm_device *, struct drm_file *file_priv);
> -
> - /**
>* @postclose:
>*
>* One of the driver callbacks when a new &struct drm_file is closed.
> @@ -131,9 +114,6 @@ struct drm_driver {
>* one &struct drm_file (see &drm_file.is_master and &drm_device.master)
>* there should never be a need to tear down any modeset related
>* resources in this callback. Doing so would be a driver design bug.
> -  *
> -  * FIXME: It is not really clear why there's both @preclose and
> -  * @postclose. Without a really good reason, use @postclose only.
>*/
>   void (*postclose) (struct drm_device *, struct drm_file *);
>  
> @@ -150,7 +130,7 @@ struct drm_driver {
>* state changes, e.g. in conjunction with the :ref:`vga_switcheroo`
>* infrastructure.
>*
> -  * This is called after @preclose and @postclose have been called.
> +  * This is called after @postclose hook has been called.
>*
>* NOTE:
>*
> @@ -516,6 +496,7 @@ struct drm_driver {
>   /* List of devices hanging off this driver with stealth attach. */
>   struct list_head legacy_dev_list;
>   int (*firstopen) (struct drm_device *);
> + void (*preclose) (struct drm_device *, struct drm_file *file_priv);
>   int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file 
> *file_priv);
>   int (*dma_quiescent) (struct drm_device *);
>   int (*context_dtor) (struct drm_device *dev, int context);
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailma

Re: [Intel-gfx] [PATCH 21/24] drm/msm: Simplify vblank event delivery

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:54PM +0100, Daniel Vetter wrote:
> The core takes care of handling the send_event vs. close() issues, we
> can remove that driver code.
> 
> Cc: Rob Clark 
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 12 +++-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 12 +++-
>  2 files changed, 6 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
> index 1c29618f4ddb..f29194a74a19 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
> @@ -114,15 +114,9 @@ static void complete_flip(struct drm_crtc *crtc, struct 
> drm_file *file)

file unused now?

>   spin_lock_irqsave(&dev->event_lock, flags);
>   event = mdp4_crtc->event;
>   if (event) {
> - /* if regular vblank case (!file) or if cancel-flip from
> -  * preclose on file that requested flip, then send the
> -  * event:
> -  */
> - if (!file || (event->base.file_priv == file)) {
> - mdp4_crtc->event = NULL;
> - DBG("%s: send event: %p", mdp4_crtc->name, event);
> - drm_crtc_send_vblank_event(crtc, event);
> - }
> + mdp4_crtc->event = NULL;
> + DBG("%s: send event: %p", mdp4_crtc->name, event);
> + drm_crtc_send_vblank_event(crtc, event);
>   }
>   spin_unlock_irqrestore(&dev->event_lock, flags);
>  }
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> index d0c8b38b96ce..87a19e0c0e67 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> @@ -138,15 +138,9 @@ static void complete_flip(struct drm_crtc *crtc, struct 
> drm_file *file)
>   spin_lock_irqsave(&dev->event_lock, flags);
>   event = mdp5_crtc->event;
>   if (event) {
> - /* if regular vblank case (!file) or if cancel-flip from
> -  * preclose on file that requested flip, then send the
> -  * event:
> -  */
> - if (!file || (event->base.file_priv == file)) {
> - mdp5_crtc->event = NULL;
> - DBG("%s: send event: %p", crtc->name, event);
> - drm_crtc_send_vblank_event(crtc, event);
> - }
> + mdp5_crtc->event = NULL;
> + DBG("%s: send event: %p", crtc->name, event);
> + drm_crtc_send_vblank_event(crtc, event);
>   }
>   spin_unlock_irqrestore(&dev->event_lock, flags);
>  
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 20/24] drm/exynos: Merge pre/postclose hooks

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:53PM +0100, Daniel Vetter wrote:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.

Commit message copypasta.

The code is 

Reviewed-by: Sean Paul 

> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index b4522f67b3cb..180e3c9884e5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -194,14 +194,9 @@ static int exynos_drm_open(struct drm_device *dev, 
> struct drm_file *file)
>   return ret;
>  }
>  
> -static void exynos_drm_preclose(struct drm_device *dev,
> - struct drm_file *file)
> -{
> - exynos_drm_subdrv_close(dev, file);
> -}
> -
>  static void exynos_drm_postclose(struct drm_device *dev, struct drm_file 
> *file)
>  {
> + exynos_drm_subdrv_close(dev, file);
>   kfree(file->driver_priv);
>   file->driver_priv = NULL;
>  }
> @@ -259,7 +254,6 @@ static struct drm_driver exynos_drm_driver = {
>   .load   = exynos_drm_load,
>   .unload = exynos_drm_unload,
>   .open   = exynos_drm_open,
> - .preclose   = exynos_drm_preclose,
>   .lastclose  = exynos_drm_lastclose,
>   .postclose  = exynos_drm_postclose,
>   .gem_free_object_unlocked = exynos_drm_gem_free_object,
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 17/24] drm/vgem: switch to postclose

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:50PM +0100, Daniel Vetter wrote:
> I didn't spot anything that would require ordering here (well not
> anywhere else either), and I'm trying to unify at least modern drivers
> on one close hook.
> 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index a1f42d125e6e..9fee38a942c4 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -104,7 +104,7 @@ static int vgem_open(struct drm_device *dev, struct 
> drm_file *file)
>   return 0;
>  }
>  
> -static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
> +static void vgem_postclose(struct drm_device *dev, struct drm_file *file)
>  {
>   struct vgem_file *vfile = file->driver_priv;
>  
> @@ -303,7 +303,7 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>  static struct drm_driver vgem_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_PRIME,
>   .open   = vgem_open,
> - .preclose   = vgem_preclose,
> + .postclose  = vgem_postclose,
>   .gem_free_object_unlocked   = vgem_gem_free_object,
>   .gem_vm_ops = &vgem_gem_vm_ops,
>   .ioctls = vgem_ioctls,
> -- 
> 2.11.0
> 
> ___
> 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 16/24] drm/tegra: switch to postclose

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:49PM +0100, Daniel Vetter wrote:
> I didn't spot anything that would require ordering here (well not
> anywhere else either), and I'm trying to unify at least modern drivers
> on one close hook.
> 
> Cc: Thierry Reding 
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/tegra/drm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index dba4e090d3df..3b419f9dbf4d 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -804,7 +804,7 @@ static const struct file_operations tegra_drm_fops = {
>   .llseek = noop_llseek,
>  };
>  
> -static void tegra_drm_preclose(struct drm_device *drm, struct drm_file *file)
> +static void tegra_drm_postclose(struct drm_device *drm, struct drm_file 
> *file)
>  {
>   struct tegra_drm_file *fpriv = file->driver_priv;
>   struct tegra_drm_context *context, *tmp;
> @@ -868,7 +868,7 @@ static struct drm_driver tegra_drm_driver = {
>   .load = tegra_drm_load,
>   .unload = tegra_drm_unload,
>   .open = tegra_drm_open,
> - .preclose = tegra_drm_preclose,
> + .postclose = tegra_drm_postclose,
>   .lastclose = tegra_drm_lastclose,
>  
>  #if defined(CONFIG_DEBUG_FS)
> -- 
> 2.11.0
> 
> ___
> 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 14/24] drm/nouveau: Merge pre/postclose hooks

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:47PM +0100, Daniel Vetter wrote:
> Again no apparent explanation for the split except hysterical raisins.
> Merging them also makes it a bit more obviuos what's going on wrt the
> runtime pm refdancing.

Yeah, holding the pm reference from preclose to postclose had me a little
nervous. However, it seems like the reference is just needed for
nouveau_abi16_fini() and nouveau_cli_fini(), as opposed to being needed while
drm_release() is active.

Reviewed-by: Sean Paul 

> 
> Cc: Ben Skeggs 
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index f0bb7606eb8b..0e26be017de7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -881,7 +881,7 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file 
> *fpriv)
>  }
>  
>  static void
> -nouveau_drm_preclose(struct drm_device *dev, struct drm_file *fpriv)
> +nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
>  {
>   struct nouveau_cli *cli = nouveau_cli(fpriv);
>   struct nouveau_drm *drm = nouveau_drm(dev);
> @@ -897,12 +897,6 @@ nouveau_drm_preclose(struct drm_device *dev, struct 
> drm_file *fpriv)
>   list_del(&cli->head);
>   mutex_unlock(&drm->client.mutex);
>  
> -}
> -
> -static void
> -nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
> -{
> - struct nouveau_cli *cli = nouveau_cli(fpriv);
>   nouveau_cli_fini(cli);
>   kfree(cli);
>   pm_runtime_mark_last_busy(dev->dev);
> @@ -974,7 +968,6 @@ driver_stub = {
>   .load = nouveau_drm_load,
>   .unload = nouveau_drm_unload,
>   .open = nouveau_drm_open,
> - .preclose = nouveau_drm_preclose,
>   .postclose = nouveau_drm_postclose,
>   .lastclose = nouveau_vga_lastclose,
>  
> -- 
> 2.11.0
> 
> ___
> 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: [Intel-gfx] [PATCH 13/24] drm/msm: switch to postclose

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:46PM +0100, Daniel Vetter wrote:
> I didn't spot anything that would require ordering here (well not
> anywhere else either), and I'm trying to unify at least modern drivers
> on one close hook.
> 
> Cc: Rob Clark 
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 

I think I've convinced myself that this is functionally equivalent (or at least
if Bad Things could happen with postclose, they would also be Bad Things with
preclose). So, fwiw:

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/msm_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 604331f3cf39..44774f02ef0e 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -540,7 +540,7 @@ static int msm_open(struct drm_device *dev, struct 
> drm_file *file)
>   return 0;
>  }
>  
> -static void msm_preclose(struct drm_device *dev, struct drm_file *file)
> +static void msm_postclose(struct drm_device *dev, struct drm_file *file)
>  {
>   struct msm_drm_private *priv = dev->dev_private;
>   struct msm_file_private *ctx = file->driver_priv;
> @@ -813,7 +813,7 @@ static struct drm_driver msm_driver = {
>   DRIVER_ATOMIC |
>   DRIVER_MODESET,
>   .open   = msm_open,
> - .preclose   = msm_preclose,
> + .postclose   = msm_postclose,
>   .lastclose  = msm_lastclose,
>   .irq_handler= msm_irq,
>   .irq_preinstall = msm_irq_preinstall,
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100089] Space Run rendering prolems

[bugzilla-daemon]

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

--- Comment #5 from Samuel Pitoiset  ---
You might want to upload the trace with gdrive or dropbox.

-- 
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: [RESEND PATCH] drm/msm: adreno: fix build error without debugfs

[Emil Velikov]

On 13 March 2017 at 17:00, Rob Clark  wrote:
> On Mon, Mar 13, 2017 at 12:43 PM, Arnd Bergmann  wrote:
>> The newly added a5xx support fails to build when debugfs is diabled:
>>
>> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' 
>> has no member named 'show'
>> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared 
>> here (not in a function); did you mean 'a5xx_irq'?
>>
>> This adds a missing #ifdef.
>>
>> Fixes: b5f103ab98c7 ("drm/msm: gpu: Add A5XX target support")
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Arnd Bergmann 
>
> I thought I had picked this one up already, but I guess my brain was
> playing tricks on me.. I've pushed this to msm-next for now and will
> cherry-pick this over to a -fixes branch when I send fixes for 4.11..
>
Sean sent a similar patch last week. I think he picked it (alongside
others) in drm-misc-fixes.
Haven't checked though ;-)

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

[Bug 100089] Space Run rendering prolems

[bugzilla-daemon]

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

--- Comment #4 from LunarG  ---
I'm having trouble adding the trace. I can't trim my current trace to the
allowable upload size (including compressing it). I also can't create a new
trace; apitrace gets an abort signal when trying to run the game with apitrace.

Let me see what I can do...

-- 
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 11/24] drm/doc: Document drm_file.[hc]

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:44PM +0100, Daniel Vetter wrote:
> Well, mostly drm_file.h, and clean up all related things:
> 
> - I didnt' figure out the difference between preclose and postclose.
>   The existing explanation in drm-internals.rst didn't convince me,
>   since it's also really outdated - we clean up pending DRM events in
>   the core nowadays. I put a FIXME in for the future.
> 
> - Another FIXME is to have a macro for default fops.
> 
> - Lots of links all around, main areas are to tie the overview in
>   drm_file.c more into the callbacks in struct drm_device, and the
>   other is to link render/primary node code to the right sections in
>   drm-uapi.rst.
> 
> - Also moved the open/close stuff to drm_drv.h from drm-internals.rst,
>   seems like the better place for that information. Since that section
>   was rather outdated this amounted to full-on rewrite.
> 
> A big missing piece here is some overview graph, but I think better to
> wait with that one until drm_device and drm_driver are also fully
> documented.
> 
> Signed-off-by: Daniel Vetter 

Overall, awesome patch, really does a good job explaining the parameters and how
they interact with each other (bonus points for the lock breadcrumbs). I just
have a few optional nits and some spelling errors.

Reviewed-by: Sean Paul 

> ---
>  Documentation/gpu/drm-internals.rst |  52 +--
>  Documentation/gpu/drm-uapi.rst  |   4 +
>  drivers/gpu/drm/drm_file.c  |  66 +
>  include/drm/drm_drv.h   |  81 ++-
>  include/drm/drm_file.h  | 267 
> 
>  5 files changed, 356 insertions(+), 114 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-internals.rst 
> b/Documentation/gpu/drm-internals.rst
> index ea329b71c459..7a2fe4a02212 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -246,61 +246,15 @@ drivers.
>  Open/Close, File Operations and IOCTLs
>  ==
>  
> -Open and Close
> ---
> -
> -Open and close handlers. None of those methods are mandatory::
> -
> -int (*firstopen) (struct drm_device *);
> -void (*lastclose) (struct drm_device *);
> -int (*open) (struct drm_device *, struct drm_file *);
> -void (*preclose) (struct drm_device *, struct drm_file *);
> -void (*postclose) (struct drm_device *, struct drm_file *);
> -
> -The firstopen method is called by the DRM core for legacy UMS (User Mode
> -Setting) drivers only when an application opens a device that has no
> -other opened file handle. UMS drivers can implement it to acquire device
> -resources. KMS drivers can't use the method and must acquire resources
> -in the load method instead.
> -
> -Similarly the lastclose method is called when the last application
> -holding a file handle opened on the device closes it, for both UMS and
> -KMS drivers. Additionally, the method is also called at module unload
> -time or, for hot-pluggable devices, when the device is unplugged. The
> -firstopen and lastclose calls can thus be unbalanced.
> -
> -The open method is called every time the device is opened by an
> -application. Drivers can allocate per-file private data in this method
> -and store them in the struct :c:type:`struct drm_file
> -` driver_priv field. Note that the open method is
> -called before firstopen.
> -
> -The close operation is split into preclose and postclose methods.
> -Drivers must stop and cleanup all per-file operations in the preclose
> -method. For instance pending vertical blanking and page flip events must
> -be cancelled. No per-file operation is allowed on the file handle after
> -returning from the preclose method.
> -
> -Finally the postclose method is called as the last step of the close
> -operation, right before calling the lastclose method if no other open
> -file handle exists for the device. Drivers that have allocated per-file
> -private data in the open method should free it here.
> -
> -The lastclose method should restore CRTC and plane properties to default
> -value, so that a subsequent open of the device will not inherit state
> -from the previous user. It can also be used to execute delayed power
> -switching state changes, e.g. in conjunction with the :ref:`vga_switcheroo`
> -infrastructure. Beyond that KMS drivers should not do any
> -further cleanup. Only legacy UMS drivers might need to clean up device
> -state so that the vga console or an independent fbdev driver could take
> -over.
> -
>  File Operations
>  ---
>  
>  .. kernel-doc:: drivers/gpu/drm/drm_file.c
> :doc: file operations
>  
> +.. kernel-doc:: include/drm/drm_file.h
> +   :internal:
> +
>  .. kernel-doc:: drivers/gpu/drm/drm_file.c
> :export:
>  
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index fcc228ef5bc4..352652810dab 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -21,6 +21,8 @@

Re: [PATCH 3/3] drm/tegra: Support for sync file-based fences in submit

[Thierry Reding]

On Mon, Mar 13, 2017 at 11:07:28AM +0200, Mikko Perttunen wrote:
> 
> 
> On 13.03.2017 09:15, Thierry Reding wrote:
> > On Thu, Mar 09, 2017 at 07:57:18PM +0200, Mikko Perttunen wrote:
> > > Add support for sync file-based prefences and postfences
> > > to job submission. Fences are passed to the Host1x implementation.
> > > 
> > > Signed-off-by: Mikko Perttunen 
> > > ---
> > >  drivers/gpu/drm/tegra/drm.c | 69 
> > > ++---
> > >  1 file changed, 59 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> > > index 64dff8530403..bf4a2a13c17d 100644
> > > --- a/drivers/gpu/drm/tegra/drm.c
> > > +++ b/drivers/gpu/drm/tegra/drm.c
> > > @@ -10,6 +10,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > 
> > >  #include 
> > >  #include 
> > > @@ -344,6 +345,7 @@ int tegra_drm_submit(struct tegra_drm_context 
> > > *context,
> > >struct drm_tegra_submit *args, struct drm_device *drm,
> > >struct drm_file *file)
> > >  {
> > > + struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
> > >   unsigned int num_cmdbufs = args->num_cmdbufs;
> > >   unsigned int num_relocs = args->num_relocs;
> > >   unsigned int num_waitchks = args->num_waitchks;
> > > @@ -361,6 +363,11 @@ int tegra_drm_submit(struct tegra_drm_context 
> > > *context,
> > >   if (args->num_syncpts != 1)
> > >   return -EINVAL;
> > > 
> > > + /* Check for unrecognized flags */
> > > + if (args->flags & ~(DRM_TEGRA_SUBMIT_WAIT_FENCE_FD |
> > > + DRM_TEGRA_SUBMIT_CREATE_FENCE_FD))
> > > + return -EINVAL;
> > > +
> > >   job = host1x_job_alloc(context->channel, args->num_cmdbufs,
> > >  args->num_relocs, args->num_waitchks);
> > >   if (!job)
> > > @@ -372,19 +379,27 @@ int tegra_drm_submit(struct tegra_drm_context 
> > > *context,
> > >   job->class = context->client->base.class;
> > >   job->serialize = true;
> > > 
> > > + if (args->flags & DRM_TEGRA_SUBMIT_WAIT_FENCE_FD) {
> > > + job->prefence = sync_file_get_fence(args->fence);
> > > + if (!job->prefence) {
> > > + err = -ENOENT;
> > > + goto put_job;
> > > + }
> > > + }
> > > +
> > >   while (num_cmdbufs) {
> > >   struct drm_tegra_cmdbuf cmdbuf;
> > >   struct host1x_bo *bo;
> > > 
> > >   if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) {
> > >   err = -EFAULT;
> > > - goto fail;
> > > + goto put_fence;
> > >   }
> > > 
> > >   bo = host1x_bo_lookup(file, cmdbuf.handle);
> > >   if (!bo) {
> > >   err = -ENOENT;
> > > - goto fail;
> > > + goto put_fence;
> > >   }
> > > 
> > >   host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
> > > @@ -398,19 +413,19 @@ int tegra_drm_submit(struct tegra_drm_context 
> > > *context,
> > > &relocs[num_relocs], drm,
> > > file);
> > >   if (err < 0)
> > > - goto fail;
> > > + goto put_fence;
> > >   }
> > > 
> > >   if (copy_from_user(job->waitchk, waitchks,
> > >  sizeof(*waitchks) * num_waitchks)) {
> > >   err = -EFAULT;
> > > - goto fail;
> > > + goto put_fence;
> > >   }
> > > 
> > >   if (copy_from_user(&syncpt, (void __user *)(uintptr_t)args->syncpts,
> > >  sizeof(syncpt))) {
> > >   err = -EFAULT;
> > > - goto fail;
> > > + goto put_fence;
> > >   }
> > > 
> > >   job->is_addr_reg = context->client->ops->is_addr_reg;
> > > @@ -423,20 +438,54 @@ int tegra_drm_submit(struct tegra_drm_context 
> > > *context,
> > > 
> > >   err = host1x_job_pin(job, context->client->base.dev);
> > >   if (err)
> > > - goto fail;
> > > + goto put_fence;
> > > 
> > >   err = host1x_job_submit(job);
> > >   if (err)
> > > - goto fail_submit;
> > > + goto unpin_job;
> > 
> > Shouldn't all error-unwinding gotos after this jump to the unpin_job
> > label as well? Seems like they all jump to put_fence instead, which I
> > think would leave the job pinned on failure.
> 
> After host1x_job_submit is succesfully called, host1x's job tracking owns
> the job and will call unpin on it once it finishes or times out, so we
> cannot unpin it from here.

Okay, might be worth explaining that in a comment above the call to
host1x_job_submit() because it's not obvious and I'm pretty sure people
would send in patches to "fix" this.

Thierry


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

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

[Gustavo Padovan]

Hi Philipp,

2017-03-13 Philipp Zabel :

> Hi Gustavo,
> 
> thank you for the review.
> 
> On Wed, 2017-03-08 at 11:37 -0300, Gustavo Padovan wrote:
> [...]
> > > @@ -385,6 +396,25 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > > void *data,
> > >   goto err_submit_objects;
> > >   }
> > >  
> > > + if (args->flags & ETNA_SUBMIT_FENCE_FD_IN) {
> > > + in_fence = sync_file_get_fence(args->fence_fd);
> > > + if (!in_fence) {
> > > + ret = -EINVAL;
> > > + goto err_submit_objects;
> > > + }
> > > +
> > > + /* TODO if we get an array-fence due to userspace merging
> > > +  * multiple fences, we need a way to determine if all the
> > > +  * backing fences are from our own context..
> > > +  */
> > 
> > All GPU drivers seem to have the same need on fence_array, so I think we
> > can create a fence array helper to inspect if it has a specific context
> > or not.
> 
> Do you have a pointer where I could read up on how this should be done?

I was thinking on some function that would iterate over all fences in
the fence_array and check their context. The if we find our own gpu
context in there we fail the submit.

> 
> > > +
> > > + if (in_fence->context != gpu->fence_context) {
> > > + ret = dma_fence_wait(in_fence, true);
> > > + if (ret)
> > > + goto err_submit_objects;
> > 
> > sync_file_get_fence() hold a fence ref, we need to release it here
> > always and not only in case of error.
> 
> We do that already. err_submit_objects is an unfortunate name for patch
> review, but the out label at the end of the function falls right through
> to it.
> 
> > > + }
> > > + }
> > > +
> > >   ret = submit_fence_sync(submit);
> > >   if (ret)
> > >   goto err_submit_objects;
> > > @@ -419,6 +449,8 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > > void *data,
> > >   flush_workqueue(priv->wq);
> > >  
> > >  err_submit_objects:
> > > + if (in_fence)
> > > + dma_fence_put(in_fence);
> 
> We pass through here in the non-error case, too.

Cool.

> 
> [...]
> > > @@ -154,6 +154,10 @@ struct drm_etnaviv_gem_submit_bo {
> > >   * one or more cmdstream buffers.  This allows for conditional execution
> > >   * (context-restore), and IB buffers needed for per tile/bin draw cmds.
> > >   */
> > > +#define ETNA_SUBMIT_NO_IMPLICIT 0x0001
> > > +#define ETNA_SUBMIT_FENCE_FD_IN 0x0002
> > 
> > ETNA_SUBMIT_NO_IMPLICIT and ETNA_SUBMIT_FENCE_FD_IN are the same, when
> > you send and fence_fd to the kernel you are requesting on explicit sync
> > thus I think the ETNA_SUBMIT_NO_IMPLICIT can be dropped and
> > ETNA_SUBMIT_FENCE_FD_IN would be the one to look at.
> 
> I just followed Rob's lead. I'm not sure if there may be a reason to
> submit an in fence still keep implicit fencing enabled at the same time,
> or to allow a submit without any fencing whatsoever. Maybe for testing
> purposes?
> I'm happy to drop the NO_IMPLICIT flag if there is no need for it.

Right. My understanding is that the flags would mean the same thing, but
I'm no expert on the GPU side of things. Maybe Rob can provide us some
insight on why he added NO_IMPLICIT.

Gustavo

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

Re: [Freedreno] [PATCH 5/6] drm/msm: gpu: Use OPP tables if we can

[Rob Clark]

On Tue, Mar 7, 2017 at 12:02 PM, Jordan Crouse  wrote:
> If a OPP table is defined for the GPU device in the device tree use
> that in lieu of the downstream style GPU frequency table. If we do
> use the downstream table convert it to a OPP table so that we can
> take advantage of the OPP lookup facilities later.

so this one should probably be accompanied by an update to
Documentation/devicetree/bindings/display/msm/gpu.txt (and cc'd to
devicetree list, although I think it should not be controversial to
use the proper bindings for this ;-))

otherwise, looks good.. 1/6 looks like fixes material so I'll pull
that one in immediately..

BR,
-R

> Signed-off-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c | 85 
> +++---
>  1 file changed, 66 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 8374e9a..24da7f6 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -17,6 +17,7 @@
>   * this program.  If not, see .
>   */
>
> +#include 
>  #include "adreno_gpu.h"
>
>  #define ANY_ID 0xff
> @@ -220,10 +221,71 @@ static int find_chipid(struct device *dev, u32 *chipid)
> return 0;
>  }
>
> +/* Get legacy powerlevels from qcom,gpu-pwrlevels and populate the opp table 
> */
> +static int adreno_get_legacy_pwrlevels(struct device *dev)
> +{
> +   struct device_node *child, *node;
> +   int ret;
> +
> +   node = of_find_compatible_node(dev->of_node, NULL,
> +   "qcom,gpu-pwrlevels");
> +   if (!node) {
> +   dev_err(dev, "Could not find the GPU powerlevels\n");
> +   return -ENXIO;
> +   }
> +
> +   for_each_child_of_node(node, child) {
> +   unsigned int val;
> +
> +   ret = of_property_read_u32(child, "qcom,gpu-freq", &val);
> +   if (ret)
> +   continue;
> +
> +   /*
> +* Skip the intentionally bogus clock value found at the 
> bottom
> +* of most legacy frequency tables
> +*/
> +   if (val != 2700)
> +   dev_pm_opp_add(dev, val, 0);
> +   }
> +
> +   return 0;
> +}
> +
> +static int adreno_get_pwrlevels(struct device *dev,
> +   struct adreno_platform_config *config)
> +{
> +   unsigned long freq = ULONG_MAX;
> +   struct dev_pm_opp *opp;
> +   int ret;
> +
> +   /* You down with OPP? */
> +   if (!of_find_property(dev->of_node, "operating-points-v2", NULL))
> +   ret = adreno_get_legacy_pwrlevels(dev);
> +   else
> +   ret = dev_pm_opp_of_add_table(dev);
> +
> +   if (ret)
> +   return ret;
> +
> +   /* Find the fastest defined rate */
> +   opp = dev_pm_opp_find_freq_floor(dev, &freq);
> +   if (!IS_ERR(opp))
> +   config->fast_rate = dev_pm_opp_get_freq(opp);
> +
> +   if (!config->fast_rate) {
> +   DRM_DEV_INFO(dev,
> +   "Could not find clock rate. Using default\n");
> +   /* Pick a suitably safe clock speed for any target */
> +   config->fast_rate = 2;
> +   }
> +
> +   return 0;
> +}
> +
>  static int adreno_bind(struct device *dev, struct device *master, void *data)
>  {
> static struct adreno_platform_config config = {};
> -   struct device_node *child, *node = dev->of_node;
> u32 val;
> int ret;
>
> @@ -238,25 +300,10 @@ static int adreno_bind(struct device *dev, struct 
> device *master, void *data)
>
> /* find clock rates: */
> config.fast_rate = 0;
> -   for_each_child_of_node(node, child) {
> -   if (of_device_is_compatible(child, "qcom,gpu-pwrlevels")) {
> -   struct device_node *pwrlvl;
> -   for_each_child_of_node(child, pwrlvl) {
> -   ret = of_property_read_u32(pwrlvl, 
> "qcom,gpu-freq", &val);
> -   if (ret) {
> -   dev_err(dev, "could not find 
> gpu-freq: %d\n", ret);
> -   return ret;
> -   }
> -   config.fast_rate = max(config.fast_rate, val);
> -   }
> -   }
> -   }
>
> -   if (!config.fast_rate) {
> -   dev_warn(dev, "could not find clk rates\n");
> -   /* This is a safe low speed for all devices: */
> -   config.fast_rate = 2;
> -   }
> +   ret = adreno_get_pwrlevels(dev, &config);
> +   if (ret)
> +   return ret;
>
> dev->platform_data = &config;
> set_gpu_pdev(dev_get_drvdata(master), to_platform_device(dev));
> --
> 1.9.1
>
> __

Re: [PATCH 2/3] drm/etnaviv: move fence allocation out of etnaviv_gpu_submit()

[Gustavo Padovan]

2017-03-13 Philipp Zabel :

> On Wed, 2017-03-08 at 11:42 -0300, Gustavo Padovan wrote:
> > Hi Philipp,
> > 
> > 2017-03-08 Philipp Zabel :
> > 
> > > The next patch will need the dma_fence to create the sync_file in
> > > etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested.
> > > 
> > > Signed-off-by: Philipp Zabel 
> > > ---
> > >  drivers/gpu/drm/etnaviv/etnaviv_gem.h|  3 ++-
> > >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  8 +++-
> > >  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 21 ++---
> > >  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  1 +
> > >  4 files changed, 16 insertions(+), 17 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
> > > b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > > index 120410d67eb5b..c4a091e874269 100644
> > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > > @@ -20,6 +20,7 @@
> > >  #include 
> > >  #include "etnaviv_drv.h"
> > >  
> > > +struct dma_fence;
> > 
> > Why not #include  ?
> 
> I don't see the need to include the header as long as the memory layout
> of struct dma_fence doesn't have to be known. Here we just need to pass
> pointers to the structure type as function arguments.
> 
> > Other than that looks good to me:
> > 
> > Reviewed-by: Gustavo Padovan 
> 
> May I keep the review tag without adding the #include?

Sure. Please keep it.

Gustavo

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

Re: [Intel-gfx] [PATCH 10/24] drm: Remove drm_pending_event->pid

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:43PM +0100, Daniel Vetter wrote:
> We might as well dump the drm_file pointer, that's about as useful
> a cookie as the pid. Noticed while typing docs for drm_file and friends.
> 
> Since the only consumer of this is the tracepoints I think we can safely
> change this - those tracepoints should not be uapi relevant at all. It
> all goes back to
> 
> commit b9c2c9ae882f058084e13e339925dbf8d2d20271
> Author: Jesse Barnes 
> Date:   Thu Jul 1 16:48:09 2010 -0700
> 
> drm: add per-event vblank event trace points
> 
> which doesn't give a special justification for using pid over a pointer.

Well, it's friendlier to look at, I suppose.

> 
> Also note that the nouveau code setting it is entirely pointless:
> Since this isn't a vblank event, it will never hit the vblank
> tracepoints.
> 
> Cc: Ben Skeggs 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_irq.c  |  5 ++---
>  drivers/gpu/drm/drm_trace.h| 20 ++--
>  drivers/gpu/drm/nouveau/nouveau_usif.c |  1 -
>  include/drm/drm_file.h |  2 --
>  4 files changed, 12 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 1906723af389..9bdca69f754c 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -978,7 +978,7 @@ static void send_vblank_event(struct drm_device *dev,
>   e->event.tv_sec = now->tv_sec;
>   e->event.tv_usec = now->tv_usec;
>  
> - trace_drm_vblank_event_delivered(e->base.pid, e->pipe,
> + trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe,
>e->event.sequence);
>  
>   drm_send_event_locked(dev, &e->base);
> @@ -1505,7 +1505,6 @@ static int drm_queue_vblank_event(struct drm_device 
> *dev, unsigned int pipe,
>   }
>  
>   e->pipe = pipe;
> - e->base.pid = current->pid;

Do you think it would be worthwhile to output the pid:file_priv mapping here in
case someone is using pid?

Regardless, the code looks correct, and I don't any skin in this game, so I'll
add my R-b and let you decide what to do if no one else complains.

Reviewed-by: Sean Paul 

>   e->event.base.type = DRM_EVENT_VBLANK;
>   e->event.base.length = sizeof(e->event);
>   e->event.user_data = vblwait->request.signal;
> @@ -1534,7 +1533,7 @@ static int drm_queue_vblank_event(struct drm_device 
> *dev, unsigned int pipe,
>   DRM_DEBUG("event on vblank count %u, current %u, crtc %u\n",
> vblwait->request.sequence, seq, pipe);
>  
> - trace_drm_vblank_event_queued(current->pid, pipe,
> + trace_drm_vblank_event_queued(file_priv, pipe,
> vblwait->request.sequence);
>  
>   e->event.sequence = vblwait->request.sequence;
> diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
> index ce3c42813fbb..14c5a777682e 100644
> --- a/drivers/gpu/drm/drm_trace.h
> +++ b/drivers/gpu/drm/drm_trace.h
> @@ -24,36 +24,36 @@ TRACE_EVENT(drm_vblank_event,
>  );
>  
>  TRACE_EVENT(drm_vblank_event_queued,
> - TP_PROTO(pid_t pid, int crtc, unsigned int seq),
> - TP_ARGS(pid, crtc, seq),
> + TP_PROTO(struct drm_file *file, int crtc, unsigned int seq),
> + TP_ARGS(file, crtc, seq),
>   TP_STRUCT__entry(
> - __field(pid_t, pid)
> + __field(struct drm_file *, file)
>   __field(int, crtc)
>   __field(unsigned int, seq)
>   ),
>   TP_fast_assign(
> - __entry->pid = pid;
> + __entry->file = file;
>   __entry->crtc = crtc;
>   __entry->seq = seq;
>   ),
> - TP_printk("pid=%d, crtc=%d, seq=%u", __entry->pid, __entry->crtc, \
> + TP_printk("file=%p, crtc=%d, seq=%u", __entry->file, __entry->crtc, 
> \
> __entry->seq)
>  );
>  
>  TRACE_EVENT(drm_vblank_event_delivered,
> - TP_PROTO(pid_t pid, int crtc, unsigned int seq),
> - TP_ARGS(pid, crtc, seq),
> + TP_PROTO(struct drm_file *file, int crtc, unsigned int seq),
> + TP_ARGS(file, crtc, seq),
>   TP_STRUCT__entry(
> - __field(pid_t, pid)
> + __field(struct drm_file *, file)
>   __field(int, crtc)
>   __field(unsigned int, seq)
>   ),
>   TP_fast_assign(
> - __entry->pid = pid;
> + __entry->file = file;
>   __entry->crtc = crtc;
>   __entry->seq = seq;
>   ),
> - TP_printk("pid=%d, crtc=%d, seq=%u", __entry->pid, __entry->crtc, \
> + TP_printk("file=%p, crtc=%d, seq=%u", __entry->file, __entry->crtc, 
> \
> __entry->seq)
>  );
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_usif.c 
> b/drivers/gpu/drm/nouveau/nouveau_usif.c
> index afbdb

Re: [PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

[Liviu Dudau]

On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote:
> Less code ftw.
> 
> This converts all drivers except the tinydrm helper module. That one
> needs more work, since it gets the THIS_MODULE reference from
> tinydrm.ko instead of the actual driver module like it should.
> Probably needs a similar trick like I used here with generating the
> entire struct with a macro.
> 
> Cc: Noralf Trønnes 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 12 +---
>  drivers/gpu/drm/arm/malidp_drv.c| 12 +---

For the hdlcd_drv.c and malidp_drv.c changes:

Acked-by: Liviu Dudau 

For the rest of the series:

Reviewed-by: Liviu Dudau 

Best regards,
Liviu

>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 12 +---
>  drivers/gpu/drm/drm_file.c  |  3 +++
>  drivers/gpu/drm/drm_gem_cma_helper.c|  3 +++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   | 12 +---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 12 +---
>  drivers/gpu/drm/imx/imx-drm-core.c  | 11 +--
>  drivers/gpu/drm/meson/meson_drv.c   | 14 +
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c   | 14 +
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 12 +---
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c| 12 +---
>  drivers/gpu/drm/sti/sti_drv.c   | 11 +--
>  drivers/gpu/drm/sun4i/sun4i_drv.c   | 12 +---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 12 +---
>  drivers/gpu/drm/zte/zx_drm_drv.c| 14 +
>  include/drm/drm_gem_cma_helper.h| 26 
> +
>  17 files changed, 46 insertions(+), 158 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 4840dc277339..0e74880b5e94 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -239,17 +239,7 @@ static int hdlcd_debugfs_init(struct drm_minor *minor)
>  }
>  #endif
>  
> -static const struct file_operations fops = {
> - .owner  = THIS_MODULE,
> - .open   = drm_open,
> - .release= drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl   = drm_compat_ioctl,
> - .poll   = drm_poll,
> - .read   = drm_read,
> - .llseek = noop_llseek,
> - .mmap   = drm_gem_cma_mmap,
> -};
> +DEFINE_DRM_GEM_CMA_FOPS(fops);
>  
>  static struct drm_driver hdlcd_driver = {
>   .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index a9608a2e5a29..ea2546f766c2 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -178,17 +178,7 @@ static void malidp_lastclose(struct drm_device *drm)
>   drm_fbdev_cma_restore_mode(malidp->fbdev);
>  }
>  
> -static const struct file_operations fops = {
> - .owner = THIS_MODULE,
> - .open = drm_open,
> - .release = drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl = drm_compat_ioctl,
> - .poll = drm_poll,
> - .read = drm_read,
> - .llseek = noop_llseek,
> - .mmap = drm_gem_cma_mmap,
> -};
> +DEFINE_DRM_GEM_CMA_FOPS(fops);
>  
>  static struct drm_driver malidp_driver = {
>   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 970bd87d7cce..178acbf5f6c5 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -724,17 +724,7 @@ static void atmel_hlcdc_dc_irq_uninstall(struct 
> drm_device *dev)
>   regmap_read(dc->hlcdc->regmap, ATMEL_HLCDC_ISR, &isr);
>  }
>  
> -static const struct file_operations fops = {
> - .owner  = THIS_MODULE,
> - .open   = drm_open,
> - .release= drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl   = drm_compat_ioctl,
> - .poll   = drm_poll,
> - .read   = drm_read,
> - .llseek = no_llseek,
> - .mmap   = drm_gem_cma_mmap,
> -};
> +DEFINE_DRM_GEM_CMA_FOPS(fops);
>  
>  static struct drm_driver atmel_hlcdc_dc_driver = {
>   .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM |
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index f8483fc6d3d7..260a83563976 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -89,6 +89,9 @@ DEFINE_MUTEX(drm_global_mutex);
>   * .mmap = drm_gem_mmap,
>   * };
>   *
> + * For CMA based drivers there is the DEFINE_DRM_GEM_CMA_FOPS() macro to make
> + * this simpler.
> + *
>   * FIXME: We should have a macro for this (and the CMA version) so that 
>

Re: [RESEND PATCH] drm/msm: adreno: fix build error without debugfs

[Rob Clark]

On Mon, Mar 13, 2017 at 12:43 PM, Arnd Bergmann  wrote:
> The newly added a5xx support fails to build when debugfs is diabled:
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' 
> has no member named 'show'
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared 
> here (not in a function); did you mean 'a5xx_irq'?
>
> This adds a missing #ifdef.
>
> Fixes: b5f103ab98c7 ("drm/msm: gpu: Add A5XX target support")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Arnd Bergmann 

I thought I had picked this one up already, but I guess my brain was
playing tricks on me.. I've pushed this to msm-next for now and will
cherry-pick this over to a -fixes branch when I send fixes for 4.11..

BR,
-R


> ---
> Originally sent on Nov 30 for v4.10, but I now see this is still required
> on v4.11-rc2
> ---
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 4414cf73735d..f0c8bd74ca91 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -860,7 +860,9 @@ static const struct adreno_gpu_funcs funcs = {
> .idle = a5xx_idle,
> .irq = a5xx_irq,
> .destroy = a5xx_destroy,
> +#ifdef CONFIG_DEBUG_FS
> .show = a5xx_show,
> +#endif
> },
> .get_timestamp = a5xx_get_timestamp,
>  };
> --
> 2.9.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/24] drm: Remove DRM_MINOR_CNT

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:41PM +0100, Daniel Vetter wrote:
> This was originally added by David Herrmann for range checks, but
> entirely unused. It confused me, so let's remove it.
> 
> Cc: David Herrmann 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 
> ---
>  include/drm/drmP.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 826101785876..7bd6752683a4 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -444,7 +444,6 @@ enum drm_minor_type {
>   DRM_MINOR_PRIMARY,
>   DRM_MINOR_CONTROL,
>   DRM_MINOR_RENDER,
> - DRM_MINOR_CNT,
>  };
>  
>  /**
> -- 
> 2.11.0
> 
> ___
> 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 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Andy Shevchenko]

On Mon, Mar 13, 2017 at 2:41 PM, Christian König
 wrote:
> From: Christian König 
>
> Try to resize BAR0 to let CPU access all of VRAM.

> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> +{
> +   u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> +   int r;
> +
> +   r = pci_resize_resource(adev->pdev, 0, size);

> +

Redundant.

> +   if (r == -ENOTSUPP) {
> +   /* The hardware don't support the extension. */
> +   return;

> +

Ditto.

> +   } else if (r == -ENOSPC) {

Useless use of else. And thus of curly braces.

> +   DRM_INFO("Not enoigh PCI address space for a large BAR.");
> +   } else if (r) {
> +   DRM_ERROR("Problem resizing BAR0 (%d).", r);
> +   }
> +
> +   /* Reinit the doorbell mapping, it is most likely moved as well */
> +   amdgpu_doorbell_fini(adev);

> +   BUG_ON(amdgpu_doorbell_init(adev));

Comment why it's used here.
-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

[Russell King - ARM Linux]

On Mon, Mar 13, 2017 at 12:55:58PM +, Jose Abreu wrote:
> Hi,
> 
> 
> On 13-03-2017 09:36, Russell King - ARM Linux wrote:
> > On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote:
> >> On 03/10/2017 10:35 AM, Romain Perier wrote:
> >>> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
> >>> step E. and is kept enabled for later use. This clock should be enabled
> >>> and disabled along with the actual audio stream and not always on (that
> >>> is bad for PM). Futhermore, this might cause sound glitches with some
> >>> HDMI devices, as the CTS+N is forced to zero when the stream is disabled
> >>> while the audio clock is still running.
> >>>
> >>> This commit adds a parameter to hdmi_audio_enable_clk() that controls
> >>> when the audio sample clock must be enabled or disabled. Then, it moves
> >>> the call to this function into dw_hdmi_audio_enable() and
> >>> dw_hdmi_audio_disable().
> >>>
> >>> Signed-off-by: Romain Perier 
> >>> ---
> >>>  drivers/gpu/drm/bridge/dw-hdmi.c | 15 +--
> >>>  1 file changed, 9 insertions(+), 6 deletions(-)
> >>>
> >> Hi Romain, Russell, Jose,
> >>
> >> This is a little out of scope, but I was wondering why the CTS calculation
> >> was not left in AUTO mode in the dw-hdmi driver ?
> > There is no indication in the iMX6 manuals that the iMX6 supports
> > automatic CTS calculation.  Bits 7:4 of the AUD_CTS3 register are
> > marked as "reserved".
> >
> > We're reliant on the information in the iMX6 manuals as we don't have
> > access to Synopsis' databooks for these parts (I understand you have
> > to be a customer to have access to that.)
> >
> 
> (Synopsis -> Synopsys :))
> 
> Trying to catch up with the conversation:
> 
> 1) In AHB audio mode the bits are always reserved.
> 2) I think we should enable/disable clock instead of just forcing
> N/CTS, though, I don't know what could be the implications for
> iMX platform. I remember at the time I tested this using I2S
> (I've never used AHB), and HDMI protocol analyzers were
> complaining about the N/CTS being forced to zero.

What you're recommending is to basically ignore the published workaround,
which, presumably, was arrived at by proper analysis of the issue both
by Freescale engineers and Synopsys engineers, and instead try some other
solution.

I'm not sure that's a good idea.  Only those with knowledge of the IP can
say what effect disabling the audio clock will have: will it still allow
the FIFO to be loaded, as required by the errata?  If not, it's not a
solution that AHB can use.  I would imagine that _if_ it was as simple as
disabling the audio clock, that simple approach would have been documented
in Freescale's errata documents, rather than the rather more complex
method of zeroing the CTS/N values.

I think there are two choices here:

1) get some definitive information about the IP and the errata for AHB,
   and determine whether the solution you propose would work.  (That's
   out of scope for me, I've no contacts with FSL/NXP and I'm not a
   Synopsys customer.)

2) the I2S audio support stops re-using the AHB audio support functions,
   switching to their own implementation that behaves correctly for them.
   (Remember, it was I2S's choice to re-use the AHB audio support functions
   I added which we're now discussing - they didn't have to do that, and
   regressing AHB audio just for I2S is not something we should ever
   consider doing.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/panel: simple: Add support for Winstar WF35LTIACD

[Richard Genoud]

On 12/03/2017 15:17, Rob Herring wrote:
> On Fri, Mar 03, 2017 at 04:21:56PM +0100, Richard Genoud wrote:
>> This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
>> LCD panel, which can be supported by the simple panel driver.
>>
>> Signed-off-by: Richard Genoud 
>> ---
>>  .../bindings/display/panel/winstar,wf35ltiacd  |  7 ++
>>  drivers/gpu/drm/panel/panel-simple.c   | 28 
>> ++
>>  2 files changed, 35 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd 
>> b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
>> new file mode 100644
>> index ..68408adf239f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
>> @@ -0,0 +1,7 @@
>> +Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "winstar,wf35ltiacd"
>> +
>> +This binding is compatible with the simple-panel binding, which is specified
>> +in simple-panel.txt in this directory.
> 
> Please specify the power supply(ies). I know a lot of bindings haven't, 
> but many panels have more than 1 supply and just relying on simple panel 
> doesn't distinguish whether the panel has 1 supply or you didn't check 
> and it has more than 1.
> 
> Rob
> 

Ok, I'll specify the power supply. And I'll add an example, it's always
nice to have one.

Thanks.

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

Re: [PATCH 0/3] Tegra Host1x dma_fence/sync_file support

[Mikko Perttunen]

On 10.03.2017 14:43, Daniel Vetter wrote:

On Thu, Mar 09, 2017 at 09:09:52PM +0200, Mikko Perttunen wrote:

On 03/09/2017 08:58 PM, Daniel Vetter wrote:

On Thu, Mar 9, 2017 at 6:57 PM, Mikko Perttunen  wrote:

Hi everyone,

this series adds support for using sync fences as prefences and
postfences for host1x job submissions. The patches are available
as a git repository at

  https://github.com/cyndis/linux/tree/host1x-fence-1

and testing code is available at

  https://github.com/cyndis/host1x_test

though you may want to edit the main function to disable the
timeout tests for now as they cause a deadlock (not caused
by this series; fix upcoming).

Verified on a Jetson TX1; should go on top of the earlier
VIC series.

Some additional points:
* I noticed that the waitchk_mask field in the submit UAPI is completely
  useless, and has never had any effect in the upstream kernel.
  It has also not existed in the downstream kernel for many years.
  We could replace it with the flags field if that is deemed
  acceptable, though of course it is possible there exists some
  application that fills it with some non-zero value.


If open source userspace (nouveau_dri.so) never used it, then you can
freely change it. Backwards compat guarantee in drm is only for open
source userspace (and by implication ofc anything that uses the ioctl
the same way). See:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements


nouveau doesn't have any host1x related code - so no, there is no
pre-existing open-source userspace that uses this :)



On that topic, do we have the nouveau patches to enable the
egl_android extension for this already published?


I assume you are referring to EGL_ANDROID_native_fence_sync; I don't know
what nouveau's status is regarding that. With this series, the host1x driver
does not yet allow other drivers access to the raw syncpoint values behind
host1x fences but that can be fixed pretty easily if/when nouveau wants to
support native syncpoint waits on Tegra.
Host1x jobs do use native waits already with this series, though.


Well you're adding new uapi to the tegra drm driver, and
EGL_ANDROID_native_fence_sync for nouveau seems like the real use-case for
this. Which means we need that, before we can merge these patches.

At least I assume that this was done for the nv blob tegra gl driver? Of
course if there's some other reasonable use-case, we can use that as open
source demonstration thing too.
-Daniel



The downstream driver doesn't actually support this UAPI; the work was 
done against the testcases linked to above. My goal was to have 
userspace clients use fence fds instead of raw syncpoints, which would 
be cleaner and less error-prone; and allow future extensibility. I 
suppose this might not be enough of a use-case though.


Now, quickly grepping through mesa and the nouveau kernel driver, it 
looks like there is currently no implementation of 
EGL_ANDROID_native_fence_sync, and no support for SYNC_FILE in nouveau. 
Regrettably, I currently don't have the time to learn these codebases 
and implement these features, so we might have to drop at least patches 
2 and 3 and revisit them later.


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

[PATCH 0/1] drm/radeon: Fix GPU lockups for the R7 M270

[Umang Raghuvanshi]

The AMD Radeon R7 M270 card's OpenGL functionality completely broke down in
Linux kernel v4.10. Before v4.10, the card was incorrectly identified as a
Radeon R7 M265 but worked perfectly (possibly due to the similarities between
the two). It should also be noted that this issue is also present in Windows
but is fixed by a vendor-specific driver by AMD which hasn't made its way to
Linux yet.

After bisecting between the v4.9 and v4.10 tags, I discovered that the commit
3a69adfe5617 ("drm/radeon: drop oland quirks") was the culprit. Due to what I
assume as lack of firmware support for the chip, the quirks which were
addressed in the firmware never made it to the card resulting in this.

Specifically, when an OpenGL app was run with DRI_PRIME=1, the GPU would stall
and the kernel logs would fill up with messages like the following:

"GPU lockup (current fence id 0x10e5 last fence id 0x10ed on ring 0)"
"ring 3 stalled for more than 40952msec"

This issue would crop up everytime DRI_PRIME=1 was used and is present across
various applications - everything from natively supported games to glxgears.
When the aforementioned stall would happen, the screen would freeze and the
only solution would be to restart the X server altogether.

The attached commit reverts this change only for the M270 (the values for
identifying it were obtained experimentally and checked across different PCs).
It fixes the issue completely but I strongly believe that a firmware patch
would be a *much* better solution.

Should the need arise, I am willing to provide any additional information that
would help fix this issue.

Umang Raghuvanshi (1):
  drm/radeon: Fix GPU lockups for the R7 M270

 drivers/gpu/drm/radeon/si_dpm.c | 5 +
 1 file changed, 5 insertions(+)

-- 
2.12.0

-- 
Cheers,
Umang Raghuvanshi.

P.S: This message was re-sent to all its original recipients because SendGrid
decided to append HTML to it which blocked it from a couple of mailing lists.
Sorry for the inconvenience.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

[Russell King - ARM Linux]

On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote:
> On 03/10/2017 10:35 AM, Romain Perier wrote:
> > Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
> > step E. and is kept enabled for later use. This clock should be enabled
> > and disabled along with the actual audio stream and not always on (that
> > is bad for PM). Futhermore, this might cause sound glitches with some
> > HDMI devices, as the CTS+N is forced to zero when the stream is disabled
> > while the audio clock is still running.
> > 
> > This commit adds a parameter to hdmi_audio_enable_clk() that controls
> > when the audio sample clock must be enabled or disabled. Then, it moves
> > the call to this function into dw_hdmi_audio_enable() and
> > dw_hdmi_audio_disable().
> > 
> > Signed-off-by: Romain Perier 
> > ---
> >  drivers/gpu/drm/bridge/dw-hdmi.c | 15 +--
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> > 
> 
> Hi Romain, Russell, Jose,
> 
> This is a little out of scope, but I was wondering why the CTS calculation
> was not left in AUTO mode in the dw-hdmi driver ?

There is no indication in the iMX6 manuals that the iMX6 supports
automatic CTS calculation.  Bits 7:4 of the AUD_CTS3 register are
marked as "reserved".

We're reliant on the information in the iMX6 manuals as we don't have
access to Synopsis' databooks for these parts (I understand you have
to be a customer to have access to that.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm/radeon: Fix GPU lockups for the R7 M270

[Umang Raghuvanshi]

Commit 3a69adfe5617 ("drm/radeon: drop oland quirks") removed
quirks for Oland but also caused a regression where M270 GPUs
would go into a lock-up when OpenGL intensive applications were used.
This reverts the change only for the M270 and fixes the lock-ups.

Signed-off-by: Umang Raghuvanshi 
---
 drivers/gpu/drm/radeon/si_dpm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 2944916f7102..e6f1da41f886 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3008,6 +3008,11 @@ static void si_apply_state_adjust_rules(struct 
radeon_device *rdev,
(rdev->pdev->device == 0x6817) ||
(rdev->pdev->device == 0x6806))
max_mclk = 12;
+   } else if (rdev->family == CHIP_OLAND && rdev->pdev->device == 0x6604 &&
+  rdev->pdev->revision == 0) {
+   // Fix max_sclk and max_mclk for the Radeon R7 M270
+   max_sclk = 75000;
+   max_mclk = 8;
} else if (rdev->family == CHIP_HAINAN) {
if ((rdev->pdev->revision == 0x81) ||
(rdev->pdev->revision == 0x83) ||
-- 
2.12.0

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

Re: [PATCH 3/3] drm/tegra: Support for sync file-based fences in submit

[Mikko Perttunen]

On 13.03.2017 09:15, Thierry Reding wrote:

On Thu, Mar 09, 2017 at 07:57:18PM +0200, Mikko Perttunen wrote:

Add support for sync file-based prefences and postfences
to job submission. Fences are passed to the Host1x implementation.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.c | 69 ++---
 1 file changed, 59 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 64dff8530403..bf4a2a13c17d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -344,6 +345,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 struct drm_tegra_submit *args, struct drm_device *drm,
 struct drm_file *file)
 {
+   struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
unsigned int num_cmdbufs = args->num_cmdbufs;
unsigned int num_relocs = args->num_relocs;
unsigned int num_waitchks = args->num_waitchks;
@@ -361,6 +363,11 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (args->num_syncpts != 1)
return -EINVAL;

+   /* Check for unrecognized flags */
+   if (args->flags & ~(DRM_TEGRA_SUBMIT_WAIT_FENCE_FD |
+   DRM_TEGRA_SUBMIT_CREATE_FENCE_FD))
+   return -EINVAL;
+
job = host1x_job_alloc(context->channel, args->num_cmdbufs,
   args->num_relocs, args->num_waitchks);
if (!job)
@@ -372,19 +379,27 @@ int tegra_drm_submit(struct tegra_drm_context *context,
job->class = context->client->base.class;
job->serialize = true;

+   if (args->flags & DRM_TEGRA_SUBMIT_WAIT_FENCE_FD) {
+   job->prefence = sync_file_get_fence(args->fence);
+   if (!job->prefence) {
+   err = -ENOENT;
+   goto put_job;
+   }
+   }
+
while (num_cmdbufs) {
struct drm_tegra_cmdbuf cmdbuf;
struct host1x_bo *bo;

if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
-   goto fail;
+   goto put_fence;
}

bo = host1x_bo_lookup(file, cmdbuf.handle);
if (!bo) {
err = -ENOENT;
-   goto fail;
+   goto put_fence;
}

host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
@@ -398,19 +413,19 @@ int tegra_drm_submit(struct tegra_drm_context *context,
  &relocs[num_relocs], drm,
  file);
if (err < 0)
-   goto fail;
+   goto put_fence;
}

if (copy_from_user(job->waitchk, waitchks,
   sizeof(*waitchks) * num_waitchks)) {
err = -EFAULT;
-   goto fail;
+   goto put_fence;
}

if (copy_from_user(&syncpt, (void __user *)(uintptr_t)args->syncpts,
   sizeof(syncpt))) {
err = -EFAULT;
-   goto fail;
+   goto put_fence;
}

job->is_addr_reg = context->client->ops->is_addr_reg;
@@ -423,20 +438,54 @@ int tegra_drm_submit(struct tegra_drm_context *context,

err = host1x_job_pin(job, context->client->base.dev);
if (err)
-   goto fail;
+   goto put_fence;

err = host1x_job_submit(job);
if (err)
-   goto fail_submit;
+   goto unpin_job;


Shouldn't all error-unwinding gotos after this jump to the unpin_job
label as well? Seems like they all jump to put_fence instead, which I
think would leave the job pinned on failure.


After host1x_job_submit is succesfully called, host1x's job tracking 
owns the job and will call unpin on it once it finishes or times out, so 
we cannot unpin it from here.






-   args->fence = job->syncpt_end;
+   if (args->flags & DRM_TEGRA_SUBMIT_CREATE_FENCE_FD) {
+   struct dma_fence *fence;
+   struct sync_file *file;
+
+   fence = host1x_fence_create(
+   host1x, host1x_syncpt_get(host1x, job->syncpt_id),
+   job->syncpt_end);
+   if (!fence) {
+   err = -ENOMEM;
+   goto put_fence;
+   }
+
+   file = sync_file_create(fence);
+   if (!file) {
+   dma_fence_put(fence);
+   err = -ENOMEM;
+   goto put_fence;
+   }
+
+   err = get_unused_fd_flags(O_CLOEXEC);
+   if (err < 0) {
+   dma_fen

Re: [PATCH V3 4/4] dts/imx6q-b850v3: Use megachips-stdpxxxx-ge-b850v3-fw bridges (LVDS-DP++)

[Shawn Guo]

On Fri, Mar 03, 2017 at 04:57:10PM +0100, Peter Senna Tschudin wrote:
> Configures the megachips-stdp-ge-b850v3-fw bridges on the GE
> B850v3 dts file.
> 
> Cc: Laurent Pinchart 
> Cc: Martyn Welch 
> Cc: Martin Donnelly 
> Cc: Javier Martinez Canillas 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> Signed-off-by: Peter Senna Tschudin 
> ---
> Unchanged since V1.
> 
>  arch/arm/boot/dts/imx6q-b850v3.dts | 68 
> ++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts 
> b/arch/arm/boot/dts/imx6q-b850v3.dts
> index b237429..3ec54da 100644
> --- a/arch/arm/boot/dts/imx6q-b850v3.dts
> +++ b/arch/arm/boot/dts/imx6q-b850v3.dts
> @@ -72,6 +72,13 @@
>   fsl,data-mapping = "spwg";
>   fsl,data-width = <24>;
>   status = "okay";
> +
> + port@4 {
> + reg = <4>;

Have a newline between property list and child node.

> + lvds0_out: endpoint {
> + remote-endpoint = <&stdp4028_in>;
> + };
> + };
>   };
>  };
>  
> @@ -146,3 +153,64 @@
>  &usdhc2 {
>   status = "disabled";
>  };
> +
> +&mux2_i2c2 {
> + status = "okay";

This okay status doesn't seem really necessary to me.  If it does,
please put it at the end of property list.

> + clock-frequency = <10>;
> +
> + stdp4028@73 {
> + compatible = "megachips,stdp4028-ge-b850v3-fw";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +

Drop this newline, as in general we do not add newline in middle of
property list.

> + reg = <0x73>;
> +

Ditto

> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + stdp4028_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };

Have a newline between nodes.

> + port@1 {
> + reg = <1>;
> + stdp4028_out: endpoint {
> + remote-endpoint = <&stdp2690_in>;
> + };
> + };
> + };
> + };
> +
> + stdp2690@72 {

Sort device nodes under bus in order of unit address.  That said,
stdp2690@72 should go before stdp4028@73.

Shawn

> + compatible = "megachips,stdp2690-ge-b850v3-fw";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x72>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + stdp2690_in: endpoint {
> + remote-endpoint = <&stdp4028_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + stdp2690_out: endpoint {
> + /* Connector for external display */
> + };
> + };
> + };
> + };
> +};
> -- 
> 2.9.3
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

[Jose Abreu]

Hi,


On 13-03-2017 09:36, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote:
>> On 03/10/2017 10:35 AM, Romain Perier wrote:
>>> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
>>> step E. and is kept enabled for later use. This clock should be enabled
>>> and disabled along with the actual audio stream and not always on (that
>>> is bad for PM). Futhermore, this might cause sound glitches with some
>>> HDMI devices, as the CTS+N is forced to zero when the stream is disabled
>>> while the audio clock is still running.
>>>
>>> This commit adds a parameter to hdmi_audio_enable_clk() that controls
>>> when the audio sample clock must be enabled or disabled. Then, it moves
>>> the call to this function into dw_hdmi_audio_enable() and
>>> dw_hdmi_audio_disable().
>>>
>>> Signed-off-by: Romain Perier 
>>> ---
>>>  drivers/gpu/drm/bridge/dw-hdmi.c | 15 +--
>>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>>
>> Hi Romain, Russell, Jose,
>>
>> This is a little out of scope, but I was wondering why the CTS calculation
>> was not left in AUTO mode in the dw-hdmi driver ?
> There is no indication in the iMX6 manuals that the iMX6 supports
> automatic CTS calculation.  Bits 7:4 of the AUD_CTS3 register are
> marked as "reserved".
>
> We're reliant on the information in the iMX6 manuals as we don't have
> access to Synopsis' databooks for these parts (I understand you have
> to be a customer to have access to that.)
>

(Synopsis -> Synopsys :))

Trying to catch up with the conversation:

1) In AHB audio mode the bits are always reserved.
2) I think we should enable/disable clock instead of just forcing
N/CTS, though, I don't know what could be the implications for
iMX platform. I remember at the time I tested this using I2S
(I've never used AHB), and HDMI protocol analyzers were
complaining about the N/CTS being forced to zero.
3) I also remember that there was something wrong with the N
calculations (I had to remove the if for pixel clock ==
25175000). I never submited a patch to that because I was running
out of time and didn't investigate this further (it could be for
example a problem specific to my setup).

Hope it helps a little bit.

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Jose Abreu]

Hi Neil,


On 09-03-2017 14:27, Jose Abreu wrote:
> Hi Neil,
>
>
> On 08-03-2017 12:12, Neil Armstrong wrote:
>> Hi Jose,
>>
>> It seems here that we only have the RGB444<->YUV444 8bit tables, from the 
>> Amlogic
>> source I have the following for 10bit, 12bit and 16bit for itu601 :
>>
>> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
>>  { 0x2000, 0x6926, 0x74fd, 0x043b },
>>  { 0x2000, 0x2cdd, 0x, 0x7a65 },
>>  { 0x2000, 0x, 0x38b4, 0x78ea }
>> };
>>
>> static const u16 csc_coeff_rgb_out_eitu601_12b_16b[3][4] = {
>>  { 0x2000, 0x6926, 0x74fd, 0x10ee },
>>  { 0x2000, 0x2cdd, 0x, 0x6992 },
>>  { 0x2000, 0x, 0x38b4, 0x63a6 }
>> };
> These two do not match anything I have here.
>
>> static const u16 csc_coeff_rgb_in_eitu601_10b[3][4] = {
>>  { 0x2591, 0x1322, 0x074b, 0x },
>>  { 0x6535, 0x2000, 0x7acc, 0x0800 },
>>  { 0x6acd, 0x7534, 0x2000, 0x0800 }
>> };
> This is more or less correct, I have small offsets. Note that I
> even have offsets with the values that are in dw-hdmi driver,
> which can be caused because I'm seeing the latest document that
> contain these values. I guess they were updated.
>
>> static const u16 csc_coeff_rgb_in_eitu601_12b_16b[3][4] = {
>>  { 0x2591, 0x1322, 0x074b, 0x },
>>  { 0x6535, 0x2000, 0x7acc, 0x2000 },
>>  { 0x6acd, 0x7534, 0x2000, 0x2000 }
>> };
> The same for this.
>
>> But I miss the itu709 values.
>>
>> Could you confirm these values and maybe provide the itu709 values ?
> I will have to check if I can provide you the values. I will get
> back to you.

Sorry but looks like I won't be able to provide you the correct
values :/ If you are working for a Synopsys customer you can
contact our CAE (If so I can guide you to the correct CAE).

Anyway, unless you can test the values you have I suggest you
don't use them, they do not match what I have here and I can't
test them because right now I don't have a setup (I'm assuming
that your CSC block within the controller was not modified).

Best regards,
Jose Miguel Abreu

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

Re: [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors

[Andy Shevchenko]

On Mon, Mar 13, 2017 at 2:41 PM, Christian König
 wrote:

> Most BIOS don't enable this because of compatibility reasons.
>
> Manually enable a 64bit BAR of 64GB size so that we have
> enough room for PCI devices.

> +static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
> +{
> +   const uint64_t size = 64ULL * 1024 * 1024 * 1024;

Perhaps extend  and use SZ_64G here?

It would be nice to do, since some of the drivers already are using
sizes like 4GB and alike.

> +   uint32_t base, limit, high;
> +   struct resource *res;
> +   unsigned i;
> +   int r;
> +

> +   for (i = 0; i < 8; ++i) {

> +

Redundant empty line.

> +   pci_read_config_dword(dev, 0x80 + i * 0x8, &base);
> +   pci_read_config_dword(dev, 0x180 + i * 0x4, &high);
> +
> +   /* Is this slot free? */
> +   if ((base & 0x3) == 0x0)
> +   break;
> +
> +   base >>= 8;
> +   base |= high << 24;
> +
> +   /* Abort if a slot already configures a 64bit BAR. */
> +   if (base > 0x1)
> +   return;

> +

Ditto.

> +   }

> +

Ditto.

> +   if (i == 8)
> +   return;
> +
> +   res = kzalloc(sizeof(*res), GFP_KERNEL);
> +   res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_MEM_64 
> |
> +   IORESOURCE_WINDOW;
> +   res->name = dev->bus->name;
> +   r = allocate_resource(&iomem_resource, res, size, 0x1,
> + 0xfd, size, NULL, NULL);
> +   if (r) {
> +   kfree(res);
> +   return;
> +   }
> +
> +   base = ((res->start >> 8) & 0xff00) | 0x3;
> +   limit = ((res->end + 1) >> 8) & 0xff00;
> +   high = ((res->start >> 40) & 0xff) |
> +   res->end + 1) >> 40) & 0xff) << 16);

Perhaps some of constants can be replaced by defines (I think some of
them are already defined in ioport.h or somewhere else).

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND PATCH] drm/msm: adreno: fix build error without debugfs

[Arnd Bergmann]

The newly added a5xx support fails to build when debugfs is diabled:

drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs' has 
no member named 'show'
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:11: error: 'a5xx_show' undeclared 
here (not in a function); did you mean 'a5xx_irq'?

This adds a missing #ifdef.

Fixes: b5f103ab98c7 ("drm/msm: gpu: Add A5XX target support")
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann 
---
Originally sent on Nov 30 for v4.10, but I now see this is still required
on v4.11-rc2
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 4414cf73735d..f0c8bd74ca91 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -860,7 +860,9 @@ static const struct adreno_gpu_funcs funcs = {
.idle = a5xx_idle,
.irq = a5xx_irq,
.destroy = a5xx_destroy,
+#ifdef CONFIG_DEBUG_FS
.show = a5xx_show,
+#endif
},
.get_timestamp = a5xx_get_timestamp,
 };
-- 
2.9.0

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

Re: [PATCH 2/4] PCI: add functionality for resizing resources v2

[Andy Shevchenko]

On Mon, Mar 13, 2017 at 2:41 PM, Christian König
 wrote:
> From: Christian König 
>
> This allows device drivers to request resizing their BARs.
>
> The function only tries to reprogram the windows of the bridge directly above
> the requesting device and only the BAR of the same type (usually mem, 64bit,
> prefetchable). This is done to make sure not to disturb other drivers by
> changing the BARs of their devices.
>
> If reprogramming the bridge BAR fails the old status is restored and -ENOSPC
> returned to the calling device driver.

Some style comments.

> v2: rebase on changes in rbar support

This kind of comments usually goes after --- delimiter below.

> Signed-off-by: Christian König 
> ---

...here.

> +int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
> +{
> +   const unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> +   IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
> +
> +   struct resource saved;
> +   LIST_HEAD(add_list);
> +   LIST_HEAD(fail_head);

> +   struct pci_dev_resource *fail_res;

Perhaps move before definition of 'saved'?

> +   unsigned i;
> +   int ret = 0;
> +
> +   /* Release all children from the matching bridge resource */
> +   for (i = PCI_BRIDGE_RESOURCES; i < PCI_BRIDGE_RESOURCE_END; ++i) {
> +   struct resource *res = &bridge->resource[i];
> +


> +   if ((res->flags & type_mask) != (type & type_mask))

IIUC it would be
if ((res->flags ^ type) & type_mask)

(I consider 'diff' as XOR operation is more understandable, but it's up to you)

> +   continue;

> +   /* restore size and flags */
> +   list_for_each_entry(fail_res, &fail_head, list) {
> +   struct resource *res = fail_res->res;
> +
> +   res->start = fail_res->start;
> +   res->end = fail_res->end;
> +   res->flags = fail_res->flags;
> +   }
> +
> +   /* Revert to the old configuration */
> +   if (!list_empty(&fail_head)) {
> +   struct resource *res = &bridge->resource[i];
> +

> +   res->start = saved.start;
> +   res->end = saved.end;
> +   res->flags = saved.flags;

Would
 *res = saved;
work?

> +int pci_resize_resource(struct pci_dev *dev, int resno, int size)
> +{
> +   struct resource *res = dev->resource + resno;
> +   u32 sizes = pci_rbar_get_possible_sizes(dev, resno);
> +   int old = pci_rbar_get_current_size(dev, resno);
> +   u64 bytes = 1ULL << (size + 20);
> +   int ret = 0;
> +

I would put
 sizes = pci_rbar_get_possible_sizes(dev, resno);
here

> +   if (!sizes)
> +   return -ENOTSUPP;
> +
> +   if (!(sizes & (1 << size)))

BIT(size) ?

> +   return -EINVAL;
> +

and
 old = pci_rbar_get_current_size(dev, resno);
here

> +   if (old < 0)
> +   return old;

> +error_resize:
> +   pci_rbar_set_size(dev, resno, old);
> +   res->end = res->start + (1ULL << (old + 20)) - 1;

BIT_ULL(old + 20) ?

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 02/24] drm: Extract drm_prime.h

[Sean Paul]

On Wed, Mar 08, 2017 at 03:12:35PM +0100, Daniel Vetter wrote:
> Plus a little bit more documentation.
> 
> v2: Untangle the missing forward decls to make drm_prime|gem.h
> free-standing.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-mm.rst  |  3 ++
>  drivers/gpu/drm/drm_prime.c   |  3 +-
>  include/drm/drmP.h| 32 ++
>  include/drm/drm_gem.h |  4 +++
>  include/drm/drm_prime.h   | 79 
> +++
>  include/drm/drm_vma_manager.h |  1 -
>  6 files changed, 91 insertions(+), 31 deletions(-)
>  create mode 100644 include/drm/drm_prime.h
> 
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index d47cbe3a9ef3..96b9c34c21e4 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -449,6 +449,9 @@ PRIME Helper Functions
>  PRIME Function References
>  -
>  
> +.. kernel-doc:: include/drm/drm_prime.h
> +   :internal:
> +
>  .. kernel-doc:: drivers/gpu/drm/drm_prime.c
> :export:
>  
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 866b294e7c61..9fb65b736a90 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -29,8 +29,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
> +#include 
>  
>  #include "drm_internal.h"
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 6105c050d7bc..5f829d2372da 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -51,13 +51,13 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -75,8 +75,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  
>  struct module;
>  
> @@ -89,6 +89,7 @@ struct drm_dma_handle;
>  struct drm_gem_object;
>  struct drm_master;
>  struct drm_vblank_crtc;
> +struct drm_vma_offset_manager;
>  
>  struct device_node;
>  struct videomode;
> @@ -370,12 +371,6 @@ struct drm_pending_event {
> we deliver the event, for tracing only */
>  };
>  
> -struct drm_prime_file_private {
> - struct mutex lock;
> - struct rb_root dmabufs;
> - struct rb_root handles;
> -};
> -
>  /** File private data */
>  struct drm_file {
>   unsigned authenticated :1;
> @@ -759,27 +754,6 @@ static inline int drm_debugfs_remove_files(const struct 
> drm_info_list *files,
>  }
>  #endif
>  
> -struct dma_buf_export_info;
> -
> -extern struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> - struct drm_gem_object *obj,
> - int flags);
> -extern int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> - struct drm_file *file_priv, uint32_t handle, uint32_t flags,
> - int *prime_fd);
> -extern struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
> - struct dma_buf *dma_buf);
> -extern int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> - struct drm_file *file_priv, int prime_fd, uint32_t *handle);
> -struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
> -   struct dma_buf_export_info *exp_info);
> -extern void drm_gem_dmabuf_release(struct dma_buf *dma_buf);
> -
> -extern int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct 
> page **pages,
> - dma_addr_t *addrs, int max_pages);
> -extern struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned 
> int nr_pages);
> -extern void drm_prime_gem_destroy(struct drm_gem_object *obj, struct 
> sg_table *sg);
> -
>  
>  extern struct drm_dma_handle *drm_pci_alloc(struct drm_device *dev, size_t 
> size,
>   size_t align);
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 3b2a28f7f49f..b9ade75ecd82 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -34,6 +34,10 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include 
> +
> +#include 
> +
>  /**
>   * struct drm_gem_object - GEM buffer object
>   *
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> new file mode 100644
> index ..77ceca711bad
> --- /dev/null
> +++ b/include/drm/drm_prime.h
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright © 2012 Red Hat
> + * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
> + * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
> + * Copyright (c) 2009-2010, Code Aurora Forum.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * 

[Bug 100089] Space Run rendering prolems

[bugzilla-daemon]

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

--- Comment #3 from LunarG  ---
This was observed on AMD R9 Fury and AMD RX480 graphic cards using Mesa 17.0.0
(git-cfdda19).

I do have a trace but it was not captured using this Mesa version and is a bit
old but the problem can be observed using it. The problem was also observed
when running the game in steam with this mesa 17.0.0 version. 

I've uploaded the trace; please let me know if you need one captured with this
mesa version and I can make time to get that for you.

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

[PATCH] drm/exynos/dsi: make te-gpios optional

[Andrzej Hajda]

In case of HW-TRIGGER te-gpios interrupt is not necessary. With this
patch we can get rid of 60 interrupt callbacks per second.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 812e2ec..f95fac5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1349,9 +1349,8 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
*dsi)
 
dsi->te_gpio = of_get_named_gpio(dsi->panel_node, "te-gpios", 0);
if (!gpio_is_valid(dsi->te_gpio)) {
-   dev_err(dsi->dev, "no te-gpios specified\n");
-   ret = dsi->te_gpio;
-   goto out;
+   dev_info(dsi->dev, "no te-gpios specified\n");
+   return 0;
}
 
ret = gpio_request(dsi->te_gpio, "te_gpio");
-- 
2.7.4

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

Re: [PATCH 0/5] drm/tinydrm: Add tinydrm_panel abstraction

[Noralf Trønnes]

Den 12.03.2017 21.40, skrev Daniel Vetter:

On Sun, Mar 12, 2017 at 09:17:00PM +0100, Noralf Trønnes wrote:

Den 12.03.2017 20.16, skrev Daniel Vetter:

On Sun, Mar 12, 2017 at 06:50:17PM +0100, Daniel Vetter wrote:

Hi Noralf,

On Sat, Mar 11, 2017 at 10:35:31PM +0100, Noralf Trønnes wrote:

Add support for displays that have a register interface and can be
operated using a simple vtable.

I have looked through the staging/fbtft drivers and it seems that,
except the MIPI controllers, most if not all controllers are operated
through a register. And since most controllers have more than one bus
interface option, regmap seems like a good choice to describe the
interface (tested[1,2]).
MIPI DCS can't be represented using regmap since some commands doesn't
have a parameter. That would be like a register without a value, which
doesn't make sense.

In my second RFC of tinydrm I used drm_panel to decribe the panels
since it was a good match to the fbtft displays. I was then told that
drm_panel wasn't supposed to used like that, so I dropped it and have
tried to use the drm_simple_display_pipe_funcs vtable directly. This
hasn't been all successful, since I ended up using devm_add_action() to
power down the controller at the right time. Thierry Reding wasn't
happy with this and suggested "to add an explicit callback somewhere".
My solution has been to copy the drm_panel_funcs vtable.
Since I now have a vtable, I also added a callback to flush the
framebuffer. So presumably all the fbtft drivers can now be operated
through the tinydrm_panel_funcs vtable.

Ehrm, what? I admit I didn't follow the discussion in-depth, but if
drm_panel can't be used to describe a panel, it's not fit for the job and
needs to be extended. Adding even more abstraction, matroschka-style,
isn't a solution.

Personally I think tinydrm itself is already a bit much wrapping, but I
see that for really simple drivers it has it's uses. But more layers feels
like going in the wrong direction.

For the callback you're looking for (i.e. the regulator_disable call) I
think the correct place is to enable/disable the regulator in the
enable/disable hooks of the drm_simple_display_pipe functions. Or maybe in
their equivalent in drm_panel (well, probably pre_enable and post_disable,
since I guess you need that regulator to driver anything). Same for _init,
if the display is completely off there's no point in keeping the hw
running. Enabling/disabling the entire hw is pretty much what ->enable and
->disable are for. This also gives you proper runtime pm for almost for
free ...

Also, since the regulator is actually stored in struct mipi_dbi, it's
probably best to handle it in the mipi_dbi helpers too. You do that
already with the backlight anyway.

I noticed that the version of tinydrm that landed doesn't use drm_panel
anymore, I thought that was the case once, and for the version I acked?

Self-correct, there never was a version with drm_panel. tbh I think that's
perfectly fine, tinydrm is aimed at simple panels behind spi/i2c buses
(where also the entire video data is uploaded through spi/i2c, not just
control information). Not changing anything like I recommend seems like
the right action still (well, shuffling the regulator into
simple_pipe->enable/disable like I think it should be).

I have looked at the emails, and I used drm_panel in the first RFC,
but I got the impression that Thierry didn't like it so it was dropped
in RFC v2.

Hm, I thought I checked all the old versions of your example tinydrm
submissions and didn't find any with drm_panel. Do you have a link to
archives? I'd like to read Thierry's aguments, in case I'm oblivious to a
bad corner case :-)


I used drm_panel in the first tinydrm RFC in March 2016:
https://lists.freedesktop.org/archives/dri-devel/2016-March/102903.html

struct tinydrm_device {
struct drm_device *base;
struct drm_panel panel;
...
};

Then you commented:
https://lists.freedesktop.org/archives/dri-devel/2016-March/102921.html

> In the case of tinydrm I think that means we should have a bunch of new
> drm helpers, or extensions for existing ones:

> - A helper to create a simple drm_connector from a drm_panel (the
>   get_modes hooks you have here), maybe also in drm_simple_kms_helper.c.

So I made:
[PATCH 4/4] drm/panel: Add helper for simple panel connector
https://lists.freedesktop.org/archives/dri-devel/2016-May/106890.html

Thierry replied:
https://lists.freedesktop.org/archives/dri-devel/2016-May/107023.html

> Okay, that gives me a better understanding of where things are headed.
> That said, why would these devices even need to deal with drm_panel in
> the first place? Sounds to me like they are devices on some sort of
> control bus that you talk to directly. And they will represent
> essentially the panel with its built-in display controller.
>
> drm_panel on the other hand was designed as an interface between display
> controllers and panels, with the goal to let any display controller talk
> to an

Re: [PATCH v2 1/9] gpu: ipu-v3: add DT binding for the Prefetch Resolve Engine

[Philipp Zabel]

On Wed, 2017-03-08 at 12:13 +0100, Lucas Stach wrote:
> The Prefetch Resolve Engine is a prefetch and tile resolve engine
> which prefetches display data from DRAM to an internal SRAM region.
> It has a single clock for configuration register access and the
> functional units. A single shared interrupt is used for status and
> error signaling.
> 
> The only external dependency is the SRAM region to use for the
> prefetch double buffer.
> 
> Signed-off-by: Lucas Stach 

I have picked up this series. Rob, are you ok with the bindings in this
patch? If so, I'll include it in the next pull request.

regards
Philipp

> ---
> v2:
> - change SRAM phandle to "fsl,iram", as used in other imx DT bindings
> - drop leading 0 in example
> ---
>  .../bindings/display/imx/fsl-imx-drm.txt   | 26 
> ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt 
> b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> index 971c3eedb1c7..70ae5335d1e3 100644
> --- a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt
> @@ -53,6 +53,32 @@ ipu: ipu@1800 {
>   };
>  };
>  
> +Freescale i.MX PRE (Prefetch Resolve Engine)
> +
> +
> +Required properties:
> +- compatible: should be "fsl,imx6qp-pre"
> +- reg: should be register base and length as documented in the
> +  datasheet
> +- clocks : phandle to the PRE axi clock input, as described
> +  in Documentation/devicetree/bindings/clock/clock-bindings.txt and
> +  Documentation/devicetree/bindings/clock/imx6q-clock.txt.
> +- clock-names: should be "axi"
> +- interrupts: should contain the PRE interrupt
> +- fsl,iram: phandle pointing to the mmio-sram device node, that should be
> +  used for the PRE SRAM double buffer.
> +
> +example:
> +
> +pre@21c8000 {
> + compatible = "fsl,imx6qp-pre";
> + reg = <0x021c8000 0x1000>;
> + interrupts = ;
> + clocks = <&clks IMX6QDL_CLK_PRE0>;
> + clock-names = "axi";
> + fsl,iram = <&ocram2>;
> +};
> +
>  Parallel display support
>  
>  


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

[Bug 76490] Hang during boot when DPM is on (R9 270X)

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

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

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

Re: connector/edid probing races

[Sean Paul]

On Sat, Mar 11, 2017 at 11:53:04AM +0100, Daniel Vetter wrote:
> On Fri, Mar 10, 2017 at 01:13:12PM -0500, Sean Paul wrote:
> > On Fri, Mar 10, 2017 at 05:52:34PM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 10, 2017 at 11:01:54AM -0500, Sean Paul wrote:
> > > > On Fri, Mar 10, 2017 at 02:12:14PM +1000, Dave Airlie wrote:
> > > > > Talk to Jonas (jadahl) on irc, he had 3 mutters running and on hotplug
> > > > > all 3 of them were diving into the connector getting code. Now I think
> > > > > we can avoid this in userspace by not probing when not owning the VT,
> > > > > but it's still messy behaviour.
> > > > > 
> > > > > It looks like one thread does a getconnector, this fills out the EDID
> > > > > blob with a specific blob id,
> > > > > then second thread does getconnector, which replaces the EDID blob
> > > > > with another one
> > > > > the first thread calls get property blob, but the blob id it is
> > > > > looking for is destroyed.
> > > > > 
> > > > > Ideas?
> > > > 
> > > > I think you could probably fix this by introducing a new
> > > > drm_property_overwrite_global_blob() function. If the size of the 
> > > > current blob is
> > > > the same as the new blob, you could just overwrite the data and 
> > > > preserve the id
> > > > and references. You could then replace the 
> > > > drm_property_replace_global_blob() call in
> > > > drm_mode_connector_update_edid_property() to call the new function. Of 
> > > > course,
> > > > you would need to fall back on *replace_global_blob() if size differed, 
> > > > but it
> > > > would probably solve the issue above.
> > > 
> > > blobs are imutable (not that userspace can use that much since we can
> > > reuse ids), 
> > 
> > Pedantic distinction: blobs themselves aren't inherantly immutable. 
> > However, the
> > EDID property is defined as immutable. I suppose there could conceivably be 
> > some
> > userspace somewhere that relies on this. Bummer.
> 
> It's more tricky: The property is labelled as IMMUTABLE, but that's a lie,
> it essentially only means that userspace isn't allowed to change it. The
> kernel is.
> 
> But blobs themselves are immutable, this is the same semantics as with
> framebuffer objects, and we carried that over when we started to allow
> userspace to create blobs (for atomic). The only benefit is for drivers,
> as long as you hold a life reference you can just compare pointers and if
> they're equal, you know nothing changed. 

Ah, right. I had conveniently forgotten this detail. 

> Due to id reuse, userspace
> unfortunately can't do this (and yes we've had clever userspace who got
> this wrong).
> 
> > > I think if we do this we should compare the contents of the
> > > blob.
> > > 
> > > > That said, I'm not convinced it should be kernel's responsibility to 
> > > > really
> > > > solve this problem. How much effort should we put into mitigating the 
> > > > effects of
> > > > a racey and wasteful userspace?
> > > 
> > > It's a tradeoff between "why should the kernel care" and "every compositor
> > > will get this wrong". Maybe something like libweston will fix this
> > > eventually 
> > 
> > So the question is whether it's worth it to penalize well-behaved 
> > compositors
> > with superfluous memcmp on EDID fetches to make up for the ill-behaved 
> > ones. I
> > don't think it is, but perhaps there are other benefits to preserving the 
> > single
> > blob for the lifetime of the connection.
> 
> If you can profile that memcmp in a 25ms edid read, I'll buy this argument

Sure. It just sucks to add extra code/complexity to cover such a basic faux pas.


> :-) I think the better argument against is that there's still cases where
> userspace must recover from similar issues (getconnector racing with a hpd
> which can also update the edid), but those are even rarer. It might be
> good to keep the easier-to-hit races open, to force better error handling
> in userspace.

Ok, we're saying the same thing, you just have better reasoning :-)

Sean

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

[Bug 99841] Switching to VT freezes X only on a dual screen

[bugzilla-daemon]

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

--- Comment #12 from p...@cooco.de ---
# bad: [7ce7d89f48834cefece7804d38fc5d85382edf77] Linux 4.10-rc1
# good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
git bisect start 'v4.10-rc1' 'v4.9'
# bad: [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag 'staging-4.10-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad 72cca7baf4fba777b8ab770b902cf2e08941773f
# good: [b8d2798f32785398fcd1c48ea80c0c6c5ab88537] Merge tag 'clk-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect good b8d2798f32785398fcd1c48ea80c0c6c5ab88537
# bad: [9439b3710df688d853eb6cb4851256f2c92b1797] Merge tag 'drm-for-v4.10' of
git://people.freedesktop.org/~airlied/linux
git bisect bad 9439b3710df688d853eb6cb4851256f2c92b1797
# bad: [628d16555e019c0cc6897b603bbea29c3b6d2c9f] Merge tag
'imx-drm-next-2016-11-10' of git://git.pengutronix.de/git/pza/linux into
drm-next
git bisect bad 628d16555e019c0cc6897b603bbea29c3b6d2c9f
# bad: [3f767e3d076dd2a24a614917c8f0b05d8d82b90b] drm/amdgpu: just not load smc
firmware if smu is already running
git bisect bad 3f767e3d076dd2a24a614917c8f0b05d8d82b90b
# good: [bf9d99ad17ff3d85dc8c807063f76560587d983a] drm/i915/gen9: Make
skl_pipe_wm_get_hw_state() reusable
git bisect good bf9d99ad17ff3d85dc8c807063f76560587d983a
# bad: [9405e47dbab33706c43caba72cf8d83b5746f843] drm/amdgpu/virtual_dce: clean
up interrupt handling
git bisect bad 9405e47dbab33706c43caba72cf8d83b5746f843
# bad: [d138dd3c0c70979215f3184cf36f95875e37932e] drm: Add support for optional
per-plane rotation property
git bisect bad d138dd3c0c70979215f3184cf36f95875e37932e
# bad: [9edbf1fa600a2ef17c7553c2103d0055d0320d15] drm: Add API for capturing
frame CRCs
git bisect bad 9edbf1fa600a2ef17c7553c2103d0055d0320d15
# good: [f7741aa75e76440f4e9ecfe512feebe9bce33ca8] drm/savage: dereferencing an
error pointer
git bisect good f7741aa75e76440f4e9ecfe512feebe9bce33ca8
# good: [6dffd431e2296cda08e7e4f0242e02df1d1698cd] drm: Add aspect ratio
parsing in DRM layer
git bisect good 6dffd431e2296cda08e7e4f0242e02df1d1698cd
# good: [f14f368670541bfa217573194027a58f2206e250] drm/edid: Rename local
variable block to edid
git bisect good f14f368670541bfa217573194027a58f2206e250
# bad: [865afb11949e5bf4bb32d9a2aa9867c1ac4d8da0] drm/fb-helper: reject any
changes to the fbdev
git bisect bad 865afb11949e5bf4bb32d9a2aa9867c1ac4d8da0
# good: [a28187ccab9410cad20e8808f00cfc07f99649c3] drm/edid: Use block local to
refer to the block
git bisect good a28187ccab9410cad20e8808f00cfc07f99649c3
# first bad commit: [865afb11949e5bf4bb32d9a2aa9867c1ac4d8da0] drm/fb-helper:
reject any changes to the fbdev

(Tested on a GTX660/GK106)

-- 
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 PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Mark Brown]

On Mon, Mar 13, 2017 at 10:54:33AM +, Brian Starkey wrote:
> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:

> > Another point is how can we put secure rules (like selinux policy) on
> > heaps since all the allocations
> > go to the same device (/dev/ion) ? For example, until now, in Android
> > we have to give the same
> > access rights to all the process that use ION.
> > It will become problem when we will add secure heaps because we won't
> > be able to distinguish secure
> > processes to standard ones or set specific policy per heaps.
> > Maybe I'm wrong here but I have never see selinux policy checking an
> > ioctl field but if that
> > exist it could be a solution.

> I might be thinking of a different type of "secure", but...

> Should the security of secure heaps be enforced by OS-level
> permissions? I don't know about other architectures, but at least on
> arm/arm64 this is enforced in hardware; it doesn't matter who has
> access to the ion heap, because only secure devices (or the CPU
> running a secure process) is physically able to access the memory
> backing the buffer.

> In fact, in the use-cases I know of, the process asking for the ion
> allocation is not a secure process, and so we wouldn't *want* to
> restrict the secure heap to be allocated from only by secure
> processes.

I think there's an orthogonal level of OS level security that can be
applied here - it's reasonable for it to want to say things like "only
processes that are supposed to be implementing functionality X should be
able to try to allocate memory set aside for that functionality".  This
mitigates against escallation attacks and so on, it's not really
directly related to secure memory as such though.


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

[GIT PULL] omapdrm fixes for v4.11

[Tomi Valkeinen]

Hi Dave,

Please pull these two omapdrm fixes for v4.11.

 Tomi

The following changes since commit 3f81e1340706e9a7f854808e2f580c3106805d0c:

  drm: mxsfb: Implement drm_panel handling (2017-03-10 11:11:14 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.11-fixes

for you to fetch changes up to 337ba7fbf0fbc12242359c4af114878618b90951:

  uapi: fix drm/omap_drm.h userspace compilation errors (2017-03-13 12:53:27 
+0200)


omapdrm fixes for v4.11

- Fix types in omapdrm uapi header to avoid userspace compilation errors
- Fix dmabuf mmap for dma_alloc'ed buffers


Dmitry V. Levin (1):
  uapi: fix drm/omap_drm.h userspace compilation errors

Tomi Valkeinen (1):
  drm/omap: fix dmabuf mmap for dma_alloc'ed buffers

 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  3 ---
 include/uapi/drm/omap_drm.h   | 38 +++
 2 files changed, 19 insertions(+), 22 deletions(-)



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

[PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Christian König]

From: Christian König 

Try to resize BAR0 to let CPU access all of VRAM.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
 4 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
*adev, struct ttm_tt *ttm,
 struct ttm_mem_reg *mem);
 void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc, 
u64 base);
 void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
 void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
 int amdgpu_ttm_init(struct amdgpu_device *adev);
 void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev, 
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
 }
 
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+   u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+   int r;
+
+   r = pci_resize_resource(adev->pdev, 0, size);
+
+   if (r == -ENOTSUPP) {
+   /* The hardware don't support the extension. */
+   return;
+
+   } else if (r == -ENOSPC) {
+   DRM_INFO("Not enoigh PCI address space for a large BAR.");
+   } else if (r) {
+   DRM_ERROR("Problem resizing BAR0 (%d).", r);
+   }
+
+   /* Reinit the doorbell mapping, it is most likely moved as well */
+   amdgpu_doorbell_fini(adev);
+   BUG_ON(amdgpu_doorbell_init(adev));
+}
+
 /*
  * GPU helpers function.
  */
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
-   /* Could aper size report 0 ? */
-   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
-   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
 
+   if (!(adev->flags & AMD_IS_APU))
+   amdgpu_resize_bar0(adev);
+   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
 #ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
-   /* Could aper size report 0 ? */
-   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
-   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
 
+   if (!(adev->flags & AMD_IS_APU))
+   amdgpu_resize_bar0(adev);
+   adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+   adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
 #ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
-- 
2.7.4

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

[PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors

[Christian König]

From: Christian König 

Most BIOS don't enable this because of compatibility reasons.

Manually enable a 64bit BAR of 64GB size so that we have
enough room for PCI devices.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 6d52b94..bff5242 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -571,3 +571,56 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0, 
pci_invalid_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
+
+static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
+{
+   const uint64_t size = 64ULL * 1024 * 1024 * 1024;
+   uint32_t base, limit, high;
+   struct resource *res;
+   unsigned i;
+   int r;
+
+   for (i = 0; i < 8; ++i) {
+
+   pci_read_config_dword(dev, 0x80 + i * 0x8, &base);
+   pci_read_config_dword(dev, 0x180 + i * 0x4, &high);
+
+   /* Is this slot free? */
+   if ((base & 0x3) == 0x0)
+   break;
+
+   base >>= 8;
+   base |= high << 24;
+
+   /* Abort if a slot already configures a 64bit BAR. */
+   if (base > 0x1)
+   return;
+
+   }
+
+   if (i == 8)
+   return;
+
+   res = kzalloc(sizeof(*res), GFP_KERNEL);
+   res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_MEM_64 |
+   IORESOURCE_WINDOW;
+   res->name = dev->bus->name;
+   r = allocate_resource(&iomem_resource, res, size, 0x1,
+ 0xfd, size, NULL, NULL);
+   if (r) {
+   kfree(res);
+   return;
+   }
+
+   base = ((res->start >> 8) & 0xff00) | 0x3;
+   limit = ((res->end + 1) >> 8) & 0xff00;
+   high = ((res->start >> 40) & 0xff) |
+   res->end + 1) >> 40) & 0xff) << 16);
+
+   pci_write_config_dword(dev, 0x180 + i * 0x4, high);
+   pci_write_config_dword(dev, 0x84 + i * 0x8, limit);
+   pci_write_config_dword(dev, 0x80 + i * 0x8, base);
+
+   pci_bus_add_resource(dev->bus, res, 0);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
-- 
2.7.4

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

[PATCH 1/4] PCI: add resizeable BAR infrastructure v3

[Christian König]

From: Christian König 

Just the defines and helper functions to read the possible sizes of a BAR and
update it's size.

See 
https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf.

This is useful for hardware with large local storage (mostly GFX) which only
expose 256MB BARs initially to be compatible with 32bit systems.

v2: provide read helper as well
v3: improve function names, use unsigned values, add better comments.

Signed-off-by: Christian König 
---
 drivers/pci/pci.c | 115 ++
 include/linux/pci.h   |   3 ++
 include/uapi/linux/pci_regs.h |   7 +++
 3 files changed, 125 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ba34907..c2d9f78 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2944,6 +2944,121 @@ bool pci_acs_path_enabled(struct pci_dev *start,
 }
 
 /**
+ * pci_rbar_get_possible_sizes - get possible sizes for BAR
+ * @dev: PCI device
+ * @bar: BAR to query
+ *
+ * Get the possible sizes of a resizeable BAR as bitmask defined in the spec
+ * (bit 0=1MB, bit 19=512GB). Returns 0 if BAR isn't resizeable.
+ */
+u32 pci_rbar_get_possible_sizes(struct pci_dev *pdev, int bar)
+{
+   unsigned pos, nbars;
+   u32 ctrl, cap;
+   unsigned i;
+
+   pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+   if (!pos)
+   return 0;
+
+   pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+   nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+   for (i = 0; i < nbars; ++i, pos += 8) {
+   int bar_idx;
+
+   pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+   bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
+   PCI_REBAR_CTRL_BAR_IDX_SHIFT;
+   if (bar_idx != bar)
+   continue;
+
+   pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
+   return (cap & PCI_REBAR_CTRL_SIZES_MASK) >>
+   PCI_REBAR_CTRL_SIZES_SHIFT;
+   }
+
+   return 0;
+}
+
+/**
+ * pci_rbar_get_current_size - get the current size of a BAR
+ * @dev: PCI device
+ * @bar: BAR to set size to
+ *
+ * Read the size of a BAR from the resizeable BAR config.
+ * Returns size if found or negativ error code.
+ */
+int pci_rbar_get_current_size(struct pci_dev *pdev, int bar)
+{
+   unsigned pos, nbars;
+   u32 ctrl;
+   unsigned i;
+
+   pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+   if (!pos)
+   return -ENOTSUPP;
+
+   pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+   nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+   for (i = 0; i < nbars; ++i, pos += 8) {
+   int bar_idx;
+
+   pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+   bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
+   PCI_REBAR_CTRL_BAR_IDX_SHIFT;
+   if (bar_idx != bar)
+   continue;
+
+   return (ctrl & PCI_REBAR_CTRL_BAR_SIZE_MASK) >>
+   PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
+   }
+
+   return -ENOENT;
+}
+
+/**
+ * pci_rbar_set_size - set a new size for a BAR
+ * @dev: PCI device
+ * @bar: BAR to set size to
+ * @size: new size as defined in the spec (log2(size in bytes) - 20)
+ *
+ * Set the new size of a BAR as defined in the spec (0=1MB, 19=512GB).
+ * Returns true if resizing was successful, false otherwise.
+ */
+int pci_rbar_set_size(struct pci_dev *pdev, int bar, int size)
+{
+   unsigned pos, nbars;
+   u32 ctrl;
+   unsigned i;
+
+   pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+   if (!pos)
+   return -ENOTSUPP;
+
+   pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+   nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+   for (i = 0; i < nbars; ++i, pos += 8) {
+   int bar_idx;
+
+   pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+   bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
+   PCI_REBAR_CTRL_BAR_IDX_SHIFT;
+   if (bar_idx != bar)
+   continue;
+
+   ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE_MASK;
+   ctrl |= size << PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
+   pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
+   return 0;
+   }
+
+   return -ENOENT;
+}
+
+/**
  * pci_swizzle_interrupt_pin - swizzle INTx for device behind bridge
  * @dev: the PCI device
  * @pin: the INTx pin (1=INTA, 2=INTB, 3=INTC, 4=INTD)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a38772a..6954e50 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1946,6 +1946,9 @@ void pci_request_acs(void);
 bool pci_acs_enabled(str

[PATCH 2/4] PCI: add functionality for resizing resources v2

[Christian König]

From: Christian König 

This allows device drivers to request resizing their BARs.

The function only tries to reprogram the windows of the bridge directly above
the requesting device and only the BAR of the same type (usually mem, 64bit,
prefetchable). This is done to make sure not to disturb other drivers by
changing the BARs of their devices.

If reprogramming the bridge BAR fails the old status is restored and -ENOSPC
returned to the calling device driver.

v2: rebase on changes in rbar support

Signed-off-by: Christian König 
---
 drivers/pci/setup-bus.c | 61 +
 drivers/pci/setup-res.c | 51 +
 include/linux/pci.h |  2 ++
 3 files changed, 114 insertions(+)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index f30ca75..cfab2c7 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1923,6 +1923,67 @@ void pci_assign_unassigned_bridge_resources(struct 
pci_dev *bridge)
 }
 EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);
 
+int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
+{
+   const unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
+   IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
+
+   struct resource saved;
+   LIST_HEAD(add_list);
+   LIST_HEAD(fail_head);
+   struct pci_dev_resource *fail_res;
+   unsigned i;
+   int ret = 0;
+
+   /* Release all children from the matching bridge resource */
+   for (i = PCI_BRIDGE_RESOURCES; i < PCI_BRIDGE_RESOURCE_END; ++i) {
+   struct resource *res = &bridge->resource[i];
+
+   if ((res->flags & type_mask) != (type & type_mask))
+   continue;
+
+   saved = *res;
+   if (res->parent) {
+   release_child_resources(res);
+   release_resource(res);
+   }
+   res->start = 0;
+   res->end = 0;
+   break;
+   }
+
+   if (i == PCI_BRIDGE_RESOURCE_END)
+   return -ENOENT;
+
+   __pci_bus_size_bridges(bridge->subordinate, &add_list);
+   __pci_bridge_assign_resources(bridge, &add_list, &fail_head);
+   BUG_ON(!list_empty(&add_list));
+
+   /* restore size and flags */
+   list_for_each_entry(fail_res, &fail_head, list) {
+   struct resource *res = fail_res->res;
+
+   res->start = fail_res->start;
+   res->end = fail_res->end;
+   res->flags = fail_res->flags;
+   }
+
+   /* Revert to the old configuration */
+   if (!list_empty(&fail_head)) {
+   struct resource *res = &bridge->resource[i];
+
+   res->start = saved.start;
+   res->end = saved.end;
+   res->flags = saved.flags;
+
+   pci_claim_resource(bridge, i);
+   ret = -ENOSPC;
+   }
+
+   free_list(&fail_head);
+   return ret;
+}
+
 void pci_assign_unassigned_bus_resources(struct pci_bus *bus)
 {
struct pci_dev *dev;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 9526e34..3bb1e29 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -363,6 +363,57 @@ int pci_reassign_resource(struct pci_dev *dev, int resno, 
resource_size_t addsiz
return 0;
 }
 
+int pci_resize_resource(struct pci_dev *dev, int resno, int size)
+{
+   struct resource *res = dev->resource + resno;
+   u32 sizes = pci_rbar_get_possible_sizes(dev, resno);
+   int old = pci_rbar_get_current_size(dev, resno);
+   u64 bytes = 1ULL << (size + 20);
+   int ret = 0;
+
+   if (!sizes)
+   return -ENOTSUPP;
+
+   if (!(sizes & (1 << size)))
+   return -EINVAL;
+
+   if (old < 0)
+   return old;
+
+   /* Make sure the resource isn't assigned before making it larger. */
+   if (resource_size(res) < bytes && res->parent) {
+   release_resource(res);
+   res->end = resource_size(res) - 1;
+   res->start = 0;
+   if (resno < PCI_BRIDGE_RESOURCES)
+   pci_update_resource(dev, resno);
+   }
+
+   ret = pci_rbar_set_size(dev, resno, size);
+   if (ret)
+   goto error_reassign;
+
+   res->end = res->start + bytes - 1;
+
+   ret = pci_reassign_bridge_resources(dev->bus->self, res->flags);
+   if (ret)
+   goto error_resize;
+
+   pci_reenable_device(dev->bus->self);
+   return 0;
+
+error_resize:
+   pci_rbar_set_size(dev, resno, old);
+   res->end = res->start + (1ULL << (old + 20)) - 1;
+
+error_reassign:
+   pci_assign_unassigned_bus_resources(dev->bus);
+   pci_setup_bridge(dev->bus);
+   pci_reenable_device(dev->bus->self);
+   return ret;
+}
+EXPORT_SYMBOL(pci_resize_resource);
+
 int pci_enable_resources(struct pci_dev *dev, int mask)
 {
   

Resizeable PCI BAR support V3

[Christian König]

Hi Bjorn and others on the lists,

it's over a year that I initially came up with that, but now I
finally have the time to finish it up.

This set of patches allows device drivers to resize and most likely also
relocate the PCI BAR of devices they manage to allow the CPU to access
all of the device local memory at once.

This is very useful for GFX device drivers where the default PCI BAR is only
about 256MB in size for compatibility reasons, but the device easily have
multiple gigabyte of local memory.

Additional to the pure resize functionality this set also adds a quirk to
enable a 64bit bar above 4GB on AMD Family 15h CPUs/APUs. Doing so is
actually trivial and I plan to extend this to all recent AMD CPUs/APUs.

Open questions:

1. Is this the right location to implement the 64bit BAR above 4GB for AMD CPUs?
I guess that this needs a bit more cleanup.

2. Any idea how to better handle intermediate bridges? Reprogramming them isn't
possible after drivers are loaded, but at least for GFX drivers we need to load
them first to know how large we actually want our BAR to be (and to kick our
vesafb/efifb).

Thanks in advance,
Christian.

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

Re: [PATCH 1/5] drm/tinydrm: Add tinydrm_rgb565_buf_copy()

[Noralf Trønnes]

Den 12.03.2017 19.00, skrev Daniel Vetter:

On Sat, Mar 11, 2017 at 10:35:32PM +0100, Noralf Trønnes wrote:

Add tinydrm_rgb565_buf_copy() function that copies buffer rectangle to
destination buffer and also handles XRGB and byte swap conversions.
Useful for displays that only support RGB565 and can do partial updates.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 56 +-
  include/drm/tinydrm/tinydrm-helpers.h  |  2 +
  2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d4cda33..e639453 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -7,13 +7,15 @@
   * (at your option) any later version.
   */
  
-#include 

-#include 
  #include 
+#include 
  #include 
  #include 
  #include 
  
+#include 

+#include 
+
  static unsigned int spi_max;
  module_param(spi_max, uint, 0400);
  MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
@@ -181,6 +183,56 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
  EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);

So I noticed that we already have the xrgb to rgb565 function, so I'm
a bit late on this, but: DRM doesn't do format conversions, with the
single exception that the legacy cursor interface is specced to be
argb.

Imo this should be removed (and preferrably before we ship tinydrm in a
stable kernel). Why did you add it?


I added it from the start because plymouth can only do xrgb and I
thought that this was probably the format that most apps/libs/tools
supported, ensuring that tinydrm would work with everything. But I was
aware that this was the kernel patching up userspace, so I knew that it
might be shot down.

But after your comment, I thought that this was in the clear:
https://lists.freedesktop.org/archives/dri-devel/2017-January/130551.html

> > +EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
>
> I wonder whether the above would make sense in drm core as some kind 
of fb

> helpers. But we can do that once there's a clear need.

I can make a patch that removes this format conversion.

Noralf.


-Daniel


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

Re: [PATCH 0/5] drm/tinydrm: Add tinydrm_panel abstraction

[Noralf Trønnes]

Den 12.03.2017 19.55, skrev Daniel Vetter:

On Sun, Mar 12, 2017 at 06:50:17PM +0100, Daniel Vetter wrote:

Hi Noralf,

On Sat, Mar 11, 2017 at 10:35:31PM +0100, Noralf Trønnes wrote:

Add support for displays that have a register interface and can be
operated using a simple vtable.

I have looked through the staging/fbtft drivers and it seems that,
except the MIPI controllers, most if not all controllers are operated
through a register. And since most controllers have more than one bus
interface option, regmap seems like a good choice to describe the
interface (tested[1,2]).
MIPI DCS can't be represented using regmap since some commands doesn't
have a parameter. That would be like a register without a value, which
doesn't make sense.

In my second RFC of tinydrm I used drm_panel to decribe the panels
since it was a good match to the fbtft displays. I was then told that
drm_panel wasn't supposed to used like that, so I dropped it and have
tried to use the drm_simple_display_pipe_funcs vtable directly. This
hasn't been all successful, since I ended up using devm_add_action() to
power down the controller at the right time. Thierry Reding wasn't
happy with this and suggested "to add an explicit callback somewhere".
My solution has been to copy the drm_panel_funcs vtable.
Since I now have a vtable, I also added a callback to flush the
framebuffer. So presumably all the fbtft drivers can now be operated
through the tinydrm_panel_funcs vtable.

Ehrm, what? I admit I didn't follow the discussion in-depth, but if
drm_panel can't be used to describe a panel, it's not fit for the job and
needs to be extended. Adding even more abstraction, matroschka-style,
isn't a solution.

Personally I think tinydrm itself is already a bit much wrapping, but I
see that for really simple drivers it has it's uses. But more layers feels
like going in the wrong direction.

For the callback you're looking for (i.e. the regulator_disable call) I
think the correct place is to enable/disable the regulator in the
enable/disable hooks of the drm_simple_display_pipe functions. Or maybe in
their equivalent in drm_panel (well, probably pre_enable and post_disable,
since I guess you need that regulator to driver anything). Same for _init,
if the display is completely off there's no point in keeping the hw
running. Enabling/disabling the entire hw is pretty much what ->enable and
->disable are for. This also gives you proper runtime pm for almost for
free ...

Also, since the regulator is actually stored in struct mipi_dbi, it's
probably best to handle it in the mipi_dbi helpers too. You do that
already with the backlight anyway.

I noticed that the version of tinydrm that landed doesn't use drm_panel
anymore, I thought that was the case once, and for the version I acked?


After having done this the question arises:
Why not extend tinydrm_device instead of subclassing it?

The benefit of subclassing is that it keeps the door open for drivers
that can use tinydrm_device, but not tinydrm_panel. But I don't know of
such a driver now, then again who knows what the future brings.
Something that might or might not happen isn't a good reason, so it
seems that I want it this way because I just like it. And it's easy to
merge the two should it be that no one uses tinydrm_device directly
three years down the line. But I'm actually not sure what's best.

As a rule of thumb, never design code for future use that you don't know
yet will happen. No one can reliably predict the future, which means
you'll get it wrong, and in the future we'll have to do 2x the work: Once
do unto the code resulting from the wrong prediction, then redoing it the
way we need to. Not including the on-going burden of maintaining unused
functionally.

So let's pls merge first, split later when there's a clean need.


To recap:

tinydrm_device
- Combines drm_simple_display_pipe with CMA backed framebuffer and fbdev.
- Optional pipe setup with a connector with one mode, but the driver
   can do it's own.

tinydrm_panel
- All drm operations are distilled down to tinydrm_panel_funcs.
- Some common driver properties

So overal sorry I'm shredding this a bit, but I don't see the point. Imo
much more useful would be:

1. Extract the non-tinydrm specific helpers from tinydrm and put them into
the right places. I think from our discussions this was:

- backlight helpers, probably best to put them into a new drm_backlight.c.
   This is because drivers/video is defactor unmaintained. We could also
   move drivers/video/backlight to drivers/gpu/backlight and take it all
   over within drm-misc, but that's more work.

- spi helpers, probably best put into spi core/helper code. Thierry said
   the spi maintainer is fast&reactive, so shouldn't be a big issue.

- extract the mipi-dbi helper (well, the non-tinydrm specific parts at
   least) into a separate helper, like we have for mipi-dsi already.

A large chunk of the tinydrm functions should probably be moved into
relevant existin drm helpers,

[PATCH v10 4/6] drm/edid: detect SCDC support in HF-VSDB

[Shashank Sharma]

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
- If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
  Thierry:
  - Fix typos in commit message and make abbreviation consistent
across the commit message.
  - Change structure object name from hdmi_info -> hdmi
  - Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
  - Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.

  Ville:
  - Change rr -> read_request
  - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Addressed review comments from Ville
  - Add clock rate calculations for 1/10 and 1/40 ratios
  - Remove leftovers from old patchset
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.

Signed-off-by: Shashank Sharma 
Reviewed-by: Thierry Reding 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/drm_edid.c|  33 ++-
 drivers/gpu/drm/drm_scdc_helper.c | 121 ++
 include/drm/drm_connector.h   |  19 ++
 include/drm/drm_edid.h|   1 -
 include/drm/drm_scdc_helper.h |  27 +
 5 files changed, 199 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d64b7bd..fad3d44 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 
@@ -3820,13 +3821,43 @@ enum hdmi_quantization_range
 static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
 const u8 *hf_vsdb)
 {
-   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+   struct drm_display_info *display = &connector->display_info;
+   struct drm_hdmi_info *hdmi = &display->hdmi;
 
if (hf_vsdb[6] & 0x80) {
hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
hdmi->scdc.read_request = true;
}
+
+   /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
+* * SCDC support available (let's check)
+* Lets check it out.
+*/
+
+   if (hf_vsdb[5]) {
+   /* max clock is 5000 KHz times block value */
+   u32 max_tmds_clock = hf_vsdb[5] * 5000;
+   struct drm_scdc *scdc = &hdmi->scdc;
+
+   if (max_tmds_clock > 34) {
+   display->max_tmds_clock = max_tmds_clock;
+   DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+   display->max_tmds_clock);
+   }
+
+   if (scdc->supported) {
+   scdc->scrambling.supported = true;
+
+   /* Few sinks support scrambling for cloks < 340M */
+   if ((hf_vsdb[6] & 0x8))
+   scdc->scrambling.low_rates = true;
+   }
+   }
 }
 
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index c2dd33f..3cd96a9 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
  */
 
 #include 
+#include 
 
 #include 
+#include 
 
 /**
  * DOC: scdc helpers
@@ -121,3 +123,122 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8 
offset,
return 0;
 }
 EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambling status.
+ *
+ * Returns:
+ * True if the scrambling is enabled, false otherwise.
+ */
+
+bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
+{
+   u8 status;
+   int ret;
+
+   ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
+   if (ret < 0) {
+   DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
+   return false;
+   }
+
+   return status & SCDC_SCRAMBLING_STATUS;
+}
+EXPORT_SYMBOL(drm_scdc_get_scrambling_status);

[PATCH v10 6/6] drm/i915: allow HDMI 2.0 clock rates

[Shashank Sharma]

Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.

V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase

Cc: Ander Conselvan De Oliveira 
Signed-off-by: Shashank Sharma 
Reviewed-by: Ander Conselvan De Oliveira 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 23b3387..f14aa39 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1209,6 +1209,8 @@ static int intel_hdmi_source_max_tmds_clock(struct 
drm_i915_private *dev_priv)
 {
if (IS_G4X(dev_priv))
return 165000;
+   else if (IS_GEMINILAKE(dev_priv))
+   return 594000;
else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
return 30;
else
-- 
1.9.1

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

[PATCH v10 5/6] drm/i915: enable scrambling

[Shashank Sharma]

Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

V2: Addressed review comments from Ville:
 - Do not track scrambling status in DRM layer, track somewhere in
   driver like in intel_crtc_state.
 - Don't talk to monitor at such a low layer, set monitor scrambling
   in intel_enable_ddi() before enabling the port.

V3: Addressed review comments from Jani
 - In comments, function names, use "sink" instead of "monitor",
   so that the implementation could be close to the language of
   HDMI spec.

V4: Addressed review comment from Maarten
 - scrambling -> hdmi_scrambling
 - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio

V5: Addressed review comments from Ville and Ander
 - Do not modifiy the crtc_state after compute_config. Move all
   scrambling and tmds_clock_ratio calcutations to compute_config.
 - While setting scrambling for source/sink, do not check the
   conditions again, just go by the crtc_state flags. This will
   simplyfy the condition checks.

V6: Addressed review comments from Ville
 - Do not add IS_GLK check in disable/enable function, instead add it
   in compute_config, while setting state flags.
 - Remove unnecessary paranthesis.
 - Simplyfy handle_sink_scrambling function as suggested.
 - Add readout code for scrambling status in get_ddi_config and add a
   check for the same in pipe_config_compare.

V7: Addressed review comments from Ander/Ville
 - No separate function for source scrambling, make it inline
 - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
 - Do not add platform check while setting source scrambling
 - Use pipe_config instead of crtc->config to set sink scrambling
 - To readout scrambling status, Compare with SCRAMBLING_MASK
   not any of its bits
 - Remove platform check in intel_pipe_config_compare while checking
   scrambling status

V8: Fixed mege conflict, Addressed review comments from Ander
 - Remove the desciption/comment about scrambling fom the caller, move
   it to the function
 - Move the IS_GLK check into scrambling function
 - Fix alignment

V9: Fixed review comments from Ville, Ander
 - Pass the scrambling state variables as bool input to the sink_scrambling
   function and let the disable call be unconditional.
 - Fix alignments in function calls and debug messages.
 - Add kernel doc for function intel_hdmi_handle_sink_scrambling

V10: Rebase
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_reg.h  |  7 
 drivers/gpu/drm/i915/intel_ddi.c | 23 +
 drivers/gpu/drm/i915/intel_display.c |  3 ++
 drivers/gpu/drm/i915/intel_drv.h | 10 ++
 drivers/gpu/drm/i915/intel_hdmi.c| 63 
 5 files changed, 106 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 19d42e8..a1aae7a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7831,7 +7831,14 @@ enum {
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
 #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
+#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
+#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
 #define  TRANS_DDI_BFI_ENABLE  (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
+#define  TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE \
+   | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
+   | TRANS_DDI_HDMI_SCRAMBLING)
 
 /* DisplayPort Transport Control */
 #define _DP_TP_CTL_A   0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ee341ef..169d2b4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1309,6 +1309,11 @@ void intel_ddi_enable_transcoder_func(const struct 
intel_crtc_state *crtc_state)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (crtc_state->hdmi_scrambling)
+   temp |= TRANS_DDI_HDMI_SCRAMBLING_MASK;
+   if (crtc_state->hdmi_high_tmds_clock_ratio)
+   temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (crtc_state->fdi_lanes - 1) << 1;
@@ -1881,6 +1886,12 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
if (type == INTEL_OUTPUT_HDMI) {
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
+   bool clock_ratio = pipe_config->h

[PATCH v10 1/6] drm: Add SCDC helpers

[Shashank Sharma]

From: Thierry Reding 

SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.

This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Addressed review comments from Ville
 - Handle the I2c return values in a better way (dp_dual_mode)
 - Make the macros for SCDC Major/Minor more readable, by adding
   a 'GET' in the macro names
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase

Signed-off-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
Reviewed-by: Jose Abreu 
---
 Documentation/gpu/drm-kms-helpers.rst |  12 
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_scdc_helper.c | 123 +++
 include/drm/drm_scdc_helper.h | 132 ++
 4 files changed, 269 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
 create mode 100644 include/drm/drm_scdc_helper.h

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:
 
+SCDC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+   :export:
+
 Rectangle Utilities Reference
 =
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59aae43..59f0f9b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
-   drm_simple_kms_helper.o drm_modeset_helper.o
+   drm_simple_kms_helper.o drm_modeset_helper.o \
+   drm_scdc_helper.o
 
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..c2dd33f
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+
+#include 
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t size)
+{
+   int ret;
+   struct i2c_msg msgs[2] = {
+   {
+   .addr = SCDC_I2C_SLAVE_ADDRESS,
+   .flags = 0,
+   .len = 1,
+   .buf = 

[PATCH v10 3/6] drm/edid: detect SCDC support in HF-VSDB

[Shashank Sharma]

This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
  This structure will be used to save and indicate if sink
  supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
  reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
  in scdc structure
- If SCDC is present, checks if sink is capable of generating
  SCDC read request, and marks it in scdc structure.

V2: Addressed review comments
 Thierry:
 - Fix typos in commit message and make abbreviation consistent
   across the commit message.
 - Change structure object name from hdmi_info -> hdmi
 - Fix typos and abbreviations in description of structure drm_hdmi_info
   end the description with a full stop.
 - Create a structure drm_scdc, and keep all information related to SCDC
   register set (supported, read request supported) etc in it.

Ville:
 - Change rr -> read_request
 - Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
   of HF-VSDB parsing can be kept in same function, in incremental
   patches.

V3: Rebase.
V4: Rebase.
V5: Rebase.
V6: Rebase.
V7: Added R-B from Jose.
V8: Rebase.
V9: Rebase.
V10: Rebase.

Signed-off-by: Shashank Sharma 
Reviewed-by: Thierry Reding 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/drm_edid.c  | 14 ++
 include/drm/drm_connector.h | 33 +
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3e0aafa..d64b7bd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3817,6 +3817,18 @@ enum hdmi_quantization_range
 }
 EXPORT_SYMBOL(drm_default_rgb_quant_range);
 
+static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
+const u8 *hf_vsdb)
+{
+   struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+   if (hf_vsdb[6] & 0x80) {
+   hdmi->scdc.supported = true;
+   if (hf_vsdb[6] & 0x40)
+   hdmi->scdc.read_request = true;
+   }
+}
+
 static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
   const u8 *hdmi)
 {
@@ -3931,6 +3943,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
 
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
+   if (cea_db_is_hdmi_forum_vsdb(db))
+   drm_parse_hdmi_forum_vsdb(connector, db);
}
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fabb35a..bf9d6f5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -87,6 +87,34 @@ enum subpixel_order {
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
+
+};
+
+/*
+ * struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
+ *
+ * Provides SCDC register support and capabilities related information on a
+ * HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
+ */
+struct drm_scdc {
+   /**
+* @supported: status control & data channel present.
+*/
+   bool supported;
+   /**
+* @read_request: sink is capable of generating scdc read request.
+*/
+   bool read_request;
+};
+
+/**
+ * struct drm_hdmi_info - runtime information about the connected HDMI sink
+ *
+ * Describes if a given display supports advanced HDMI 2.0 features.
+ * This information is available in CEA-861-F extension blocks (like HF-VSDB).
+ */
+struct drm_hdmi_info {
+   struct drm_scdc scdc;
 };
 
 /**
@@ -204,6 +232,11 @@ struct drm_display_info {
 * @cea_rev: CEA revision of the HDMI sink.
 */
u8 cea_rev;
+
+   /**
+* @hdmi: advance features of a HDMI sink.
+*/
+   struct drm_hdmi_info hdmi;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,
-- 
1.9.1

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

[PATCH v10 0/6] HDMI 2.0: Scrambling in DRM layer

[Shashank Sharma]

HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.

This patch series contains 6 patches:
- First two patches add generic drm helper functions to read and
  write into SCDC registers. These patches are written by Thierry,
  in a patch series published here:
  https://patchwork.kernel.org/patch/9459051/
  Minor changes were done to map the patches into this series.

- Next two patches add functions for scrambling detection and
  scrambling control.

- Next two patches use this infrastructure in DRM layer from
  I915 driver, to enable scrambling on a GLK deivce which sports
  a native HDMI 2.0 controller.

V2:
 - addressed review comments from Thierry, Ville and Dhinakaran
 - added signed-off-by:self in first two patches(Jani N)

V3:
 - addressed review comments from Jose and Jani

V4:
 - addressed review comments from Maarten on patch 5,
   rebase all other patches

V5:
 - addressed review comments from Ville/Ander on patch 1, 4, 5
   rebase all other patches

V6:
 - addressed review comments from Ville on patch 4, 5
   rebase all other patches

V7:
 - addressed review comments from Ander on patch 5
   rebase all other patches,
   added r-b from Jose on patch 3,4

V8:
 - addressed review comments from Ander on patch 5
 - rebase and fixed merge conflict
 
V9:
 - addressed review comments from Ander on patch 5
 
V10:
 - rebase

Shashank Sharma (4):
  drm/edid: detect SCDC support in HF-VSDB
  drm/edid: detect SCDC support in HF-VSDB
  drm/i915: enable scrambling
  drm/i915: allow HDMI 2.0 clock rates

Thierry Reding (2):
  drm: Add SCDC helpers
  drm/edid: check for HF-VSDB block

 Documentation/gpu/drm-kms-helpers.rst |  12 ++
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_edid.c|  60 +
 drivers/gpu/drm/drm_scdc_helper.c | 244 ++
 drivers/gpu/drm/i915/i915_reg.h   |   7 +
 drivers/gpu/drm/i915/intel_ddi.c  |  23 
 drivers/gpu/drm/i915/intel_display.c  |   3 +
 drivers/gpu/drm/i915/intel_drv.h  |  10 ++
 drivers/gpu/drm/i915/intel_hdmi.c |  65 +
 include/drm/drm_connector.h   |  52 
 include/drm/drm_edid.h|   1 -
 include/drm/drm_scdc_helper.h | 159 ++
 include/linux/hdmi.h  |   1 +
 13 files changed, 638 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
 create mode 100644 include/drm/drm_scdc_helper.h

-- 
1.9.1

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

[PATCH v10 2/6] drm/edid: check for HF-VSDB block

[Shashank Sharma]

From: Thierry Reding 

This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase

Signed-off-by: Thierry Reding 
Signed-off-by: Shashank Sharma 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/drm_edid.c | 15 +++
 include/linux/hdmi.h   |  1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5da5a85..3e0aafa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3251,6 +3251,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
return hdmi_id == HDMI_IEEE_OUI;
 }
 
+static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
+{
+   unsigned int oui;
+
+   if (cea_db_tag(db) != VENDOR_BLOCK)
+   return false;
+
+   if (cea_db_payload_len(db) < 7)
+   return false;
+
+   oui = db[3] << 16 | db[2] << 8 | db[1];
+
+   return oui == HDMI_FORUM_IEEE_OUI;
+}
+
 #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)
 
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index edbb4fc..d271ff2 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -35,6 +35,7 @@ enum hdmi_infoframe_type {
 };
 
 #define HDMI_IEEE_OUI 0x000c03
+#define HDMI_FORUM_IEEE_OUI 0xc45dd8
 #define HDMI_INFOFRAME_HEADER_SIZE  4
 #define HDMI_AVI_INFOFRAME_SIZE13
 #define HDMI_SPD_INFOFRAME_SIZE25
-- 
1.9.1

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

Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

[Philipp Zabel]

Hi Dan,

On Fri, 2017-03-10 at 11:11 +, Dan MacDonald wrote:
> Should your patches work fine under 4.11-rc1 Phillipp or do I need to
> test againt the very latest git? I realise that would be preferred.

The patches from the v4.10-ipu-dp-plane-fix-2 tag should work under
v4.11-rc1, they are applied on top of v4.11-rc1 in the imx-drm/next
branch.

regards
Philipp

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

Re: [PATCH 2/3] drm/etnaviv: move fence allocation out of etnaviv_gpu_submit()

[Philipp Zabel]

On Wed, 2017-03-08 at 11:42 -0300, Gustavo Padovan wrote:
> Hi Philipp,
> 
> 2017-03-08 Philipp Zabel :
> 
> > The next patch will need the dma_fence to create the sync_file in
> > etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_gem.h|  3 ++-
> >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  8 +++-
> >  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 21 ++---
> >  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  1 +
> >  4 files changed, 16 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > index 120410d67eb5b..c4a091e874269 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> > @@ -20,6 +20,7 @@
> >  #include 
> >  #include "etnaviv_drv.h"
> >  
> > +struct dma_fence;
> 
> Why not #include  ?

I don't see the need to include the header as long as the memory layout
of struct dma_fence doesn't have to be known. Here we just need to pass
pointers to the structure type as function arguments.

> Other than that looks good to me:
> 
> Reviewed-by: Gustavo Padovan 

May I keep the review tag without adding the #include?

regards
Philipp

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

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

[Philipp Zabel]

Hi Gustavo,

thank you for the review.

On Wed, 2017-03-08 at 11:37 -0300, Gustavo Padovan wrote:
[...]
> > @@ -385,6 +396,25 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > void *data,
> > goto err_submit_objects;
> > }
> >  
> > +   if (args->flags & ETNA_SUBMIT_FENCE_FD_IN) {
> > +   in_fence = sync_file_get_fence(args->fence_fd);
> > +   if (!in_fence) {
> > +   ret = -EINVAL;
> > +   goto err_submit_objects;
> > +   }
> > +
> > +   /* TODO if we get an array-fence due to userspace merging
> > +* multiple fences, we need a way to determine if all the
> > +* backing fences are from our own context..
> > +*/
> 
> All GPU drivers seem to have the same need on fence_array, so I think we
> can create a fence array helper to inspect if it has a specific context
> or not.

Do you have a pointer where I could read up on how this should be done?

> > +
> > +   if (in_fence->context != gpu->fence_context) {
> > +   ret = dma_fence_wait(in_fence, true);
> > +   if (ret)
> > +   goto err_submit_objects;
> 
> sync_file_get_fence() hold a fence ref, we need to release it here
> always and not only in case of error.

We do that already. err_submit_objects is an unfortunate name for patch
review, but the out label at the end of the function falls right through
to it.

> > +   }
> > +   }
> > +
> > ret = submit_fence_sync(submit);
> > if (ret)
> > goto err_submit_objects;
> > @@ -419,6 +449,8 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > void *data,
> > flush_workqueue(priv->wq);
> >  
> >  err_submit_objects:
> > +   if (in_fence)
> > +   dma_fence_put(in_fence);

We pass through here in the non-error case, too.

[...]
> > @@ -154,6 +154,10 @@ struct drm_etnaviv_gem_submit_bo {
> >   * one or more cmdstream buffers.  This allows for conditional execution
> >   * (context-restore), and IB buffers needed for per tile/bin draw cmds.
> >   */
> > +#define ETNA_SUBMIT_NO_IMPLICIT 0x0001
> > +#define ETNA_SUBMIT_FENCE_FD_IN 0x0002
> 
> ETNA_SUBMIT_NO_IMPLICIT and ETNA_SUBMIT_FENCE_FD_IN are the same, when
> you send and fence_fd to the kernel you are requesting on explicit sync
> thus I think the ETNA_SUBMIT_NO_IMPLICIT can be dropped and
> ETNA_SUBMIT_FENCE_FD_IN would be the one to look at.

I just followed Rob's lead. I'm not sure if there may be a reason to
submit an in fence still keep implicit fencing enabled at the same time,
or to allow a submit without any fencing whatsoever. Maybe for testing
purposes?
I'm happy to drop the NO_IMPLICIT flag if there is no need for it.

regards
Philipp

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

Re: [PATCH 3/3] drm/etnaviv: submit support for out-fences

[Philipp Zabel]

On Wed, 2017-03-08 at 11:48 -0300, Gustavo Padovan wrote:
[...]
> > @@ -437,10 +447,25 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > void *data,
> > goto out;
> > }
> >  
> > +   if (args->flags & ETNA_SUBMIT_FENCE_FD_OUT) {
> > +   sync_file = sync_file_create(submit->fence);
> > +   if (!sync_file) {
> > +   dma_fence_put(submit->fence);
> > +   submit->fence = NULL;
> > +   ret = -ENOMEM;
> > +   goto out;
> > +   }
> > +   }
> > +
> > ret = etnaviv_gpu_submit(gpu, submit, cmdbuf);
> > if (ret == 0)
> > cmdbuf = NULL;
> >  
> > +   if (args->flags & ETNA_SUBMIT_FENCE_FD_OUT) {
> > +   fd_install(out_fence_fd, sync_file->file);
> > +   }
> 
> Extra braces here.

I'll drop those next time.

> Otherwise looks good to me.
> 
> Reviewed-by: Gustavo Padovan 

thanks
Philipp

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

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Brian Starkey]

On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:

2017-03-09 18:38 GMT+01:00 Laura Abbott :

On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:

2017-03-06 17:04 GMT+01:00 Daniel Vetter :

On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:

On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:


No one gave a thing about android in upstream, so Greg KH just dumped it
all into staging/android/. We've discussed ION a bunch of times, recorded
anything we'd like to fix in staging/android/TODO, and Laura's patch
series here addresses a big chunk of that.



This is pretty much the same approach we (gpu folks) used to de-stage the
syncpt stuff.


Well, there's also the fact that quite a few people have issues with the
design (like Laurent).  It seems like a lot of them have either got more
comfortable with it over time, or at least not managed to come up with
any better ideas in the meantime.


See the TODO, it has everything a really big group (look at the patch for
the full Cc: list) figured needs to be improved at LPC 2015. We don't just
merge stuff because merging stuff is fun :-)

Laurent was even in that group ...
-Daniel


For me those patches are going in the right direction.

I still have few questions:
- since alignment management has been remove from ion-core, should it
be also removed from ioctl structure ?


Yes, I think I'm going to go with the suggestion to fixup the ABI
so we don't need the compat layer and as part of that I'm also
dropping the align argument.


- can you we ride off ion_handle (at least in userland) and only
export a dma-buf descriptor ?


Yes, I think this is the right direction given we're breaking
everything anyway. I was debating trying to keep the two but
moving to only dma bufs is probably cleaner. The only reason
I could see for keeping the handles is running out of file
descriptors for dma-bufs but that seems unlikely.


In the future how can we add new heaps ?
Some platforms have very specific memory allocation
requirements (just have a look in the number of gem custom allocator in drm)
Do you plan to add heap type/mask for each ?


Yes, that was my thinking.


My concern is about the policy to adding heaps, will you accept
"customs" heap per
platforms ? per devices ? or only generic ones ?
If you are too strict, we will have lot of out-of-tree heaps and if
you accept of of them
it will be a nightmare to maintain



Are you concerned about actual heaps (e.g. a carveout at 0x8000 vs
a carveout at 0x6000) or heap types?

For heap types, I think the policy can be strict - if it's generally
useful then it should live in-tree in ion. Otherwise, it would be
out-of-tree. I'd expect most "custom" heaps to be parameterisable to
the point of being generally useful.

For actual heap instances, I would expect them to be communicated via
reserved-memory regions or something similar, and so the maintenance
burden is pretty low.

The existing query ioctl can allow heap IDs to get assigned
dynamically at runtime, so there's no need to reserve "bit 6" for
"CUSTOM_ACME_HEAP_1"


Another point is how can we put secure rules (like selinux policy) on
heaps since all the allocations
go to the same device (/dev/ion) ? For example, until now, in Android
we have to give the same
access rights to all the process that use ION.
It will become problem when we will add secure heaps because we won't
be able to distinguish secure
processes to standard ones or set specific policy per heaps.
Maybe I'm wrong here but I have never see selinux policy checking an
ioctl field but if that
exist it could be a solution.



I might be thinking of a different type of "secure", but...

Should the security of secure heaps be enforced by OS-level
permissions? I don't know about other architectures, but at least on
arm/arm64 this is enforced in hardware; it doesn't matter who has
access to the ion heap, because only secure devices (or the CPU
running a secure process) is physically able to access the memory
backing the buffer.

In fact, in the use-cases I know of, the process asking for the ion
allocation is not a secure process, and so we wouldn't *want* to
restrict the secure heap to be allocated from only by secure
processes.

-Brian





Benjamin



Thanks,
Laura


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

Re: [PATCH] drm: virtio: fix kmem_cache_alloc error check

[Daniel Vetter]

On Mon, Mar 13, 2017 at 09:22:26AM +0100, Gerd Hoffmann wrote:
> kmem_cache_alloc returns NULL on error, not ERR_PTR.
> 
> Fixes: f5985bf9cadd4e3ed8d5d9a9cbbb2e39cdb81cd9
> Reported-by: Jiri Slaby 
> Signed-off-by: Gerd Hoffmann 

I guess we should have smatch integrated into 0day to catch these ...

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
> b/drivers/gpu/drm/virtio/virtgpu_vq.c
> index 472e349..9eb96fb2 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
> @@ -97,8 +97,8 @@ void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev)
>   struct virtio_gpu_vbuffer *vbuf;
>  
>   vbuf = kmem_cache_alloc(vgdev->vbufs, GFP_KERNEL);
> - if (IS_ERR(vbuf))
> - return ERR_CAST(vbuf);
> + if (!vbuf)
> + return ERR_PTR(-ENOMEM);
>   memset(vbuf, 0, VBUFFER_SIZE);
>  
>   BUG_ON(size > MAX_INLINE_CMD_SIZE);
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] drm: drm_pci.h: add missing include

[Daniel Vetter]

On Sun, Mar 12, 2017 at 10:34:07PM -0400, Jérémy Lefaure wrote:
> The structure platform_device is used in drm_pci.h without including
> plaform_device.h so the compiler raises a warning:
> 
> In file included from drivers/gpu/drm/drm_pci.c:29:0:
> ./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’
> declared inside parameter list
>  extern int drm_platform_init(struct drm_driver *driver,
>  struct platform_device *platform_device);
> ^
> 
> Fixes: 23ef59ef6dcc ("drm: Extract drm_pci.h")
> Signed-off-by: Jérémy Lefaure 

Fixed differently by entirely removing the drm_platform_init decl, that
one is now completely gone in linux-next.

Thanks for your patch anyway.
-Daniel

> ---
>  include/drm/drm_pci.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
> index 5081b3e..3697a41 100644
> --- a/include/drm/drm_pci.h
> +++ b/include/drm/drm_pci.h
> @@ -33,6 +33,7 @@
>  #define _DRM_PCI_H_
>  
>  #include 
> +#include 
>  
>  struct drm_dma_handle;
>  struct drm_device;
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 0/3] Tegra Host1x dma_fence/sync_file support

[Daniel Vetter]

On Mon, Mar 13, 2017 at 10:55:01AM +0200, Mikko Perttunen wrote:
> 
> 
> On 10.03.2017 14:43, Daniel Vetter wrote:
> > On Thu, Mar 09, 2017 at 09:09:52PM +0200, Mikko Perttunen wrote:
> > > On 03/09/2017 08:58 PM, Daniel Vetter wrote:
> > > > On Thu, Mar 9, 2017 at 6:57 PM, Mikko Perttunen  
> > > > wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > this series adds support for using sync fences as prefences and
> > > > > postfences for host1x job submissions. The patches are available
> > > > > as a git repository at
> > > > > 
> > > > >   https://github.com/cyndis/linux/tree/host1x-fence-1
> > > > > 
> > > > > and testing code is available at
> > > > > 
> > > > >   https://github.com/cyndis/host1x_test
> > > > > 
> > > > > though you may want to edit the main function to disable the
> > > > > timeout tests for now as they cause a deadlock (not caused
> > > > > by this series; fix upcoming).
> > > > > 
> > > > > Verified on a Jetson TX1; should go on top of the earlier
> > > > > VIC series.
> > > > > 
> > > > > Some additional points:
> > > > > * I noticed that the waitchk_mask field in the submit UAPI is 
> > > > > completely
> > > > >   useless, and has never had any effect in the upstream kernel.
> > > > >   It has also not existed in the downstream kernel for many years.
> > > > >   We could replace it with the flags field if that is deemed
> > > > >   acceptable, though of course it is possible there exists some
> > > > >   application that fills it with some non-zero value.
> > > > 
> > > > If open source userspace (nouveau_dri.so) never used it, then you can
> > > > freely change it. Backwards compat guarantee in drm is only for open
> > > > source userspace (and by implication ofc anything that uses the ioctl
> > > > the same way). See:
> > > > 
> > > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> > > 
> > > nouveau doesn't have any host1x related code - so no, there is no
> > > pre-existing open-source userspace that uses this :)
> > > 
> > > > 
> > > > On that topic, do we have the nouveau patches to enable the
> > > > egl_android extension for this already published?
> > > 
> > > I assume you are referring to EGL_ANDROID_native_fence_sync; I don't know
> > > what nouveau's status is regarding that. With this series, the host1x 
> > > driver
> > > does not yet allow other drivers access to the raw syncpoint values behind
> > > host1x fences but that can be fixed pretty easily if/when nouveau wants to
> > > support native syncpoint waits on Tegra.
> > > Host1x jobs do use native waits already with this series, though.
> > 
> > Well you're adding new uapi to the tegra drm driver, and
> > EGL_ANDROID_native_fence_sync for nouveau seems like the real use-case for
> > this. Which means we need that, before we can merge these patches.
> > 
> > At least I assume that this was done for the nv blob tegra gl driver? Of
> > course if there's some other reasonable use-case, we can use that as open
> > source demonstration thing too.
> > -Daniel
> > 
> 
> The downstream driver doesn't actually support this UAPI; the work was done
> against the testcases linked to above. My goal was to have userspace clients
> use fence fds instead of raw syncpoints, which would be cleaner and less
> error-prone; and allow future extensibility. I suppose this might not be
> enough of a use-case though.
> 
> Now, quickly grepping through mesa and the nouveau kernel driver, it looks
> like there is currently no implementation of EGL_ANDROID_native_fence_sync,
> and no support for SYNC_FILE in nouveau. Regrettably, I currently don't have
> the time to learn these codebases and implement these features, so we might
> have to drop at least patches 2 and 3 and revisit them later.

Yeah demos and test-cases are cool, but for final merging we want the real
thing (in some way or another).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194867] New: DRM BUG while initializing cape verde (2nd card)

[bugzilla-daemon]

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

Bug ID: 194867
   Summary: DRM BUG while initializing cape verde (2nd card)
   Product: Drivers
   Version: 2.5
Kernel Version: 4.11-rc2
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: janpieter.sol...@dommel.be
Regression: No

Created attachment 255215
  --> https://bugzilla.kernel.org/attachment.cgi?id=255215&action=edit
zip file with all listed attachments

There seems to be a logical error while specifying the memory sizes for ttm in
the amdgpu module on the SI architecture:
while the Fiji card boots fine, the Cape Verde card gives a kernel BUG.
dmesg and .config and proposed patch in attachment.
the problem lies in linux/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: the
determination of the p_size is reduced 0 when the page_shift is too big
I managed to work around the problem when changing the sentence
"adev->gds.mem.total_size >> PAGE_SHIFT)" in  amdgpu_ttm_init to
"(adev->gds.mem.total_size >> PAGE_SHIFT) + 1)", and the same for
"(adev->gds.gws.total_size" and "adev->gds.oa.total_size", though I am not sure
this is the correct solution.  The problem is that my SI card is limited in
memory (I guess) and the page_size is 12

-- 
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/5] PCI: add resizeable BAR infrastructure v2

[Christian König]

Am 06.03.2017 um 13:20 schrieb Andy Shevchenko:

On Mon, Mar 6, 2017 at 1:40 PM, Christian König  wrote:

+   for (i = 0; i < nbars; ++i, pos += 8) {

8 is defined somewhere in the spec? (Yes, I understand that is just 64
bits shift)


Yes, it is defined in the spec, see "Figure 7-x1 Resizable BAR Capability".

It just doesn't have a name or something if that's what you are asking for.

I've addressed all other comments in code and will send out the next 
version of the patch set today.


Thanks for the comments,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled

[Jyri Sarha]

Touching HW while clocks are off is a serious error and for instance
breaks suspend functionality. After this patch tilcdc_crtc_update_fb()
always updates the primary plane's framebuffer pointer, increases fb's
reference count and stores vblank event. tilcdc_crtc_update_fb() only
writes the fb's DMA address to HW if the crtc is enabled, as
tilcdc_crtc_enable() takes care of writing the address on enable.

This patch also refactors the tilcdc_crtc_update_fb() a bit. Number of
subsequent small changes had made it almost unreadable. There should
be no other functional changes but checking the CRTC's enable
state. However, the locking goes a bit differently and some of the
redundant checks have been removed in this new version.

The enable_lock should be enough to protect the access to
tilcdc_crtc->enabled. The irq_lock protects the access to last_vblank
and next_fb. The check for vrefresh and last_vblank being valid is
redundant, as the vrefresh should be always valid if the CRTC is
enabled and now last_vblank should be too, because it is initialized
to current time when CRTC raster is enabled. If for some reason the
values are not correctly initialized the division by zero warning is
quite appropriate.

Signed-off-by: Jyri Sarha 
---
Since first version:
  - Restored the accidentally removed comment begin mark to beginning of file
  - Fixed two typos and one broken sentence, pointed out by Tomi Valkeinen

 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 35 +++
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index f80bf93..f2a16fa 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -464,6 +464,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+   unsigned long flags;
 
WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
mutex_lock(&tilcdc_crtc->enable_lock);
@@ -484,7 +485,17 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
tilcdc_write_mask(dev, LCDC_RASTER_CTRL_REG,
  LCDC_PALETTE_LOAD_MODE(DATA_ONLY),
  LCDC_PALETTE_LOAD_MODE_MASK);
+
+   /* There is no real chance for a race here as the time stamp
+* is taken before the raster DMA is started. The spin-lock is
+* taken to have a memory barrier after taking the time-stamp
+* and to avoid a context switch between taking the stamp and
+* enabling the raster.
+*/
+   spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
+   tilcdc_crtc->last_vblank = ktime_get();
tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+   spin_unlock_irqrestore(&tilcdc_crtc->irq_lock, flags);
 
drm_crtc_vblank_on(crtc);
 
@@ -539,7 +550,6 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc, bool 
shutdown)
}
 
drm_flip_work_commit(&tilcdc_crtc->unref_work, priv->wq);
-   tilcdc_crtc->last_vblank = 0;
 
tilcdc_crtc->enabled = false;
mutex_unlock(&tilcdc_crtc->enable_lock);
@@ -602,7 +612,6 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
-   unsigned long flags;
 
WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
 
@@ -614,28 +623,30 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
drm_framebuffer_reference(fb);
 
crtc->primary->fb = fb;
+   tilcdc_crtc->event = event;
 
-   spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
+   mutex_lock(&tilcdc_crtc->enable_lock);
 
-   if (crtc->hwmode.vrefresh && ktime_to_ns(tilcdc_crtc->last_vblank)) {
+   if (tilcdc_crtc->enabled) {
+   unsigned long flags;
ktime_t next_vblank;
s64 tdiff;
 
+   spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
+
next_vblank = ktime_add_us(tilcdc_crtc->last_vblank,
-   100 / crtc->hwmode.vrefresh);
-
+  100 / crtc->hwmode.vrefresh);
tdiff = ktime_to_us(ktime_sub(next_vblank, ktime_get()));
 
if (tdiff < TILCDC_VBLANK_SAFETY_THRESHOLD_US)
tilcdc_crtc->next_fb = fb;
+   else
+   set_scanout(crtc, fb);
+
+   spin_unlock_irqrestore(&tilcdc_crtc->irq_lock, flags);
}
 
-   if (tilcdc_crtc->next_fb != fb)
-   set_scanout(crtc, fb);
-
-   tilcdc_crtc->event = event;
-
-   spin_unlock_irqrestore(&tilcdc_crtc->irq_lock, flags);
+   mutex_unlock(&tilcdc_crtc->enable_lock);
 
return 0;
 }
-- 
1.9.1

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

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

[Neil Armstrong]

On 03/10/2017 10:35 AM, Romain Perier wrote:
> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
> step E. and is kept enabled for later use. This clock should be enabled
> and disabled along with the actual audio stream and not always on (that
> is bad for PM). Futhermore, this might cause sound glitches with some
> HDMI devices, as the CTS+N is forced to zero when the stream is disabled
> while the audio clock is still running.
> 
> This commit adds a parameter to hdmi_audio_enable_clk() that controls
> when the audio sample clock must be enabled or disabled. Then, it moves
> the call to this function into dw_hdmi_audio_enable() and
> dw_hdmi_audio_disable().
> 
> Signed-off-by: Romain Perier 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 

Hi Romain, Russell, Jose,

This is a little out of scope, but I was wondering why the CTS calculation was 
not left
in AUTO mode in the dw-hdmi driver ?

In the Amlogic Vendor tree, they don't set the HDMI_AUD_CTS3_CTS_MANUAL bit and 
leave
the CTS value to 0.

I am wondering if the AUTO feature is specific to newer IP version, or it was 
disabled
in the iMX.6 IP configuration ? or simply tied to the AHB audio specificity.

It would be simpler and smarter to leave the AUTO feature enabled for I2S and 
S/PDIF
input when the IP supports it.

Jose, is there a config bit for this feature, or a specific IP version where it 
landed ?

Anyway, we should really differentiate the AHB audio and I2S/SPDIF audio in the 
CTS/N calculation,
since the I2S/SPDIF depends on an different clock for audio input and the AUTO 
CTS calculation
feature will certainly offer a better clock synchronization.

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