RE: [PATCH 1/2] drm/ttm: don't update global memory count for some special cases

[He, Roger]

It is the first step for the GTT size issue.
Need other patches I am working on it.

Thanks
Roger(Hongbo.He)
-Original Message-
From: Zhou, David(ChunMing) 
Sent: Friday, January 12, 2018 2:46 PM
To: He, Roger ; dri-devel@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: Re: [PATCH 1/2] drm/ttm: don't update global memory count for some 
special cases

Can this fix GTT size issue or not?


Regards,
David Zhou
On 2018年01月12日 14:14, Roger He wrote:
> add input parameter for ttm_dma_unpopulate.
> when ttm_dma_pool_get_pages or ttm_mem_global_alloc_page fail, don't 
> call ttm_mem_global_free_page to update global memory count.
>
> Signed-off-by: Roger He 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
>   drivers/gpu/drm/nouveau/nouveau_bo.c |  2 +-
>   drivers/gpu/drm/radeon/radeon_ttm.c  |  2 +-
>   drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 19 +++
>   drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c   |  2 +-
>   include/drm/ttm/ttm_page_alloc.h |  5 +++--
>   6 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index e4bb435..723ccf1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1046,7 +1046,7 @@ static void amdgpu_ttm_tt_unpopulate(struct 
> ttm_tt *ttm)
>   
>   #ifdef CONFIG_SWIOTLB
>   if (swiotlb_nr_tbl()) {
> - ttm_dma_unpopulate(>ttm, adev->dev);
> + ttm_dma_unpopulate(>ttm, adev->dev, true);
>   return;
>   }
>   #endif
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index ce328ed..3f7c30f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1632,7 +1632,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
>   
>   #if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)
>   if (swiotlb_nr_tbl()) {
> - ttm_dma_unpopulate((void *)ttm, dev);
> + ttm_dma_unpopulate((void *)ttm, dev, true);
>   return;
>   }
>   #endif
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index a0a839b..449cc65 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -789,7 +789,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt 
> *ttm)
>   
>   #ifdef CONFIG_SWIOTLB
>   if (swiotlb_nr_tbl()) {
> - ttm_dma_unpopulate(>ttm, rdev->dev);
> + ttm_dma_unpopulate(>ttm, rdev->dev, true);
>   return;
>   }
>   #endif
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index c7f01a4..4cda764 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -969,7 +969,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev,
>   ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
>   pool->size, ctx);
>   if (unlikely(ret != 0)) {
> - ttm_dma_unpopulate(ttm_dma, dev);
> + ttm_dma_unpopulate(ttm_dma, dev, false);
>   return -ENOMEM;
>   }
>   
> @@ -998,14 +998,14 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev,
>   while (num_pages) {
>   ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
>   if (ret != 0) {
> - ttm_dma_unpopulate(ttm_dma, dev);
> + ttm_dma_unpopulate(ttm_dma, dev, false);
>   return -ENOMEM;
>   }
>   
>   ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
>   pool->size, ctx);
>   if (unlikely(ret != 0)) {
> - ttm_dma_unpopulate(ttm_dma, dev);
> + ttm_dma_unpopulate(ttm_dma, dev, false);
>   return -ENOMEM;
>   }
>   
> @@ -1016,7 +1016,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev,
>   if (unlikely(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
>   ret = ttm_tt_swapin(ttm);
>   if (unlikely(ret != 0)) {
> - ttm_dma_unpopulate(ttm_dma, dev);
> + ttm_dma_unpopulate(ttm_dma, dev, true);
>   return ret;
>   }
>   }
> @@ -1027,7 +1027,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
> device *dev,
>   EXPORT_SYMBOL_GPL(ttm_dma_populate);
>   
>   /* Put all pages in pages list to correct pool to wait for reuse */ 
> -void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device 
> *dev)
> +void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev,
> +

Re: [PATCH 1/2] drm/ttm: don't update global memory count for some special cases

[Chunming Zhou]

Can this fix GTT size issue or not?


Regards,
David Zhou
On 2018年01月12日 14:14, Roger He wrote:

add input parameter for ttm_dma_unpopulate.
when ttm_dma_pool_get_pages or ttm_mem_global_alloc_page fail, don't
call ttm_mem_global_free_page to update global memory count.

Signed-off-by: Roger He 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
  drivers/gpu/drm/nouveau/nouveau_bo.c |  2 +-
  drivers/gpu/drm/radeon/radeon_ttm.c  |  2 +-
  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 19 +++
  drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c   |  2 +-
  include/drm/ttm/ttm_page_alloc.h |  5 +++--
  6 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e4bb435..723ccf1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1046,7 +1046,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
  
  #ifdef CONFIG_SWIOTLB

if (swiotlb_nr_tbl()) {
-   ttm_dma_unpopulate(>ttm, adev->dev);
+   ttm_dma_unpopulate(>ttm, adev->dev, true);
return;
}
  #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index ce328ed..3f7c30f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1632,7 +1632,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
  
  #if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)

if (swiotlb_nr_tbl()) {
-   ttm_dma_unpopulate((void *)ttm, dev);
+   ttm_dma_unpopulate((void *)ttm, dev, true);
return;
}
  #endif
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839b..449cc65 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -789,7 +789,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
  
  #ifdef CONFIG_SWIOTLB

if (swiotlb_nr_tbl()) {
-   ttm_dma_unpopulate(>ttm, rdev->dev);
+   ttm_dma_unpopulate(>ttm, rdev->dev, true);
return;
}
  #endif
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..4cda764 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -969,7 +969,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
pool->size, ctx);
if (unlikely(ret != 0)) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, false);
return -ENOMEM;
}
  
@@ -998,14 +998,14 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev,

while (num_pages) {
ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
if (ret != 0) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, false);
return -ENOMEM;
}
  
  		ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],

pool->size, ctx);
if (unlikely(ret != 0)) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, false);
return -ENOMEM;
}
  
@@ -1016,7 +1016,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev,

if (unlikely(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
ret = ttm_tt_swapin(ttm);
if (unlikely(ret != 0)) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, true);
return ret;
}
}
@@ -1027,7 +1027,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
  EXPORT_SYMBOL_GPL(ttm_dma_populate);
  
  /* Put all pages in pages list to correct pool to wait for reuse */

-void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev)
+void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev,
+   bool update_glob_count)
  {
struct ttm_tt *ttm = _dma->ttm;
struct dma_pool *pool;
@@ -1049,7 +1050,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
continue;
  
  			count++;

-   ttm_mem_global_free_page(ttm->glob->mem_glob,
+   if (update_glob_count)
+   ttm_mem_global_free_page(ttm->glob->mem_glob,
 d_page->p, pool->size);
   

[PATCH v3 8/8] drm: Add and handle new aspect ratios in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul  (V2)
Reviewed-by: Jose Abreu  (V2)

Cc: Ville Syrjala 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: rebase
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c545552..5913d93 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1631,6 +1631,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1692,6 +1698,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index d1a69ff..e7ee7f9 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -89,6 +89,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -98,6 +100,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
2.7.4

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

[PATCH v3 6/8] drm: Expose modes with aspect ratio, only if requested

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's
modelist. This adds CEA modes with aspect ratio information
too, regadless of if user space requested this information or
not.

This patch prunes the modes with aspect-ratio information, from
a connector's modelist, if the user-space has not set the aspect
ratio DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of
modes with aspect-ratio, if the aspect-ratio is not supported.
Instead of straight away pruning such a mode, the mode is
retained with aspect-ratio bits set to zero, provided it is
unique.
---
 drivers/gpu/drm/drm_connector.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b85a774..d968ec3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1502,7 +1502,8 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
 }
 
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+static bool drm_mode_expose_to_userspace(const struct drm_display_mode 
*last_mode,
+const struct drm_display_mode *mode,
 const struct drm_file *file_priv)
 {
/*
@@ -1511,6 +1512,18 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE &&
+   drm_mode_match(mode, last_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
+   return false;
 
return true;
 }
@@ -1522,6 +1535,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
+   struct drm_display_mode last_valid_mode;
int mode_count = 0;
int encoders_count = 0;
int ret = 0;
@@ -1577,9 +1591,12 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->connection = connector->status;
 
/* delayed so we get modes regardless of pre-fill_modes state */
+   memset(_valid_mode, 0, sizeof(struct drm_display_mode));
list_for_each_entry(mode, >modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
+   if (drm_mode_expose_to_userspace(_valid_mode, mode, 
file_priv)) {
mode_count++;
+   drm_mode_copy(_valid_mode, mode);
+   }
 
/*
 * This ioctl is called twice, once to determine how much space is
@@ -1588,10 +1605,16 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp->modes_ptr;
+   memset(_valid_mode, 0, sizeof(struct drm_display_mode));
list_for_each_entry(mode, >modes, head) {
-   if (!drm_mode_expose_to_userspace(mode, file_priv))
+   if (!drm_mode_expose_to_userspace(_valid_mode,
+ mode,
+ file_priv))
continue;
-
+   if (!file_priv->aspect_ratio_allowed)
+   mode->picture_aspect_ratio =
+   HDMI_PICTURE_ASPECT_NONE;
+   drm_mode_copy(_valid_mode, mode);
drm_mode_convert_to_umode(_mode, mode);
if (copy_to_user(mode_ptr + copied,
 _mode, sizeof(u_mode))) {
-- 
2.7.4

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

[PATCH v3 5/8] drm: Handle aspect ratio info in atomic and legacy modeset paths

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

If the user mode does not support aspect-ratio, and requests for
a modeset, then the flag bits representing aspect ratio in the
given user-mode must be rejected.
Similarly, while preparing a user-mode from kernel mode, the
aspect-ratio info must not be given, if aspect-ratio is not
supported by the user.

This patch:
1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
which is set only if the aspect-ratio is supported by the user.
2. discards the aspect-ratio info from the user mode while
preparing kernel mode structure, during modeset, if the
user does not support aspect ratio.
3. avoids setting the aspect-ratio info in user-mode, while
converting user-mode from the kernel-mode.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
-Do not corrupt the current crtc state by updating aspect ratio
on the fly.
---
 drivers/gpu/drm/drm_atomic.c | 61 +---
 drivers/gpu/drm/drm_crtc.c   | 19 ++
 include/drm/drm_atomic.h |  2 ++
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 69ff763..39313e2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -316,6 +316,35 @@ static s32 __user *get_out_fence_for_crtc(struct 
drm_atomic_state *state,
 
return fence_ptr;
 }
+/**
+ * drm_atomic_allow_aspect_ratio_for_kmode
+ * @state: the crtc state
+ * @mode: kernel-internal mode, which is used to create a duplicate mode,
+ * with updated picture aspect ratio.
+ *
+ * Allow the aspect ratio info in the kernel mode only if aspect ratio is
+ * supported.
+ *
+ * RETURNS:
+ * kernel-internal mode with updated picture aspect ratio value.
+ */
+
+struct drm_display_mode*
+drm_atomic_allow_aspect_ratio_for_kmode(struct drm_crtc_state *state,
+   const struct drm_display_mode *mode)
+{
+   struct drm_atomic_state *atomic_state = state->state;
+   struct drm_display_mode *ar_kmode;
+
+   ar_kmode = drm_mode_duplicate(state->crtc->dev, mode);
+   /*
+* If aspect ratio is not supported, set the picture aspect ratio as
+* NONE.
+*/
+   if (atomic_state && !atomic_state->allow_aspect_ratio)
+   ar_kmode->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   return ar_kmode;
+}
 
 /**
  * drm_atomic_set_mode_for_crtc - set mode for CRTC
@@ -341,7 +370,10 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
state->mode_blob = NULL;
 
if (mode) {
-   drm_mode_convert_to_umode(, mode);
+   struct drm_display_mode *ar_mode;
+
+   ar_mode = drm_atomic_allow_aspect_ratio_for_kmode(state, mode);
+   drm_mode_convert_to_umode(, ar_mode);
state->mode_blob =
drm_property_create_blob(state->crtc->dev,
 sizeof(umode),
@@ -349,10 +381,11 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
if (IS_ERR(state->mode_blob))
return PTR_ERR(state->mode_blob);
 
-   drm_mode_copy(>mode, mode);
+   drm_mode_copy(>mode, ar_mode);
state->enable = true;
DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
-mode->name, state);
+ar_mode->name, state);
+   drm_mode_destroy(state->crtc->dev, ar_mode);
} else {
memset(>mode, 0, sizeof(state->mode));
state->enable = false;
@@ -436,6 +469,25 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
 }
 
 /**
+ * drm_atomic_allow_aspect_ratio_for_umode
+ * @state: the crtc state
+ * @umode: userspace mode, whose aspect ratio flag bits are to be updated.
+ *
+ * Allow the aspect ratio info in the userspace mode only if aspect ratio is
+ * supported.
+ */
+void
+drm_atomic_allow_aspect_ratio_for_umode(struct drm_crtc_state *state,
+   struct drm_mode_modeinfo *umode)
+{
+   struct drm_atomic_state *atomic_state = state->state;
+
+   /* Reset the aspect ratio flags if aspect ratio is not supported */
+   if (atomic_state && !atomic_state->allow_aspect_ratio)
+   umode->flags &= (~DRM_MODE_FLAG_PIC_AR_MASK);
+}
+
+/**
  * drm_atomic_crtc_set_property - set property on CRTC
  * @crtc: the drm CRTC to set a property on
  * @state: the state object to update with the new property value
@@ -464,6 +516,9 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
else if (property == config->prop_mode_id) {
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
+   drm_atomic_allow_aspect_ratio_for_umode(state,
+   

[PATCH v3 2/8] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd5379..1818a71 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3025,7 +3025,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks(to_match, hdmi_mode))
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}
 
-- 
2.7.4

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

[PATCH v3 1/8] drm/modes: Introduce drm_mode_match()

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 134 ++--
 include/drm/drm_modes.h |   9 +++
 2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4a3f68a..8128dbb 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_mode_duplicate);
 
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
 /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
  * @mode1: first mode
  * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
  *
  * Check to see if @mode1 and @mode2 are equivalent.
  *
  * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
  */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
 {
if (!mode1 && !mode2)
return true;
@@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
 
-   /* do clock check convert to PICOS so fb modes get matched
-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
return false;
 
-   return drm_mode_equal_no_clocks(mode1, mode2);
+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_mode_equal(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return drm_mode_match(mode1, mode2,
+ 

[PATCH v3 3/8] drm/edid: Fix cea mode aspect ratio handling

[Nautiyal, Ankit K]

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1818a71..3d57c41 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2908,11 +2908,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2926,7 +2930,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2943,11 +2947,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
  */
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2961,7 +2969,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3008,6 +3016,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
 static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3025,7 +3034,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
 
@@ -3042,6 +3051,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  */
 static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3057,7 +3067,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
 
if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
 

[PATCH v3 7/8] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new
flags provided by Ville.
https://patchwork.freedesktop.org/patch/188043/
---
 drivers/gpu/drm/drm_modes.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 8128dbb..c545552 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1050,7 +1050,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);
 }
 EXPORT_SYMBOL(drm_mode_equal);
 
@@ -1621,6 +1622,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1666,6 +1682,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
2.7.4

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

[PATCH v3 4/8] drm: Add DRM client cap for aspect-ratio

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

A new drm client cap is required to enable user-space to advertise
if it supports modes with aspect-ratio. Based on this cap value, the
kernel will take a call on exposing the aspect ratio information in
modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
---
 drivers/gpu/drm/drm_ioctl.c | 5 +
 include/drm/drm_file.h  | 7 +++
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe48..e092550 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..6e0e435 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,13 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True if client has asked to expose the aspect-ratio flags with mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..fe5f531 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will expose aspect ratio flags to userspace.
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

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

[PATCH v3 0/8] Aspect ratio support in DRM layer

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in
translation during a user->kernel mode or vice versa.

The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out of which 2 patches were reverted due to lack of drm client
protection while loading the aspect information.

This patch series also includes 3 patches from Ville Syrjälä's series for
'Info-frame cleanup and fixes' https://patchwork.freedesktop.org/series/33730/
which fixes the mode matching mechanism via flags.

This patch series, adds a DRM client option for aspect ratio, and loads aspect
ratio flags, only when the client sets this cap. 
Also, to test this patch series there is a userspace implementation by
Ankit Nautiyal in Wayland/weston layer:
https://patchwork.freedesktop.org/patch/188125/
(Which is already ACK'ed by wayland community.)
This, helps us in passing HDMI compliance test cases like 7-27, where the test
equipment applies a CEA mode, and expects the exact VIC in the AVI infoframes.

Ankit Nautiyal (3):
  drm: Add DRM client cap for aspect-ratio
  drm: Handle aspect ratio info in atomic and legacy modeset paths
  drm: Expose modes with aspect ratio, only if requested

Sharma, Shashank (2):
  drm: Add aspect ratio parsing in DRM layer
  drm: Add and handle new aspect ratios in DRM layer

Ville Syrjälä (3):
  drm/modes: Introduce drm_mode_match()
  drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
  drm/edid: Fix cea mode aspect ratio handling

 drivers/gpu/drm/drm_atomic.c|  61 +-
 drivers/gpu/drm/drm_connector.c |  31 ++-
 drivers/gpu/drm/drm_crtc.c  |  19 +
 drivers/gpu/drm/drm_edid.c  |  18 +++-
 drivers/gpu/drm/drm_ioctl.c |   5 ++
 drivers/gpu/drm/drm_modes.c | 177 +---
 include/drm/drm_atomic.h|   2 +
 include/drm/drm_file.h  |   7 ++
 include/drm/drm_modes.h |   9 ++
 include/uapi/drm/drm.h  |   7 ++
 include/uapi/drm/drm_mode.h |   6 ++
 11 files changed, 300 insertions(+), 42 deletions(-)

-- 
2.7.4

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

[PATCH 2/2] drm/ttm: only free pages rather than update global memory count together

[Roger He]

if ttm_get_pages or ttm_mem_global_alloc_page fail, should not update
global memory count.

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

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 0eab24e..aebabf1 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1075,7 +1075,8 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
ret = ttm_get_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
ttm->caching_state);
if (unlikely(ret != 0)) {
-   ttm_pool_unpopulate(ttm);
+   ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
+   ttm->caching_state);
return ret;
}
 
@@ -1083,7 +1084,8 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct 
ttm_operation_ctx *ctx)
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
PAGE_SIZE, ctx);
if (unlikely(ret != 0)) {
-   ttm_pool_unpopulate(ttm);
+   ttm_put_pages(ttm->pages, ttm->num_pages,
+   ttm->page_flags, ttm->caching_state);
return -ENOMEM;
}
}
-- 
2.7.4

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

[PATCH 1/2] drm/ttm: don't update global memory count for some special cases

[Roger He]

add input parameter for ttm_dma_unpopulate.
when ttm_dma_pool_get_pages or ttm_mem_global_alloc_page fail, don't
call ttm_mem_global_free_page to update global memory count.

Signed-off-by: Roger He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c |  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c  |  2 +-
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 19 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c   |  2 +-
 include/drm/ttm/ttm_page_alloc.h |  5 +++--
 6 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e4bb435..723ccf1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1046,7 +1046,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
 
 #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
-   ttm_dma_unpopulate(>ttm, adev->dev);
+   ttm_dma_unpopulate(>ttm, adev->dev, true);
return;
}
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index ce328ed..3f7c30f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1632,7 +1632,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
 
 #if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)
if (swiotlb_nr_tbl()) {
-   ttm_dma_unpopulate((void *)ttm, dev);
+   ttm_dma_unpopulate((void *)ttm, dev, true);
return;
}
 #endif
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839b..449cc65 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -789,7 +789,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
 
 #ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
-   ttm_dma_unpopulate(>ttm, rdev->dev);
+   ttm_dma_unpopulate(>ttm, rdev->dev, true);
return;
}
 #endif
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c7f01a4..4cda764 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -969,7 +969,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
pool->size, ctx);
if (unlikely(ret != 0)) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, false);
return -ENOMEM;
}
 
@@ -998,14 +998,14 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
while (num_pages) {
ret = ttm_dma_pool_get_pages(pool, ttm_dma, i);
if (ret != 0) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, false);
return -ENOMEM;
}
 
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
pool->size, ctx);
if (unlikely(ret != 0)) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, false);
return -ENOMEM;
}
 
@@ -1016,7 +1016,7 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
if (unlikely(ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
ret = ttm_tt_swapin(ttm);
if (unlikely(ret != 0)) {
-   ttm_dma_unpopulate(ttm_dma, dev);
+   ttm_dma_unpopulate(ttm_dma, dev, true);
return ret;
}
}
@@ -1027,7 +1027,8 @@ int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct 
device *dev,
 EXPORT_SYMBOL_GPL(ttm_dma_populate);
 
 /* Put all pages in pages list to correct pool to wait for reuse */
-void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev)
+void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct device *dev,
+   bool update_glob_count)
 {
struct ttm_tt *ttm = _dma->ttm;
struct dma_pool *pool;
@@ -1049,7 +1050,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
struct device *dev)
continue;
 
count++;
-   ttm_mem_global_free_page(ttm->glob->mem_glob,
+   if (update_glob_count)
+   ttm_mem_global_free_page(ttm->glob->mem_glob,
 d_page->p, pool->size);
ttm_dma_page_put(pool, d_page);
}
@@ -1094,11 +1096,12 @@ void 

Re: [PATCH v2 05/12] drm/bridge/synopsys: dw-hdmi: Add deinit callback

[Chen-Yu Tsai]

On Thu, Jan 11, 2018 at 3:25 AM, Jernej Skrabec  wrote:
> Some SoCs, like Allwinner A83T, have to do additional cleanup when
> HDMI driver unloads. When using DW HDMI through DRM bridge API, there is
> no place to store driver's private data so it can be accessed in unbind
> function. Because of that, add deinit function which is called at the
> very end, so drivers can do a proper cleanup.
>
> Signed-off-by: Jernej Skrabec 

8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata"), which is
already in drm-misc-next, is a much saner solution. :)

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

Re: [RFC][PATCH 5/5] drm_hwcomposer: HACK: Fix tearing on hikey/hikey960

[John Stultz]

On Tue, Jan 9, 2018 at 10:05 PM, John Stultz  wrote:
> When using drm_hwcomposer with the hikey/hikey960 boards, the
> resulting display shows lots of tearing.
>
> I'm not much of an expert in how this code should work, but it
> seems that we never call sync_wait(), and thus don't seem to be
> handling the fences properly? I'm not sure.
>
> Anyway, in a daze, I started cutting out code trying to make
> sure we call the CreateNextTimelineFence() and
> fb.set_release_fence_fd().
>
> After doing so the tearing went away. I'm really not sure
> what is wrong that requires these hacks. It may be the
> hikey/hikey960 drm driver is incorrectly reporting or
> handling something?
>
> We do only have a single plane and no hardware compositing on
> the boards, so we are having to force the gpu to do all the
> compositing.
>
> Any ideas for what a proper fix here would be? Or even just
> hints on why this might make things work?

So I've maybe started to understand things a bit (though probably not
much) more here. Again, my apologies for being very new to all this.

This patch actually isn't necessary on the HiKey960, as in the mix of
testing both boards, I didn't get it working until after the HiKey
board so I incorrectly assumed this would be needed.

This patch is really only useful to avoid the tearing I see with the
HiKey board.

The core issue on HiKey is that in
DrmDisplayCompositor::PrepareFrame(), when we initialize the
precompositor_ to a new GLWorkerCompositor, the eglCreateContext()
call fails because we're asking for version 3, which the HiKey's
utgard mali implementation doesn't support (thus why the
pre_compositor_->Composite() call always fails in ApplySquash() -
though still need to figure out why squash_regions are empty).

Asking for version 2 gets us along a bit further, but then I hit other
trouble with the eglMakeCurrent() call in BeginContext, as passing
EGL_NO_SURFACE, EGL_NO_SURFACE without EGL_NO_CONTEXT seems to trigger
an error in the mali GL implementation. However, using EGL_NO_CONTEXT
causes surfaceflinger to crash, so I just hacked it up to skip the
eglMakeCurrent call to keep things going.

The next issue that I run into is maybe the more problematic one: The
vertex and fragment shaders in the glworker.c are marked as "#version
300 es", which utgard can't handle (apparently it maxes out at
"#version 100", but can't seemingly handle other syntax like "in").

So the bigger question I guess I have is: Is the drm_hwcomposer as a
project targeting a certain minimal GLES version, or is it open to
supporting older/limited hardware like the utgard level mali?  I can
look into trying to figure out if what needs to be done can be done in
a simpler shader language, or alternatively we can add fallback code
to still allow for fence handling for tear-free functionality w/o the
GL compositor (which is basically what this hack patch in-effect
allows).

Are either of these preferred? Or none?

Thoughts?

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

Re: [PATCH] drm/virtio: Add window server support

[Dave Airlie]

>
> this work is based on the virtio_wl driver in the ChromeOS kernel by
> Zach Reizner, currently at:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
>
> There's two features missing in this patch when compared with virtio_wl:
>
> * Allow the guest access directly host memory, without having to resort
> to TRANSFER_TO_HOST
>
> * Pass FDs from host to guest (Wayland specifies that the compositor
> shares keyboard data with the guest via a shared buffer)
>
> I plan to work on this next, but I would like to get some comments on
> the general approach so I can better choose which patch to follow.

Shouldn't qemu expose some kind of capability to enable this so we know to
look for the extra vqs?

What happens if you run this on plain qemu, does it fallback correctly?

Are there any scenarios where we don't want to expose this API because there
is nothing to back it.

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

[PATCH] drm: rcar-du: Enable VSP compositor by default on Gen3

[Laurent Pinchart]

On Gen3 hardware the VSP compositor is required for display. Enable it
by default in the kernel configuration. The option is kept
user-configurable for testing purpose on Gen2 platforms.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1d6f1b849287..2b104daf56eb 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -27,7 +27,8 @@ config DRM_RCAR_LVDS
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
 config DRM_RCAR_VSP
-   bool "R-Car DU VSP Compositor Support"
+   bool "R-Car DU VSP Compositor Support" if ARM
+   default y if ARM64
depends on DRM_RCAR_DU
depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m)
help
-- 
Regards,

Laurent Pinchart

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

[Bug 104592] [r600g] Rejected CS when using dolphin's GPU texture decoder

[bugzilla-daemon]

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

Bug ID: 104592
   Summary: [r600g] Rejected CS when using dolphin's GPU texture
decoder
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: megwa...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136672
  --> https://bugs.freedesktop.org/attachment.cgi?id=136672=edit
Apitrace of dolphin

Dolphin emulator's GPU texture decoder is now supported, as it requires compute
shaders. It however misrender and the line 
"The kernel rejected CS, see dmesg for more information"
is repetitively printed.

I have the folowwing lines repeated in dmesg:
"[ 4885.617750] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
[ 4885.624044] radeon :01:00.0: evergreen_cs_track_check:982 mask
0x00FF | 0x00FF no cb for 1
[ 4885.624047] radeon :01:00.0: evergreen_packet3_check:1908 invalid cmd
stream"

I have attached an apitrace of dolphin. The trace renders fine on Skylake. It
seems that the first rejected CS is at frame 0, call 2731.
(glDrawRangeElementsBaseVertex())

Tested on HD 5770.

-- 
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 104591] [r600g] Compute demos and pigilt tests broken on REDWOOD, works fine on JUNIPER

[bugzilla-daemon]

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

Bug ID: 104591
   Summary: [r600g] Compute demos and pigilt tests broken on
REDWOOD, works fine on JUNIPER
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: megwa...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 136671
  --> https://bugs.freedesktop.org/attachment.cgi?id=136671=edit
"pigilt run -t compute" left:REDWOOD right:JUNIPER

Some games and demos which use compute shaders misrender on my HD 5670
(REDWOOD), but works fine on my HD 5770 (JUNIPER). Tested with various Ogre
demos and Supertuxkart.

When running pigilt's compute tests ("pigilt run -t compute") 19 tests doesn't
pass on REDWOOD but pass on JUNIPER. The comparison between those 2 pigilt runs
is attached.

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

[git pull] drm fixes for v4.15-rc8

[Dave Airlie]

Hey Linus,

Hopefully the final set of fixes,

Nouveau regression fix,
Tegra regression fix,
vmwgfx crasher + freed data leak
i915 KASAN use after free fix, whitelist register to avoid hang fix, GVT fixes
vc4 irq/pm fix

Dave.

The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:

  Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.15-rc8

for you to fetch changes up to fee6c614a5c20783a5c28c2671c186c06e19c215:

  Merge tag 'drm-intel-fixes-2018-01-11-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-01-12
11:48:06 +1000)


i915, tegra, nouveau, vc4 and vmwgfx fixes


Changbin Du (1):
  drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser

Chris Wilson (1):
  drm/i915: Don't adjust priority on an already signaled fence

Dan Carpenter (1):
  drm/vmwgfx: Potential off by one in vmw_view_add()

Dave Airlie (5):
  Merge tag 'drm-misc-fixes-2018-01-08' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm/tegra/for-4.15-rc8' of
git://anongit.freedesktop.org/tegra/linux into drm-fixes
  Merge branch 'vmwgfx-fixes-4.15' of
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-01-11-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Jani Nikula (1):
  Merge tag 'gvt-fixes-2018-01-08' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Kenneth Graunke (1):
  drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

Rob Clark (1):
  drm/nouveau/disp/gf119: add missing drive vfunc ptr

Stefan Schake (1):
  drm/vc4: Move IRQ enable to PM path

Thierry Reding (1):
  drm/tegra: sor: Fix hang on Tegra124 eDP

Thomas Hellstrom (1):
  drm/vmwgfx: Don't cache framebuffer maps

Zhi Wang (1):
  drm/i915/gvt: Clear the shadow page table entry after post-sync

 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  4 +--
 drivers/gpu/drm/i915/gvt/gtt.c |  5 ++-
 drivers/gpu/drm/i915/i915_gem.c|  2 +-
 drivers/gpu/drm/i915/i915_reg.h|  2 ++
 drivers/gpu/drm/i915/intel_engine_cs.c |  5 +++
 drivers/gpu/drm/i915/intel_lrc.c   |  3 ++
 .../gpu/drm/nouveau/nvkm/engine/disp/sorgf119.c|  1 +
 drivers/gpu/drm/tegra/sor.c|  3 ++
 drivers/gpu/drm/vc4/vc4_irq.c  |  3 --
 drivers/gpu/drm/vc4/vc4_v3d.c  |  3 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c|  2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  6 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   | 41 +++---
 14 files changed, 39 insertions(+), 43 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: rcar-du: lvds: refactor LVDS startup

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Thursday, 11 January 2018 18:54:33 EET Sergei Shtylyov wrote:
> After the recent correction of the R-Car gen3 LVDCR1 value, already similar
> enough at their  ends rcar_du_lvdsenc_start_gen{2|3}() started asking for a
> merge and it's becoming actually necessary with the addition the R-Car V3M
> (R8A77970) support -- this  gen3 SoC  has gen2-like LVDPLLCR layout.
> 
> BTW, such a merge saves 72 bytes of the object code with AArch64 gcc 4.8.5.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  132 +++---
>  1 file changed, 54 insertions(+), 78 deletions(-)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -39,98 +39,41 @@ static void rcar_lvds_write(struct rcar_
>   iowrite32(data, lvds->mmio + reg);
>  }
> 
> -static void rcar_du_lvdsenc_start_gen2(struct rcar_du_lvdsenc *lvds,
> -struct rcar_du_crtc *rcrtc)
> +static u32 rcar_lvds_gen2_lvdpllcr(unsigned int freq)
>  {
> - const struct drm_display_mode *mode = >crtc.mode;
> - unsigned int freq = mode->clock;
> - u32 lvdcr0;
> - u32 pllcr;
> + u32 lvdpllcr;
> 
> - /* PLL clock configuration */
>   if (freq < 39000)
> - pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
> + lvdpllcr = LVDPLLCR_PLLDLYCNT_38M;
>   else if (freq < 61000)
> - pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
> + lvdpllcr = LVDPLLCR_PLLDLYCNT_60M;
>   else if (freq < 121000)
> - pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | 
> LVDPLLCR_PLLDLYCNT_121M;
> + lvdpllcr = LVDPLLCR_PLLDLYCNT_121M;
>   else
> - pllcr = LVDPLLCR_PLLDLYCNT_150M;
> -
> - rcar_lvds_write(lvds, LVDPLLCR, pllcr);
> -
> - /*
> -  * Select the input, hardcode mode 0, enable LVDS operation and turn
> -  * bias circuitry on.
> -  */
> - lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
> - if (rcrtc->index == 2)
> - lvdcr0 |= LVDCR0_DUSEL;
> - rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> + return LVDPLLCR_PLLDLYCNT_150M;
> 
> - /* Turn all the channels on. */
> - rcar_lvds_write(lvds, LVDCR1,
> - LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> - LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
> -
> - /*
> -  * Turn the PLL on, wait for the startup delay, and turn the output
> -  * on.
> -  */
> - lvdcr0 |= LVDCR0_PLLON;
> - rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> -
> - usleep_range(100, 150);
> -
> - lvdcr0 |= LVDCR0_LVRES;
> - rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> + return lvdpllcr | LVDPLLCR_CEEN | LVDPLLCR_COSEL;
>  }
> 
> -static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc *lvds,
> -struct rcar_du_crtc *rcrtc)
> +static u32 rcar_lvds_gen3_lvdpllcr(unsigned int freq)
>  {
> - const struct drm_display_mode *mode = >crtc.mode;
> - unsigned int freq = mode->clock;
> - u32 lvdcr0;
> - u32 pllcr;
> -
> - /* PLL clock configuration */
>   if (freq < 42000)
> - pllcr = LVDPLLCR_PLLDIVCNT_42M;
> + return LVDPLLCR_PLLDIVCNT_42M;
>   else if (freq < 85000)
> - pllcr = LVDPLLCR_PLLDIVCNT_85M;
> + return LVDPLLCR_PLLDIVCNT_85M;
>   else if (freq < 128000)
> - pllcr = LVDPLLCR_PLLDIVCNT_128M;
> - else
> - pllcr = LVDPLLCR_PLLDIVCNT_148M;
> -
> - rcar_lvds_write(lvds, LVDPLLCR, pllcr);
> -
> - /* Turn all the channels on. */
> - rcar_lvds_write(lvds, LVDCR1,
> - LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> - LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
> -
> - /*
> -  * Turn the PLL on, set it to LVDS normal mode, wait for the startup
> -  * delay and turn the output on.
> -  */
> - lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
> - rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> -
> - lvdcr0 |= LVDCR0_PWD;
> - rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> + return LVDPLLCR_PLLDIVCNT_128M;
> 
> - usleep_range(100, 150);
> -
> - lvdcr0 |= LVDCR0_LVRES;
> - rcar_lvds_write(lvds, LVDCR0, lvdcr0);
> + return LVDPLLCR_PLLDIVCNT_148M;
>  }
> 
>  static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
>struct rcar_du_crtc *rcrtc)
>  {
> - u32 lvdhcr;
> + u32 lvdhcr, lvdpllcr, lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;

Please declare variables on separate lines. Especially having lvdcr0 on a line 
of its own will make it clearer.

> + 

Re: [PATCH 03/19] drm/exynos: Use the alpha format helper

[Inki Dae]

2018년 01월 09일 19:56에 Maxime Ripard 이(가) 쓴 글:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Kyungmin Park 
> Cc: Seung-Woo Kim 
> Signed-off-by: Maxime Ripard 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index dc5d79465f9b..d7339a6d072c 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -179,18 +179,6 @@ static const u8 filter_cr_horiz_tap4[] = {
>   70, 59, 48, 37, 27, 19, 11, 5,
>  };
>  
> -static inline bool is_alpha_format(unsigned int pixel_format)
> -{
> - switch (pixel_format) {
> - case DRM_FORMAT_ARGB:
> - case DRM_FORMAT_ARGB1555:
> - case DRM_FORMAT_ARGB:
> - return true;
> - default:
> - return false;
> - }
> -}
> -
>  static inline u32 vp_reg_read(struct mixer_context *ctx, u32 reg_id)
>  {
>   return readl(ctx->vp_regs + reg_id);
> @@ -625,7 +613,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
>   mixer_reg_write(ctx, MXR_GRAPHIC_BASE(win), dma_addr);
>  
>   mixer_cfg_layer(ctx, win, priority, true);
> - mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
> + mixer_cfg_gfx_blend(ctx, win, drm_format_has_alpha(fb->format->format));
>  
>   /* layer update mandatory for mixer 16.0.33.0 */
>   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: rcar-du: add R8A77970 support

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Thursday, 11 January 2018 18:54:35 EET Sergei Shtylyov wrote:
> Add support for the R-Car  V3M  (R8A77970) SoC to the DU driver (this SoC
> has only  1 display port). Note that there are some differences  with the
> other R-Car gen3 SoCs in the LVDS encoder part, e.g. LVDPLLCR has the same
> layout  as  on the R-Car gen2 SoCs...
> 
> Signed-off-by: Sergei Shtylyov 

Could you please rebase this series on top of the LVDS rework posted as 
"[PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver" (https://
www.spinics.net/lists/dri-devel/msg161931.html) ? It should make it easier to 
implement support for V3M. Please then split the DU and LVDS drivers changes 
in two patches.

> ---
>  Documentation/devicetree/bindings/display/renesas,du.txt |1

Please split the DT bindings changes to a separate patch.

>  drivers/gpu/drm/rcar-du/rcar_du_drv.c|   23 +++
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h|1
>  drivers/gpu/drm/rcar-du/rcar_du_group.c  |   10 +++---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c|   20 +++
>  5 files changed, 45 insertions(+), 10 deletions(-)
> 
> Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
> ===
> --- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ linux/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -13,6 +13,7 @@ Required Properties:
>  - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
>  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
> +- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
> 
>- reg: A list of base address and length of each memory resource, one for
> each entry in the reg-names property.

You also need to update the ports table further down in this file.

> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -258,6 +258,28 @@ static const struct rcar_du_device_info
>   .dpll_ch =  BIT(1),
>  };
> 
> +static const struct rcar_du_device_info rcar_du_r8a77970_info = {
> + .gen = 3,
> + .model = R8A77970,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> +   | RCAR_DU_FEATURE_EXT_CTRL_REGS
> +   | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .num_crtcs = 1,
> + .routes = {
> + /* R8A77970 has one RGB output and one LVDS output. */
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(0),
> + .port = 1,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 0,
> + },

All the other SoCs have DPAD0 as port 0. Unless there's a specific need for a 
different implementation with V3M I'd keep the same order.

> + },
> + .num_lvds = 1,
> + .dpll_ch  = BIT(1),

This doesn't seem to be correct, there's no DPLL in V3M.

> +};
> +
>  static const struct of_device_id rcar_du_of_table[] = {
>   { .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
>   { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> @@ -269,6 +291,7 @@ static const struct of_device_id rcar_du
>   { .compatible = "renesas,du-r8a7794", .data = _du_r8a7794_info },
>   { .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
>   { .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
> + { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
>   { }
>  };
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -59,6 +59,7 @@ enum rcar_du_model {
>   R8A7794,
>   R8A7795,
>   R8A7796,
> + R8A77970,
>  };
> 
>  /*
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_group.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_group.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_group.c
> @@ -133,10 +133,12 @@ static void rcar_du_group_setup(struct r
>   rcar_du_group_write(rgrp, DORCR, DORCR_PG1D_DS1 | DORCR_DPRS);
> 
>   /* Apply planes to CRTCs association. */
> - mutex_lock(>lock);
> - rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
> - rgrp->dptsr_planes);
> - mutex_unlock(>lock);
> + if (rcdu->info->num_crtcs > 1) {
> + mutex_lock(>lock);
> + rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 

[PATCH 09/10] arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
 .../boot/dts/renesas/r8a7795-es1-salvator-x.dts|  3 +-
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  3 +-
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   | 35 ++
 5 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
index 9ef9a4e5f376..0dda1c0ed1ce 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1-salvator-x.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index 0afe777973de..f0d6528c05eb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -44,11 +44,10 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 < 3>,
 < 4>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 00ad1ab53a7d..e34b986185d4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index 79e8b65622db..31f2abaa90aa 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -43,12 +43,11 @@
 < CPG_MOD 723>,
 < CPG_MOD 722>,
 < CPG_MOD 721>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2", "du.3",
  "dclkin.0", "dclkin.1", "dclkin.2", "dclkin.3";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 15ef292a8d9f..d6c423988ab6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2077,9 +2077,8 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7795";
-   reg = <0 0xfeb0 0 0x8>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x8>;
+   reg-names = "du";
interrupts = ,
 ,
 ,
@@ -2087,9 +2086,8 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0  0  0  1>;
status = "disabled";
 
@@ -2117,6 +2115,31 @@
port@3 {
reg = <3>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+

[PATCH 08/10] ARM: dts: r8a7793: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7793-gose.dts | 10 +++---
 arch/arm/boot/dts/r8a7793.dtsi | 35 +--
 2 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts 
b/arch/arm/boot/dts/r8a7793-gose.dts
index 51b3ffac8efa..c6121f9b72a8 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -303,10 +303,9 @@
pinctrl-names = "default";
status = "okay";
 
-   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -314,6 +313,11 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   ports {
port@1 {
lvds_connector: endpoint {
};
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 0cd1035de1a4..c044291bb2a2 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -976,15 +976,13 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7793";
-   reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x4>;
+   reg-names = "du";
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-< CPG_MOD 723>,
-< CPG_MOD 726>;
-   clock-names = "du.0", "du.1", "lvds.0";
+< CPG_MOD 723>;
+   clock-names = "du.0", "du.1";
status = "disabled";
 
ports {
@@ -999,6 +997,31 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7793";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

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

[PATCH 10/10] arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |  3 +-
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   | 35 ++
 3 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index daee1f1a3f68..21bd679062f3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -33,10 +33,9 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 727>,
 < 1>,
 < 3>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2",
  "dclkin.0", "dclkin.1", "dclkin.2";
 };
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts 
b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index 4088bea8d62c..ecbfbcb65df3 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -32,11 +32,10 @@
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 727>,
 < 1>,
 <_clk>,
 < 2>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0",
+   clock-names = "du.0", "du.1", "du.2",
  "dclkin.0", "dclkin.1", "dclkin.2";
 };
 
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index f2b2e40c655e..ed30660c367b 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1826,17 +1826,15 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7796";
-   reg = <0 0xfeb0 0 0x7>,
- <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x7>;
+   reg-names = "du";
interrupts = ,
 ,
 ;
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
-< CPG_MOD 722>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0";
+< CPG_MOD 722>;
+   clock-names = "du.0", "du.1", "du.2";
status = "disabled";
 
vsps = <  >;
@@ -1859,6 +1857,31 @@
port@2 {
reg = <2>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7796";
+   reg = <0 0xfeb9 0 0x14>;
+   clocks = < CPG_MOD 727>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

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

[PATCH 04/10] drm: rcar-du: Convert LVDS encoder code to bridge driver

[Laurent Pinchart]

The LVDS encoders used to be described in DT as part of the DU. They now
have their own DT node, linked to the DU using the OF graph bindings.
This allows moving internal LVDS encoder support to a separate driver
modelled as a DRM bridge. Backward compatibility is retained as legacy
DT is patched live to move to the new bindings.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig   |   4 +-
 drivers/gpu/drm/rcar-du/Makefile  |   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c |  93 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  24 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 270 ---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |  64 
 drivers/gpu/drm/rcar-du/rcar_lvds.c   | 554 ++
 12 files changed, 591 insertions(+), 649 deletions(-)
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds.c

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index e3193ebd3ced..1d6f1b849287 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -19,8 +19,8 @@ config DRM_RCAR_DW_HDMI
  Enable support for R-Car Gen3 internal HDMI encoder.
 
 config DRM_RCAR_LVDS
-   bool "R-Car DU LVDS Encoder Support"
-   depends on DRM_RCAR_DU
+   tristate "R-Car DU LVDS Encoder Support"
+   depends on DRM && DRM_BRIDGE && OF
select DRM_PANEL
select OF_OVERLAY
help
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf457bef1f2..d2ae53efd982 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,14 +4,12 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_encoder.o \
 rcar_du_group.o \
 rcar_du_kms.o \
-rcar_du_lvdscon.o \
 rcar_du_of.o \
 rcar_du_of_lvds.dtb.o \
 rcar_du_plane.o
 
-rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
-
 rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
 
 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
 obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
+obj-$(CONFIG_DRM_RCAR_LVDS)+= rcar_lvds.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 6e02c762a557..06a3fbdd728a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -29,6 +29,7 @@
 
 #include "rcar_du_drv.h"
 #include "rcar_du_kms.h"
+#include "rcar_du_of.h"
 #include "rcar_du_regs.h"
 
 /* 
-
@@ -74,7 +75,6 @@ static const struct rcar_du_device_info rzg1_du_r8a7745_info 
= {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7779_info = {
@@ -95,14 +95,13 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
-   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
.num_crtcs = 3,
.routes = {
/*
@@ -164,7 +163,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7792_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7794_info = {
@@ -186,7 +184,6 @@ static const struct rcar_du_device_info 
rcar_du_r8a7794_info = {
.port = 1,
},
},
-   .num_lvds = 0,
 };
 
 static const struct rcar_du_device_info rcar_du_r8a7795_info = {
@@ -434,7 +431,19 @@ static struct platform_driver rcar_du_platform_driver = {
},
 };
 
-module_platform_driver(rcar_du_platform_driver);
+static int __init rcar_du_init(void)
+{
+   rcar_du_of_init(rcar_du_of_table);
+
+   return platform_driver_register(_du_platform_driver);
+}
+module_init(rcar_du_init);
+
+static void __exit rcar_du_exit(void)
+{
+   platform_driver_unregister(_du_platform_driver);
+}
+module_exit(rcar_du_exit);
 
 MODULE_AUTHOR("Laurent Pinchart 

[PATCH 07/10] ARM: dts: r8a7791: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 10 --
 arch/arm/boot/dts/r8a7791-porter.dts  | 16 +---
 arch/arm/boot/dts/r8a7791.dtsi| 35 +--
 3 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index e164eda69baf..5a0f87ed7f16 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -332,8 +332,7 @@
 
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -341,6 +340,13 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
port@1 {
lvds_connector: endpoint {
};
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index 9a02d03b23c2..e6d02839d636 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -419,10 +419,9 @@
pinctrl-names = "default";
status = "okay";
 
-   clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 726>,
+   clocks = < CPG_MOD 724>, < CPG_MOD 723>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "lvds.0",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -433,6 +432,17 @@
};
 };
 
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
+   lvds_connector: endpoint {
+   };
+   };
+   };
+};
+
 _sound {
pinctrl-0 = <_pins _clk_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 67831d0405f3..c2415a558997 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1103,15 +1103,13 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7791";
-   reg = <0 0xfeb0 0 0x4>,
- <0 0xfeb9 0 0x1c>;
-   reg-names = "du", "lvds.0";
+   reg = <0 0xfeb0 0 0x4>;
+   reg-names = "du";
interrupts = ,
 ;
clocks = < CPG_MOD 724>,
-< CPG_MOD 723>,
-< CPG_MOD 726>;
-   clock-names = "du.0", "du.1", "lvds.0";
+< CPG_MOD 723>;
+   clock-names = "du.0", "du.1";
status = "disabled";
 
ports {
@@ -1126,6 +1124,31 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7791";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
};
};
};
-- 
Regards,

Laurent Pinchart

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

[PATCH 05/10] ARM: dts: porter: Fix HDMI output routing

[Laurent Pinchart]

The HDMI encoder is connected to the RGB output of the DU, which is
port@0, not port@1. Fix the incorrect DT description.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts 
b/arch/arm/boot/dts/r8a7791-porter.dts
index eb374956294f..9a02d03b23c2 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -425,7 +425,7 @@
  "dclkin.0", "dclkin.1";
 
ports {
-   port@1 {
+   port@0 {
endpoint {
remote-endpoint = <_in>;
};
-- 
Regards,

Laurent Pinchart

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

[PATCH 06/10] ARM: dts: r8a7790: Convert to new LVDS DT bindings

[Laurent Pinchart]

The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 22 ++---
 arch/arm/boot/dts/r8a7790.dtsi  | 61 -
 2 files changed, 71 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 7d5cd01069a3..f84963cb6785 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -317,10 +317,8 @@
status = "okay";
 
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
-< CPG_MOD 726>, < CPG_MOD 725>,
 <_clk>, <_clk>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1",
- "dclkin.0", "dclkin.1";
+   clock-names = "du.0", "du.1", "du.2", "dclkin.0", "dclkin.1";
 
ports {
port@0 {
@@ -328,12 +326,26 @@
remote-endpoint = <_in>;
};
};
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
port@1 {
endpoint {
remote-endpoint = <_in>;
};
};
-   port@2 {
+   };
+};
+
+ {
+   status = "okay";
+
+   ports {
+   port@1 {
lvds_connector: endpoint {
};
};
@@ -689,7 +701,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
-   remote-endpoint = <_out_lvds0>;
+   remote-endpoint = <_out>;
};
};
 
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 62baabd757b6..ccb3e4fb36ed 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1067,17 +1067,14 @@
 
du: display@feb0 {
compatible = "renesas,du-r8a7790";
-   reg = <0 0xfeb0 0 0x7>,
- <0 0xfeb9 0 0x1c>,
- <0 0xfeb94000 0 0x1c>;
-   reg-names = "du", "lvds.0", "lvds.1";
+   reg = <0 0xfeb0 0 0x7>;
+   reg-names = "du";
interrupts = ,
 ,
 ;
clocks = < CPG_MOD 724>, < CPG_MOD 723>,
-< CPG_MOD 722>, < CPG_MOD 726>,
-< CPG_MOD 725>;
-   clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1";
+< CPG_MOD 722>;
+   clock-names = "du.0", "du.1", "du.2";
status = "disabled";
 
ports {
@@ -1092,11 +1089,61 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+   remote-endpoint = <_in>;
};
};
port@2 {
reg = <2>;
du_out_lvds1: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7790";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
+
+   lvds1: lvds@feb94000 {
+   compatible = "renesas,lvds-r8a7790";
+   reg = <0 0xfeb94000 0 0x1c>;
+   clocks = < CPG_MOD 725>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds1_in: endpoint {
+   remote-endpoint = <_out_lvds1>;
+   };
+   };
+   port@1 {
+

[PATCH 02/10] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings, representing
them as part of the DU is deprecated.

Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/display/renesas,du.txt | 26 +-
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt 
b/Documentation/devicetree/bindings/display/renesas,du.txt
index cd48aba3bc8c..8f6e0e118e3e 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -17,9 +17,7 @@ Required Properties:
   - reg: A list of base address and length of each memory resource, one for
 each entry in the reg-names property.
   - reg-names: Name of the memory resources. The DU requires one memory
-resource for the DU core (named "du") and one memory resource for each
-LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical
-index).
+resource for the DU core (named "du").
 
   - interrupt-parent: phandle of the parent interrupt controller.
   - interrupts: Interrupt specifiers for the DU interrupts.
@@ -29,14 +27,13 @@ Required Properties:
   - clock-names: Name of the clocks. This property is model-dependent.
 - R8A7779 uses a single functional clock. The clock doesn't need to be
   named.
-- All other DU instances use one functional clock per channel and one
-  clock per LVDS encoder (if available). The functional clocks must be
-  named "du.x" with "x" being the channel numerical index. The LVDS clocks
-  must be named "lvds.x" with "x" being the LVDS encoder numerical index.
-- In addition to the functional and encoder clocks, all DU versions also
-  support externally supplied pixel clocks. Those clocks are optional.
-  When supplied they must be named "dclkin.x" with "x" being the input
-  clock numerical index.
+- All other DU instances use one functional clock per channel The
+  functional clocks must be named "du.x" with "x" being the channel
+  numerical index.
+- In addition to the functional clocks, all DU versions also support
+  externally supplied pixel clocks. Those clocks are optional. When
+  supplied they must be named "dclkin.x" with "x" being the input clock
+  numerical index.
 
   - vsps: A list of phandle and channel index tuples to the VSPs that handle
 the memory interfaces for the DU channels. The phandle identifies the VSP
@@ -71,7 +68,7 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
compatible = "renesas,du-r8a7795";
reg = <0 0xfeb0 0 0x8>,
  <0 0xfeb9 0 0x14>;
-   reg-names = "du", "lvds.0";
+   reg-names = "du";
interrupts = ,
 ,
 ,
@@ -79,9 +76,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
clocks = < CPG_MOD 724>,
 < CPG_MOD 723>,
 < CPG_MOD 722>,
-< CPG_MOD 721>,
-< CPG_MOD 727>;
-   clock-names = "du.0", "du.1", "du.2", "du.3", "lvds.0";
+< CPG_MOD 721>;
+   clock-names = "du.0", "du.1", "du.2", "du.3";
vsps = < 0>, < 0>, < 0>, < 1>;
 
ports {
-- 
Regards,

Laurent Pinchart

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

[PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

[Laurent Pinchart]

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.

Signed-off-by: Laurent Pinchart 
---
 .../bindings/display/bridge/renesas,lvds.txt   | 54 ++
 MAINTAINERS|  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt 
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
new file mode 100644
index ..459c56822eda
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -0,0 +1,54 @@
+Renesas R-Car LVDS Encoder
+==
+
+These DT bindings describe the LVDS encoder embedded in the Renesas R-Car Gen2
+and Gen3 SoCs.
+
+Required properties:
+
+- compatible : Shall contain one of
+  - "renesas,lvds-r8a7743" for R8A7790 (R-Car RZ/G1M) compatible LVDS encoders
+  - "renesas,lvds-r8a7790" for R8A7790 (R-Car H2) compatible LVDS encoders
+  - "renesas,lvds-r8a7791" for R8A7791 (R-Car M2-W) compatible LVDS encoders
+  - "renesas,lvds-r8a7793" for R8A7791 (R-Car M2-N) compatible LVDS encoders
+  - "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS encoders
+  - "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS encoders
+
+- reg: Base address and length for the memory-mapped registers
+- clocks: A phandle + clock-specifier pair for the functional clock
+
+Requires nodes:
+
+The LVDS encoder has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 corresponds to the parallel input
+- Video port 1 corresponds to the LVDS output
+
+Each port shall have a single endpoint.
+
+
+Example:
+
+   lvds0: lvds@feb9 {
+   compatible = "renesas,lvds-r8a7790";
+   reg = <0 0xfeb9 0 0x1c>;
+   clocks = < CPG_MOD 726>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   lvds0_in: endpoint {
+   remote-endpoint = <_out_lvds0>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   lvds0_out: endpoint {
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 40aea858c7ea..5609a7f5ac4d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4725,6 +4725,7 @@ F:drivers/gpu/drm/rcar-du/
 F: drivers/gpu/drm/shmobile/
 F: include/linux/platform_data/shmob_drm.h
 F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
 F: Documentation/devicetree/bindings/display/renesas,du.txt
 
 DRM DRIVERS FOR ROCKCHIP
-- 
Regards,

Laurent Pinchart

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

[PATCH 03/10] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

[Laurent Pinchart]

The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.

Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig |   1 +
 drivers/gpu/drm/rcar-du/Makefile|   2 +
 drivers/gpu/drm/rcar-du/rcar_du_of.c| 440 
 drivers/gpu/drm/rcar-du/rcar_du_of.h|  16 +
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts |  82 ++
 5 files changed, 541 insertions(+)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 8a50dab19e5c..e3193ebd3ced 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,7 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+   select OF_OVERLAY
help
  Enable support for the R-Car Display Unit embedded LVDS encoders.
 
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf5c11030e8..0cf457bef1f2 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -5,6 +5,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_group.o \
 rcar_du_kms.o \
 rcar_du_lvdscon.o \
+rcar_du_of.o \
+rcar_du_of_lvds.dtb.o \
 rcar_du_plane.o
 
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c 
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..c2726e29bd59
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,440 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * rcar_du_of.c - Legacy DT bindings compatibility
+ *
+ * Copyright (C) 2018 Laurent Pinchart 
+ *
+ * Based on work from Jyri Sarha 
+ * Copyright (C) 2015 Texas Instruments
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rcar_du_crtc.h"
+#include "rcar_du_drv.h"
+
+extern u8 __dtb_rcar_du_of_lvds_begin[];
+extern u8 __dtb_rcar_du_of_lvds_end[];
+
+struct rcar_du_of_overlay {
+   struct device_node *np;
+   void *data;
+   void *mem;
+};
+
+static void __init rcar_du_of_free_overlay(struct rcar_du_of_overlay *overlay)
+{
+   of_node_put(overlay->np);
+   kfree(overlay->data);
+   kfree(overlay->mem);
+}
+
+static int __init rcar_du_of_get_overlay(struct rcar_du_of_overlay *overlay,
+u8 *begin, u8 *end)
+{
+   const size_t size = end - begin;
+
+   memset(overlay, 0, sizeof(*overlay));
+
+   if (!size)
+   return -EINVAL;
+
+   overlay->data = kmemdup(begin, size, GFP_KERNEL);
+   if (!overlay->data)
+   return -ENOMEM;
+
+   overlay->mem = of_fdt_unflatten_tree(overlay->data, NULL, >np);
+   if (!overlay->mem) {
+   rcar_du_of_free_overlay(overlay);
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+
+static struct device_node __init *
+rcar_du_of_find_node_by_path(struct device_node *parent, const char *path)
+{
+   parent = of_node_get(parent);
+   if (!parent)
+   return NULL;
+
+   while (parent && *path == '/') {
+   struct device_node *child = NULL;
+   struct device_node *node;
+   const char *next;
+   size_t len;
+
+   /* Skip the initial '/' delimiter and find the next one. */
+   path++;
+   next = strchrnul(path, '/');
+   len = next - path;
+   if (!len)
+   goto error;
+
+   for_each_child_of_node(parent, node) {
+   const char *name = kbasename(node->full_name);
+
+   if (strncmp(path, name, len) == 0 &&
+   strlen(name) == len) {
+   child = node;
+   break;
+   }
+   }
+
+   if (!child)
+   goto error;
+
+   of_node_put(parent);
+   parent = child;
+   path = next;
+   }
+
+   return parent;
+
+error:
+   of_node_put(parent);
+   return NULL;
+}
+
+static int __init rcar_du_of_add_property(struct device_node *np,
+ const char *name, const void *value,
+ size_t length)
+{
+   struct property 

[PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver

[Laurent Pinchart]

Hello,

This patch series addresses a design mistake that dates back from the initial
DU support. Support for the LVDS encoders, which are IP cores separate from
the DU, was bundled in the DU driver. Worse, both the DU and LVDS were
described through a single DT node.

To fix the, patches 01/10 and 02/10 define new DT bindings for the LVDS
encoders, and deprecate their description inside the DU bindings. To retain
backward compatibility with existing DT, patch 03/10 then patches the device
tree at runtime to convert the legacy bindings to the new ones.

With the DT side addressed, patch 04/10 then converts the LVDS support code to
a separate bridge driver. After a small fix to the Porter board device tree in
patch 05/10, patches 06/10 to 10/10 then update all the device tree sources to
the new LVDS encoders bindings.

I decided to go for live DT patching in patch 03/10 because implementing
support for both the legacy and new bindings in the driver would have been
very intrusive, and prevented further cleanups. I'm in a way both proud and 
ashamed of that patch that I would call a neat and dirty hack. It was fun to
write perhaps in a similar way that one would enjoy researching and developing
proof-of-concepts for security holes: they're good and bad at the same time.

Anyway, with this philosophical considerations aside, there were a few
shortcomings in the OF API that I worked around with local code in the driver.
If anyone is interested in performing similar live DT patching I think we
could move some of the code to the OF core. For instance I was surprised
to not find a device node lookup by path function that would start at a
given node instead of the root of the live device tree, and had to write
rcar_du_of_find_node_by_path(). Utility functions to add or modify properties
or to rename nodes could similarly be added.

Laurent Pinchart (10):
  dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
  dt-bindings: display: renesas: Deprecate LVDS support in the DU
bindings
  drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
  drm: rcar-du: Convert LVDS encoder code to bridge driver
  ARM: dts: porter: Fix HDMI output routing
  ARM: dts: r8a7790: Convert to new LVDS DT bindings
  ARM: dts: r8a7791: Convert to new LVDS DT bindings
  ARM: dts: r8a7793: Convert to new LVDS DT bindings
  arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings
  arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings

 .../bindings/display/bridge/renesas,lvds.txt   |  54 ++
 .../devicetree/bindings/display/renesas,du.txt |  26 +-
 MAINTAINERS|   1 +
 arch/arm/boot/dts/r8a7790-lager.dts|  22 +-
 arch/arm/boot/dts/r8a7790.dtsi |  61 ++-
 arch/arm/boot/dts/r8a7791-koelsch.dts  |  10 +-
 arch/arm/boot/dts/r8a7791-porter.dts   |  18 +-
 arch/arm/boot/dts/r8a7791.dtsi |  35 +-
 arch/arm/boot/dts/r8a7793-gose.dts |  10 +-
 arch/arm/boot/dts/r8a7793.dtsi |  35 +-
 .../boot/dts/renesas/r8a7795-es1-salvator-x.dts|   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |   3 +-
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  35 +-
 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts |   3 +-
 arch/arm64/boot/dts/renesas/r8a7796.dtsi   |  35 +-
 drivers/gpu/drm/rcar-du/Kconfig|   5 +-
 drivers/gpu/drm/rcar-du/Makefile   |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  |  21 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 175 +--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h  |  12 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  14 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  |  93 
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  |  24 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  | 270 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  |  64 ---
 drivers/gpu/drm/rcar-du/rcar_du_of.c   | 440 
 drivers/gpu/drm/rcar-du/rcar_du_of.h   |  16 +
 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts|  82 +++
 drivers/gpu/drm/rcar-du/rcar_lvds.c| 554 +
 33 files changed, 1420 insertions(+), 721 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
 create mode 

Re: [PATCH v2] drm/vc4: Expose performance counters to userspace

[Eric Anholt]

Boris Brezillon  writes:

> The V3D engine has various hardware counters which might be interesting
> to userspace performance analysis tools.
>
> Expose new ioctls to create/destroy a performance monitor object and
> query the counter values of this perfmance monitor.
>
> Note that a perfomance monitor is given an ID that is only valid on the
> file descriptor it has been allocated from. A performance monitor can be
> attached to a CL submission and the driver will enable HW counters for
> this request and update the performance monitor values at the end of the
> job.
>
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Get rid of the CL extension stuff
> - Fix isolation of jobs when perfmon attached to them are different
> - Add more comments in the code
> - Use an SPDX header for vc4_perfmon.c
> - Consider 0 as an invalid perfmonid to be backward compatible with mesa
>   versions that lack perfmon support
> ---
>  drivers/gpu/drm/vc4/Makefile  |   1 +
>  drivers/gpu/drm/vc4/vc4_drv.c |  26 ++
>  drivers/gpu/drm/vc4/vc4_drv.h |  68 ++
>  drivers/gpu/drm/vc4/vc4_gem.c |  48 +-
>  drivers/gpu/drm/vc4/vc4_irq.c |  40 +++-
>  drivers/gpu/drm/vc4/vc4_perfmon.c | 188 
> ++
>  drivers/gpu/drm/vc4/vc4_regs.h|  35 +--
>  drivers/gpu/drm/vc4/vc4_v3d.c |  64 ++---
>  include/uapi/drm/vc4_drm.h|  67 ++
>  9 files changed, 465 insertions(+), 72 deletions(-)
>  create mode 100644 drivers/gpu/drm/vc4/vc4_perfmon.c
>
> diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
> index f5500df51686..4a3a868235f8 100644
> --- a/drivers/gpu/drm/vc4/Makefile
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -15,6 +15,7 @@ vc4-y := \
>   vc4_vec.o \
>   vc4_hvs.o \
>   vc4_irq.o \
> + vc4_perfmon.o \
>   vc4_plane.o \
>   vc4_render_cl.o \
>   vc4_trace_points.o \
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index ceb385fd69c5..94b99c90425a 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -101,6 +101,7 @@ static int vc4_get_param_ioctl(struct drm_device *dev, 
> void *data,
>   case DRM_VC4_PARAM_SUPPORTS_THREADED_FS:
>   case DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER:
>   case DRM_VC4_PARAM_SUPPORTS_MADVISE:
> + case DRM_VC4_PARAM_SUPPORTS_PERFMON:
>   args->value = true;
>   break;
>   default:
> @@ -111,6 +112,26 @@ static int vc4_get_param_ioctl(struct drm_device *dev, 
> void *data,
>   return 0;
>  }
>  
> +static int vc4_open(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vc4_file *vc4file;
> +
> + vc4file = kzalloc(sizeof(*vc4file), GFP_KERNEL);
> + if (!vc4file)
> + return -ENOMEM;
> +
> + vc4_perfmon_open_file(vc4file);
> + file->driver_priv = vc4file;
> + return 0;
> +}
> +
> +static void vc4_close(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vc4_file *vc4file = file->driver_priv;
> +
> + vc4_perfmon_close_file(vc4file);
> +}
> +
>  static const struct vm_operations_struct vc4_vm_ops = {
>   .fault = vc4_fault,
>   .open = drm_gem_vm_open,
> @@ -143,6 +164,9 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(VC4_GET_TILING, vc4_get_tiling_ioctl, 
> DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(VC4_LABEL_BO, vc4_label_bo_ioctl, DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(VC4_GEM_MADVISE, vc4_gem_madvise_ioctl, 
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_PERFMON_CREATE, vc4_perfmon_create_ioctl, 
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_PERFMON_DESTROY, vc4_perfmon_destroy_ioctl, 
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_PERFMON_GET_VALUES, vc4_perfmon_get_values_ioctl, 
> DRM_RENDER_ALLOW),
>  };
>  
>  static struct drm_driver vc4_drm_driver = {
> @@ -153,6 +177,8 @@ static struct drm_driver vc4_drm_driver = {
>   DRIVER_RENDER |
>   DRIVER_PRIME),
>   .lastclose = drm_fb_helper_lastclose,
> + .open = vc4_open,
> + .postclose = vc4_close,
>   .irq_handler = vc4_irq,
>   .irq_preinstall = vc4_irq_preinstall,
>   .irq_postinstall = vc4_irq_postinstall,
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 3af22936d9b3..fefa1664a9f5 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -11,6 +11,8 @@
>  #include 
>  #include 
>  
> +#include "uapi/drm/vc4_drm.h"
> +
>  /* Don't forget to update vc4_bo.c: bo_type_names[] when adding to
>   * this.
>   */
> @@ -29,6 +31,36 @@ enum vc4_kernel_bo_type {
>   VC4_BO_TYPE_COUNT
>  };
>  
> +/* Performance monitor object. The perform lifetime is controlled by 
> userspace
> + * using perfmon related ioctls. A perfmon can be attached to a 

Re: [PATCH] drm: rcar-du: lvds: fix LVDCR1 for R-Car gen3

[Laurent Pinchart]

Hi Sergei,

On Thursday, 21 December 2017 22:23:30 EET Sergei Shtylyov wrote:
> The LVDCR1 register for the R-Car gen3 SoCs was documented as having the
> layout different from the gen2 SoCs in  the early R-Car gen3 manuals but
> since v0.52 the LVDCR1 layout is described as being the same as on the gen2
> SoCs; the old CHn control values are said to be prohibited now (and there
> seems to be no valid output signal when they are used).
> 
> Fixes: 6bc2e15cf21c ("drm: rcar-du: lvds: Add R-Car Gen3 support")
> Signed-off-by: Sergei Shtylyov 

I've tested this on Salvator-X H3 ES1.1, Salvator-XS H3 ES2.0 and Salvator-X 
M3-W, and the LVDS output works correctly. I assume both settings work on 
these SoCs, while only the new settings work on V3M. Thus,

Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 

and applied to my tree.

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |   10 --
>  drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |6 ++
>  2 files changed, 6 insertions(+), 10 deletions(-)
> 
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -70,9 +70,8 @@ static void rcar_du_lvdsenc_start_gen2(s
> 
>   /* Turn all the channels on. */
>   rcar_lvds_write(lvds, LVDCR1,
> - LVDCR1_CHSTBY_GEN2(3) | LVDCR1_CHSTBY_GEN2(2) |
> - LVDCR1_CHSTBY_GEN2(1) | LVDCR1_CHSTBY_GEN2(0) |
> - LVDCR1_CLKSTBY_GEN2);
> + LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> + LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
> 
>   /*
>* Turn the PLL on, wait for the startup delay, and turn the output
> @@ -109,9 +108,8 @@ static void rcar_du_lvdsenc_start_gen3(s
> 
>   /* Turn all the channels on. */
>   rcar_lvds_write(lvds, LVDCR1,
> - LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
> - LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
> - LVDCR1_CLKSTBY_GEN3);
> + LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> + LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
> 
>   /*
>* Turn the PLL on, set it to LVDS normal mode, wait for the startup
> Index: linux/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
> +++ linux/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
> @@ -26,10 +26,8 @@
> 
>  #define LVDCR1   0x0004
>  #define LVDCR1_CKSEL (1 << 15)   /* Gen2 only */
> -#define LVDCR1_CHSTBY_GEN2(n)(3 << (2 + (n) * 2))/* Gen2 
> only */
> -#define LVDCR1_CHSTBY_GEN3(n)(1 << (2 + (n) * 2))/* Gen3 
> only */
> -#define LVDCR1_CLKSTBY_GEN2  (3 << 0)/* Gen2 only */
> -#define LVDCR1_CLKSTBY_GEN3  (1 << 0)/* Gen3 only */
> +#define LVDCR1_CHSTBY(n) (3 << (2 + (n) * 2))
> +#define LVDCR1_CLKSTBY   (3 << 0)
> 
>  #define LVDPLLCR 0x0008
>  #define LVDPLLCR_CEEN(1 << 14)
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Regards,

Laurent Pinchart

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

[PATCH] drm/nouveau: Pass the proper arguments to nvif_object_map_handle()

[Thierry Reding]

From: Thierry Reding 

This is obviously wrong in the current code. Make sure to record the
correct size of the arguments and pass the actual arguments to the
nvif_object_map_handle() function.

Suggested-by: Ben Skeggs 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index a8a957207f3a..8334b3f4e60b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1494,11 +1494,13 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *reg)
args.nv50.ro = 0;
args.nv50.kind = mem->kind;
args.nv50.comp = mem->comp;
+   argc = sizeof(args.nv50);
break;
case NVIF_CLASS_MEM_GF100:
args.gf100.version = 0;
args.gf100.ro = 0;
args.gf100.kind = mem->kind;
+   argc = sizeof(args.gf100);
break;
default:
WARN_ON(1);
@@ -1506,7 +1508,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *reg)
}
 
ret = nvif_object_map_handle(>mem.object,
-, argc,
+, argc,
 , );
if (ret != 1) {
pr_info("  nvif_object_map_handle(): %d\n", 
ret);
-- 
2.15.1

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

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

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

--- Comment #17 from higu...@gmx.net ---
Sorry for the delay!

yes, it works! After applying the patch, i can use the radeon card without the
runpm=0 normally

-- 
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 v3 7/7] drm/tinydrm/mipi-dbi: Change reset active time

[David Lechner]

On 01/10/2018 12:59 PM, Noralf Trønnes wrote:

The MIPI DBI spec states that reset active/low time should be more
than 9us. Change from 20ms to 20us.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 6798b4837441..75dd65c57e74 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -414,7 +414,7 @@ void mipi_dbi_hw_reset(struct mipi_dbi *mipi)
return;
  
  	gpiod_set_value_cansleep(mipi->reset, 0);

-   msleep(20);
+   usleep_range(20, 1000);
gpiod_set_value_cansleep(mipi->reset, 1);
msleep(120);
  }



Reviewed-by: David Lechner 
Tested-by: David Lechner 

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

Re: [PATCH v3 4/7] drm/tinydrm/mipi-dbi: Add poweron-reset functions

[David Lechner]

On 01/10/2018 12:59 PM, Noralf Trønnes wrote:

Split out common poweron-reset functionality.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 22 ++--
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 73 ++
  drivers/gpu/drm/tinydrm/st7586.c   |  9 ++---
  drivers/gpu/drm/tinydrm/st7735r.c  |  8 ++---
  include/drm/tinydrm/mipi-dbi.h |  2 ++
  5 files changed, 83 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index c69a4d958f24..1617405faed4 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,33 +49,17 @@
  
  static int mi0283qt_init(struct mipi_dbi *mipi)

  {
-   struct tinydrm_device *tdev = >tinydrm;
-   struct device *dev = tdev->drm->dev;
u8 addr_mode;
int ret;
  
  	DRM_DEBUG_KMS("\n");
  
-	ret = regulator_enable(mipi->regulator);

-   if (ret) {
-   DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+   ret = mipi_dbi_poweron_conditional_reset(mipi);
+   if (ret < 0)
return ret;
-   }
-
-   /* Avoid flicker by skipping setup if the bootloader has done it */


It could be helpful to keep this comment.


-   if (mipi_dbi_display_is_on(mipi))
+   if (ret == 1)
return 0;
  
-	mipi_dbi_hw_reset(mipi);

-   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
-   if (ret) {
-   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
-   regulator_disable(mipi->regulator);
-   return ret;
-   }
-
-   msleep(20);
-
mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
  
  	mipi_dbi_command(mipi, ILI9341_PWCTRLB, 0x00, 0x83, 0x30);

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 1c8ef0c4d6d4..3e879d605ed3 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -463,6 +463,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
  
  	val &= ~DCS_POWER_MODE_RESERVED_MASK;
  
+	/* The poweron/reset value is 08h DCS_POWER_MODE_DISPLAY_NORMAL_MODE */

if (val != (DCS_POWER_MODE_DISPLAY |
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
@@ -473,6 +474,78 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
  }
  EXPORT_SYMBOL(mipi_dbi_display_is_on);
  
+static int mipi_dbi_poweron_reset_conditional(struct mipi_dbi *mipi, bool cond)

+{
+   struct device *dev = mipi->tinydrm.drm->dev;
+   int ret;
+
+   if (mipi->regulator) {
+   ret = regulator_enable(mipi->regulator);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n", 
ret);
+   return ret;
+   }
+   }
+
+   if (cond && mipi_dbi_display_is_on(mipi))
+   return 1;
+
+   mipi_dbi_hw_reset(mipi);
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
+   if (mipi->regulator)
+   regulator_disable(mipi->regulator);
+   return ret;
+   }
+
+   /*
+* If we did a hw reset, we know the controller is in Sleep mode and
+* per MIPI DSC spec should wait 5ms after soft reset. If we didn't,
+* we assume worst case and wait 120ms.
+*/
+   if (mipi->reset)
+   usleep_range(5000, 2);
+   else
+   msleep(120);
+
+   return 0;
+}
+
+/**
+ * mipi_dbi_poweron_reset - MIPI DBI poweron and reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and does a hardware and software
+ * reset.
+ *
+ * Returns:
+ * Zero on success, or a negative error code.
+ */
+int mipi_dbi_poweron_reset(struct mipi_dbi *mipi)
+{
+   return mipi_dbi_poweron_reset_conditional(mipi, false);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_reset);
+
+/**
+ * mipi_dbi_poweron_conditional_reset - MIPI DBI poweron and conditional reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and if the display is off, it
+ * does a hardware and software reset. If mipi_dbi_display_is_on() determines
+ * that the display is on, no reset is performed.
+ *
+ * Returns:
+ * Zero if the controller was reset, 1 if the display was already on, or a
+ * negative error code.
+ */
+int mipi_dbi_poweron_conditional_reset(struct mipi_dbi *mipi)
+{
+   return mipi_dbi_poweron_reset_conditional(mipi, true);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_conditional_reset);
+
  #if IS_ENABLED(CONFIG_SPI)
  
  /**

diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 9fd4423c8e70..a6396ef9cc4a 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -179,19 +179,16 @@ 

[PATCH libdrm] nouveau: Support fence FDs

[Thierry Reding]

From: Thierry Reding 

Add a new nouveau_pushbuf_kick_fence() function that takes and emits a
sync fence FD. The fence FD can be waited on, or merged with other fence
FDs, or passed back to the kernel as a prerequisite for a subsequent HW
operation.

Based heavily on work by Lauri Peltonen 

Signed-off-by: Thierry Reding 
---
For the kernel patches that add the new IOCTL, see the series at:

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

 include/drm/nouveau_drm.h |  23 
 nouveau/nouveau.h |   2 +
 nouveau/pushbuf.c | 130 ++
 3 files changed, 121 insertions(+), 34 deletions(-)

diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index cb077821c43f..e7f1a2aefd22 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -178,6 +178,28 @@ struct drm_nouveau_gem_pushbuf {
__u64 gart_available;
 };
 
+#define NOUVEAU_GEM_PUSHBUF_FENCE_WAIT (1 << 0)
+#define NOUVEAU_GEM_PUSHBUF_FENCE_EMIT (1 << 1)
+#define NOUVEAU_GEM_PUSHBUF_FLAGS (NOUVEAU_GEM_PUSHBUF_FENCE_WAIT | \
+   NOUVEAU_GEM_PUSHBUF_FENCE_EMIT)
+
+struct drm_nouveau_gem_pushbuf2 {
+uint32_t channel;
+uint32_t nr_buffers;
+uint64_t buffers;
+uint32_t nr_relocs;
+uint32_t nr_push;
+uint64_t relocs;
+uint64_t push;
+uint32_t suffix0;
+uint32_t suffix1;
+uint64_t vram_available;
+uint64_t gart_available;
+uint32_t flags;
+int32_t fence;
+uint64_t reserved;
+};
+
 #define NOUVEAU_GEM_CPU_PREP_NOWAIT  0x0001
 #define NOUVEAU_GEM_CPU_PREP_NOBLOCK 0x0002
 #define NOUVEAU_GEM_CPU_PREP_WRITE   0x0004
@@ -212,6 +234,7 @@ struct drm_nouveau_sarea {
 #define DRM_NOUVEAU_GEM_CPU_PREP   0x42
 #define DRM_NOUVEAU_GEM_CPU_FINI   0x43
 #define DRM_NOUVEAU_GEM_INFO   0x44
+#define DRM_NOUVEAU_GEM_PUSHBUF2   0x45
 
 #if defined(__cplusplus)
 }
diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index 335ce77dca77..70d680700faf 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -226,6 +226,8 @@ void nouveau_pushbuf_reloc(struct nouveau_pushbuf *, struct 
nouveau_bo *,
 int nouveau_pushbuf_validate(struct nouveau_pushbuf *);
 uint32_t nouveau_pushbuf_refd(struct nouveau_pushbuf *, struct nouveau_bo *);
 int nouveau_pushbuf_kick(struct nouveau_pushbuf *, struct nouveau_object 
*chan);
+int nouveau_pushbuf_kick_fence(struct nouveau_pushbuf *,
+   struct nouveau_object *chan, int *fence);
 struct nouveau_bufctx *
 nouveau_pushbuf_bufctx(struct nouveau_pushbuf *, struct nouveau_bufctx *);
 
diff --git a/nouveau/pushbuf.c b/nouveau/pushbuf.c
index 035e3019f2cd..f13804db7534 100644
--- a/nouveau/pushbuf.c
+++ b/nouveau/pushbuf.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -77,7 +78,7 @@ nouveau_pushbuf(struct nouveau_pushbuf *push)
 }
 
 static int pushbuf_validate(struct nouveau_pushbuf *, bool);
-static int pushbuf_flush(struct nouveau_pushbuf *);
+static int pushbuf_flush(struct nouveau_pushbuf *, int *);
 
 static bool
 pushbuf_kref_fits(struct nouveau_pushbuf *push, struct nouveau_bo *bo,
@@ -172,7 +173,7 @@ pushbuf_kref(struct nouveau_pushbuf *push, struct 
nouveau_bo *bo,
 */
fpush = cli_push_get(push->client, bo);
if (fpush && fpush != push)
-   pushbuf_flush(fpush);
+   pushbuf_flush(fpush, NULL);
 
kref = cli_kref_get(push->client, bo);
if (kref) {
@@ -307,7 +308,8 @@ pushbuf_dump(struct nouveau_pushbuf_krec *krec, int 
krec_id, int chid)
 }
 
 static int
-pushbuf_submit(struct nouveau_pushbuf *push, struct nouveau_object *chan)
+pushbuf_submit(struct nouveau_pushbuf *push, struct nouveau_object *chan,
+   int *fence)
 {
struct nouveau_pushbuf_priv *nvpb = nouveau_pushbuf(push);
struct nouveau_pushbuf_krec *krec = nvpb->list;
@@ -315,9 +317,9 @@ pushbuf_submit(struct nouveau_pushbuf *push, struct 
nouveau_object *chan)
struct nouveau_drm *drm = nouveau_drm(>object);
struct drm_nouveau_gem_pushbuf_bo_presumed *info;
struct drm_nouveau_gem_pushbuf_bo *kref;
-   struct drm_nouveau_gem_pushbuf req;
struct nouveau_fifo *fifo = chan->data;
struct nouveau_bo *bo;
+   int fence_out = -1;
int krec_id = 0;
int ret = 0, i;
 
@@ -330,35 +332,81 @@ pushbuf_submit(struct nouveau_pushbuf *push, struct 
nouveau_object *chan)
nouveau_pushbuf_data(push, NULL, 0, 0);
 
while (krec && krec->nr_push) {
-   req.channel = fifo->channel;
-   req.nr_buffers = krec->nr_buffer;
-   req.buffers = (uint64_t)(unsigned long)krec->buffer;
-   req.nr_relocs = krec->nr_reloc;
-   req.nr_push = krec->nr_push;
-   

[PATCH 2/3] drm/tegra: Add sync file support to submit interface

[Thierry Reding]

From: Mikko Perttunen 

Adds ability to pass sync file based prefences and get back
sync file based postfences during job submission. Both
fence fd's are passed in the `fence` field. A new `flags`
field is used to specify if the prefence should be waited
or a postfence created.

Signed-off-by: Mikko Perttunen 
Signed-off-by: Thierry Reding 
---
 include/uapi/drm/tegra_drm.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index d954f8c33321..03492d6670a5 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -117,6 +117,11 @@ struct drm_tegra_waitchk {
__u32 thresh;
 };
 
+#define DRM_TEGRA_SUBMIT_WAIT_FENCE_FD (1 << 0)
+#define DRM_TEGRA_SUBMIT_CREATE_FENCE_FD   (1 << 1)
+#define DRM_TEGRA_SUBMIT_FLAGS (DRM_TEGRA_SUBMIT_WAIT_FENCE_FD | \
+   DRM_TEGRA_SUBMIT_CREATE_FENCE_FD)
+
 struct drm_tegra_submit {
__u64 context;
__u32 num_syncpts;
@@ -129,9 +134,10 @@ struct drm_tegra_submit {
__u64 cmdbufs;
__u64 relocs;
__u64 waitchks;
-   __u32 fence;/* Return value */
+   __u32 fence;
+   __u32 flags;
 
-   __u32 reserved[5];  /* future expansion */
+   __u32 reserved[4];  /* future expansion */
 };
 
 #define DRM_TEGRA_GEM_TILING_MODE_PITCH 0
-- 
2.15.1

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

Re: [PATCH v5 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

[Rob Herring]

On Tue, Jan 09, 2018 at 03:31:48PM +0530, Vivek Gautam wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
> 
> Signed-off-by: Vivek Gautam 
> ---
> 
>  * Major change in this patch -
>Changed compatible string from 'qcom,msm8996-smmu-v2' to
>'qcom,smmu-v2' to reflect the IP version rather than the
>platform on which it is used.

The bugs and how things are connected are all the same? I'd suggest you 
keep both strings.

>The same IP is used across multiple platforms including msm8996,
>and sdm845 etc.

But for only 2 or so platforms a fallback is not really worth it. You'll 
probably be on SMMUv3 before too long...

> 
>  .../devicetree/bindings/iommu/arm,smmu.txt | 35 
> ++
>  drivers/iommu/arm-smmu.c   | 13 
>  2 files changed, 48 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 8a6ffce12af5..e4951288c87c 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -17,6 +17,7 @@ conditions.
>  "arm,mmu-401"
>  "arm,mmu-500"
>  "cavium,smmu-v2"
> +"qcom,smmu-v2"
>  
>depending on the particular implementation and/or the
>version of the architecture implemented.
> @@ -71,6 +72,23 @@ conditions.
>or using stream matching with #iommu-cells = <2>, and
>may be ignored if present in such cases.
>  
> +- clock-names:Should be "bus", and "iface" for "qcom,smmu-v2"
> +  implementation.
> +
> +  "bus" clock for "qcom,smmu-v2" is required for downstream
> +  bus access and for the smmu ptw.
> +
> +  "iface" clock is required to access smmu's registers 
> through
> +  the TCU's programming interface.
> +
> +- clocks: Phandles for respective clocks described by clock-names.
> +
> +- power-domains:  Phandles to SMMU's power domain specifier. This is
> +  required even if SMMU belongs to the master's power
> +  domain, as the SMMU will have to be enabled and
> +  accessed before master gets enabled and linked to its
> +  SMMU.
> +
>  ** Deprecated properties:
>  
>  - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> @@ -137,3 +155,20 @@ conditions.
>  iommu-map = <0  0 0x400>;
>  ...
>  };
> +
> + /* Qcom's arm,smmu-v2 implementation */
> + smmu4: iommu {
> + compatible = "qcom,smmu-v2";
> + reg = <0xd0 0x1>;
> +
> + #global-interrupts = <1>;
> + interrupts = ,
> +  ,
> +  ;
> + #iommu-cells = <1>;
> + power-domains = < MDSS_GDSC>;
> +
> + clocks = < SMMU_MDP_AXI_CLK>,
> +  < SMMU_MDP_AHB_CLK>;
> + clock-names = "bus", "iface";
> + };
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 33bbcfedb896..2ade214c41bc 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -119,6 +119,7 @@ enum arm_smmu_implementation {
>   GENERIC_SMMU,
>   ARM_MMU500,
>   CAVIUM_SMMUV2,
> + QCOM_SMMUV2,
>  };
>  
>  struct arm_smmu_s2cr {
> @@ -1971,6 +1972,17 @@ struct arm_smmu_match_data {
>  ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
>  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
>  
> +static const char * const qcom_smmuv2_clks[] = {
> + "bus", "iface",
> +};
> +
> +static const struct arm_smmu_match_data qcom_smmuv2 = {
> + .version = ARM_SMMU_V2,
> + .model = QCOM_SMMUV2,
> + .clks = qcom_smmuv2_clks,
> + .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
> +};
> +
>  static const struct of_device_id arm_smmu_of_match[] = {
>   { .compatible = "arm,smmu-v1", .data = _generic_v1 },
>   { .compatible = "arm,smmu-v2", .data = _generic_v2 },
> @@ -1978,6 +1990,7 @@ struct arm_smmu_match_data {
>   { .compatible = "arm,mmu-401", .data = _mmu401 },
>   { .compatible = "arm,mmu-500", .data = _mmu500 },
>   { .compatible = "cavium,smmu-v2", .data = _smmuv2 },
> + { .compatible = "qcom,smmu-v2", .data = _smmuv2 },
>   { },
>  };
>  MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 
___
dri-devel mailing list

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

[Thierry Reding]

From: Mikko Perttunen 

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

Signed-off-by: Mikko Perttunen 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/drm.c | 82 -
 1 file changed, 66 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d50bddb2e447..c40175c32dd7 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -374,6 +375,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;
@@ -382,7 +384,6 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct drm_tegra_waitchk __user *user_waitchks;
struct drm_tegra_syncpt __user *user_syncpt;
struct drm_tegra_syncpt syncpt;
-   struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
struct drm_gem_object **refs;
struct host1x_syncpt *sp;
struct host1x_job *job;
@@ -402,6 +403,10 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (args->num_waitchks != 0)
return -EINVAL;
 
+   /* Check for unrecognized flags */
+   if (args->flags & ~DRM_TEGRA_SUBMIT_FLAGS)
+   return -EINVAL;
+
job = host1x_job_alloc(context->channel, args->num_cmdbufs,
   args->num_relocs, args->num_waitchks);
if (!job)
@@ -413,6 +418,14 @@ 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;
+   }
+   }
+
/*
 * Track referenced BOs so that they can be unreferenced after the
 * submission is complete.
@@ -436,7 +449,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 
if (copy_from_user(, user_cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
-   goto fail;
+   goto put_bos;
}
 
/*
@@ -445,13 +458,13 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 */
if (cmdbuf.words > CDMA_GATHER_FETCHES_MAX_NB) {
err = -EINVAL;
-   goto fail;
+   goto put_bos;
}
 
bo = host1x_bo_lookup(file, cmdbuf.handle);
if (!bo) {
err = -ENOENT;
-   goto fail;
+   goto put_bos;
}
 
offset = (u64)cmdbuf.offset + (u64)cmdbuf.words * sizeof(u32);
@@ -465,7 +478,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 */
if (offset & 3 || offset >= obj->gem.size) {
err = -EINVAL;
-   goto fail;
+   goto put_bos;
}
 
host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
@@ -482,7 +495,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
  _relocs[num_relocs], drm,
  file);
if (err < 0)
-   goto fail;
+   goto put_bos;
 
reloc = >relocarray[num_relocs];
obj = host1x_to_tegra_bo(reloc->cmdbuf.bo);
@@ -496,7 +509,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (reloc->cmdbuf.offset & 3 ||
reloc->cmdbuf.offset >= obj->gem.size) {
err = -EINVAL;
-   goto fail;
+   goto put_bos;
}
 
obj = host1x_to_tegra_bo(reloc->target.bo);
@@ -504,7 +517,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 
if (reloc->target.offset >= obj->gem.size) {
err = -EINVAL;
-   goto fail;
+   goto put_bos;
}
}
 
@@ -516,7 +529,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
err = host1x_waitchk_copy_from_user(
wait, 

[PATCH 1/3] gpu: host1x: Add support for DMA fences

[Thierry Reding]

From: Mikko Perttunen 

Add an implementation of DMA fences backed by Host1x syncpoints,
an interface to specify a prefence for job submissions.

Before submission, prefences containing only Host1x syncpoints
are waited by pushing wait commands to CDMA, whereas other
fences are CPU-waited.

Signed-off-by: Mikko Perttunen 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/Kconfig |   1 +
 drivers/gpu/host1x/Makefile|   1 +
 drivers/gpu/host1x/dev.h   |  12 ++-
 drivers/gpu/host1x/fence.c | 202 +
 drivers/gpu/host1x/fence.h |  28 +
 drivers/gpu/host1x/hw/channel_hw.c |  36 +--
 drivers/gpu/host1x/intr.c  |  11 +-
 drivers/gpu/host1x/intr.h  |   8 +-
 drivers/gpu/host1x/syncpt.c|   2 +
 include/linux/host1x.h |  12 ++-
 10 files changed, 302 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/host1x/fence.c
 create mode 100644 drivers/gpu/host1x/fence.h

diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index 91916326957f..e41032ebf16d 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -1,6 +1,7 @@
 config TEGRA_HOST1X
tristate "NVIDIA Tegra host1x driver"
depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
+   select DMA_SHARED_BUFFER
select IOMMU_IOVA if IOMMU_SUPPORT
help
  Driver for the NVIDIA Tegra host1x hardware.
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index b92016ce09b7..ae3a6edf74b4 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -9,6 +9,7 @@ host1x-y = \
job.o \
debug.o \
mipi.o \
+   fence.o \
hw/host1x01.o \
hw/host1x02.o \
hw/host1x04.o \
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 43e9fabb43a1..c9071c9c443e 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012-2015, NVIDIA Corporation.
+ * Copyright (C) 2012-2016 NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -42,6 +42,7 @@ struct host1x_channel_ops {
int (*init)(struct host1x_channel *channel, struct host1x *host,
unsigned int id);
int (*submit)(struct host1x_job *job);
+   void (*push_wait)(struct host1x_channel *ch, u32 id, u32 thresh);
 };
 
 struct host1x_cdma_ops {
@@ -117,6 +118,8 @@ struct host1x {
struct clk *clk;
struct reset_control *rst;
 
+   u64 fence_ctx_base;
+
struct iommu_group *group;
struct iommu_domain *domain;
struct iova_domain iova;
@@ -250,6 +253,13 @@ static inline int host1x_hw_channel_submit(struct host1x 
*host,
return host->channel_op->submit(job);
 }
 
+static inline void host1x_hw_channel_push_wait(struct host1x *host,
+  struct host1x_channel *channel,
+  u32 id, u32 thresh)
+{
+   host->channel_op->push_wait(channel, id, thresh);
+}
+
 static inline void host1x_hw_cdma_start(struct host1x *host,
struct host1x_cdma *cdma)
 {
diff --git a/drivers/gpu/host1x/fence.c b/drivers/gpu/host1x/fence.c
new file mode 100644
index ..3b056623ea64
--- /dev/null
+++ b/drivers/gpu/host1x/fence.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2016 NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include "fence.h"
+#include "intr.h"
+#include "syncpt.h"
+#include "cdma.h"
+#include "channel.h"
+#include "dev.h"
+
+struct host1x_fence {
+   struct dma_fence base;
+   spinlock_t lock;
+
+   struct host1x_syncpt *syncpt;
+   u32 threshold;
+
+   struct host1x *host;
+   void *waiter;
+
+   char timeline_name[10];
+};
+
+static inline struct host1x_fence *to_host1x_fence(struct dma_fence *fence)
+{
+   return (struct host1x_fence *)fence;
+}
+
+static const char *host1x_fence_get_driver_name(struct dma_fence *fence)
+{
+   return "host1x";
+}
+
+static const char *host1x_fence_get_timeline_name(struct dma_fence *fence)
+{

[PATCH 0/3] drm/tegra: Add support for fence FDs

[Thierry Reding]

From: Thierry Reding 

This set of patches adds support for fences to Tegra DRM and complements
the fence FD support for Nouveau. Technically this isn't necessary for a
fence-based synchronization loop with Nouveau because the KMS core takes
care of all that, but engines behind host1x can use the IOCTL extensions
provided here to emit fence FDs that in turn can be used to synchronize
their jobs with either the scanout engine or the GPU.

See the following link for the Nouveau fence FD support series:

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

Thierry

Mikko Perttunen (3):
  gpu: host1x: Add support for DMA fences
  drm/tegra: Add sync file support to submit interface
  drm/tegra: Support for sync file-based fences in submit

 drivers/gpu/drm/tegra/drm.c|  82 ---
 drivers/gpu/host1x/Kconfig |   1 +
 drivers/gpu/host1x/Makefile|   1 +
 drivers/gpu/host1x/dev.h   |  12 ++-
 drivers/gpu/host1x/fence.c | 202 +
 drivers/gpu/host1x/fence.h |  28 +
 drivers/gpu/host1x/hw/channel_hw.c |  36 +--
 drivers/gpu/host1x/intr.c  |  11 +-
 drivers/gpu/host1x/intr.h  |   8 +-
 drivers/gpu/host1x/syncpt.c|   2 +
 include/linux/host1x.h |  12 ++-
 include/uapi/drm/tegra_drm.h   |  10 +-
 12 files changed, 376 insertions(+), 29 deletions(-)
 create mode 100644 drivers/gpu/host1x/fence.c
 create mode 100644 drivers/gpu/host1x/fence.h

-- 
2.15.1

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

[PATCH 3/3] drm/nouveau: Support DMA fence arrays

[Thierry Reding]

From: Thierry Reding 

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_fence.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index d61fcfb97b09..53178b1471e3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -331,9 +332,9 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool lazy, 
bool intr)
return 0;
 }
 
-int
-nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
-  bool intr)
+static int
+__nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
+bool intr)
 {
struct nouveau_fence_chan *fctx = chan->fence;
struct nouveau_channel *prev = NULL;
@@ -356,6 +357,30 @@ nouveau_fence_sync(struct dma_fence *fence, struct 
nouveau_channel *chan,
return ret;
 }
 
+int
+nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
+  bool intr)
+{
+   int ret = 0;
+
+   if (dma_fence_is_array(fence)) {
+   struct dma_fence_array *array = to_dma_fence_array(fence);
+   unsigned int i;
+
+   for (i = 0; i < array->num_fences; i++) {
+   struct dma_fence *f = array->fences[i];
+
+   ret = __nouveau_fence_sync(f, chan, intr);
+   if (ret < 0)
+   break;
+   }
+   } else {
+   ret = __nouveau_fence_sync(fence, chan, intr);
+   }
+
+   return ret;
+}
+
 void
 nouveau_fence_unref(struct nouveau_fence **pfence)
 {
-- 
2.15.1

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

[PATCH 0/3] drm/nouveau: Add support for fence FDs

[Thierry Reding]

From: Thierry Reding 

This small series of patches implements support for waiting on and
emitting fence FDs on kickoff. This enables explicit fencing and can be
used for example to synchronize buffer accesses between the display
engine and the GPU on Tegra.

The first patch lays the groundwork by splitting up nouveau_fence_sync()
to allow reuse. Patch 2 is where the interesting stuff happens. It adds
a new IOCTL (PUSHBUF2) that is a superset of the existing PUSHBUF IOCTL
and reuses most of the code while adding support for pre- and post-
fences.

Finally, the third patch teaches Nouveau how to deal with fence arrays,
which are usually a result of chaining together multiple dependent jobs.

I have corresponding userspace support for these in libdrm and Mesa:

https://cgit.freedesktop.org/~tagr/drm/log/?h=nouveau-sync-fd
https://cgit.freedesktop.org/~tagr/mesa/log/?h=nouveau-sync-fd

I'll send those patches out shortly. There's some more work depending on
these patches that I plan to send out in the coming days or weeks. The
final result allows Nouveau and Tegra DRM to negotiate for a framebuffer
modifier and then go into a render/scanout loop using fences for
synchronization. All of this was tested using a slightly modified
version of kmscube.

Thierry

Thierry Reding (3):
  drm/nouveau: Split nouveau_fence_sync()
  drm/nouveau: Support fence FDs at kickoff
  drm/nouveau: Support DMA fence arrays

 drivers/gpu/drm/nouveau/nouveau_bo.c  | 38 ++-
 drivers/gpu/drm/nouveau/nouveau_bo.h  |  2 +
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c |  1 +
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 81 +--
 drivers/gpu/drm/nouveau/nouveau_fence.h   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c | 80 --
 drivers/gpu/drm/nouveau/nouveau_gem.h |  2 +
 include/uapi/drm/nouveau_drm.h| 14 ++
 9 files changed, 167 insertions(+), 57 deletions(-)

-- 
2.15.1

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

RE: [PATCH v2 4/5] drm/dp: Macro for DSC eDP Output BPP

[Srivatsa, Anusha]

Looks good to me.


>-Original Message-
>From: Navare, Manasi D
>Sent: Thursday, January 4, 2018 12:23 AM
>To: gfx-internal-de...@eclists.intel.com
>Cc: Navare, Manasi D ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; dri-devel@lists.freedesktop.org
>Subject: [PATCH v2 4/5] drm/dp: Macro for DSC eDP Output BPP
>
>This returns the maximum output BPP supported by the eDP panel by reading the
>MAX_SUPPORTED_BPP DSC DPCD register.
>
>Cc: Jani Nikula 
>Cc: Ville Syrjala 
>Cc: Anusha Srivatsa 
>Cc: dri-devel@lists.freedesktop.org
>Signed-off-by: Manasi Navare 
Reviewed-by: Anusha Srivatsa

>---
> include/drm/drm_dp_helper.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
>06e41b2..4e8f357 100644
>--- a/include/drm/drm_dp_helper.h
>+++ b/include/drm/drm_dp_helper.h
>@@ -980,6 +980,16 @@ drm_dp_is_branch(const u8
>dpcd[DP_RECEIVER_CAP_SIZE])
>   return dpcd[DP_DOWNSTREAMPORT_PRESENT] &
>DP_DWN_STRM_PORT_PRESENT;  }
>
>+/* DP/eDP DSC support */
>+static inline u16
>+drm_edp_dsc_get_output_bpp(const u8
>dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
>+{
>+  return dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW -
>DP_DSC_SUPPORT] |
>+  (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI -
>DP_DSC_SUPPORT] &
>+   DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK <<
>+   DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
>+}
>+
> /*
>  * DisplayPort AUX channel
>  */
>--
>2.7.4

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

[PATCH 2/3] drm/nouveau: Support fence FDs at kickoff

[Thierry Reding]

From: Thierry Reding 

Add a new NOUVEAU_GEM_PUSHBUF2 IOCTL that accepts and emits a sync fence
FD from/to userspace if requested by the corresponding flags.

Based heavily on work by Lauri Peltonen 

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c |  1 +
 drivers/gpu/drm/nouveau/nouveau_gem.c | 78 +--
 drivers/gpu/drm/nouveau/nouveau_gem.h |  2 +
 include/uapi/drm/nouveau_drm.h| 14 +++
 4 files changed, 91 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3ce2f02e9e58..b38500a64236 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1012,6 +1012,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, 
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF2, nouveau_gem_ioctl_pushbuf2, 
DRM_AUTH|DRM_RENDER_ALLOW),
 };
 
 long
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index ea5e1cbd..ad5c939b4f33 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -24,6 +24,8 @@
  *
  */
 
+#include 
+
 #include "nouveau_drv.h"
 #include "nouveau_dma.h"
 #include "nouveau_fence.h"
@@ -666,22 +668,28 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
return ret;
 }
 
-int
-nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+static int
+__nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
+   struct drm_nouveau_gem_pushbuf2 *request,
+   struct drm_file *file_priv)
 {
struct nouveau_abi16 *abi16 = nouveau_abi16_get(file_priv);
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_abi16_chan *temp;
struct nouveau_drm *drm = nouveau_drm(dev);
-   struct drm_nouveau_gem_pushbuf *req = data;
+   struct drm_nouveau_gem_pushbuf *req = >base;
struct drm_nouveau_gem_pushbuf_push *push;
struct drm_nouveau_gem_pushbuf_bo *bo;
struct nouveau_channel *chan = NULL;
struct validate_op op;
struct nouveau_fence *fence = NULL;
+   struct dma_fence *prefence = NULL;
int i, j, ret = 0, do_reloc = 0;
 
+   /* check for unrecognized flags */
+   if (request->flags & ~NOUVEAU_GEM_PUSHBUF_FLAGS)
+   return -EINVAL;
+
if (unlikely(!abi16))
return -ENOMEM;
 
@@ -746,6 +754,15 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
*data,
goto out_prevalid;
}
 
+   if (request->flags & NOUVEAU_GEM_PUSHBUF_FENCE_WAIT) {
+   prefence = sync_file_get_fence(request->fence);
+   if (prefence) {
+   ret = nouveau_fence_sync(prefence, chan, true);
+   if (ret < 0)
+   goto out;
+   }
+   }
+
/* Apply any relocations that are required */
if (do_reloc) {
ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
@@ -830,7 +847,30 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
*data,
goto out;
}
 
+   if (request->flags & NOUVEAU_GEM_PUSHBUF_FENCE_EMIT) {
+   struct sync_file *file;
+   int fd;
+
+   fd = get_unused_fd_flags(O_CLOEXEC);
+   if (fd < 0) {
+   ret = fd;
+   goto out;
+   }
+
+   file = sync_file_create(>base);
+   if (!file) {
+   put_unused_fd(fd);
+   goto out;
+   }
+
+   fd_install(fd, file->file);
+   request->fence = fd;
+   }
+
 out:
+   if (prefence)
+   dma_fence_put(prefence);
+
validate_fini(, fence, bo);
nouveau_fence_unref();
 
@@ -855,6 +895,27 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
*data,
return nouveau_abi16_put(abi16, ret);
 }
 
+int
+nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_nouveau_gem_pushbuf *request = data;
+   struct drm_nouveau_gem_pushbuf2 req;
+   int ret;
+
+   memset(, 0, sizeof(req));
+   memcpy(, request, sizeof(*request));
+
+   ret = __nouveau_gem_ioctl_pushbuf(dev, , file_priv);
+
+   request->gart_available = req.base.gart_available;
+   request->vram_available = req.base.vram_available;
+   request->suffix1 = req.base.suffix1;
+   

[PATCH 1/3] drm/nouveau: Split nouveau_fence_sync()

[Thierry Reding]

From: Thierry Reding 

Turn nouveau_fence_sync() into a low-level helper that adds fence waits
to the channel command stream. The new nouveau_bo_sync() helper replaces
the previous nouveau_fence_sync() implementation. It passes each of the
buffer object's fences to nouveau_fence_sync() in turn.

This provides more fine-grained control over fences which is needed by
subsequent patches for sync fd support.

Heavily based on work by Lauri Peltonen .

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 38 -
 drivers/gpu/drm/nouveau/nouveau_bo.h  |  2 +
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +-
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 68 +++
 drivers/gpu/drm/nouveau/nouveau_fence.h   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c |  2 +-
 6 files changed, 57 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 41e7f2927443..0285ca4c6235 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -545,6 +545,42 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
PAGE_SIZE, DMA_FROM_DEVICE);
 }
 
+int
+nouveau_bo_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan,
+   bool exclusive, bool intr)
+{
+   struct reservation_object *resv = nvbo->bo.resv;
+   struct reservation_object_list *fobj;
+   struct dma_fence *fence;
+   int ret = 0, i;
+
+   if (!exclusive) {
+   ret = reservation_object_reserve_shared(resv);
+   if (ret < 0)
+   return ret;
+   }
+
+   fobj = reservation_object_get_list(resv);
+   fence = reservation_object_get_excl(resv);
+
+   if (fence && (!exclusive || !fobj || !fobj->shared_count))
+   return nouveau_fence_sync(fence, chan, intr);
+
+   if (!exclusive || !fobj)
+   return ret;
+
+   for (i = 0; i < fobj->shared_count && !ret; ++i) {
+   fence = rcu_dereference_protected(fobj->shared[i],
+ 
reservation_object_held(resv));
+
+   ret = nouveau_fence_sync(fence, chan, intr);
+   if (ret < 0)
+   break;
+   }
+
+   return ret;
+}
+
 int
 nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -1114,7 +1150,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict, bool intr,
}
 
mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
-   ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
+   ret = nouveau_bo_sync(nouveau_bo(bo), chan, true, intr);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, >mem, new_reg);
if (ret == 0) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 7b5cc5c73d20..d2ef12c0e39a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -93,6 +93,8 @@ int  nouveau_bo_validate(struct nouveau_bo *, bool 
interruptible,
 bool no_wait_gpu);
 void nouveau_bo_sync_for_device(struct nouveau_bo *nvbo);
 void nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo);
+int nouveau_bo_sync(struct nouveau_bo *nvbo, struct nouveau_channel *channel,
+   bool exclusive, bool intr);
 
 /* TODO: submit equivalent to TTM generic API upstream? */
 static inline void __iomem *
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 009713404cc4..526280e9677a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -755,7 +755,7 @@ nouveau_page_flip_emit(struct nouveau_channel *chan,
spin_unlock_irqrestore(>event_lock, flags);
 
/* Synchronize with the old framebuffer */
-   ret = nouveau_fence_sync(old_bo, chan, false, false);
+   ret = nouveau_bo_sync(old_bo, chan, false, false);
if (ret)
goto fail;
 
@@ -819,7 +819,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
goto fail_unpin;
 
/* synchronise rendering channel with the kernel's channel */
-   ret = nouveau_fence_sync(new_bo, chan, false, true);
+   ret = nouveau_bo_sync(new_bo, chan, false, true);
if (ret) {
ttm_bo_unreserve(_bo->bo);
goto fail_unpin;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 9c8f3a154d55..d61fcfb97b09 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -332,66 +332,26 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool 
lazy, bool intr)
 }
 
 int
-nouveau_fence_sync(struct nouveau_bo 

Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly

[Laurent Pinchart]

Hi Maxime,

On Friday, 12 January 2018 00:06:06 EET Laurent Pinchart wrote:
> On Thursday, 11 January 2018 15:12:56 EET Maxime Ripard wrote:
> > On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> >> On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> >>> The devm_regulator_get_optional function, unlike it was assumed in the
> >>> commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >>> property"), is actually returning an error pointer with -ENODEV instead
> >>> of NULL when there's no regulator to find.
> >>> 
> >>> Make sure we handle that case properly.
> >>> 
> >>> Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >>> property") Signed-off-by: Maxime Ripard
> >>> 
> >>> ---
> >>> 
> >>>  drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
> >>>  1 file changed, 7 insertions(+), 2 deletions(-)
> >>> 
> >>> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> >>> b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> >>> 100644
> >>> --- a/drivers/gpu/drm/panel/panel-lvds.c
> >>> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> >>> @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> >>> *pdev)
> >>>   lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> >>>   if (IS_ERR(lvds->supply)) {
> >>>   ret = PTR_ERR(lvds->supply);
> >>> - dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> >>> - return ret;
> >>> +
> >>> + if (ret != -ENODEV) {
> >>> + dev_err(lvds->dev, "failed to request regulator: %d\n", 
> >>> ret);
> >>> + return ret;
> >> 
> >> I wouldn't print an error message if ret == -EPROBE_DEFER.
> >> 
> >>> + } else {
> >>> + lvds->supply = NULL;
> >>> + }
> >>>   }
> >> 
> >> How about
> >> 
> >>lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> >>if (IS_ERR(lvds->supply)) {
> >>ret = PTR_ERR(lvds->supply);
> >>if (ret != -ENODEV) {
> >>if (ret == -EPROBE_DEFER)
> > 
> > I guess that would be != -EPROBE_DEFER
> 
> Of course, my bad.
> 
> >>dev_err(lvds->dev, "failed to request 
> >> regulator: %d\n", ret);
> >>return ret;
> >>}
> >>
> >>lvds->supply = NULL;
> >>}
> > 
> > Otherwise, it works for me.

With the above change,

Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 

> >> My preference, however, would be for devm_regulator_get_optional() to
> >> return NULL when no regulator is present. The current implementation
> >> returns -ENODEV in multiple cases, making it impossible to properly
> >> discriminate between having no regulator and not being able to get the
> >> regulator due to an error.
> > 
> > It would feel more intuitive to me too, but it would also require to
> > fix most of the call sites that would have a similar pattern.
> 
> Of course. I don't mean we need to delay this patch, but I still think it
> would be a good API improvement that could be developed separately (and of
> course I wouldn't complain if you volunteered ;-)).

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly

[Laurent Pinchart]

Hi Maxime,

On Thursday, 11 January 2018 15:12:56 EET Maxime Ripard wrote:
> On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> > On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> >> The devm_regulator_get_optional function, unlike it was assumed in the
> >> commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >> property"), is actually returning an error pointer with -ENODEV instead
> >> of NULL when there's no regulator to find.
> >> 
> >> Make sure we handle that case properly.
> >> 
> >> Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >> property") Signed-off-by: Maxime Ripard
> >> 
> >> ---
> >> 
> >>  drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
> >>  1 file changed, 7 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> >> b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> >> 100644
> >> --- a/drivers/gpu/drm/panel/panel-lvds.c
> >> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> >> @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> >> *pdev)
> >>lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> >>if (IS_ERR(lvds->supply)) {
> >>ret = PTR_ERR(lvds->supply);
> >> -  dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> >> -  return ret;
> >> +
> >> +  if (ret != -ENODEV) {
> >> +  dev_err(lvds->dev, "failed to request regulator: %d\n", 
> >> ret);
> >> +  return ret;
> > 
> > I wouldn't print an error message if ret == -EPROBE_DEFER.
> > 
> >> +  } else {
> >> +  lvds->supply = NULL;
> >> +  }
> >>}
> > 
> > How about
> > 
> > lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> > if (IS_ERR(lvds->supply)) {
> > ret = PTR_ERR(lvds->supply);
> > if (ret != -ENODEV) {
> > if (ret == -EPROBE_DEFER)
> 
> I guess that would be != -EPROBE_DEFER

Of course, my bad.

> > dev_err(lvds->dev, "failed to request 
> > regulator: %d\n", ret);
> > return ret;
> > }
> > 
> > lvds->supply = NULL;
> > }
> 
> Otherwise, it works for me.
> 
> > My preference, however, would be for devm_regulator_get_optional() to
> > return NULL when no regulator is present. The current implementation
> > returns -ENODEV in multiple cases, making it impossible to properly
> > discriminate between having no regulator and not being able to get the
> > regulator due to an error.
> 
> It would feel more intuitive to me too, but it would also require to
> fix most of the call sites that would have a similar pattern.

Of course. I don't mean we need to delay this patch, but I still think it 
would be a good API improvement that could be developed separately (and of 
course I wouldn't complain if you volunteered ;-)).

-- 
Regards,

Laurent Pinchart

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

[PATCH 1/5] drm/prime: Remove duplicate forward declaration

[Thierry Reding]

From: Thierry Reding 

struct device is forward-declared twice. Remove the second instance.

Reviewed-by: Chris Wilson 
Signed-off-by: Thierry Reding 
---
 include/drm/drm_prime.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 9cd9e36f77b5..59ccab402e85 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -59,8 +59,6 @@ struct drm_device;
 struct drm_gem_object;
 struct drm_file;
 
-struct device;
-
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj,
 int flags);
-- 
2.15.1

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

[PATCH 5/5] drm/nouveau: prime: Implement cache maintenance

[Thierry Reding]

From: Thierry Reding 

Implement the ->begin_cpu_access() and ->end_cpu_access() callbacks to
allow userspace to invalidate the cache before accessing a buffer that
is exported using PRIME and flush the cache after modifying the buffer
through its userspace mapping.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_prime.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 5d885d7cb059..a3a586ce864c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -29,6 +29,26 @@
 #include "nouveau_drv.h"
 #include "nouveau_gem.h"
 
+static int nouveau_gem_prime_begin_cpu_access(struct dma_buf *buf,
+ enum dma_data_direction direction)
+{
+   struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
+
+   nouveau_bo_sync_for_cpu(bo);
+
+   return 0;
+}
+
+static int nouveau_gem_prime_end_cpu_access(struct dma_buf *buf,
+   enum dma_data_direction direction)
+{
+   struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
+
+   nouveau_bo_sync_for_device(bo);
+
+   return 0;
+}
+
 static void *nouveau_gem_prime_kmap_atomic(struct dma_buf *buf,
   unsigned long page)
 {
@@ -106,6 +126,8 @@ static const struct dma_buf_ops 
nouveau_gem_prime_dmabuf_ops = {
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
+   .begin_cpu_access = nouveau_gem_prime_begin_cpu_access,
+   .end_cpu_access = nouveau_gem_prime_end_cpu_access,
.map_atomic = nouveau_gem_prime_kmap_atomic,
.unmap_atomic = nouveau_gem_prime_kunmap_atomic,
.map = nouveau_gem_prime_kmap,
-- 
2.15.1

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

[PATCH 2/5] drm/prime: Export more helpers for drivers

[Thierry Reding]

From: Thierry Reding 

Export some more of the helpers in order to allow drivers to more fine-
grainedly select which helpers to use. This gives drivers an easy way to
reuse a lot of the code in the helpers while at the same time allowing
them to provide their own implementation for other functions in struct
dma_buf_ops.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_prime.c | 23 +--
 include/drm/drm_prime.h | 12 
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9a17725b0f7a..f9903e6b59f6 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -180,9 +180,8 @@ static int drm_prime_lookup_buf_handle(struct 
drm_prime_file_private *prime_fpri
return -ENOENT;
 }
 
-static int drm_gem_map_attach(struct dma_buf *dma_buf,
- struct device *target_dev,
- struct dma_buf_attachment *attach)
+int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
+  struct dma_buf_attachment *attach)
 {
struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf->priv;
@@ -200,9 +199,10 @@ static int drm_gem_map_attach(struct dma_buf *dma_buf,
 
return dev->driver->gem_prime_pin(obj);
 }
+EXPORT_SYMBOL(drm_gem_map_attach);
 
-static void drm_gem_map_detach(struct dma_buf *dma_buf,
-  struct dma_buf_attachment *attach)
+void drm_gem_map_detach(struct dma_buf *dma_buf,
+   struct dma_buf_attachment *attach)
 {
struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
@@ -228,6 +228,7 @@ static void drm_gem_map_detach(struct dma_buf *dma_buf,
kfree(prime_attach);
attach->priv = NULL;
 }
+EXPORT_SYMBOL(drm_gem_map_detach);
 
 void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private 
*prime_fpriv,
struct dma_buf *dma_buf)
@@ -254,8 +255,8 @@ void drm_prime_remove_buf_handle_locked(struct 
drm_prime_file_private *prime_fpr
}
 }
 
-static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
-   enum dma_data_direction dir)
+struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
+enum dma_data_direction dir)
 {
struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = attach->dmabuf->priv;
@@ -291,13 +292,15 @@ static struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
 
return sgt;
 }
+EXPORT_SYMBOL(drm_gem_map_dma_buf);
 
-static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
- struct sg_table *sgt,
- enum dma_data_direction dir)
+void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+  struct sg_table *sgt,
+  enum dma_data_direction dir)
 {
/* nothing to be done here */
 }
+EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
 
 /**
  * drm_gem_dmabuf_export - dma_buf export implementation for GEM
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 59ccab402e85..3a9706815773 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -50,8 +50,10 @@ struct drm_prime_file_private {
struct rb_root handles;
 };
 
+enum dma_data_direction;
 struct device;
 
+struct dma_buf_attachment;
 struct dma_buf_export_info;
 struct dma_buf;
 
@@ -59,6 +61,16 @@ struct drm_device;
 struct drm_gem_object;
 struct drm_file;
 
+int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
+  struct dma_buf_attachment *attach);
+void drm_gem_map_detach(struct dma_buf *dma_buf,
+   struct dma_buf_attachment *attach);
+struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
+enum dma_data_direction dir);
+void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+  struct sg_table *sgt,
+  enum dma_data_direction dir);
+
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj,
 int flags);
-- 
2.15.1

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

[PATCH 3/5] drm/nouveau: Provide custom struct dma_buf_ops

[Thierry Reding]

From: Thierry Reding 

Instead of relying on the DRM PRIME helpers to provide all of the
DMA-BUF operations, provide a custom version of struct dma_buf_ops to
allow additional functionality to be implemented.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c   |   9 +-
 drivers/gpu/drm/nouveau/nouveau_gem.h   |  15 +--
 drivers/gpu/drm/nouveau/nouveau_prime.c | 157 +---
 3 files changed, 135 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 56fe261b6268..3ce2f02e9e58 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1081,15 +1081,12 @@ driver_stub = {
 
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
-   .gem_prime_export = drm_gem_prime_export,
-   .gem_prime_import = drm_gem_prime_import,
+   .gem_prime_export = nouveau_gem_prime_export,
+   .gem_prime_import = nouveau_gem_prime_import,
.gem_prime_pin = nouveau_gem_prime_pin,
-   .gem_prime_res_obj = nouveau_gem_prime_res_obj,
.gem_prime_unpin = nouveau_gem_prime_unpin,
+   .gem_prime_res_obj = nouveau_gem_prime_res_obj,
.gem_prime_get_sg_table = nouveau_gem_prime_get_sg_table,
-   .gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
-   .gem_prime_vmap = nouveau_gem_prime_vmap,
-   .gem_prime_vunmap = nouveau_gem_prime_vunmap,
 
.gem_free_object_unlocked = nouveau_gem_object_del,
.gem_open_object = nouveau_gem_object_open,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h 
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index fe39998f65cc..eb55c1eb1d9f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -32,13 +32,14 @@ extern int nouveau_gem_ioctl_cpu_fini(struct drm_device *, 
void *,
 extern int nouveau_gem_ioctl_info(struct drm_device *, void *,
  struct drm_file *);
 
-extern int nouveau_gem_prime_pin(struct drm_gem_object *);
+struct dma_buf *nouveau_gem_prime_export(struct drm_device *dev,
+struct drm_gem_object *obj,
+int flags);
+struct drm_gem_object *nouveau_gem_prime_import(struct drm_device *drm,
+   struct dma_buf *buf);
+int nouveau_gem_prime_pin(struct drm_gem_object *obj);
+void nouveau_gem_prime_unpin(struct drm_gem_object *obj);
 struct reservation_object *nouveau_gem_prime_res_obj(struct drm_gem_object *);
-extern void nouveau_gem_prime_unpin(struct drm_gem_object *);
-extern struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object 
*);
-extern struct drm_gem_object *nouveau_gem_prime_import_sg_table(
-   struct drm_device *, struct dma_buf_attachment *, struct sg_table *);
-extern void *nouveau_gem_prime_vmap(struct drm_gem_object *);
-extern void nouveau_gem_prime_vunmap(struct drm_gem_object *, void *);
+struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object *obj);
 
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 1fefc93af1d7..63cf4aca2d8e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -23,69 +23,152 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "nouveau_drv.h"
 #include "nouveau_gem.h"
 
-struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object *obj)
+static void *nouveau_gem_prime_kmap_atomic(struct dma_buf *buf,
+  unsigned long page)
 {
-   struct nouveau_bo *nvbo = nouveau_gem_object(obj);
-   int npages = nvbo->bo.num_pages;
+   return NULL;
+}
 
-   return drm_prime_pages_to_sg(nvbo->bo.ttm->pages, npages);
+static void nouveau_gem_prime_kunmap_atomic(struct dma_buf *buf,
+   unsigned long page, void *addr)
+{
 }
 
-void *nouveau_gem_prime_vmap(struct drm_gem_object *obj)
+static void *nouveau_gem_prime_kmap(struct dma_buf *buf, unsigned long page)
 {
-   struct nouveau_bo *nvbo = nouveau_gem_object(obj);
+   return NULL;
+}
+
+static void nouveau_gem_prime_kunmap(struct dma_buf *buf, unsigned long page,
+void *addr)
+{
+}
+
+static void *nouveau_gem_prime_vmap(struct dma_buf *buf)
+{
+   struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
int ret;
 
-   ret = ttm_bo_kmap(>bo, 0, nvbo->bo.num_pages,
- >dma_buf_vmap);
+   ret = ttm_bo_kmap(>bo, 0, bo->bo.num_pages, >dma_buf_vmap);
if (ret)
return ERR_PTR(ret);
 
-   return nvbo->dma_buf_vmap.virtual;
+   return bo->dma_buf_vmap.virtual;
 }
 
-void nouveau_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+static void 

[PATCH 4/5] drm/nouveau: prime: Implement mmap()

[Thierry Reding]

From: Thierry Reding 

Provide an implementation of mmap() for PRIME exported buffers. This
allows userspace to map these buffers and access them using the CPU.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_prime.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 63cf4aca2d8e..5d885d7cb059 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -50,6 +50,37 @@ static void nouveau_gem_prime_kunmap(struct dma_buf *buf, 
unsigned long page,
 {
 }
 
+static inline u64 nouveau_bo_mmap_offset(struct nouveau_bo *bo)
+{
+   return drm_vma_node_offset_addr(>bo.vma_node) >> PAGE_SHIFT;
+}
+
+static int nouveau_gem_prime_mmap(struct dma_buf *buf,
+ struct vm_area_struct *vma)
+{
+   struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
+   struct drm_gem_object *obj = buf->priv;
+   int ret;
+
+   /* check for valid size */
+   if (obj->size < vma->vm_end - vma->vm_start)
+   return -EINVAL;
+
+   vma->vm_pgoff += nouveau_bo_mmap_offset(bo);
+
+   if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
+   return drm_legacy_mmap(vma->vm_file, vma);
+
+   ret = drm_vma_node_allow(>vma_node, vma->vm_file->private_data);
+   if (ret)
+   return ret;
+
+   ret = ttm_bo_mmap(vma->vm_file, vma, bo->bo.bdev);
+   drm_vma_node_revoke(>vma_node, vma->vm_file->private_data);
+
+   return ret;
+}
+
 static void *nouveau_gem_prime_vmap(struct dma_buf *buf)
 {
struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
@@ -79,6 +110,7 @@ static const struct dma_buf_ops nouveau_gem_prime_dmabuf_ops 
= {
.unmap_atomic = nouveau_gem_prime_kunmap_atomic,
.map = nouveau_gem_prime_kmap,
.unmap = nouveau_gem_prime_kunmap,
+   .mmap = nouveau_gem_prime_mmap,
.vmap = nouveau_gem_prime_vmap,
.vunmap = nouveau_gem_prime_vunmap,
 };
-- 
2.15.1

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

[PATCH 2/2] drm/nouveau: tegra: Use IOMMU groups

[Thierry Reding]

From: Thierry Reding 

Use IOMMU groups to attach the GPU to its IOMMU domain. This is not
strictly necessary because the domain isn't shared with any other
device, but it makes the code consistent with how IOMMU is handled in
other drivers and provides an easy way to detect when no IOMMU has
been attached via device tree.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h  |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 18 +++---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h 
b/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h
index 5c102d0206a7..5a9a796380dc 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h
@@ -25,6 +25,7 @@ struct nvkm_device_tegra {
 
struct nvkm_mm mm;
struct iommu_domain *domain;
+   struct iommu_group *group;
unsigned long pgshift;
} iommu;
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 78597da6313a..1f07999aea1d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -110,7 +110,8 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra 
*tdev)
 
mutex_init(>iommu.mutex);
 
-   if (iommu_present(_bus_type)) {
+   tdev->iommu.group = iommu_group_get(dev);
+   if (tdev->iommu.group) {
tdev->iommu.domain = iommu_domain_alloc(_bus_type);
if (!tdev->iommu.domain)
goto error;
@@ -132,7 +133,7 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra 
*tdev)
tdev->iommu.pgshift -= 1;
}
 
-   ret = iommu_attach_device(tdev->iommu.domain, dev);
+   ret = iommu_attach_group(tdev->iommu.domain, tdev->iommu.group);
if (ret)
goto free_domain;
 
@@ -140,19 +141,21 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra 
*tdev)
   (1ULL << tdev->func->iommu_bit) >>
   tdev->iommu.pgshift, 1);
if (ret)
-   goto detach_device;
+   goto detach_group;
}
 
return;
 
-detach_device:
-   iommu_detach_device(tdev->iommu.domain, dev);
+detach_group:
+   iommu_detach_group(tdev->iommu.domain, tdev->iommu.group);
 
 free_domain:
iommu_domain_free(tdev->iommu.domain);
 
 error:
+   iommu_group_put(tdev->iommu.group);
tdev->iommu.domain = NULL;
+   tdev->iommu.group = NULL;
tdev->iommu.pgshift = 0;
dev_err(dev, "cannot initialize IOMMU MM\n");
 #endif
@@ -162,10 +165,11 @@ static void
 nvkm_device_tegra_remove_iommu(struct nvkm_device_tegra *tdev)
 {
 #if IS_ENABLED(CONFIG_IOMMU_API)
-   if (tdev->iommu.domain) {
+   if (tdev->iommu.group && tdev->iommu.domain) {
nvkm_mm_fini(>iommu.mm);
-   iommu_detach_device(tdev->iommu.domain, tdev->device.dev);
+   iommu_detach_group(tdev->iommu.domain, tdev->iommu.group);
iommu_domain_free(tdev->iommu.domain);
+   iommu_group_put(tdev->iommu.group);
}
 #endif
 }
-- 
2.15.1

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

[PATCH 1/2] drm/nouveau: Remove redundant _get

[Thierry Reding]

From: Thierry Reding 

The nouveau_fence_get_get_driver_name() function has a redundant _get in
its name. Remove it.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 503fa94dc06d..9c8f3a154d55 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -426,7 +426,7 @@ nouveau_fence_new(struct nouveau_channel *chan, bool sysmem,
return ret;
 }
 
-static const char *nouveau_fence_get_get_driver_name(struct dma_fence *fence)
+static const char *nouveau_fence_get_driver_name(struct dma_fence *fence)
 {
return "nouveau";
 }
@@ -496,7 +496,7 @@ static void nouveau_fence_release(struct dma_fence *f)
 }
 
 static const struct dma_fence_ops nouveau_fence_ops_legacy = {
-   .get_driver_name = nouveau_fence_get_get_driver_name,
+   .get_driver_name = nouveau_fence_get_driver_name,
.get_timeline_name = nouveau_fence_get_timeline_name,
.enable_signaling = nouveau_fence_no_signaling,
.signaled = nouveau_fence_is_signaled,
@@ -523,7 +523,7 @@ static bool nouveau_fence_enable_signaling(struct dma_fence 
*f)
 }
 
 static const struct dma_fence_ops nouveau_fence_ops_uevent = {
-   .get_driver_name = nouveau_fence_get_get_driver_name,
+   .get_driver_name = nouveau_fence_get_driver_name,
.get_timeline_name = nouveau_fence_get_timeline_name,
.enable_signaling = nouveau_fence_enable_signaling,
.signaled = nouveau_fence_is_signaled,
-- 
2.15.1

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #15 from Bong Cosca  ---
[39409/39409] skip: 2874, pass: 15671, warn: 12, fail: 20845, crash: 7

Piglit results haven't changed much since, but notably with more crashes.

-- 
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/panel: lvds: Handle the optional regulator case properly

[Laurent Pinchart]

Hi Jani,

On Thursday, 11 January 2018 16:31:59 EET Jani Nikula wrote:
> On Thu, 11 Jan 2018, Laurent Pinchart wrote:
> > My preference, however, would be for devm_regulator_get_optional() to
> > return NULL when no regulator is present. The current implementation
> > returns -ENODEV in multiple cases, making it impossible to properly
> > discriminate between having no regulator and not being able to get the
> > regulator due to an error.
> 
> Just a word of warning, IS_ERR(NULL) is false, and your proposed change
> would apparently require quite a churn all over the kernel.

That's correct, but I still think that would make the API clearer. I don't 
want to block this patch until we make such a change, but it's a good 
opportunity to discuss it. I'd like to know what Mark's opinion is.

-- 
Regards,

Laurent Pinchart

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

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM

[bugzilla-daemon]

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

--- Comment #20 from Alex Deucher  ---
Everything looks like it's implemented properly in the code to enable HBR
audio.  Take a look at:
drivers/gpu/drm/amd/display/dc/dce/dce_audio.c for audio configuration
drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c for display stream
infoframes

Can you add some debugging output to dce_aud_az_configure() to see why it may
not be getting enabled in your case?  Specifically see if
is_audio_format_supported() is failing for HBR formats and why and see if
set_high_bit_rate_capable() is getting enabled.

-- 
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/prime: Remove duplicate forward declaration

[Chris Wilson]

Quoting Thierry Reding (2018-01-11 20:17:30)
> From: Thierry Reding 
> 
> struct device is forward-declared twice. Remove the second instance.

So good they declared it twice. Also the first one first in with the
alphabetical ordering.
 
> Signed-off-by: Thierry Reding 
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4 v6] drm/bridge: Provide a way to embed timing info in bridges

[Eric Anholt]

Daniel Vetter  writes:

> On Wed, Jan 10, 2018 at 03:12:24PM +0100, Linus Walleij wrote:
>> After some discussion and failed patch sets trying to convey
>> the right timing information between the display engine and
>> a bridge using the connector, I try instead to use an optional
>> timing information container in the bridge itself, so that
>> display engines can retrieve it from any bridge and use it to
>> determine how to drive outputs.
>> 
>> Signed-off-by: Linus Walleij 
>> ---
>> ChangeLog v5->v6:
>> - Sort forward struct declarations alphabetically
>> - Switch to using DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
>>   positive or negatice clock samling edge
>> ChangeLog ->v5:
>> - New patch
>> ---
>>  include/drm/drm_bridge.h | 21 +
>>  1 file changed, 21 insertions(+)
>> 
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 682d01ba920c..28c9ac6d9036 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -29,6 +29,7 @@
>>  #include 
>>  
>>  struct drm_bridge;
>> +struct drm_bridge_timings;
>>  struct drm_panel;
>>  
>>  /**
>> @@ -222,6 +223,23 @@ struct drm_bridge_funcs {
>>  void (*enable)(struct drm_bridge *bridge);
>>  };
>>  
>> +/**
>> + * struct drm_bridge_timings - timing information for the bridge
>> + * @sampling_edge: whether the bridge samples the digital input signal from 
>> the
>> + * display engine on the positive or negative edge of the clock, this should
>> + * reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE bitwise flags from the DRM
>> + * connector (bit 2 and 3 valid)
>> + * @setup_time_ps: the time in picoseconds the input data lines must be 
>> stable
>> + * before the clock edge
>> + * @hold_time_ps: the time in picoseconds taken for the bridge to sample the
>> + * input signal after the clock edge
>> + */
>
> Just a style nit: for longer kerneldoc comments for struct members the
> in-line style, split up for each member, is imo better.
> -Daniel

The new style also discourages the comments getting out of sync with the
code.  I'd be happy to r-b with them moved.


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

Re: [PATCH 4/4 v6] drm/pl111: Support handling bridge timings

[Eric Anholt]

Linus Walleij  writes:

> If the bridge has a too strict setup time for the incoming
> signals, we may not be fast enough and then we need to
> compensate by outputting the signal on the inverse clock
> edge so it is for sure stable when the bridge samples it.
>
> Since bridges in difference to panels does not expose their
> connectors, make the connector optional in the display
> setup code.
>
> Acked-by: Laurent Pinchart 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v5->v6:
> - Collect Laurent's ACK.
> ChangeLog v4->v5:
> - Use the new bridge timings setup method.
> ---
>  drivers/gpu/drm/pl111/Kconfig |  1 +
>  drivers/gpu/drm/pl111/pl111_display.c | 35 
> +++
>  drivers/gpu/drm/pl111/pl111_drv.c | 20 +++-
>  3 files changed, 43 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index e5e2abd66491..82cb3e60ddc8 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -8,6 +8,7 @@ config DRM_PL111
>   select DRM_GEM_CMA_HELPER
>   select DRM_BRIDGE
>   select DRM_PANEL_BRIDGE
> + select DRM_DUMB_VGA_DAC
>   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>   help
> Choose this option for DRM support for the PL111 CLCD controller.

Should this be in PL111, or in whatever machine is a consumer of this
driver plus a dumb dac?  I'm OK either way, it's not a big deal for the
platform I've got.

> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index 201d57d5cb54..101a9c7db6ff 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -107,11 +107,17 @@ static int pl111_modeset_init(struct drm_device *dev)
>   ret = PTR_ERR(bridge);
>   goto out_config;
>   }
> - /*
> -  * TODO: when we are using a different bridge than a panel
> -  * (such as a dumb VGA connector) we need to devise a different
> -  * method to get the connector out of the bridge.
> -  */
> + } else if (bridge) {
> + dev_info(dev->dev, "Using non-panel bridge\n");

This looks like it might be a debug printf you didn't intend to leave
in.  Either way, the patch gets my:

Reviewed-by: Eric Anholt 


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

[PATCH] drm/prime: Remove duplicate forward declaration

[Thierry Reding]

From: Thierry Reding 

struct device is forward-declared twice. Remove the second instance.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_prime.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 9cd9e36f77b5..59ccab402e85 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -59,8 +59,6 @@ struct drm_device;
 struct drm_gem_object;
 struct drm_file;
 
-struct device;
-
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj,
 int flags);
-- 
2.15.1

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

RE: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms bindings

[Hyun Kwon]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Thursday, January 11, 2018 6:43 AM
> To: Hyun Kwon 
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> Simek 
> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
> bindings
> 
> On Wed, Jan 10, 2018 at 8:04 PM, Hyun Kwon  wrote:
> > Hi Rob,
> >
> > Thanks for the feedback.
> >
> >> -Original Message-
> >> From: Rob Herring [mailto:r...@kernel.org]
> >> Sent: Monday, January 08, 2018 8:00 PM
> >> To: Hyun Kwon 
> >> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> >> Simek 
> >> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
> >> bindings
> >>
> >> On Thu, Jan 04, 2018 at 06:05:50PM -0800, Hyun Kwon wrote:
> >> > The dt binding for Xilinx DRM KMS driver.
> >>
> >> Bindings are for h/w, not drivers.
> >
> > I'll rephrase this.
> >
> >>
> >> >
> >> > Signed-off-by: Hyun Kwon 
> >> > ---
> >> >  .../devicetree/bindings/display/xlnx/xlnx,kms.txt| 20
> >> 
> >> >  1 file changed, 20 insertions(+)
> >> >  create mode 100644
> >> Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> >
> >> > diff --git
> a/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> > new file mode 100644
> >> > index 000..8dcd552
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> > @@ -0,0 +1,20 @@
> >> > +Xilinx KMS Pipeline
> >> > +---
> >> > +
> >> > +Xilinx display pipelines can be designed with hardened video IPs and
> soft
> >> video
> >> > +IPs in programmable logic. This KMS module provides the common
> >> functionality
> >> > +of individual subdevice drivers, and glue logics between them.
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: Must be "xlnx,kms".
> >
> > I'll also rephrase the description and rename this to xlnx,display.
> >
> >> > +
> >> > +- ports: phandles for CRTC ports, using the DT bindings defined in
> >> > +  Documentation/devicetree/bindings/graph.txt.
> >>
> >> This use of ports is not part of the graph binding.
> >
> > I'll add more details in the description.
> >
> >>
> >> > +
> >> > +Example:
> >> > +
> >> > +   xlnx_drm: xlnx_drm {
> >> > +   compatible = "xlnx,kms";
> >>
> >> drm and kms are Linuxisms.
> >
> > I agree. I'll remove linux subsystem specific terms.
> >
> >>
> >> Why do you need this node?
> >
> > This node is used to represent a display pipeline as a single entity, which
> can consist of multiple components / IPs. I'll elaborate more per your
> suggestion.
> 
> You generally don't need that. Just have the DRM driver match with the
> first block in the display pipeline. Then use the OF graph to connect
> to the other components in the pipeline. It would help to have a block
> diagram showing the data pipelines and h/w blocks.
> 

Some examples are as following. In simple case, a pipeline is linear with 
multiple blocks:

ZynqMP DisplayPort pipeline:

ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP encoder

FPGA display pipeline where each block comes as a separate device:

FPGA DMA -> FPGA mixer -> FPGA HDMI encoder

It gets more interesting as those can be mixed:

ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP encoder
|
FPAG DMA ->
or

ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP encoder
 |
 -> FPGA HDMI encoder

Or even,

ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP 
encoder
| |
FPAG DMA -> FPGA mixer -> -> 
FPGA HDMI encoder

This node is representation of such variations as a single pipeline device.

Thanks,
-hyun

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

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Laurent Pinchart]

Hi Daniel,

On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote:
> On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
>  On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > Some drivers duplicate the logic to create a property to store a
> > per-plane alpha.
> > 
> > Let's create a helper in order to move that to the core.
> > 
> > Cc: Boris Brezillon 
> > Cc: Laurent Pinchart 
> > Signed-off-by: Maxime Ripard 
>  
>  Do we have userspace for this?
> >>> 
> >>> Wayland seems to be on its way to implement this, with ChromeOS using
> >>> it:
> >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741
> >>> .html
> >>> 
> >>> and more specifically:
> >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way
> >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1
> >>> .xml#118
> >> 
> >> Yay, would be good to include these links in the patch description.
> >> Really happy we're having a real standard now used by multiple people.
> > 
> > I will.
> > 
> >> > > Is encoding a fixed 0-255 range really the best idea?
> >> > 
> >> > I don't really know, is there hardware or formats where there is more
> >> > than 255? Or did you mean less than that?
> >> 
> >> 30bit I'd assume wants more alpha. In the past we've done some
> >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using
> >> that for the blend equation docs is also what I recommend (and that we
> >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of that
> >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's
> >> what we're doing for gamma tables already, and that way drivers can
> >> simply throw away the lower bits.
> > 
> > But that would also break the two users of that property that won't be
> > able to move to the generic property (with the same name) without
> > breaking userspace. The point of that patch was to allow some code
> > consolidation, and that would mean failing to do so here :/
> 
> Let me try to clarify:
> - We'll keep the exact existing property semantics with the 0-255
> range for the userspace visible property.
> 
> - But internally, in the decode value that we store into
> drm_plane_state, we'll do the slightly more future proof thing with a
> few more bits.
> 
> That gives us the option of exposing those bits in the future without
> having to change all the drivers again (which we have to do for this
> series here already anyway, since the decoded value moves into
> drm_plane_state from driver subclasses).
> 
> Definitely not asking to break userspace here :-)

As the property range is available to userspace, we could allow drivers to 
expose a driver-dependent number of bits for the alpha value without breaking 
anything. We can even require new drivers to expose 16 bits regardless of the 
number of bits that the hardware can handle, or we could keep that driver-
specific.

Please note, however, that U0.16 can only represent [0.0, 0.84741...] 
while we need [0.0, 1.0]. As all the hardware I know map the full range of 
values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend that 
the 16-bit value exposed to userspace is U0.16.

>  I know other drivers have skimped on the rules here a bit ... But at
>  least internally (i.e. within the drm_plane_state) we probably should
>  restrict ourselves to u8. And this needs real docs (i.e. the full blend
>  equation drivers are supposed to implement).
> >>> 
> >>> You mean straight vs premultiplied? Maybe we should implement this as
> >>> an additional property in read only depending on how the hardware
> >>> behaves?
> >> 
> >> No need for an additional property right now, but definitely document
> >> whether you mean straight or pre-multiplied. Just writing down the blend
> >> equation is probably best.

-- 
Regards,

Laurent Pinchart

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

[PATCH 3/3] drm: rcar-du: add R8A77970 support

[Sergei Shtylyov]

Add support for the R-Car  V3M  (R8A77970) SoC to the DU driver (this SoC
has only  1 display port). Note that there are some differences  with the
other R-Car gen3 SoCs in the LVDS encoder part, e.g. LVDPLLCR has the same
layout  as  on the R-Car gen2 SoCs...

Signed-off-by: Sergei Shtylyov 

---
 Documentation/devicetree/bindings/display/renesas,du.txt |1 
 drivers/gpu/drm/rcar-du/rcar_du_drv.c|   23 +++
 drivers/gpu/drm/rcar-du/rcar_du_drv.h|1 
 drivers/gpu/drm/rcar-du/rcar_du_group.c  |   10 +++---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c|   20 +
 5 files changed, 45 insertions(+), 10 deletions(-)

Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
===
--- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt
+++ linux/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -13,6 +13,7 @@ Required Properties:
 - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
 - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
 - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
+- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
 
   - reg: A list of base address and length of each memory resource, one for
 each entry in the reg-names property.
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -258,6 +258,28 @@ static const struct rcar_du_device_info
.dpll_ch =  BIT(1),
 };
 
+static const struct rcar_du_device_info rcar_du_r8a77970_info = {
+   .gen = 3,
+   .model = R8A77970,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
+   .num_crtcs = 1,
+   .routes = {
+   /* R8A77970 has one RGB output and one LVDS output. */
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(0),
+   .port = 1,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .port = 0,
+   },
+   },
+   .num_lvds = 1,
+   .dpll_ch  = BIT(1),
+};
+
 static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
{ .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
@@ -269,6 +291,7 @@ static const struct of_device_id rcar_du
{ .compatible = "renesas,du-r8a7794", .data = _du_r8a7794_info },
{ .compatible = "renesas,du-r8a7795", .data = _du_r8a7795_info },
{ .compatible = "renesas,du-r8a7796", .data = _du_r8a7796_info },
+   { .compatible = "renesas,du-r8a77970", .data = _du_r8a77970_info },
{ }
 };
 
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -59,6 +59,7 @@ enum rcar_du_model {
R8A7794,
R8A7795,
R8A7796,
+   R8A77970,
 };
 
 /*
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_group.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -133,10 +133,12 @@ static void rcar_du_group_setup(struct r
rcar_du_group_write(rgrp, DORCR, DORCR_PG1D_DS1 | DORCR_DPRS);
 
/* Apply planes to CRTCs association. */
-   mutex_lock(>lock);
-   rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
-   rgrp->dptsr_planes);
-   mutex_unlock(>lock);
+   if (rcdu->info->num_crtcs > 1) {
+   mutex_lock(>lock);
+   rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
+   rgrp->dptsr_planes);
+   mutex_unlock(>lock);
+   }
 }
 
 /*
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -71,8 +71,10 @@ static int rcar_du_lvdsenc_start(struct
 struct rcar_du_crtc *rcrtc)
 {
u32 lvdhcr, lvdpllcr, lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+   const struct rcar_du_device_info *info = lvds->dev->info;
const struct drm_display_mode *mode = >crtc.mode;
-   unsigned int gen = lvds->dev->info->gen;
+   unsigned int gen = info->gen;
+   enum rcar_du_model model = info->model;
unsigned int freq = 

[PATCH 2/3] drm: rcar-du: add model field to struct rcar_du_device_info

[Sergei Shtylyov]

In order to add the R-Car V3M (R8A77970) support to the DU driver we'd need
to keep  track  not only  of the SoC generation but also of the exact model
(for the LVDS encoder support).  Therefore add the 'model'  field  to the
'struct rcar_du_device_info' and initialize it accordingly  for the already
supported SoCs.

Signed-off-by: Sergei Shtylyov 

---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |9 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   14 ++
 2 files changed, 23 insertions(+)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -37,6 +37,7 @@
 
 static const struct rcar_du_device_info rzg1_du_r8a7743_info = {
.gen = 2,
+   .model = R8A7743,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -58,6 +59,7 @@ static const struct rcar_du_device_info
 
 static const struct rcar_du_device_info rzg1_du_r8a7745_info = {
.gen = 2,
+   .model = R8A7745,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -79,6 +81,7 @@ static const struct rcar_du_device_info
 
 static const struct rcar_du_device_info rcar_du_r8a7779_info = {
.gen = 2,
+   .model = R8A7779,
.features = 0,
.num_crtcs = 2,
.routes = {
@@ -100,6 +103,7 @@ static const struct rcar_du_device_info
 
 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
+   .model = R8A7790,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
@@ -128,6 +132,7 @@ static const struct rcar_du_device_info
 /* M2-W (r8a7791) and M2-N (r8a7793) are identical */
 static const struct rcar_du_device_info rcar_du_r8a7791_info = {
.gen = 2,
+   .model = R8A7791,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -150,6 +155,7 @@ static const struct rcar_du_device_info
 
 static const struct rcar_du_device_info rcar_du_r8a7792_info = {
.gen = 2,
+   .model = R8A7792,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -169,6 +175,7 @@ static const struct rcar_du_device_info
 
 static const struct rcar_du_device_info rcar_du_r8a7794_info = {
.gen = 2,
+   .model = R8A7794,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -191,6 +198,7 @@ static const struct rcar_du_device_info
 
 static const struct rcar_du_device_info rcar_du_r8a7795_info = {
.gen = 3,
+   .model = R8A7795,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS
  | RCAR_DU_FEATURE_VSP1_SOURCE,
@@ -223,6 +231,7 @@ static const struct rcar_du_device_info
 
 static const struct rcar_du_device_info rcar_du_r8a7796_info = {
.gen = 3,
+   .model = R8A7796,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
  | RCAR_DU_FEATURE_EXT_CTRL_REGS
  | RCAR_DU_FEATURE_VSP1_SOURCE,
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -49,9 +49,22 @@ struct rcar_du_output_routing {
unsigned int port;
 };
 
+enum rcar_du_model {
+   R8A7743,
+   R8A7745,
+   R8A7779,
+   R8A7790,
+   R8A7791,
+   R8A7792,
+   R8A7794,
+   R8A7795,
+   R8A7796,
+};
+
 /*
  * struct rcar_du_device_info - DU model-specific information
  * @gen: device generation (2 or 3)
+ * @model: device model
  * @features: device features (RCAR_DU_FEATURE_*)
  * @quirks: device quirks (RCAR_DU_QUIRK_*)
  * @num_crtcs: total number of CRTCs
@@ -60,6 +73,7 @@ struct rcar_du_output_routing {
  */
 struct rcar_du_device_info {
unsigned int gen;
+   enum rcar_du_model model;
unsigned int features;
unsigned int quirks;
unsigned int num_crtcs;

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

[PATCH 0/3] Add R-Car V3M (R8A77970) support to the DU driver

[Sergei Shtylyov]

Hello!

Here's the set of 3 patches against the 'drm-next' branch of David Airlie's
'linux.git' repo plus the patch fixing LVDCR1 for R-Car gen3 posted recently.
The main purpose of these patches is to add the R-Car V3M (R8A77970) support
to the DU driver, we have to do some refactoring first to achieve this goal...

[1/3] drm: rcar-du: lvds: refactor LVDS startup
[2/3] drm: rcar-du: add 'model' field to 'struct rcar_du_device_info'
[3/3] drm: rcar-du: add R8A77970 support

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

[PATCH 1/3] drm: rcar-du: lvds: refactor LVDS startup

[Sergei Shtylyov]

After the recent correction of the R-Car gen3 LVDCR1 value, already similar
enough at their  ends rcar_du_lvdsenc_start_gen{2|3}() started asking for a
merge and it's becoming actually necessary with the addition the R-Car V3M
(R8A77970) support -- this  gen3 SoC  has gen2-like LVDPLLCR layout.

BTW, such a merge saves 72 bytes of the object code with AArch64 gcc 4.8.5.

Signed-off-by: Sergei Shtylyov 

---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c |  132 --
 1 file changed, 54 insertions(+), 78 deletions(-)

Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -39,98 +39,41 @@ static void rcar_lvds_write(struct rcar_
iowrite32(data, lvds->mmio + reg);
 }
 
-static void rcar_du_lvdsenc_start_gen2(struct rcar_du_lvdsenc *lvds,
-  struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_gen2_lvdpllcr(unsigned int freq)
 {
-   const struct drm_display_mode *mode = >crtc.mode;
-   unsigned int freq = mode->clock;
-   u32 lvdcr0;
-   u32 pllcr;
+   u32 lvdpllcr;
 
-   /* PLL clock configuration */
if (freq < 39000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
+   lvdpllcr = LVDPLLCR_PLLDLYCNT_38M;
else if (freq < 61000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
+   lvdpllcr = LVDPLLCR_PLLDLYCNT_60M;
else if (freq < 121000)
-   pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | 
LVDPLLCR_PLLDLYCNT_121M;
+   lvdpllcr = LVDPLLCR_PLLDLYCNT_121M;
else
-   pllcr = LVDPLLCR_PLLDLYCNT_150M;
-
-   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
-   /*
-* Select the input, hardcode mode 0, enable LVDS operation and turn
-* bias circuitry on.
-*/
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
-   if (rcrtc->index == 2)
-   lvdcr0 |= LVDCR0_DUSEL;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return LVDPLLCR_PLLDLYCNT_150M;
 
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
-   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
-   /*
-* Turn the PLL on, wait for the startup delay, and turn the output
-* on.
-*/
-   lvdcr0 |= LVDCR0_PLLON;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   usleep_range(100, 150);
-
-   lvdcr0 |= LVDCR0_LVRES;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return lvdpllcr | LVDPLLCR_CEEN | LVDPLLCR_COSEL;
 }
 
-static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc *lvds,
-  struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_gen3_lvdpllcr(unsigned int freq)
 {
-   const struct drm_display_mode *mode = >crtc.mode;
-   unsigned int freq = mode->clock;
-   u32 lvdcr0;
-   u32 pllcr;
-
-   /* PLL clock configuration */
if (freq < 42000)
-   pllcr = LVDPLLCR_PLLDIVCNT_42M;
+   return LVDPLLCR_PLLDIVCNT_42M;
else if (freq < 85000)
-   pllcr = LVDPLLCR_PLLDIVCNT_85M;
+   return LVDPLLCR_PLLDIVCNT_85M;
else if (freq < 128000)
-   pllcr = LVDPLLCR_PLLDIVCNT_128M;
-   else
-   pllcr = LVDPLLCR_PLLDIVCNT_148M;
-
-   rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
-   LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
-   /*
-* Turn the PLL on, set it to LVDS normal mode, wait for the startup
-* delay and turn the output on.
-*/
-   lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   lvdcr0 |= LVDCR0_PWD;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return LVDPLLCR_PLLDIVCNT_128M;
 
-   usleep_range(100, 150);
-
-   lvdcr0 |= LVDCR0_LVRES;
-   rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+   return LVDPLLCR_PLLDIVCNT_148M;
 }
 
 static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
 struct rcar_du_crtc *rcrtc)
 {
-   u32 lvdhcr;
+   u32 lvdhcr, lvdpllcr, lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+   const struct drm_display_mode *mode = >crtc.mode;
+   unsigned int gen = lvds->dev->info->gen;
+   unsigned int freq = mode->clock;
int ret;
 
if (lvds->enabled)
@@ -158,14 +101,47 @@ static int rcar_du_lvdsenc_start(struct
else
lvdhcr = LVDCHCR_CHSEL_CH(0, 

RE: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

[Hyun Kwon]

Hi Daniel,

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, January 11, 2018 12:06 AM
> To: Hyun Kwon 
> Cc: Daniel Vetter ; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; Tejas Upadhyay ; Michal
> Simek 
> Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
> 
> On Thu, Jan 11, 2018 at 02:05:31AM +, Hyun Kwon wrote:
> > Hi Daniel,
> >
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > > Vetter
> > > Sent: Tuesday, January 09, 2018 1:54 AM
> > > To: Hyun Kwon 
> > > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Tejas
> > > Upadhyay ; Michal Simek 
> > > Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
> > >
> > > On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> > > > Debugfs can be used to exploit some specific setting. Main purpose
> > > > is for testing and debug diagnostic.
> > > >
> > > > Signed-off-by: Tejas Upadhyay 
> > > > Signed-off-by: Hyun Kwon 
> > >
> > > Hm, not sure what's the use, it seems to just be for setting/getting
> > > your driver-private properties. Usually people use modetest and similar
> > > tools, but if there's demand for setting properties in debugfs (we already
> > > have all the infrastructure for dumping the entire kms state, see the
> > > various atomic_print_state callbacks) I think that should be done with
> > > generic drm code.
> > >
> > > I'd drop this patch for now (if there's no other reason for it).
> >
> > Thanks for the input. It'd be helpful, for my own understanding, if this
> > can be elaborated a little more. We are using standard tools as well as
> > custom script/tool, but some specific properties / controls are hard to
> > be executed with modetest only unless we change the entire set up /
> > design between each run. The debugfs is used to run all (or as much as
> > possible) properties in a single run, and from what I understand, that
> > doesn't violate intended debugfs usage as long as it's not treated as a
> > stable ABI. The intention is to help isolate issues and enhance the
> > diagnostics. I agree, in the long term, this kind of stuff should be
> > handled in generic way, but would it be still reasonable to keep it
> > driver specific in the meantime?
> 
> Well since the property stuff needs more work anyway I think we could do
> it properly (for upstream) from the start.
> 
> What exactly is the issue with modetest? For intel we don't use it, we do
> all our testing using the igt gpu tests:
> 
> https://cgit.freedesktop.org/drm/igt
> 
> A big pile of these tests also run on non-intel (and we're definitely very
> much appreciating such work). But if you want just a bit of scripting,
> modetest should be able to do it. If not I guess we'll need patches.

For example, for DisplayPort, there are lane count / link rate, and the maximum 
values depend on the board or connected monitors. We are enforcing those values 
manually through debugfs before running tests. We will think how to remove the 
driver specific debugfs, and we can drop it for now. I'll take a look at the 
repo. Thanks for the pointer.

Thanks,
-hyun

> -Daniel
> >
> > Thanks,
> > -hyun
> >
> > > -Daniel
> > >
> > > > ---
> > > >  drivers/gpu/drm/xlnx/Kconfig   |  21 +++
> > > >  drivers/gpu/drm/xlnx/zynqmp_disp.c | 326
> > > +
> > > >  drivers/gpu/drm/xlnx/zynqmp_dp.c   | 304
> > > ++
> > > >  3 files changed, 651 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> > > > index 7c5529c..befce0f 100644
> > > > --- a/drivers/gpu/drm/xlnx/Kconfig
> > > > +++ b/drivers/gpu/drm/xlnx/Kconfig
> > > > @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
> > > >   this option if you have a Xilinx ZynqMP SoC with DisplayPort
> > > >   subsystem. The driver provides the kernel mode setting
> > > >   functionlaities for ZynqMP DP subsystem.
> > > > +
> > > > +config DRM_ZYNQMP_DISP_DEBUG_FS
> > > > +   bool "ZynqMP Display debugfs"
> > > > +   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > > > +   select DRM_ZYNQMP_DP_DEBUG_FS
> > > > +   help
> > > > + Enable the debugfs code for DP Sub driver. The debugfs code
> > > > + enables debugging or testing related features. It exposes some
> > > > + low level controls to the user space to help testing 
> > > > automation,
> > > > + as well as can enable additional diagnostic or statistical
> > > > + information.
> > > > +
> > > > +config DRM_ZYNQMP_DP_DEBUG_FS
> > > > +   bool "ZynqMP DP debugfs"
> > > > +   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > > > +   help
> > 

[GIT PULL] drm/tegra: Changes for v4.16-rc1 (with fixes)

[Thierry Reding]

Hi Dave,

The following changes since commit ebae8d07435ae91314f4a28d69b530d09c625815:

  drm/tegra: dc: Implement legacy blending (2017-12-21 14:55:55 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.16-rc1-fixes

for you to fetch changes up to 8f62142e490d761ceb92b55a7c05bb79294d6c6c:

  drm/tegra: dc: Properly cleanup overlay planes (2018-01-08 16:24:13 +0100)

This has fixes for the issues that Dmitry had pointed out in response to
my first pull request. It is based on top of my earlier pull request, so
I've only included the shortlog of the changes since then. It should be
safe to pull only this one in order to get all of the other changes as
well.

Thanks,
Thierry


drm/tegra: Changes for v4.16-rc1

The bulk of these changes are preparation work and addition of support
for Tegra186. Currently only HDMI output (the primary output on Jetson
TX2) is supported, but the hardware is also capable of doing DSI and
DisplayPort.

Tegra DRM now also uses the atomic commit helpers instead of the open-
coded variant that was only doing half its job. As a bit of a byproduct
of the Tegra186 support the driver also gained HDMI 2.0 as well as zpos
property support.

Along the way there are also a few patches to clean up a few things and
fix minor issues.


Thierry Reding (3):
  drm/tegra: dc: Restore YUV overlay support
  drm/tegra: dc: Fix possible_crtcs mask for planes
  drm/tegra: dc: Properly cleanup overlay planes

 drivers/gpu/drm/tegra/dc.c| 35 +++
 drivers/gpu/drm/tegra/plane.c |  5 +
 2 files changed, 28 insertions(+), 12 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Patch v2 1/2] dma-buf: add some lockdep asserts to the reservation object implementation

[Lucas Stach]

This adds lockdep asserts to the reservation functions which state in their
documentation that obj->lock must be held. Allows builds with PROVE_LOCKING
enabled to check that the locking requirements are met.

Signed-off-by: Lucas Stach 
---
v2: remove erroneous check from reservation_object_get_excl
---
 drivers/dma-buf/reservation.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index b44d9d7db347..accd398e2ea6 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -71,6 +71,8 @@ int reservation_object_reserve_shared(struct 
reservation_object *obj)
struct reservation_object_list *fobj, *old;
u32 max;
 
+   reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
 
if (old && old->shared_max) {
@@ -211,6 +213,8 @@ void reservation_object_add_shared_fence(struct 
reservation_object *obj,
 {
struct reservation_object_list *old, *fobj = obj->staged;
 
+   reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
obj->staged = NULL;
 
@@ -236,6 +240,8 @@ void reservation_object_add_excl_fence(struct 
reservation_object *obj,
struct reservation_object_list *old;
u32 i = 0;
 
+   reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
if (old)
i = old->shared_count;
@@ -276,6 +282,8 @@ int reservation_object_copy_fences(struct 
reservation_object *dst,
size_t size;
unsigned i;
 
+   reservation_object_assert_held(dst);
+
rcu_read_lock();
src_list = rcu_dereference(src->fence);
 
-- 
2.11.0

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

[Patch v2 2/2] dma-buf: clarify locking documentation for reservation_object_get_excl

[Lucas Stach]

The documentation was misleading, as for a lot of use-cases holding
the RCU read side lock is sufficient.

Signed-off-by: Lucas Stach 
---
 include/linux/reservation.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 21fc84d82d41..ae1175e5997c 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -204,7 +204,8 @@ reservation_object_unlock(struct reservation_object *obj)
  * @obj: the reservation object
  *
  * Returns the exclusive fence (if any).  Does NOT take a
- * reference.  The obj->lock must be held.
+ * reference. Writers must hold obj->lock, readers may only
+ * hold a RCU read side lock.
  *
  * RETURNS
  * The exclusive fence or NULL
-- 
2.11.0

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

Re: [GIT PULL] drm/tegra: Fixes for v4.15-rc1

[Thierry Reding]

On Thu, Jan 11, 2018 at 05:41:17PM +0100, Thierry Reding wrote:
> Hi Dave,
> 
>   Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes 
> (2018-01-09 12:03:10 +1000)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc8
> 
> for you to fetch changes up to d780537f9b49e9d714a454e5ed989d909beab8ec:
> 
>   drm/tegra: sor: Fix hang on Tegra124 eDP (2018-01-10 13:04:58 +0100)
> 
> Thanks,
> Thierry

I fat-fingered this, please disregard.

Sorry,
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 3/3] drm/amdgpu: Move to gtt before cpu accesses dma buf.

[Li, Samuel]

A good catch. I'll fix that.

Regards,
Samuel Li


> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, January 11, 2018 1:43 AM
> To: kbu...@01.org; Li, Samuel 
> Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; Li, Samuel ; Dan Carpenter
> 
> Subject: Re: [PATCH 3/3] drm/amdgpu: Move to gtt before cpu accesses dma
> buf.
> 
> 
> Hi Samuel,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on drm/drm-next] [also build test WARNING on
> v4.15-rc7 next-20180110] [if your patch is applied to the wrong git tree,
> please drop us a note to help improve the system]
> 
> url:https://github.com/0day-ci/linux/commits/Samuel-Li/drm-amdgpu-
> allow-framebuffer-in-GART-memory-as-well/20180106-050432
> base:   git://people.freedesktop.org/~airlied/linux.git drm-next
> 
> smatch warnings:
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c:226
> amdgpu_gem_prime_export() error: 'buf' dereferencing possible ERR_PTR()
> 
> # https://github.com/0day-
> ci/linux/commit/6aa2afecb5a3efc463d200023839399571404843
> git remote add linux-review https://github.com/0day-ci/linux git remote
> update linux-review git checkout
> 6aa2afecb5a3efc463d200023839399571404843
> vim +/buf +226 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> 
> 6aa2afecb5 Samuel Li   2018-01-04  211
> d38ceaf99e Alex Deucher2015-04-20  212  struct dma_buf
> *amdgpu_gem_prime_export(struct drm_device *dev,
> d38ceaf99e Alex Deucher2015-04-20  213
>   struct drm_gem_object *gobj,
> d38ceaf99e Alex Deucher2015-04-20  214
>   int flags)
> d38ceaf99e Alex Deucher2015-04-20  215  {
> d38ceaf99e Alex Deucher2015-04-20  216struct amdgpu_bo *bo =
> gem_to_amdgpu_bo(gobj);
> 4b277247b1 Christian König 2017-11-13  217struct dma_buf *buf;
> d38ceaf99e Alex Deucher2015-04-20  218
> e1eb899b45 Christian König 2017-08-25  219if
> (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
> e1eb899b45 Christian König 2017-08-25  220bo->flags &
> AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
> d38ceaf99e Alex Deucher2015-04-20  221return ERR_PTR(-
> EPERM);
> d38ceaf99e Alex Deucher2015-04-20  222
> 4b277247b1 Christian König 2017-11-13  223buf =
> drm_gem_prime_export(dev, gobj, flags);
> 4b277247b1 Christian König 2017-11-13  224if (!IS_ERR(buf))
> 4b277247b1 Christian König 2017-11-13  225buf->file->f_mapping
> = dev->anon_inode->i_mapping;
> 6aa2afecb5 Samuel Li   2018-01-04 @226buf->ops =
> _dmabuf_ops;
> 6aa2afecb5 Samuel Li   2018-01-04  227
> 4b277247b1 Christian König 2017-11-13  228return buf;
> d38ceaf99e Alex Deucher2015-04-20  229  }
> 6aa2afecb5 Samuel Li   2018-01-04  230
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] drm/tegra: Fixes for v4.15-rc8

[Thierry Reding]

Hi Dave,

The following changes since commit b0bb222440a5c8273f67dd37946707e6ba6ad832:

  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes 
(2018-01-09 12:03:10 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc8

for you to fetch changes up to d780537f9b49e9d714a454e5ed989d909beab8ec:

  drm/tegra: sor: Fix hang on Tegra124 eDP (2018-01-10 13:04:58 +0100)

Thanks,
Thierry


drm/tegra: Fixes for v4.15-rc8

A single fix for a Tegra124 eDP regression introduced by the SOR changes
in v4.15-rc1.


Thierry Reding (1):
  drm/tegra: sor: Fix hang on Tegra124 eDP

 drivers/gpu/drm/tegra/sor.c | 3 +++
 1 file changed, 3 insertions(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] drm/tegra: Fixes for v4.15-rc1

[Thierry Reding]

Hi Dave,

  Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes 
(2018-01-09 12:03:10 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc8

for you to fetch changes up to d780537f9b49e9d714a454e5ed989d909beab8ec:

  drm/tegra: sor: Fix hang on Tegra124 eDP (2018-01-10 13:04:58 +0100)

Thanks,
Thierry


drm/tegra: Fixes for v4.15-rc8

A single fix for a Tegra124 eDP regression introduced by the SOR changes
in v4.15-rc1.


Thierry Reding (1):
  drm/tegra: sor: Fix hang on Tegra124 eDP

 drivers/gpu/drm/tegra/sor.c | 3 +++
 1 file changed, 3 insertions(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Daniel Vetter]

On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard
 wrote:
> On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
>> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
>> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
>> > > > Some drivers duplicate the logic to create a property to store a 
>> > > > per-plane
>> > > > alpha.
>> > > >
>> > > > Let's create a helper in order to move that to the core.
>> > > >
>> > > > Cc: Boris Brezillon 
>> > > > Cc: Laurent Pinchart 
>> > > > Signed-off-by: Maxime Ripard 
>> > >
>> > > Do we have userspace for this?
>> >
>> > Wayland seems to be on its way to implement this, with ChromeOS using
>> > it:
>> > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>> >
>> > and more specifically:
>> > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
>>
>> Yay, would be good to include these links in the patch description. Really
>> happy we're having a real standard now used by multiple people.
>
> I will.
>
>> > > Is encoding a fixed 0-255 range really the best idea?
>> >
>> > I don't really know, is there hardware or formats where there is more
>> > than 255? Or did you mean less than that?
>>
>> 30bit I'd assume wants more alpha. In the past we've done some fixed-point
>> stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
>> blend equation docs is also what I recommend (and that we map from 0-255
>> to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
>> 0.16 fixed point, stored in a u16 is probably best. That's what we're
>> doing for gamma tables already, and that way drivers can simply throw away
>> the lower bits.
>
> But that would also break the two users of that property that won't be
> able to move to the generic property (with the same name) without
> breaking userspace. The point of that patch was to allow some code
> consolidation, and that would mean failing to do so here :/

Let me try to clarify:
- We'll keep the exact existing property semantics with the 0-255
range for the userspace visible property.

- But internally, in the decode value that we store into
drm_plane_state, we'll do the slightly more future proof thing with a
few more bits.

That gives us the option of exposing those bits in the future without
having to change all the drivers again (which we have to do for this
series here already anyway, since the decoded value moves into
drm_plane_state from driver subclasses).

Definitely not asking to break userspace here :-)

Cheers, Daniel

>> > > I know other drivers have skimped on the rules here a bit ... But at 
>> > > least
>> > > internally (i.e. within the drm_plane_state) we probably should restrict
>> > > ourselves to u8. And this needs real docs (i.e. the full blend equation
>> > > drivers are supposed to implement).
>> >
>> > You mean straight vs premultiplied? Maybe we should implement this as
>> > an additional property in read only depending on how the hardware
>> > behaves?
>>
>> No need for an additional property right now, but definitely document
>> whether you mean straight or pre-multiplied. Just writing down the blend
>> equation is probably best.
>
> Ack.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Maxime Ripard]

On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > > Some drivers duplicate the logic to create a property to store a 
> > > > per-plane
> > > > alpha.
> > > > 
> > > > Let's create a helper in order to move that to the core.
> > > > 
> > > > Cc: Boris Brezillon 
> > > > Cc: Laurent Pinchart 
> > > > Signed-off-by: Maxime Ripard 
> > > 
> > > Do we have userspace for this?
> > 
> > Wayland seems to be on its way to implement this, with ChromeOS using
> > it:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
> > 
> > and more specifically:
> > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
> 
> Yay, would be good to include these links in the patch description. Really
> happy we're having a real standard now used by multiple people.

I will.

> > > Is encoding a fixed 0-255 range really the best idea?
> > 
> > I don't really know, is there hardware or formats where there is more
> > than 255? Or did you mean less than that?
> 
> 30bit I'd assume wants more alpha. In the past we've done some fixed-point
> stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
> blend equation docs is also what I recommend (and that we map from 0-255
> to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
> 0.16 fixed point, stored in a u16 is probably best. That's what we're
> doing for gamma tables already, and that way drivers can simply throw away
> the lower bits.

But that would also break the two users of that property that won't be
able to move to the generic property (with the same name) without
breaking userspace. The point of that patch was to allow some code
consolidation, and that would mean failing to do so here :/

> > > I know other drivers have skimped on the rules here a bit ... But at least
> > > internally (i.e. within the drm_plane_state) we probably should restrict
> > > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > > drivers are supposed to implement).
> > 
> > You mean straight vs premultiplied? Maybe we should implement this as
> > an additional property in read only depending on how the hardware
> > behaves?
> 
> No need for an additional property right now, but definitely document
> whether you mean straight or pre-multiplied. Just writing down the blend
> equation is probably best.

Ack.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]

[bugzilla-daemon]

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

--- Comment #6 from Vedran Miletić  ---
Still the case in Fedora rawhide with kernel 4.15.0-0.rc7.git0.1.fc28.x86_64

[ 2582.430297] [drm] radeon: finishing device.
[ 2582.445874] [TTM] Finalizing pool allocator
[ 2582.445877] [TTM] Finalizing DMA pool allocator
[ 2582.445912] WARNING: CPU: 2 PID: 2446 at
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:565
ttm_dma_free_pool.part.9+0x11c/0x120 [ttm]
[ 2582.445913] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security
ebtable_filter ebtables ip6table_filter ip6_tables sunrpc intel_rapl
x86_pkg_temp_thermal snd_hda_codec_realtek intel_powerclamp
snd_hda_codec_generic coretemp snd_hda_codec_hdmi snd_hda_intel snd_hda_codec
kvm_intel kvm snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer
snd iTCO_wdt wmi_bmof irqbypass eeepc_wmi asus_wmi sparse_keymap rfkill
iTCO_vendor_support crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
intel_cstate
[ 2582.445930]  intel_uncore mxm_wmi intel_rapl_perf soundcore mei_me mei
i2c_i801 shpchp lpc_ich wmi xfs libcrc32c amdgpu chash i915 radeon(-)
i2c_algo_bit drm_kms_helper ttm r8169 drm crc32c_intel mii video
[ 2582.445937] CPU: 2 PID: 2446 Comm: modprobe Not tainted
4.15.0-0.rc7.git0.1.fc28.x86_64 #1
[ 2582.445938] Hardware name: ASUS All Series/Z87-A, BIOS 1602 10/29/2013
[ 2582.445941] RIP: 0010:ttm_dma_free_pool.part.9+0x11c/0x120 [ttm]
[ 2582.445941] RSP: 0018:b1d8029afd40 EFLAGS: 00010202
[ 2582.445942] RAX: 0202 RBX: 8cda93b27540 RCX:

[ 2582.445942] RDX: 00018041 RSI: f7c0104eca80 RDI:
b1d8029afcf0
[ 2582.445943] RBP: 8cda9ce482d8 R08: 8cda93b2a900 R09:
00018040
[ 2582.445943] R10: b1d8029afbc0 R11:  R12:
0008
[ 2582.445943] R13: c046f1d0 R14: 8cda9d193100 R15:
c046f160
[ 2582.445944] FS:  7f4991aca0c0() GS:8cdaafa8()
knlGS:
[ 2582.445945] CS:  0010 DS:  ES:  CR0: 80050033
[ 2582.445945] CR2: 7fff854e7968 CR3: 0003a6dbe002 CR4:
001606e0
[ 2582.445946] Call Trace:
[ 2582.445950]  ttm_dma_page_alloc_fini+0x7d/0xf0 [ttm]
[ 2582.445952]  ttm_mem_global_release+0x14/0x80 [ttm]
[ 2582.445963]  drm_global_item_unref+0x44/0x60 [drm]
[ 2582.445976]  radeon_ttm_fini+0x12b/0x190 [radeon]
[ 2582.445984]  radeon_bo_fini+0xe/0x30 [radeon]
[ 2582.445996]  cik_fini+0xc6/0xf0 [radeon]
[ 2582.446002]  radeon_device_fini+0x31/0x110 [radeon]
[ 2582.446007]  radeon_driver_unload_kms+0x3e/0x70 [radeon]
[ 2582.446013]  drm_dev_unregister+0x3c/0xe0 [drm]
[ 2582.446018]  drm_put_dev+0x2e/0x60 [drm]
[ 2582.446020]  pci_device_remove+0x36/0xb0
[ 2582.446023]  device_release_driver_internal+0x157/0x220
[ 2582.446024]  driver_detach+0x32/0x60
[ 2582.446025]  bus_remove_driver+0x51/0xd0
[ 2582.446026]  pci_unregister_driver+0x22/0xa0
[ 2582.446036]  radeon_exit+0xc/0x64 [radeon]
[ 2582.446038]  SyS_delete_module+0x1a1/0x2b0
[ 2582.446040]  ? exit_to_usermode_loop+0x8a/0xa0
[ 2582.446042]  entry_SYSCALL_64_fastpath+0x1a/0x7d
[ 2582.446043] RIP: 0033:0x7f4990fc8a17
[ 2582.446043] RSP: 002b:7fff854eaa98 EFLAGS: 0206
[ 2582.446044] Code: 00 00 00 00 ad de 48 89 df 48 89 03 48 05 00 01 00 00 48
89 43 08 e8 24 7d 09 e8 5b 5d 41 5c 48 8b 3d 99 b8 00 00 e9 b4 e7 6d e8 <0f> ff
eb b3 0f 1f 44 00 00 48 8b 06 48 85 c0 74 0d 48 85 ff 74 
[ 2582.446057] ---[ end trace f3849642451d16df ]---
[ 2582.446223] [TTM] Zone  kernel: Used memory at exit: 2080 kiB
[ 2582.446225] [TTM] Zone   dma32: Used memory at exit: 24 kiB
[ 2582.446225] [drm] radeon: ttm finalized

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

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

Hopefully final drm/i915 fixes for v4.15:
- Fix a KASAN reported use after free
- Whitelist a register to avoid hangs
- GVT fixes

BR,
Jani.

The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d:

  Linux 4.15-rc7 (2018-01-07 14:22:41 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-01-11-1

for you to fetch changes up to 5005c8514285ae4f28e862f8d91faaa2015e03a3:

  drm/i915: Don't adjust priority on an already signaled fence (2018-01-11 
11:42:53 +0200)


Hopefully final drm/i915 fixes for v4.15:
- Fix a KASAN reported use after free
- Whitelist a register to avoid hangs
- GVT fixes


Changbin Du (1):
  drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser

Chris Wilson (1):
  drm/i915: Don't adjust priority on an already signaled fence

Jani Nikula (1):
  Merge tag 'gvt-fixes-2018-01-08' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Kenneth Graunke (1):
  drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.

Zhi Wang (1):
  drm/i915/gvt: Clear the shadow page table entry after post-sync

 drivers/gpu/drm/i915/gvt/cmd_parser.c  | 4 ++--
 drivers/gpu/drm/i915/gvt/gtt.c | 5 -
 drivers/gpu/drm/i915/i915_gem.c| 2 +-
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 drivers/gpu/drm/i915/intel_engine_cs.c | 5 +
 drivers/gpu/drm/i915/intel_lrc.c   | 3 +++
 6 files changed, 17 insertions(+), 4 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #180 from x...@amail.club ---
>From watching this bug progress over the last two years and not really
improving, I guess this problem is never going to get fixed, at least not too
soon.

>From my testing last year, it would seem that the majority who have this
problem own the MSI brand one, both 390 an 390x have the problem, and there
isn't a proper workaround for it besides forcing the memory(maybe core) clock
high, so it would seem that the clock is not being set correctly, or the
"sensor" isn't realizing that clock should be increased.

I have tried every kernel from the past year in hopes that this problem would
be solved, with no successful test, I have tried using both AMDGPU and radeon
modules, while blacklisting the other to make sure that there was not a problem
with one, and still no success.

On Windows 10, there is never an issue with artifacts, or crashes.

If there is anyway to get this on a fast track to being fixed, please let
everyone know, so that we can help, that is what community is for...I think.

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

Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms bindings

[Rob Herring]

On Wed, Jan 10, 2018 at 8:04 PM, Hyun Kwon  wrote:
> Hi Rob,
>
> Thanks for the feedback.
>
>> -Original Message-
>> From: Rob Herring [mailto:r...@kernel.org]
>> Sent: Monday, January 08, 2018 8:00 PM
>> To: Hyun Kwon 
>> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
>> Simek 
>> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
>> bindings
>>
>> On Thu, Jan 04, 2018 at 06:05:50PM -0800, Hyun Kwon wrote:
>> > The dt binding for Xilinx DRM KMS driver.
>>
>> Bindings are for h/w, not drivers.
>
> I'll rephrase this.
>
>>
>> >
>> > Signed-off-by: Hyun Kwon 
>> > ---
>> >  .../devicetree/bindings/display/xlnx/xlnx,kms.txt| 20
>> 
>> >  1 file changed, 20 insertions(+)
>> >  create mode 100644
>> Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> > new file mode 100644
>> > index 000..8dcd552
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> > @@ -0,0 +1,20 @@
>> > +Xilinx KMS Pipeline
>> > +---
>> > +
>> > +Xilinx display pipelines can be designed with hardened video IPs and soft
>> video
>> > +IPs in programmable logic. This KMS module provides the common
>> functionality
>> > +of individual subdevice drivers, and glue logics between them.
>> > +
>> > +Required properties:
>> > +
>> > +- compatible: Must be "xlnx,kms".
>
> I'll also rephrase the description and rename this to xlnx,display.
>
>> > +
>> > +- ports: phandles for CRTC ports, using the DT bindings defined in
>> > +  Documentation/devicetree/bindings/graph.txt.
>>
>> This use of ports is not part of the graph binding.
>
> I'll add more details in the description.
>
>>
>> > +
>> > +Example:
>> > +
>> > +   xlnx_drm: xlnx_drm {
>> > +   compatible = "xlnx,kms";
>>
>> drm and kms are Linuxisms.
>
> I agree. I'll remove linux subsystem specific terms.
>
>>
>> Why do you need this node?
>
> This node is used to represent a display pipeline as a single entity, which 
> can consist of multiple components / IPs. I'll elaborate more per your 
> suggestion.

You generally don't need that. Just have the DRM driver match with the
first block in the display pipeline. Then use the OF graph to connect
to the other components in the pipeline. It would help to have a block
diagram showing the data pipelines and h/w blocks.

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

Re: [PATCH v2] drm/amdkfd: Fix potential NULL pointer dereferences

[Oded Gabbay]

On Thu, Jan 11, 2018 at 1:15 AM, Gustavo A. R. Silva
 wrote:
> In case kfd_get_process_device_data returns null, there are some
> null pointer dereferences in functions kfd_bind_processes_to_device
> and kfd_unbind_processes_from_device.
>
> Fix this by printing a WARN_ON for PDDs that aren't found and skip
> them with continue statements.
>
> Addresses-Coverity-ID: 1463794 ("Dereference null return value")
> Addresses-Coverity-ID: 1463772 ("Dereference null return value")
> Suggested-by: Felix Kuehling 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> Changes in v2:
>  Print a WARN_ON and skip PDDs that aren't found instead of returning
>  an error.
>
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index a22fb071..4ff5f0f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -461,7 +461,8 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
> hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
> mutex_lock(>mutex);
> pdd = kfd_get_process_device_data(dev, p);
> -   if (pdd->bound != PDD_BOUND_SUSPENDED) {
> +
> +   if (WARN_ON(!pdd) || pdd->bound != PDD_BOUND_SUSPENDED) {
> mutex_unlock(>mutex);
> continue;
> }
> @@ -501,6 +502,11 @@ void kfd_unbind_processes_from_device(struct kfd_dev 
> *dev)
> mutex_lock(>mutex);
> pdd = kfd_get_process_device_data(dev, p);
>
> +   if (WARN_ON(!pdd)) {
> +   mutex_unlock(>mutex);
> +   continue;
> +   }
> +
> if (pdd->bound == PDD_BOUND)
> pdd->bound = PDD_BOUND_SUSPENDED;
> mutex_unlock(>mutex);
> --
> 2.7.4
>
This patch is:
Reviewed-by: Oded Gabbay 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly

[Jani Nikula]

On Thu, 11 Jan 2018, Laurent Pinchart  wrote:
> My preference, however, would be for devm_regulator_get_optional() to return 
> NULL when no regulator is present. The current implementation returns -ENODEV 
> in multiple cases, making it impossible to properly discriminate between 
> having no regulator and not being able to get the regulator due to an error.

Just a word of warning, IS_ERR(NULL) is false, and your proposed change
would apparently require quite a churn all over the kernel.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v2 6/8] drm: Handle fbdev emulation in core

[Noralf Trønnes]

Den 11.01.2018 08.45, skrev Daniel Vetter:

On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote:

Den 09.01.2018 11.38, skrev Daniel Vetter:

On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:

Prepare for generic fbdev emulation by letting DRM core work directly
with the fbdev compatibility layer. This is done by adding new fbdev
helper vtable callbacks for restore, hotplug_event, unregister and
release.

Signed-off-by: Noralf Trønnes 

No clue whether my idea is any good, but inspired by the bootsplash
discussion, and the prospect that we might get other in-kernel drm/kms
clients I'm wondering whether we should make this a bit more generic and
tie it to drm_file?

The idea would be to have a list of internal drm clients by putting all
the internal drm_files onto a list (same way we do with the userspace
ones). Then we'd just walk that list and call ->hotplug, ->unregister and
->release at the right places.

->restore would be a bit different, I guess for that we'd only call the
->restore callback of the very first kernel-internal client.

With that we could then add/remove kernel-internal drm clients like normal
userspace clients, which should make integration of emergency consoles,
boot splashes and whatever else real easy. And I think it would be a lot
cleaner than leaking fb_helper knowledge into the drm core, which feels a
rather backwards.

Otoh that feels a bit overengineered (but at least it shouldn't be a lot
more code really). If the list is too much work we could start with 1
drm_file * pointer for internal stuff (but would still need locking, so
list_head is probably easier).

Thoughts?

I prefer to have a proper in-kernel client API from the get go, instead
of fixing it up later. The reason I skipped spending time on it in this
RFC, was that I didn't know if I was on the right track at the right time
to get the necessary attention to make this dumb_buffer idea happen.

With a drm_file centric approach, are you thinking something like this:

  struct drm_device {
+    struct list_head filelist_internal;
  };

+struct drm_file_funcs {
+    int (*restore)(struct drm_file *file);
+    void (*hotplug)(struct drm_file *file);
+    void (*unregister)(struct drm_file *file);

I guess we still need a cleanup callback here? For the usual two-stage
driver unload sequence of 1. unregister 2. cleanup.


There's no need for a cleanup callback in this scenario.
The client holds a ref on drm_device through drm_internal_open() and if
it can't release the drm_file on .unregister, there won't be any cleanup.
When the client is in a position to release drm_file (fb_close), it will
do so and the ref is dropped.

If for some reason we can't take a ref, then we need to use
drm_device.open_count to avoid drm_device going away in drm_dev_unplug().

Noralf.




+};

  struct drm_file {
+    struct drm_device *dev;
+    const struct drm_file_funcs *funcs;
  };

  struct drm_file *drm_file_alloc(struct drm_minor *minor)
  {
+    file->dev = dev;
  }

struct drm_file* drm_internal_open(struct drm_device *dev,
                    const struct drm_file_funcs *funcs)
     struct drm_file *file;
     int ret;

     if (!try_module_get(dev->driver->fops->owner))
         return ERR_PTR(-ENODEV);

     drm_dev_ref(dev);

     file = drm_file_alloc(dev);
     if (IS_ERR(file)) {
         drm_dev_unref(dev);
         module_put(dev->driver->fops->owner);
         return file;
     }

     file->funcs = funcs;

     mutex_lock(>filelist_mutex);
     list_add(>lhead, >filelist_internal);
     mutex_unlock(>filelist_mutex);

     return file;
}

void drm_internal_release(struct drm_file *file)
{
     struct drm_device *dev = file->dev;

     mutex_lock(>filelist_mutex);
     list_del(>lhead);
     mutex_unlock(>filelist_mutex);

     drm_file_free(file);
     drm_dev_unref(dev);
     module_put(dev->driver->fops->owner);
}

  void drm_lastclose(struct drm_device *dev)
  {

+    mutex_lock(>filelist_mutex);
+    list_for_each_entry(file, >filelist_internal, lhead) {
+        if (file->funcs && file->funcs->restore &&
+            !file->funcs->restore(file))
+                break;
+    mutex_unlock(>filelist_mutex);
  }

  void drm_kms_helper_hotplug_event(struct drm_device *dev)
  {

+    mutex_lock(>filelist_mutex);
+    list_for_each_entry(file, >filelist_internal, lhead) {
+        if (file->funcs && file->funcs->hotplug)
+            file->funcs->hotplug(file);
+    mutex_unlock(>filelist_mutex);
  }

How is locking done when .unregister will call into drm_internal_release()?

  void drm_dev_unregister(struct drm_device *dev)
  {

+    list_for_each_entry(file, >filelist_internal, lhead) {
+        if (file->funcs && file->funcs->unregister)
+            file->funcs->unregister(file);
  }

There is also the case where .unregister can't release the drm_file
because userspace has mmap'ed the buffer (fbdev). The client holds a ref
on drm_device so cleanup is stalled but that requires 

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

[Philippe CORNU]

Hi Brian & All *DSI DRM experts*,

1) Re-reading this patch, I realize that the returned value of 
dw_mipi_dsi_host_transfer() is not correct: we should return the number 
of transfered/received bytes...

so I think there are two solutions: fix this in this serie or add a TODO 
for later (both solutions are fine to me :-)


2) Digging more into the drm code, the function 
mipi_dsi_device_transfer() in drm_mipi_dsi.c is called in the same file 
by the 3 following functions: mipi_dsi_shutdown_peripheral(), 
mipi_dsi_turn_on_peripheral() & 
mipi_dsi_set_maximum_return_packet_size(). All these 3 functions are 
expecting "Return: 0 on success or a negative error code on failure." 
that is not in line with the transfer function.

So then, we can change the documentation in this file and have instead 
"* Return: The number of bytes transmitted on success or a negative 
error code on failure." as for mipi_dsi_generic_write()...
Or we can change the source code of these 3 functions to match with the 
documentation "Return: 0 on success...".

note: Hopefully, "users" of these 3 functions test the sign of the 
return value (or do not use it).

Does anyone have a preferred solutions?

Many thanks
Philippe :-)

On 01/09/2018 09:32 PM, Brian Norris wrote:
> This takes care of 2 TODOs in this driver, by using the common DSI
> packet-marshalling code instead of our custom short/long write code.
> This both saves us some duplicated code and gets us free support for
> command types that weren't already part of our switch block (e.g.,
> MIPI_DSI_GENERIC_LONG_WRITE).
> 
> The code logic stays mostly intact, except that it becomes unnecessary
> to split the short/long write functions, and we have to copy data a bit
> more.
> 
> Along the way, I noticed that loop bounds were a little odd:
> 
>   while (DIV_ROUND_UP(len, pld_data_bytes))
> 
> This really was just supposed to be 'len != 0', so I made that more
> clear.
> 
> Tested on RK3399 with some pending refactoring patches by Nickey Yang,
> to make the Rockchip DSI driver wrap this common driver.
> 
> Signed-off-by: Brian Norris 
> Reviewed-by: Philippe Cornu 
> Tested-by: Philippe Cornu 
> ---
> v2:
>   * remove "dcs" naming, since these commands handle generic DSI too, not
> just DCS (thanks Philippe)
>   * add Philippe's {Tested,Reviewed}-by
> ---
>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78 
> ++-
>   1 file changed, 16 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4fd66ec..ed91e32ee43a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -136,10 +136,6 @@
>GEN_SW_0P_TX_LP)
>   
>   #define DSI_GEN_HDR 0x6c
> -/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet() 
> */
> -#define GEN_HDATA(data)  (((data) & 0x) << 8)
> -#define GEN_HTYPE(type)  (((type) & 0xff) << 0)
> -
>   #define DSI_GEN_PLD_DATA0x70
>   
>   #define DSI_CMD_PKT_STATUS  0x74
> @@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
> dw_mipi_dsi *dsi, u32 hdr_val)
>   return 0;
>   }
>   
> -static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
> -const struct mipi_dsi_msg *msg)
> -{
> - const u8 *tx_buf = msg->tx_buf;
> - u16 data = 0;
> - u32 val;
> -
> - if (msg->tx_len > 0)
> - data |= tx_buf[0];
> - if (msg->tx_len > 1)
> - data |= tx_buf[1] << 8;
> -
> - if (msg->tx_len > 2) {
> - dev_err(dsi->dev, "too long tx buf length %zu for short 
> write\n",
> - msg->tx_len);
> - return -EINVAL;
> - }
> -
> - val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
> -}
> -
> -static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
> -   const struct mipi_dsi_msg *msg)
> +static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> +  const struct mipi_dsi_packet *packet)
>   {
> - const u8 *tx_buf = msg->tx_buf;
> - int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
> - u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
> + const u8 *tx_buf = packet->payload;
> + int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
>   u32 remainder;
>   u32 val;
>   
> - if (msg->tx_len < 3) {
> - dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
> - msg->tx_len);
> - return -EINVAL;
> - }
> -
> - while (DIV_ROUND_UP(len, pld_data_bytes)) {
> + while (len) {
>   if (len < 

Re: [PATCH] drm/bridge/synopsys: dsi: make dw_mipi_dsi_bridge_mode_set() static

[Philippe CORNU]

Hi Brian,

Reviewed-by: Philippe Cornu 

Many thanks,
Philippe :-)

On 01/09/2018 09:33 PM, Brian Norris wrote:
> sparse complains:
> 
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:703:6: warning: symbol
> 'dw_mipi_dsi_bridge_mode_set' was not declared. Should it be static?
> 
> Signed-off-by: Brian Norris 
> ---
>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 90f13df6f106..d60a77e98b57 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -700,9 +700,9 @@ static void dw_mipi_dsi_bridge_post_disable(struct 
> drm_bridge *bridge)
>   pm_runtime_put(dsi->dev);
>   }
>   
> -void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
> -  struct drm_display_mode *mode,
> -  struct drm_display_mode *adjusted_mode)
> +static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
>   {
>   struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
>   const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly

[Maxime Ripard]

Hi,

On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> (CC'ing Mark Brown)
> 
> Thank you for the patch.
> 
> On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> > The devm_regulator_get_optional function, unlike it was assumed in the
> > commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> > property"), is actually returning an error pointer with -ENODEV instead of
> > NULL when there's no regulator to find.
> > 
> > Make sure we handle that case properly.
> > 
> > Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> > property") Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> > b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> > 100644
> > --- a/drivers/gpu/drm/panel/panel-lvds.c
> > +++ b/drivers/gpu/drm/panel/panel-lvds.c
> > @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> > *pdev) lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> > if (IS_ERR(lvds->supply)) {
> > ret = PTR_ERR(lvds->supply);
> > -   dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> > -   return ret;
> > +
> > +   if (ret != -ENODEV) {
> > +   dev_err(lvds->dev, "failed to request regulator: %d\n", 
> > ret);
> > +   return ret;
> 
> I wouldn't print an error message if ret == -EPROBE_DEFER.
> 
> > +   } else {
> > +   lvds->supply = NULL;
> > +   }
> > }
> 
> How about
> 
>   lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
>   if (IS_ERR(lvds->supply)) {
>   ret = PTR_ERR(lvds->supply);
>   if (ret != -ENODEV) {
>   if (ret == -EPROBE_DEFER)

I guess that would be != -EPROBE_DEFER

>   dev_err(lvds->dev, "failed to request 
> regulator: %d\n", ret);
>   return ret;
>   }
> 
>   lvds->supply = NULL;
>   }

Otherwise, it works for me.

> My preference, however, would be for devm_regulator_get_optional() to return 
> NULL when no regulator is present. The current implementation returns -ENODEV 
> in multiple cases, making it impossible to properly discriminate between 
> having no regulator and not being able to get the regulator due to an error.

It would feel more intuitive to me too, but it would also require to
fix most of the call sites that would have a similar pattern.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly

[Laurent Pinchart]

Hi Maxime,

(CC'ing Mark Brown)

Thank you for the patch.

On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> The devm_regulator_get_optional function, unlike it was assumed in the
> commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> property"), is actually returning an error pointer with -ENODEV instead of
> NULL when there's no regulator to find.
> 
> Make sure we handle that case properly.
> 
> Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> property") Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> *pdev) lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
>   if (IS_ERR(lvds->supply)) {
>   ret = PTR_ERR(lvds->supply);
> - dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> - return ret;
> +
> + if (ret != -ENODEV) {
> + dev_err(lvds->dev, "failed to request regulator: %d\n", 
> ret);
> + return ret;

I wouldn't print an error message if ret == -EPROBE_DEFER.

> + } else {
> + lvds->supply = NULL;
> + }
>   }

How about

lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
if (IS_ERR(lvds->supply)) {
ret = PTR_ERR(lvds->supply);
if (ret != -ENODEV) {
if (ret == -EPROBE_DEFER)
dev_err(lvds->dev, "failed to request 
regulator: %d\n", ret);
return ret;
}

lvds->supply = NULL;
}

My preference, however, would be for devm_regulator_get_optional() to return 
NULL when no regulator is present. The current implementation returns -ENODEV 
in multiple cases, making it impossible to properly discriminate between 
having no regulator and not being able to get the regulator due to an error.

Mark, what do you think about this ?

>   /* Get GPIOs and backlight controller. */

-- 
Regards,

Laurent Pinchart

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

Re: [Intel-gfx] [PATCH v2] x86/gpu: add CFL to early quirks

[Timo Aaltonen]

On 15.12.2017 23:19, Rodrigo Vivi wrote:
> On Fri, Dec 15, 2017 at 04:39:25PM +, Ingo Molnar wrote:
>>
>> * Lucas De Marchi  wrote:
>>
>>> CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
>>> allow the memory region to be stolen, otherwise we could have RAM being
>>> arbitrarily overwritten if for example we keep using the UEFI framebuffer,
>>> depending on how BIOS has set up the e820 map.
>>>
>>> Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
>>> Signed-off-by: Lucas De Marchi 
>>> Cc: Rodrigo Vivi 
>>> Cc: Anusha Srivatsa 
>>> Cc: Jani Nikula 
>>> Cc: Joonas Lahtinen 
>>> Cc: David Airlie 
>>> Cc: intel-...@lists.freedesktop.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: Ingo Molnar 
>>> Cc: H. Peter Anvin 
>>> Cc: Thomas Gleixner 
>>> Cc: x...@kernel.org
>>> Cc:  # v4.13+ 0890540e21cf drm/i915: add GT number 
>>> to intel_device_info
>>> Cc:  # v4.13+ 41693fd52373 drm/i915/kbl: Change a 
>>> KBL pci id to GT2 from GT1.5
>>> Cc:  # v4.13+
>>> Reviewed-by: Rodrigo Vivi 
>>> ---
>>>
>>> v2: improve commit message, add Fixes tag and CC stable
>>>
>>>  arch/x86/kernel/early-quirks.c | 1 +
>>>  include/drm/i915_pciids.h  | 6 ++
>>>  2 files changed, 7 insertions(+)
>>
>> Acked-by: Ingo Molnar 
> 
> Merged to drm-intel-next-queued.
> Thanks for the patches, suggestions and acks.

Shouldn't this go to v4.15 as well, because CFL is enabled there? I
don't see it in rc8.

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

Re: [PATCH v3 0/3] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate

[Maxime Ripard]

On Tue, Jan 09, 2018 at 01:03:20PM +1100, Jonathan Liu wrote:
> This patchset fixes several issues in sun4i_tmds_determine_rate that I
> discovered while trying to get a projector connected to an Olimex
> A20-OLinuXino-LIME using HDMI with a native resolution of 1280x800 and
> pixel clock of 83.5 MHz to display at its native resolution.

Queued all three patches as fixes, thanks!
maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH v5] drm/omap: plane zpos/zorder management improvements

[Laurent Pinchart]

Hi Daniel,

On Thursday, 11 January 2018 10:19:50 EET Daniel Vetter wrote:
> On Wed, Jan 10, 2018 at 06:28:51PM +0200, Peter Ujfalusi wrote:
> > On 01/09/2018 04:40 PM, Daniel Vetter wrote:
> >> On Tue, Jan 09, 2018 at 04:18:48PM +0200, Peter Ujfalusi wrote:
> >>> On 2018-01-09 14:44, Daniel Vetter wrote:
> > Changes since v4:
> > - further simplify the zpos checking by using a mask and a single
> >   loop
> > - Commit message has been extended
> > 
> > Changes since v3:
> > - Use drm_plane_index() instead of storing the same index wothin
> >   omap_plane struct
> > - Optimize the zpos validation loop so we avoid extra checks.
> > 
> > Changes since v2:
> > - The check for duplicate zpos is moved to omap_crtc
> > 
> > Changes since v1:
> > - Dropped the zpos normalization related patches
> > - New patch based on the discussion, see commit message.
>  
>  Sorry for jumping in late to the party, but except when you have a
>  really, really, really good reason for why omapdrm has to not normalize
>  zpos like the other drivers do in this case, then I think we should be
>  consistent.
>  
>  An inconsistent kms uapi is a lot worse than an uapi with some design
>  issues: The latter just means we eventually need v2, the former
>  guarantees
>  we need v2.
> >>> 
> >>> Even if the v2 contains the "drm/blend: Account also the primary plane
> >>> of the crtc for normalized_zpos"?
> >>> It is to ensure that the crtc->primary plane is going to have zpos = 0,
> >>> even if it's plane_id is higher.
> >> 
> >> It's a bit a hack, but imo makes sense, given where we are with uapi.>
> >> Except it sounds like we have more bikesheds going on about what
> >> exactly zpos is supposed to do.
> > 
> > As https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html have this to say
> > about zpos:
> > "priority of the given plane on crtc (optional) Note that multiple active
> > planes on the same crtc can have an identical zpos value. The rule to
> > solving the conflict is to compare the plane object IDs; the plane with a
> > higher ID must be stacked on top of a plane with a lower ID."
> > 
> > It implies that the driver should not try to be clever about the
> > normalization of the zpos. Even if it make sense.
> >
> > Considering only crtc->primary is a bit flowed anyway as for the sake of
> > completeness the crtc->cursor plane should have been kept on top at the
> > same time.
> > 
> >>> As it was discussed we have use case when we have two (or more) crtcs,
> >>> each with one plane (they are the primary planes for the given crtc)
> >>> and user moves one of the plane from one crtc to another, where it is no
> >>> longer the primary plane, but still holds zpos = 0.
> >>> 
> >>> In this case we prefer to keep the actual primary plane of the crtc at
> >>> the bottom and stack the new planes on top.
> >> 
> >> Yeah that all sounds reasonable. Or we state that userspace in that case
> >> better readjust zpos to make it non-ambiguous. Or something else.
> >> 
> >> Just something that's consistent across drivers. I'm totally fine with
> >> "organically grown uapi with lots of cruds and hacks".
> > 
> > I'm fine with using the current normalization as it is and refer to the
> > UAPI doc if user space is not complying with it.
> > But then, should the normalization be forced in the core for all drivers
> > to get consistency?
> 
> We had that, but then removed it again for reasons I no longer entirely
> understand. I guess we can keep it as-is for now, or if you want you can
> float a patch to move it back into the main helpers.

The problem is that zpos normalization requires accessing the state of all 
enabled planes for a CRTC in order to compute (and store) the normalized zpos 
values. This thus forces all planes to be added to the commit state, even when 
the commit doesn't touch the zpos property. I assume this caused issues 
(possibly performance issues) in drivers that then performed hardware setup of 
all planes as a result.

It could be possible to implement zpos normalization in a more efficient way, 
or to make it possible for driver to optimize hardware setup when plane states 
have not changed. For instance (thinking out loud) we could add a bit to the 
plane state to tell whether anything has changed, drivers could then easily 
skip those planes.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 07/12] drm/sun4i: Add has_channel_0 TCON quirk

[Maxime Ripard]

On Wed, Jan 10, 2018 at 08:25:07PM +0100, Jernej Skrabec wrote:
> Some TCONs on newer SoCs doesn't support channel 0, since they are meant
> to be used only with TV or HDMI encoder.
> 
> Prepare support for them with adding has_channel_0 quirk.
> 
> Signed-off-by: Jernej Skrabec 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH v2 08/12] drm/sun4i: Add support for A83T second TCON

[Maxime Ripard]

On Wed, Jan 10, 2018 at 08:25:08PM +0100, Jernej Skrabec wrote:
> This TCON is connected to HDMI encoder.
> 
> Signed-off-by: Jernej Skrabec 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, ) == -22

[bugzilla-daemon]

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

--- Comment #11 from Marta Löfstedt  ---

https://patchwork.freedesktop.org/patch/197018/

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