Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

2017-06-27 Thread Daniel Vetter
On Tue, Jun 27, 2017 at 10:51 PM, Jeff Kirsher
 wrote:
> This was submitted and accepted into David Miller's net-next tree.  I can
> see if Dave can pull it into his net tree.  DOes stable need to pick this
> up as well?

Nah if it landed somewhere at least I'm happy, we can carry the fixup
for a while longer locally.

Thanks, Daniel
-- 
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: xilinx_drm and atomic modesetting

2017-06-27 Thread Hyun Kwon
Hi Jean-Francois,

As you noted, the Xilinx DRM driver in Xilinx tree is missing many mainline 
features including the atomic mode setting and needs some restructuring. Please 
feel free to send patches to Xilinx git-dev, but note that we are also 
developing / cleaning up the driver internally at Xilinx to upstream in near 
feature. While doing that, the code base may change due to heavy cleanup.

Thanks,
-hyun

> -Original Message-
> From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com]
> Sent: Tuesday, June 27, 2017 6:21 AM
> To: Hyun Kwon ; Michal Simek
> 
> Cc: Soren Brinkmann ; git ;
> airl...@linux.ie; dri-devel@lists.freedesktop.org
> Subject: xilinx_drm and atomic modesetting
>
> Hi guys,
>
> Note: I was a total DRM newbie at the beginning of this exercise. Now I
> would say I'm just newbie. ;)
>
> I am trying to implement our lvds panel using xilinx_drm on zynqmp. We
> are composing our pipeline starting with the xilinx-vdma, then a few logic
> parts from the ALI3 on zedboard ref design. The only configurable bits in
> this pipeline are the vdma registers at one end, then an enable GPIO and
> PWM going to the panel itself. The rest (resolution, etc.) are hard-coded at
> synthesis time.
>
> This makes things simpler, in theory.
>
> I opted to use the lvds-encoder.c (found upstream) which is actually a
> drm_bridge (!??), and the panel-lvds.c(also upstream) driver which take
> resolution and timings from dts and create a drm_panel. All I was missing is
> an encoder (xilinx_drm_encoder would not do). I created a somewhat
> dummy encoder which binds the crtc to the bridge just by being present. It
> is discovered by xilinx_drm_drv by the component subsys using the
> endpoints in dts.
>
> From what I now understand, there are two "worlds" in the DRM/KMS
> framework, legacy and atomic. From what I gather, xilinx_drm stands on
> the legacy side. Whereas the drm_bridge and drm_panel are more on the
> atomic side.
>
> I believe this is what's causing a few OOPS and exceptions here and there
> that I had to "patch" by adding "if" statements for null objects. For example,
> one is struct drm_connector_state missing on the crtc. This is used by
> atomic helpers invoked by the drm_bridge (if I remember correctly).
>
> In https://github.com/Xilinx/linux-
> xlnx/commit/d5733539adba1c509cb82bd3d4d418a3dbfbfd68 there is
> suggestion that xilinx_drm be converted to atomic modesetting.
>
> Is this work started? I would like to contribute by testing and submitting
> patches. Maybe a topic branch on github in linux-xlnx would help us out,
> and help you out as well to get the driver more polished sooner.
>
> Cheers!
> /jfd


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

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


Re: [PATCH v4 1/6] drm/stm: ltdc: Add panel-bridge support

2017-06-27 Thread Archit Taneja



On 06/19/2017 09:58 PM, Philippe CORNU wrote:

Add the panel-bridge support for both panels & bridges (used by DSI host &
HDMI/LVDS bridges).


Reviewed-by: Archit Taneja 



Signed-off-by: Philippe CORNU 
---
  drivers/gpu/drm/stm/Kconfig |   2 +-
  drivers/gpu/drm/stm/ltdc.c  | 211 
  drivers/gpu/drm/stm/ltdc.h  |   3 +-
  3 files changed, 38 insertions(+), 178 deletions(-)

diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig
index 2c4817f..4b88223 100644
--- a/drivers/gpu/drm/stm/Kconfig
+++ b/drivers/gpu/drm/stm/Kconfig
@@ -4,7 +4,7 @@ config DRM_STM
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
-   select DRM_PANEL
+   select DRM_PANEL_BRIDGE
select VIDEOMODE_HELPERS
select FB_PROVIDE_GET_FB_UNMAPPED_AREA
default y
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 1b9483d..8aa0586 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -21,7 +21,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  
  #include 

@@ -269,11 +269,6 @@ static inline struct ltdc_device *encoder_to_ltdc(struct 
drm_encoder *enc)
return (struct ltdc_device *)enc->dev->dev_private;
  }
  
-static inline struct ltdc_device *connector_to_ltdc(struct drm_connector *con)

-{
-   return (struct ltdc_device *)con->dev->dev_private;
-}
-
  static inline enum ltdc_pix_fmt to_ltdc_pixelformat(u32 drm_fmt)
  {
enum ltdc_pix_fmt pf;
@@ -813,130 +808,35 @@ static int ltdc_crtc_init(struct drm_device *ddev, 
struct drm_crtc *crtc)
   * DRM_ENCODER
   */
  
-static void ltdc_rgb_encoder_enable(struct drm_encoder *encoder)

-{
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_prepare(ldev->panel);
-   drm_panel_enable(ldev->panel);
-}
-
-static void ltdc_rgb_encoder_disable(struct drm_encoder *encoder)
-{
-   struct ltdc_device *ldev = encoder_to_ltdc(encoder);
-
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_panel_disable(ldev->panel);
-   drm_panel_unprepare(ldev->panel);
-}
-
-static const struct drm_encoder_helper_funcs ltdc_rgb_encoder_helper_funcs = {
-   .enable = ltdc_rgb_encoder_enable,
-   .disable = ltdc_rgb_encoder_disable,
-};
-
-static const struct drm_encoder_funcs ltdc_rgb_encoder_funcs = {
+static const struct drm_encoder_funcs ltdc_encoder_funcs = {
.destroy = drm_encoder_cleanup,
  };
  
-static struct drm_encoder *ltdc_rgb_encoder_create(struct drm_device *ddev)

+static int ltdc_encoder_init(struct drm_device *ddev)
  {
+   struct ltdc_device *ldev = ddev->dev_private;
struct drm_encoder *encoder;
+   int ret;
  
  	encoder = devm_kzalloc(ddev->dev, sizeof(*encoder), GFP_KERNEL);

if (!encoder)
-   return NULL;
+   return -ENOMEM;
  
  	encoder->possible_crtcs = CRTC_MASK;

encoder->possible_clones = 0; /* No cloning support */
  
-	drm_encoder_init(ddev, encoder, _rgb_encoder_funcs,

+   drm_encoder_init(ddev, encoder, _encoder_funcs,
 DRM_MODE_ENCODER_DPI, NULL);
  
-	drm_encoder_helper_add(encoder, _rgb_encoder_helper_funcs);

-
-   DRM_DEBUG_DRIVER("RGB encoder:%d created\n", encoder->base.id);
-
-   return encoder;
-}
-
-/*
- * DRM_CONNECTOR
- */
-
-static int ltdc_rgb_connector_get_modes(struct drm_connector *connector)
-{
-   struct drm_device *ddev = connector->dev;
-   struct ltdc_device *ldev = ddev->dev_private;
-   int ret = 0;
-
-   DRM_DEBUG_DRIVER("\n");
-
-   if (ldev->panel)
-   ret = drm_panel_get_modes(ldev->panel);
-
-   return ret < 0 ? 0 : ret;
-}
-
-static struct drm_connector_helper_funcs ltdc_rgb_connector_helper_funcs = {
-   .get_modes = ltdc_rgb_connector_get_modes,
-};
-
-static enum drm_connector_status
-ltdc_rgb_connector_detect(struct drm_connector *connector, bool force)
-{
-   struct ltdc_device *ldev = connector_to_ltdc(connector);
-
-   return ldev->panel ? connector_status_connected :
-  connector_status_disconnected;
-}
-
-static void ltdc_rgb_connector_destroy(struct drm_connector *connector)
-{
-   DRM_DEBUG_DRIVER("\n");
-
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static const struct drm_connector_funcs ltdc_rgb_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .detect = ltdc_rgb_connector_detect,
-   .destroy = ltdc_rgb_connector_destroy,
-   .reset = drm_atomic_helper_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-struct drm_connector *ltdc_rgb_connector_create(struct 

[PATCH 5/5] drm/amdgpu: Don't force BOs into visible VRAM for page faults

2017-06-27 Thread John Brooks
There is no need for page faults to force BOs into visible VRAM if it's
full, and the time it takes to do so is great enough to cause noticeable
stuttering. Add GTT as a possible placement so that if visible VRAM is
full, page faults move BOs to GTT instead of evicting other BOs from VRAM.

Signed-off-by: John Brooks 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 658d7b1..a215d8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -968,19 +968,21 @@ int amdgpu_bo_fault_reserve_notify(struct 
ttm_buffer_object *bo)
/* hurrah the memory is not visible ! */
atomic64_inc(>num_vram_cpu_page_faults);
abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
-   amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM);
+   amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM |
+AMDGPU_GEM_DOMAIN_GTT);
+
+   /* Avoid costly evictions; only set GTT as a busy placement */
+   abo->placement.num_busy_placement = 1;
+   abo->placement.busy_placement = >placements[1];
 
r = ttm_bo_validate(bo, >placement, false, false);
-   if (unlikely(r == -ENOMEM)) {
-   amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_GTT);
-   return ttm_bo_validate(bo, >placement, false, false);
-   } else if (unlikely(r != 0)) {
+   if (unlikely(r != 0))
return r;
-   }
 
offset = bo->mem.start << PAGE_SHIFT;
/* this should never happen */
-   if ((offset + size) > adev->mc.visible_vram_size)
+   if (bo->mem.mem_type == TTM_PL_VRAM &&
+   (offset + size) > adev->mc.visible_vram_size)
return -EINVAL;
 
return 0;
-- 
2.7.4

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


[PATCH 3/5] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo

2017-06-27 Thread John Brooks
Signed-off-by: John Brooks 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
 3 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 7366115..34c293a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -428,6 +428,9 @@ struct amdgpu_bo {
void*metadata;
u32 metadata_size;
unsignedprime_shared_count;
+   unsigned long   last_page_fault_jiffies;
+   unsigned long   last_cs_move_jiffies;
+
/* list of all virtual address to which this bo
 * is associated to
 */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 1dfa847..071b592 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -335,6 +335,7 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
u64 initial_bytes_moved, bytes_moved;
uint32_t domain;
+   uint32_t old_mem;
int r;
 
if (bo->pin_count)
@@ -364,6 +365,7 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
 retry:
amdgpu_ttm_placement_from_domain(bo, domain);
initial_bytes_moved = atomic64_read(>num_bytes_moved);
+   old_mem = bo->tbo.mem.mem_type;
r = ttm_bo_validate(>tbo, >placement, true, false);
bytes_moved = atomic64_read(>num_bytes_moved) -
  initial_bytes_moved;
@@ -377,6 +379,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
goto retry;
}
 
+   if (bo->tbo.mem.mem_type != old_mem)
+   bo->last_cs_move_jiffies = jiffies;
+
return r;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index dcf1ddb..b71775c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -953,6 +953,8 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object 
*bo)
if (bo->mem.mem_type != TTM_PL_VRAM)
return 0;
 
+   abo->last_page_fault_jiffies = jiffies;
+
size = bo->mem.num_pages << PAGE_SHIFT;
offset = bo->mem.start << PAGE_SHIFT;
/* TODO: figure out how to map scattered VRAM to the CPU */
-- 
2.7.4

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


[PATCH 2/5] drm/amdgpu: Throttle visible VRAM moves separately

2017-06-27 Thread John Brooks
The BO move throttling code is designed to allow VRAM to fill quickly if it
is relatively empty. However, this does not take into account situations
where the visible VRAM is smaller than total VRAM, and total VRAM may not
be close to full but the visible VRAM segment is under pressure. In such
situations, visible VRAM would experience unrestricted swapping and
performance would drop.

Add a separate counter specifically for moves involving visible VRAM, and
check it before moving BOs there.

v2: Only perform calculations for separate counter if visible VRAM is
smaller than total VRAM. (Michel Dänzer)

Fixes: 95844d20ae02 (drm/amdgpu: throttle buffer migrations at CS using a fixed 
MBps limit (v2))
Signed-off-by: John Brooks 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 84 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 ++--
 3 files changed, 78 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 06ed45c..7366115 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1157,7 +1157,9 @@ struct amdgpu_cs_parser {
struct list_headvalidated;
struct dma_fence*fence;
uint64_tbytes_moved_threshold;
+   uint64_tbytes_moved_vis_threshold;
uint64_tbytes_moved;
+   uint64_tbytes_moved_vis;
struct amdgpu_bo_list_entry *evictable;
 
/* user fence */
@@ -1591,6 +1593,7 @@ struct amdgpu_device {
spinlock_t  lock;
s64 last_update_us;
s64 accum_us; /* accumulated microseconds */
+   s64 accum_us_vis; /* for visible VRAM */
u32 log2_max_MBps;
} mm_stats;
 
@@ -1926,7 +1929,8 @@ bool amdgpu_need_post(struct amdgpu_device *adev);
 void amdgpu_update_display_priority(struct amdgpu_device *adev);
 
 int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void *data);
-void amdgpu_cs_report_moved_bytes(struct amdgpu_device *adev, u64 num_bytes);
+void amdgpu_cs_report_moved_bytes(struct amdgpu_device *adev, u64 num_bytes,
+ u64 num_vis_bytes);
 void amdgpu_ttm_placement_from_domain(struct amdgpu_bo *abo, u32 domain);
 bool amdgpu_ttm_bo_is_amdgpu_bo(struct ttm_buffer_object *bo);
 int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm, struct page **pages);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index aeee684..1dfa847 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -223,11 +223,13 @@ static s64 bytes_to_us(struct amdgpu_device *adev, u64 
bytes)
  * ticks. The accumulated microseconds (us) are converted to bytes and
  * returned.
  */
-static u64 amdgpu_cs_get_threshold_for_moves(struct amdgpu_device *adev)
+static void amdgpu_cs_get_threshold_for_moves(struct amdgpu_device *adev,
+ u64 *max_bytes,
+ u64 *max_vis_bytes)
 {
s64 time_us, increment_us;
-   u64 max_bytes;
u64 free_vram, total_vram, used_vram;
+   u64 free_vis_vram = 0, total_vis_vram = 0, used_vis_vram = 0;
 
/* Allow a maximum of 200 accumulated ms. This is basically per-IB
 * throttling.
@@ -238,13 +240,23 @@ static u64 amdgpu_cs_get_threshold_for_moves(struct 
amdgpu_device *adev)
 */
const s64 us_upper_bound = 20;
 
-   if (!adev->mm_stats.log2_max_MBps)
-   return 0;
+   if (!adev->mm_stats.log2_max_MBps) {
+   *max_bytes = 0;
+   *max_vis_bytes = 0;
+   return;
+   }
 
total_vram = adev->mc.real_vram_size - adev->vram_pin_size;
used_vram = atomic64_read(>vram_usage);
free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;
 
+   if (adev->mc.visible_vram_size < adev->mc.real_vram_size) {
+   total_vis_vram = adev->mc.visible_vram_size;
+   used_vis_vram = atomic64_read(>vram_vis_usage);
+   free_vis_vram = used_vis_vram >= total_vis_vram ?
+   0 : total_vis_vram - used_vis_vram;
+   }
+
spin_lock(>mm_stats.lock);
 
/* Increase the amount of accumulated us. */
@@ -252,7 +264,11 @@ static u64 amdgpu_cs_get_threshold_for_moves(struct 
amdgpu_device *adev)
increment_us = time_us - adev->mm_stats.last_update_us;
adev->mm_stats.last_update_us = time_us;
adev->mm_stats.accum_us = min(adev->mm_stats.accum_us + increment_us,
-  us_upper_bound);
+ 

[PATCH 1/5] drm/amdgpu: Add vis_vramlimit module parameter

2017-06-27 Thread John Brooks
Allow specifying a limit on visible VRAM via a module parameter. This is
helpful for testing performance under visible VRAM pressure.

v2: Add cast to 64-bit (Christian König)

Signed-off-by: John Brooks 
Reviewed-by: Michel Dänzer 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 12d61ed..06ed45c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -74,6 +74,7 @@
  */
 extern int amdgpu_modeset;
 extern int amdgpu_vram_limit;
+extern int amdgpu_vis_vram_limit;
 extern int amdgpu_gart_size;
 extern int amdgpu_moverate;
 extern int amdgpu_benchmarking;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 4c7c262..a14f458 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -73,6 +73,7 @@
 #define KMS_DRIVER_PATCHLEVEL  0
 
 int amdgpu_vram_limit = 0;
+int amdgpu_vis_vram_limit = 0;
 int amdgpu_gart_size = -1; /* auto */
 int amdgpu_moverate = -1; /* auto */
 int amdgpu_benchmarking = 0;
@@ -119,6 +120,9 @@ int amdgpu_lbpw = -1;
 MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in megabytes");
 module_param_named(vramlimit, amdgpu_vram_limit, int, 0600);
 
+MODULE_PARM_DESC(vis_vramlimit, "Restrict visible VRAM for testing, in 
megabytes");
+module_param_named(vis_vramlimit, amdgpu_vis_vram_limit, int, 0444);
+
 MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32, 
64, etc., -1 = auto)");
 module_param_named(gartsize, amdgpu_gart_size, int, 0600);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index c9b131b..7d14ae1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1095,6 +1095,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
 int amdgpu_ttm_init(struct amdgpu_device *adev)
 {
int r;
+   u64 vis_vram_limit;
 
r = amdgpu_ttm_global_init(adev);
if (r) {
@@ -1118,6 +1119,13 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
}
+
+   /* Reduce size of CPU-visible VRAM if requested */
+   vis_vram_limit = (u64)amdgpu_vis_vram_limit * 1024 * 1024;
+   if (amdgpu_vis_vram_limit > 0 &&
+   vis_vram_limit <= adev->mc.visible_vram_size)
+   adev->mc.visible_vram_size = vis_vram_limit;
+
/* Change the size here instead of the init above so only lpfn is 
affected */
amdgpu_ttm_set_active_vram_size(adev, adev->mc.visible_vram_size);
 
-- 
2.7.4

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


[PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

2017-06-27 Thread John Brooks
When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
it should only be treated as a hint to initially place a BO somewhere CPU
accessible, rather than having a permanent effect on BO placement.

Instead of the flag being set in stone at BO creation, set the flag when a
page fault occurs so that it goes somewhere CPU-visible, and clear it when
the BO is requested by the GPU.

However, clearing the CPU_ACCESS_REQUIRED flag may move BOs in GTT to
invisible VRAM, where they may promptly generate another page fault. When
BOs are constantly moved back and forth like this, it is highly detrimental
to performance. Only clear the flag on CS if:

- The BO wasn't page faulted for a certain amount of time (currently 10
  seconds), and
- its last page fault didn't occur too soon (currently 500ms) after its
  last CS request, or vice versa.

Setting the flag in amdgpu_fault_reserve_notify() also means that we can
remove the loop to restrict lpfn to the end of visible VRAM, because
amdgpu_ttm_placement_init() will do it for us.

Signed-off-by: John Brooks 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 45 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 +
 3 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 071b592..1ac3c2e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -341,6 +341,8 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
if (bo->pin_count)
return 0;
 
+   amdgpu_bo_clear_cpu_access_required(bo);
+
/* Don't move this buffer if we have depleted our allowance
 * to move it. Don't move anything if the threshold is zero.
 */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index b71775c..658d7b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -943,8 +943,8 @@ int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object 
*bo)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct amdgpu_bo *abo;
-   unsigned long offset, size, lpfn;
-   int i, r;
+   unsigned long offset, size;
+   int r;
 
if (!amdgpu_ttm_bo_is_amdgpu_bo(bo))
return 0;
@@ -967,15 +967,9 @@ int amdgpu_bo_fault_reserve_notify(struct 
ttm_buffer_object *bo)
 
/* hurrah the memory is not visible ! */
atomic64_inc(>num_vram_cpu_page_faults);
+   abo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM);
-   lpfn =  adev->mc.visible_vram_size >> PAGE_SHIFT;
-   for (i = 0; i < abo->placement.num_placement; i++) {
-   /* Force into visible VRAM */
-   if ((abo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
-   (!abo->placements[i].lpfn ||
-abo->placements[i].lpfn > lpfn))
-   abo->placements[i].lpfn = lpfn;
-   }
+
r = ttm_bo_validate(bo, >placement, false, false);
if (unlikely(r == -ENOMEM)) {
amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_GTT);
@@ -1033,3 +1027,34 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
 
return bo->tbo.offset;
 }
+
+/**
+ * amdgpu_bo_clear_cpu_access_required
+ * @bo: BO to update
+ *
+ * Clears CPU_ACCESS_REQUIRED flag if the BO hasn't had a page fault in a while
+ * and it didn't have a page fault too soon after the last time it was moved to
+ * VRAM.
+ *
+ * Caller should have bo reserved.
+ *
+ */
+void amdgpu_bo_clear_cpu_access_required(struct amdgpu_bo *bo)
+{
+   const unsigned int page_fault_timeout_ms = 1;
+   const unsigned int min_period_ms = 500;
+   unsigned int ms_since_pf, period_ms;
+
+   ms_since_pf = jiffies_to_msecs(jiffies - bo->last_page_fault_jiffies);
+   period_ms = jiffies_to_msecs(abs(bo->last_page_fault_jiffies -
+bo->last_cs_move_jiffies));
+
+   /*
+* Try to avoid a revolving door between GTT and VRAM. Clearing the
+* flag may move this BO back to VRAM, so don't clear it if it's likely
+* to page fault and go right back to GTT.
+*/
+   if ((!bo->last_page_fault_jiffies || !bo->last_cs_move_jiffies) ||
+   (ms_since_pf > page_fault_timeout_ms && period_ms > min_period_ms))
+   bo->flags &= ~AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 3824851..b0cb137 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -182,6 +182,7 @@ int amdgpu_bo_restore_from_shadow(struct amdgpu_device 
*adev,
 

[PATCH v2] Visible VRAM Management Improvements

2017-06-27 Thread John Brooks
Changes in this version:
- Dropped former patch 1 ("Separate placements and busy placements") as it was
  no longer necessary
- Dropped former patch 4 ("Don't force BOs into visible VRAM if they can go to
  GTT instead") as it was unnecessary and had too many side effects (Thanks
  Christian)
- Dropped former patches 8 and 9 ("Asynchronously move BOs to visible VRAM" and
  an associated optimization), as there may be better ways to address the root
  of the problem
- Added a u64 cast to patch 1 (Thanks Christian)
- Optimized patch 2 in the case where visible VRAM is not smaller than total
  VRAM (Thanks Michel)

The series as it is now fixes Dying Light and improves DiRT Rally frame times.
Without the asynchronous moves, there is still occasional stalling in DiRT
Rally.


The "Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS" patch received
objections, but I have not removed it yet as there seems to be some support for
the idea. The precise details of when to set and clear the flag may need further
discussion.

I note that if the patch is removed (but retaining the preventative measures
against repeated moves back and forth between GTT and invisible VRAM), there
are very few evictions but the average framerate drops from ~89 to ~82.
Presumably we'll see either higher memory presure or lower framerates depending
on whether userspace over- or under-estimates when to set this flag. What we do
in the kernel may depend on which side of this tradeoff we want to end up on
for now.

--
John Brooks (Frogging101)

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


[Bug 101584] clover: ethminer -G --benchmark: ring buffer overflow, GPU faults

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101584

--- Comment #1 from Christoph Haag  ---
Created attachment 132290
  --> https://bugs.freedesktop.org/attachment.cgi?id=132290=edit
without X

Thanks to a tip from tom stellard I tried it without X (after exiting sddm). 

I've tried to start the miner with "real work" from a pool as recommended:

GPU_FORCE_64BIT_PTR=0 GPU_MAX_HEAP_SIZE=100 GPU_USE_SYNC_OBJECTS=1
GPU_MAX_ALLOC_PERCENT=100 GPU_SINGLE_ALLOC_PERCENT=100 ./ethminer
--farm-recheck 200 -G -S eu1.ethermine.org: etc. etc.

I get gpu faults, but no hangs or other issues and the system is usable
normally after exiting the miner.

The -G --benchmark mode still has worse troubles with hangs etc.

-- 
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 101561] [bisected] [llvm] Blue color shift on videos in MPV when using vo=opengl[-hq]

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101561

Nick Sarnie  changed:

   What|Removed |Added

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

--- Comment #7 from Nick Sarnie  ---
Fixed by
https://github.com/llvm-mirror/llvm/commit/06ed4a14fdcacacc12b31f6316efaab5620ffe85

-- 
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 101594] Blender doesn't detect OpenCL with Clover

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101594

--- Comment #2 from Luke A. Guest  ---
Number of platforms   1
  Platform Name   Clover
  Platform Vendor Mesa
  Platform VersionOpenCL 1.1 Mesa 17.2.0-devel
(git-d5a9608076)
  Platform ProfileFULL_PROFILE
  Platform Extensions cl_khr_icd
  Platform Extensions function suffix MESA

  Platform Name   Clover
Number of devices 1
  Device Name AMD Radeon R9 390 Series (AMD
HAWAII / DRM 3.15.0 / 4.12.0-rc6, LLVM 5.0.0)
  Device Vendor   AMD
  Device Vendor ID0x1002
  Device Version  OpenCL 1.1 Mesa 17.2.0-devel
(git-d5a9608076)
  Driver Version  17.2.0-devel
  Device OpenCL C Version OpenCL C 1.1 
  Device Type GPU
  Device AvailableYes
  Device Profile  FULL_PROFILE
  Max compute units   40
  Max clock frequency 1040MHz
  Max work item dimensions3
  Max work item sizes 256x256x256
  Max work group size 256
  Compiler Available  Yes
  Preferred work group size multiple  64
  Preferred / native vector sizes 
char16 / 16  
short8 / 8   
int  4 / 4   
long 2 / 2   
half 0 / 0(n/a)
float4 / 4   
double   2 / 2   
(cl_khr_fp64)
  Half-precision Floating-point support   (n/a)
  Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest  Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add   No
Support is emulated in software   No
Correctly-rounded divide and sqrt operations  No
  Double-precision Floating-point support (cl_khr_fp64)
Denormals Yes
Infinity and NANs Yes
Round to nearest  Yes
Round to zero Yes
Round to infinity Yes
IEEE754-2008 fused multiply-add   Yes
Support is emulated in software   No
Correctly-rounded divide and sqrt operations  No
  Address bits64, Little-Endian
  Global memory size  8588677120 (7.999GiB)
  Error Correction supportNo
  Max memory allocation   6012073984 (5.599GiB)
  Unified memory for Host and Device  No
  Minimum alignment for any data type 128 bytes
  Alignment of base address   1024 bits (128 bytes)
  Global Memory cache typeNone
  Image support   No
  Local memory type   Local
  Local memory size   32768 (32KiB)
  Max constant buffer size2147483647 (2GiB)
  Max number of constant args 16
  Max size of kernel argument 1024
  Queue properties
Out-of-order executionNo
Profiling Yes
  Profiling timer resolution  0ns
  Execution capabilities  
Run OpenCL kernelsYes
Run native kernelsNo
  Device Extensions  
cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics
cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics
cl_khr_byte_addressable_store cl_khr_fp64

NULL platform behavior
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  No platform
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   No platform
  clCreateContext(NULL, ...) [default]No platform
  clCreateContext(NULL, ...) [other]  Success 

Re: [PATCH 00/13] fbdev locking rework and deferred setup, take 2

2017-06-27 Thread John Stultz
On Tue, Jun 27, 2017 at 7:59 AM, Daniel Vetter  wrote:
>
> Thanks to Liviu's help I realized that I fumbled the locking rework 
> completely.
> This one here should be better, but somehow I'm having a real bad day today 
> and
> I spent all day typing shit code, and then making it worse.
>
> This here seems to work at first glance, but please test and review carefully.

After some self-caused testing pain (somehow missed picking one of the
patches in mutt), I managed to get these tested w/ HiKey against
4.12-rc7.

Things seemed to work fairly well.

Though the one quirk I saw was that previously if I booted the device
w/o HDMI plugged in, it would boot up defaulting to 1024x768
resolution, and when I plugged in the HDMI cable, the monitor would
start up and use that resolution.

With your patchset, if I boot without the monitor attached,  it seems
no fb is created, so surfaceflinger crashes repeatedly trying to start
up.  Then when I do plug the montior in, I get the following crash:

[  106.503724] Unable to handle kernel NULL pointer dereference at
virtual address 0038
[  106.512050] pgd = ff8008e89000
[  106.515596] [0038] *pgd=77ffe003,
*pud=77ffe003, *pmd=
[  106.524050] Internal error: Oops: 9605 [#1] PREEMPT SMP
[  106.529678] CPU: 2 PID: 1184 Comm: kworker/2:2 Tainted: GW
 4.12.0-rc7-00093-g42439fe-dirty #3054
[  106.539711] Hardware name: HiKey Development Board (DT)
[  106.544996] Workqueue: events adv7511_hpd_work
[  106.549484] task: ffc0753c3e80 task.stack: ffc074b0c000
[  106.555449] PC is at drm_sysfs_hotplug_event+0x34/0x58
[  106.560624] LR is at drm_sysfs_hotplug_event+0x34/0x58
[  106.565796] pc : [] lr : []
pstate: 4145
[  106.573221] sp : ffc074b0fd40
[  106.576562] x29: ffc074b0fd40 x28: 
[  106.581925] x27: ffc005f93d20 x26: ffc074d387b8
[  106.587288] x25: ffc0753c3e80 x24: ffc0747e3258
[  106.592650] x23:  x22: ffc077f44a80
[  106.598012] x21: ffc077f46900 x20: ffc07441cd00
[  106.603373] x19:  x18: 
[  106.608733] x17:  x16: 
[  106.614093] x15: 0018cc1b97ed x14: 
[  106.619453] x13:  x12: 
[  106.624813] x11: 02e5 x10: 0880
[  106.630173] x9 : ffc074b0fa10 x8 : ffc0753c4760
[  106.635534] x7 : ffc077f3ec80 x6 : ffc077f3c090
[  106.640895] x5 : ff8008da0568 x4 : 
[  106.646254] x3 :  x2 : ff8008c39d90
[  106.651613] x1 : 0001 x0 : ff8008c02fe8
[  106.656981] Process kworker/2:2 (pid: 1184, stack limit = 0xffc074b0c000)
[  106.664152] Stack: (0xffc074b0fd40 to 0xffc074b1)
[  106.669940] fd40: ffc074b0fd70 ff800851d1ec
 ff80085c7b04
[  106.677813] fd60: ff8008c39d80 
ffc074b0fd90 ff8008550bd4
[  106.685687] fd80: ffc0747e3018 ff80080df688
ffc074b0fdc0 ff80080d0814
[  106.693561] fda0:  ff8008a45eb8
ffc074b0fdc0 00d0080d0808
[  106.701436] fdc0: ffc074b0fe00 ff80080d0a68
ffc07441cd00 ffc074a83a00
[  106.709310] fde0: ffc077f44a80 ffc07441cd30
ff8008d46000 ffc077f44aa0
[  106.717184] fe00: ffc074b0fe60 ff80080d6974
ffc074d38780 ffc074a83a00
[  106.725059] fe20: ff8008df9160 ffc0753c3e80
ff8008bf9528 ffc07441cd00
[  106.732929] fe40: ff80080d0a20 ffc074d387b8
ffc005f93d20 
[  106.740801] fe60:  ff8008082ec0
ff80080d6878 ffc074a83a00
[  106.748671] fe80:  
 
[  106.756541] fea0:  
 
[  106.764411] fec0:  
 
[  106.772281] fee0:  
 
[  106.780151] ff00:  
 
[  106.788021] ff20:  
 
[  106.795889] ff40:  
 
[  106.803759] ff60:  
 
[  106.811629] ff80:  
 
[  106.819475] ffa0:  
 
[  106.827308] ffc0:  0005
 
[  106.835143] ffe0:  
 
[  106.842974] Call trace:
[  106.845422] Exception stack(0xffc074b0fb70 to 0xffc074b0fca0)
[  106.851866] fb60:
 0080
[  106.859701] fb80: ffc074b0fd40 

Re: [PATCH] libdrm: add drm syncobj create/destroy/import/export

2017-06-27 Thread Eric Anholt
Dave Airlie  writes:

> From: Dave Airlie 
>
> These ioctls are now in drm next so add the first set of libdrm APIs.
>
> Signed-off-by: Dave Airlie 

It took me a bit of digging to understand the functional difference
between drmSyncobjHandleToFD() and drmSyncobjExportSyncFile(), but the
wrappers for these ioctls seem fine.

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


Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD

2017-06-27 Thread Pandiyan, Dhinakaran



On Tue, 2017-06-27 at 16:23 +0300, David Weinehall wrote:
> On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> > On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> > > This patch adds option to enable dynamic backlight for eDP
> > > panel that supports this feature via DPCD register and
> > > set minimum / maximum brightness to 0% and 100% of the
> > > normal brightness.
> > 
> > This patch causes a regression on my ThinkPad X1 Carbon Gen 4;
> > with enable_dbc = true the backlight stays off; setting i915.enable_dbc=0
> > on boot makes things work properly again.
> 
> Some more testing indicates that while i915.enable_dbc=0 solves the
> initial issue of backlight not coming on, it's not enough--after
> suspend/resume the backlight stays off.
> 
> Passing i915.enable_dpcd_backlight=0 seems to work both for the initial
> case of backlight not coming on at boot, and the issue with backlight
> not coming on after suspend/resume.
> 
> So:
> 
> DBC:1, DPCD: -1: blank screen on boot
> DBC:0, DPCD: -1: screen OK on boot, blank after suspend/resume
> DBC:1, DPCD:  0: screen OK on boot, screen OK after suspend/resume
> DBC:0, DPCD:  0: screen OK on boot, screen OK after suspend/resume
> 
> So it seems that at least for the ThinkPad X1 Carbon Gen 4 (possibly
> limited to the 2560x1440 model) DPCD backlight isn't supported.
> 

Hi David, 

Thanks for the bug report. It's come a bit sooner than I expected
though.

We shouldn't be enabling DPCD backlight control if the panel does not
support it. I'd like to look at the dmesg with drm.debug=0xE. We debug
log the panel capabilities early during boot and that will be useful.
Can you also provide the output of i915_dpcd in debugfs for the eDP
connector?

I guess it makes sense to file an FDO and attach the logs there. 



-DK

> Or possibly something is wrong with the DPCD backlight patch.
> 
> > > Signed-off-by: Puthikorn Voravootivat 
> > > Reviewed-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/i915_params.c|  5 +
> > >  drivers/gpu/drm/i915/i915_params.h|  3 ++-
> > >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26 
> > > ++
> > >  3 files changed, 33 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > > b/drivers/gpu/drm/i915/i915_params.c
> > > index 5b5ab15d191f..88b9d3e6713a 100644
> > > --- a/drivers/gpu/drm/i915/i915_params.c
> > > +++ b/drivers/gpu/drm/i915/i915_params.c
> > > @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
> > >   .inject_load_failure = 0,
> > >   .enable_dpcd_backlight = -1,
> > >   .enable_gvt = false,
> > > + .enable_dbc = true,
> > >  };
> > >  
> > >  module_param_named(modeset, i915.modeset, int, 0400);
> > > @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> > >  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> > >  MODULE_PARM_DESC(enable_gvt,
> > >   "Enable support for Intel GVT-g graphics virtualization host 
> > > support(default:false)");
> > > +
> > > +module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> > > +MODULE_PARM_DESC(enable_dbc,
> > > + "Enable support for dynamic backlight control (default:true)");
> > > diff --git a/drivers/gpu/drm/i915/i915_params.h 
> > > b/drivers/gpu/drm/i915/i915_params.h
> > > index 0d6cf9138dc4..057e203e6bda 100644
> > > --- a/drivers/gpu/drm/i915/i915_params.h
> > > +++ b/drivers/gpu/drm/i915/i915_params.h
> > > @@ -67,7 +67,8 @@
> > >   func(bool, verbose_state_checks); \
> > >   func(bool, nuclear_pageflip); \
> > >   func(bool, enable_dp_mst); \
> > > - func(bool, enable_gvt)
> > > + func(bool, enable_gvt); \
> > > + func(bool, enable_dbc)
> > >  
> > >  #define MEMBER(T, member) T member
> > >  struct i915_params {
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> > > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > index fea161727c6e..b25cd88fc1c5 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > @@ -173,6 +173,24 @@ static bool intel_dp_aux_set_pwm_freq(struct 
> > > intel_connector *connector)
> > >   return true;
> > >  }
> > >  
> > > +/*
> > > +* Set minimum / maximum dynamic brightness percentage. This value is 
> > > expressed
> > > +* as the percentage of normal brightness in 5% increments.
> > > +*/
> > > +static bool
> > > +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> > > +u32 min, u32 max)
> > > +{
> > > + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> > > +
> > > + if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> > > +   dbc, sizeof(dbc)) < 0) {
> > > + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> > > + return false;
> > > + }
> > > + return true;
> > > +}
> > > +
> 

[PATCH 7/8] drm: Add old state pointer to CRTC .enable() helper function

2017-06-27 Thread Laurent Pinchart
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.

While at it, rename the operation to .atomic_enable() to be consistent
with .atomic_disable(), as the .enable() operation is used by atomic
helpers only.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  5 ++--
 drivers/gpu/drm/arm/hdlcd_crtc.c|  5 ++--
 drivers/gpu/drm/arm/malidp_crtc.c   |  5 ++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  5 ++--
 drivers/gpu/drm/drm_atomic_helper.c |  7 +++--
 drivers/gpu/drm/drm_simple_kms_helper.c |  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|  5 ++--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  |  5 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  5 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  5 ++--
 drivers/gpu/drm/imx/ipuv3-crtc.c|  5 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  5 ++--
 drivers/gpu/drm/meson/meson_crtc.c  |  5 ++--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c|  5 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  5 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c |  5 ++--
 drivers/gpu/drm/qxl/qxl_display.c   |  5 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  5 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  5 ++--
 drivers/gpu/drm/sti/sti_crtc.c  |  5 ++--
 drivers/gpu/drm/stm/ltdc.c  |  5 ++--
 drivers/gpu/drm/sun4i/sun4i_crtc.c  |  5 ++--
 drivers/gpu/drm/tegra/dc.c  |  5 ++--
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c|  8 +-
 drivers/gpu/drm/vc4/vc4_crtc.c  |  5 ++--
 drivers/gpu/drm/virtio/virtgpu_display.c|  5 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  7 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  7 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|  5 ++--
 drivers/gpu/drm/zte/zx_vou.c|  5 ++--
 include/drm/drm_modeset_helper_vtables.h| 38 +
 31 files changed, 117 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 1f306781c9d5..c9bc6a90ac83 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -119,7 +119,8 @@ static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
clk_set_rate(arcpgu->clk, m->crtc_clock * 1000);
 }
 
-static void arc_pgu_crtc_enable(struct drm_crtc *crtc)
+static void arc_pgu_crtc_atomic_enable(struct drm_crtc *crtc,
+  struct drm_crtc_state *old_state)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
 
@@ -161,9 +162,9 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.mode_set   = drm_helper_crtc_mode_set,
.mode_set_base  = drm_helper_crtc_mode_set_base,
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
-   .enable = arc_pgu_crtc_enable,
.disable= arc_pgu_crtc_disable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
+   .atomic_enable  = arc_pgu_crtc_atomic_enable,
 };
 
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index d67b6f15e8b8..2b7f4f05d91f 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -165,7 +165,8 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
clk_set_rate(hdlcd->clk, m->crtc_clock * 1000);
 }
 
-static void hdlcd_crtc_enable(struct drm_crtc *crtc)
+static void hdlcd_crtc_atomic_enable(struct drm_crtc *crtc,
+struct drm_crtc_state *old_state)
 {
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
@@ -218,10 +219,10 @@ static void hdlcd_crtc_atomic_begin(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
-   .enable = hdlcd_crtc_enable,
.disable= hdlcd_crtc_disable,
.atomic_check   = hdlcd_crtc_atomic_check,
.atomic_begin   = hdlcd_crtc_atomic_begin,
+   .atomic_enable  = hdlcd_crtc_atomic_enable,
 };
 
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 4bb38a21efec..8e5b1c0181ab 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -46,7 +46,8 @@ static enum drm_mode_status malidp_crtc_mode_valid(struct 
drm_crtc *crtc,
return MODE_OK;
 }
 
-static void malidp_crtc_enable(struct drm_crtc *crtc)
+static void malidp_crtc_atomic_enable(struct drm_crtc *crtc,
+ struct 

[PATCH 3/8] drm: qxl: Remove unused CRTC .dpms() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC .dpms() helper operation is called by the atomic helpers only
when no .prepare(), .atomic_disable() or .disable() operation is
provided. As the qxl driver provides a .disable() operation, the .dpms()
operation is unused and can be removed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/qxl/qxl_display.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 72dcaab84bba..19ba336ce096 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -378,10 +378,6 @@ qxl_framebuffer_init(struct drm_device *dev,
return 0;
 }
 
-static void qxl_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
-}
-
 static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
  const struct drm_display_mode *mode,
  struct drm_display_mode *adjusted_mode)
@@ -467,7 +463,6 @@ static void qxl_crtc_disable(struct drm_crtc *crtc)
 }
 
 static const struct drm_crtc_helper_funcs qxl_crtc_helper_funcs = {
-   .dpms = qxl_crtc_dpms,
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
.mode_set_nofb = qxl_mode_set_nofb,
-- 
Regards,

Laurent Pinchart

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


[PATCH 8/8] drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()

2017-06-27 Thread Laurent Pinchart
The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo-cult use of
.disable() in new drivers.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   | 5 +++--
 drivers/gpu/drm/arm/hdlcd_crtc.c| 5 +++--
 drivers/gpu/drm/arm/malidp_crtc.c   | 5 +++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 5 +++--
 drivers/gpu/drm/drm_simple_kms_helper.c | 5 +++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 5 +++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 5 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 5 +++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +++--
 drivers/gpu/drm/meson/meson_crtc.c  | 5 +++--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 5 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 5 +++--
 drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +++--
 drivers/gpu/drm/qxl/qxl_display.c   | 5 +++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 5 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +++--
 drivers/gpu/drm/sti/sti_crtc.c  | 5 +++--
 drivers/gpu/drm/stm/ltdc.c  | 5 +++--
 drivers/gpu/drm/sun4i/sun4i_crtc.c  | 5 +++--
 drivers/gpu/drm/tegra/dc.c  | 5 +++--
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 8 +++-
 drivers/gpu/drm/vc4/vc4_crtc.c  | 5 +++--
 drivers/gpu/drm/virtio/virtgpu_display.c| 5 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 7 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 7 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 5 +++--
 drivers/gpu/drm/zte/zx_vou.c| 5 +++--
 27 files changed, 87 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index c9bc6a90ac83..1859dd3ad622 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -130,7 +130,8 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc 
*crtc,
  ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
+static void arc_pgu_crtc_atomic_disable(struct drm_crtc *crtc,
+   struct drm_crtc_state *old_state)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
 
@@ -162,9 +163,9 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.mode_set   = drm_helper_crtc_mode_set,
.mode_set_base  = drm_helper_crtc_mode_set_base,
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
-   .disable= arc_pgu_crtc_disable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
.atomic_enable  = arc_pgu_crtc_atomic_enable,
+   .atomic_disable = arc_pgu_crtc_atomic_disable,
 };
 
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 2b7f4f05d91f..16e1e20cf04c 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -176,7 +176,8 @@ static void hdlcd_crtc_atomic_enable(struct drm_crtc *crtc,
drm_crtc_vblank_on(crtc);
 }
 
-static void hdlcd_crtc_disable(struct drm_crtc *crtc)
+static void hdlcd_crtc_atomic_disable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
 {
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
@@ -219,10 +220,10 @@ static void hdlcd_crtc_atomic_begin(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
-   .disable= hdlcd_crtc_disable,
.atomic_check   = hdlcd_crtc_atomic_check,
.atomic_begin   = hdlcd_crtc_atomic_begin,
.atomic_enable  = hdlcd_crtc_atomic_enable,
+   .atomic_disable = hdlcd_crtc_atomic_disable,
 };
 
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 8e5b1c0181ab..3615d18a7ddf 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -70,7 +70,8 @@ static void malidp_crtc_atomic_enable(struct drm_crtc *crtc,
drm_crtc_vblank_on(crtc);
 }
 
-static void malidp_crtc_disable(struct drm_crtc *crtc)
+static void malidp_crtc_atomic_disable(struct drm_crtc *crtc,
+  struct drm_crtc_state *old_state)
 {
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
@@ -409,9 +410,9 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
 
 static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = {
.mode_valid = 

[PATCH 5/8] drm: vmwgfx: Remove unneeded CRTC .prepare() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC .prepare() helper operation is part of the legacy helpers and
is deprecated in favour of the .disable() helper operation. As the
vmwgfx driver provides a .disable() helper operation, and as the
.prepare() helper operation implementation is empty, we can remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 449ed4fba0f2..639e16703b80 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -203,18 +203,6 @@ static void vmw_ldu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 }
 
 /**
- * vmw_ldu_crtc_helper_prepare - Noop
- *
- * @crtc: CRTC associated with the new screen
- *
- * Prepares the CRTC for a mode set, but we don't need to do anything here.
- *
- */
-static void vmw_ldu_crtc_helper_prepare(struct drm_crtc *crtc)
-{
-}
-
-/**
  * vmw_ldu_crtc_helper_commit - Noop
  *
  * @crtc: CRTC associated with the new screen
@@ -388,7 +376,6 @@ drm_plane_helper_funcs vmw_ldu_primary_plane_helper_funcs = 
{
 };
 
 static const struct drm_crtc_helper_funcs vmw_ldu_crtc_helper_funcs = {
-   .prepare = vmw_ldu_crtc_helper_prepare,
.commit = vmw_ldu_crtc_helper_commit,
.disable = vmw_ldu_crtc_helper_disable,
.mode_set_nofb = vmw_ldu_crtc_mode_set_nofb,
-- 
Regards,

Laurent Pinchart

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


[PATCH 6/8] drm: vmwgfx: Replace CRTC .commit() helper operation with .enable()

2017-06-27 Thread Laurent Pinchart
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 639e16703b80..f8acd3a15523 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -203,7 +203,7 @@ static void vmw_ldu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 }
 
 /**
- * vmw_ldu_crtc_helper_commit - Noop
+ * vmw_ldu_crtc_helper_enable - Noop
  *
  * @crtc: CRTC associated with the new screen
  *
@@ -212,7 +212,7 @@ static void vmw_ldu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
  * but since for LDU the display plane is closely tied to the
  * CRTC, it makes more sense to do those at plane update time.
  */
-static void vmw_ldu_crtc_helper_commit(struct drm_crtc *crtc)
+static void vmw_ldu_crtc_helper_enable(struct drm_crtc *crtc)
 {
 }
 
@@ -376,7 +376,7 @@ drm_plane_helper_funcs vmw_ldu_primary_plane_helper_funcs = 
{
 };
 
 static const struct drm_crtc_helper_funcs vmw_ldu_crtc_helper_funcs = {
-   .commit = vmw_ldu_crtc_helper_commit,
+   .enable = vmw_ldu_crtc_helper_enable,
.disable = vmw_ldu_crtc_helper_disable,
.mode_set_nofb = vmw_ldu_crtc_mode_set_nofb,
.atomic_check = vmw_du_crtc_atomic_check,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 3b917c9b0c21..1cb826c503bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -270,13 +270,13 @@ static void vmw_sou_crtc_helper_prepare(struct drm_crtc 
*crtc)
 }
 
 /**
- * vmw_sou_crtc_helper_commit - Noop
+ * vmw_sou_crtc_helper_enable - Noop
  *
  * @crtc: CRTC associated with the new screen
  *
  * This is called after a mode set has been completed.
  */
-static void vmw_sou_crtc_helper_commit(struct drm_crtc *crtc)
+static void vmw_sou_crtc_helper_enable(struct drm_crtc *crtc)
 {
 }
 
@@ -573,7 +573,7 @@ drm_plane_helper_funcs vmw_sou_primary_plane_helper_funcs = 
{
 
 static const struct drm_crtc_helper_funcs vmw_sou_crtc_helper_funcs = {
.prepare = vmw_sou_crtc_helper_prepare,
-   .commit = vmw_sou_crtc_helper_commit,
+   .enable = vmw_sou_crtc_helper_enable,
.disable = vmw_sou_crtc_helper_disable,
.mode_set_nofb = vmw_sou_crtc_mode_set_nofb,
.atomic_check = vmw_du_crtc_atomic_check,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 6aecba6cd5e2..4eb93b47d6db 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -412,7 +412,7 @@ static void vmw_stdu_crtc_helper_prepare(struct drm_crtc 
*crtc)
 }
 
 
-static void vmw_stdu_crtc_helper_commit(struct drm_crtc *crtc)
+static void vmw_stdu_crtc_helper_enable(struct drm_crtc *crtc)
 {
struct vmw_private *dev_priv;
struct vmw_screen_target_display_unit *stdu;
@@ -1415,7 +1415,7 @@ drm_plane_helper_funcs 
vmw_stdu_primary_plane_helper_funcs = {
 
 static const struct drm_crtc_helper_funcs vmw_stdu_crtc_helper_funcs = {
.prepare = vmw_stdu_crtc_helper_prepare,
-   .commit = vmw_stdu_crtc_helper_commit,
+   .enable = vmw_stdu_crtc_helper_enable,
.disable = vmw_stdu_crtc_helper_disable,
.mode_set_nofb = vmw_stdu_crtc_mode_set_nofb,
.atomic_check = vmw_du_crtc_atomic_check,
-- 
Regards,

Laurent Pinchart

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


[PATCH 2/8] drm: arcpgu: Remove CRTC .prepare() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC helper .prepare() operation is legacy code, the atomic helpers
prefer the .disable() operation. As the arcpgu driver implements the
.disable() and .prepare() operations identicallly, .prepare() can be
removed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 51745608e09d..1f306781c9d5 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -163,7 +163,6 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
.enable = arc_pgu_crtc_enable,
.disable= arc_pgu_crtc_disable,
-   .prepare= arc_pgu_crtc_disable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
 
-- 
Regards,

Laurent Pinchart

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


[PATCH 4/8] drm: qxl: Replace CRTC .commit() helper operation with .enable()

2017-06-27 Thread Laurent Pinchart
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 19ba336ce096..7ede5f131a5c 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -447,7 +447,7 @@ static void qxl_mode_set_nofb(struct drm_crtc *crtc)
 
 }
 
-static void qxl_crtc_commit(struct drm_crtc *crtc)
+static void qxl_crtc_enable(struct drm_crtc *crtc)
 {
DRM_DEBUG("\n");
 }
@@ -466,7 +466,7 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
.mode_set_nofb = qxl_mode_set_nofb,
-   .commit = qxl_crtc_commit,
+   .enable = qxl_crtc_enable,
.atomic_flush = qxl_crtc_atomic_flush,
 };
 
-- 
Regards,

Laurent Pinchart

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


[PATCH 1/8] drm: arcpgu: Remove CRTC .commit() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. As the arcpgu driver implements the
.enable() operation, .commit() is never used and can be removed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 611af74a31c0..51745608e09d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -164,7 +164,6 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.enable = arc_pgu_crtc_enable,
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
-   .commit = arc_pgu_crtc_enable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
 
-- 
Regards,

Laurent Pinchart

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


[PULL] drm-misc-next-fixes

2017-06-27 Thread Sean Paul
Hi Dave,
When I said I had ~6 changes yesterday, I was lying. 3 of those changes were
included in the final misc-next pull and already exist in your tree. So then
there were 3. All quite simple, nothing to write home about.

You'll notice the unsightly backmerges below, this was due to the rockchip patch
being merged to -next-fixes instead of -next weeks earlier. Since I couldn't
fast forward, I had to resort to a series of backmerges to sync everything up. 
In
hindsight, I should have just rebased -next-fixes and re-applied the patch, but 
I
chose a preservationist route. Mentally noted for next time, I guess. Anyways,
hopefully this is headache free and things will be cleaner from here on out.

drm-misc-next-fixes-2017-06-27:
Core Changes:
- bridge: return -ve errno in drm_panel_bridge_add (Eric)

Driver Changes:
- rockchip: ensure mm lock is held in error paths (Caesar)
- dw-hdmi: fix formatting in input format table (Jonathan)

Cc: Caesar Wang 
Cc: Eric Anholt 
Cc: Jonathan Corbet 

Happy vacation, Sean


The following changes since commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b:

  Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-06-27

for you to fetch changes up to c048c984de38d906bb0df56ec2ae90eafc123d0a:

  Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next-fixes 
(2017-06-27 11:36:28 -0400)


Core Changes:
- bridge: return -ve errno in drm_panel_bridge_add (Eric)

Driver Changes:
- rockchip: ensure mm lock is held in error paths (Caesar)
- dw-hdmi: fix formatting in input format table (Jonathan)

Cc: Caesar Wang 
Cc: Eric Anholt 
Cc: Jonathan Corbet 


Caesar Wang (1):
  drm/rockchip: gem: add the lacks lock and trivial changes

Eric Anholt (1):
  bridge: Fix panel-bridge error return on !panel.

Jonathan Corbet (1):
  DRM: Fix an incorrectly formatted table

Sean Paul (4):
  Merge remote-tracking branch 'origin/master' into drm-misc-next-fixes
  Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next-fixes
  Merge tag 'drm-misc-next-2017-06-19_0' of 
git://anongit.freedesktop.org/git/drm-misc into drm-misc-next-fixes
  Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next-fixes

 drivers/gpu/drm/bridge/panel.c  |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  5 ++-
 include/drm/bridge/dw_hdmi.h| 70 ++---
 4 files changed, 40 insertions(+), 39 deletions(-)

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


Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

2017-06-27 Thread Jeff Kirsher
On Wed, 2017-06-28 at 05:28 +1000, Dave Airlie wrote:
> On 20 June 2017 at 18:49, Daniel Vetter  wrote:
> > On Wed, Jun 07, 2017 at 01:07:33AM +, Brown, Aaron F wrote:
> > > > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org]
> > > > On Behalf
> > > > Of Jeff Kirsher
> > > > Sent: Tuesday, June 6, 2017 1:46 PM
> > > > To: David Miller ; Nikula, Jani
> > > > 
> > > > Cc: Ursulin, Tvrtko ; daniel.vetter@ffwll
> > > > .ch; intel-
> > > > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > > > jani.nik...@linux.intel.com; ch...@chris-wilson.co.uk; Ertman,
> > > > David M
> > > > ; intel-wired-...@lists.osuosl.org; dri-
> > > > de...@lists.freedesktop.org; net...@vger.kernel.org; airlied@gmail.
> > > > com
> > > > Subject: Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo
> > > > e1000e_pm_freeze if __e1000_shutdown fails
> > > > 
> > > > On Fri, 2017-06-02 at 14:14 -0400, David Miller wrote:
> > > > > From: Jani Nikula 
> > > > > Date: Wed, 31 May 2017 18:50:43 +0300
> > > > > 
> > > > > > From: Chris Wilson 
> > > > > > 
> > > > > > An error during suspend (e100e_pm_suspend),
> > > > > 
> > > > >  ...
> > > > > > lead to complete failure:
> > > > > 
> > > > >  ...
> > > > > > The unwind failures stems from commit 2800209994f8 ("e1000e:
> > > > > > Refactor PM
> > > > > > flows"), but it may be a later patch that introduced the non-
> > > > > > recoverable
> > > > > > behaviour.
> > > > > > 
> > > > > > Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
> > > > > > Cc: Tvrtko Ursulin 
> > > > > > Cc: Jeff Kirsher 
> > > > > > Cc: Dave Ertman 
> > > > > > Cc: Bruce Allan 
> > > > > > Cc: intel-wired-...@lists.osuosl.org
> > > > > > Cc: net...@vger.kernel.org
> > > > > > Signed-off-by: Chris Wilson 
> > > > > > [Jani: bikeshed repainted]
> > > > > > Signed-off-by: Jani Nikula 
> > > > > 
> > > > > Jeff, please make sure this gets submitted to me soon.
> > > > 
> > > > Expect it later tonight, just finishing up testing.
> > > 
> > > Tested-by: Aaron Brown 
> > 
> > Hm, I seem to be blind, but I can't find it anywhere in -rc6. Does
> > someone
> > have the sha1 from Linus' git for this patch?
> 
> Guys this is a pretty serious regression, just left blowing in the
> wind, is anyone responsible for e1000e?

This was submitted and accepted into David Miller's net-next tree.  I can
see if Dave can pull it into his net tree.  DOes stable need to pick this
up as well?

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

2017-06-27 Thread Arnd Bergmann
On Mon, Jun 26, 2017 at 6:26 PM, Logan Gunthorpe  wrote:
> Hi Jyri,
>
> Thanks for the ack. However, I'm reworking this patch set to use the
> include/linux/io-64-nonatomic* headers which will explicitly devolve
> into two 32-bit transfers. It's not clear whether this is appropriate
> for the tilcdc driver as it was never setup to use 32-bit transfers
> (unlike the others I had patched).
>
> If you think it's ok, I can still patch this driver to use the
> non-atomic headers. Otherwise I can leave it out. Please let me know.

You'd have to first figure out whether this device is of the lo-hi
or the hi-lo variant, or doesn't allow the I/O to be split at all.

Note that we could theoretically define ARM to use strd/ldrd
for writeq/readq, but I would expect that to be wrong with many
other devices that can use the existing io-64-nonatomic headers.

The comment in set_scanout() suggests that we actually do rely
on the write64 to be atomic, so we probably don't want to change
this driver.

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


[PATCH 7/8] drm: Add old state pointer to CRTC .enable() helper function

2017-06-27 Thread Laurent Pinchart
The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.

While at it, rename the operation to .atomic_enable() to be consistent
with .atomic_disable(), as the .enable() operation is used by atomic
helpers only.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  5 ++--
 drivers/gpu/drm/arm/hdlcd_crtc.c|  5 ++--
 drivers/gpu/drm/arm/malidp_crtc.c   |  5 ++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  5 ++--
 drivers/gpu/drm/drm_atomic_helper.c |  7 +++--
 drivers/gpu/drm/drm_simple_kms_helper.c |  5 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|  5 ++--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  |  5 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  5 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  5 ++--
 drivers/gpu/drm/imx/ipuv3-crtc.c|  5 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  5 ++--
 drivers/gpu/drm/meson/meson_crtc.c  |  5 ++--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c|  5 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  5 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c |  5 ++--
 drivers/gpu/drm/qxl/qxl_display.c   |  5 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  5 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  5 ++--
 drivers/gpu/drm/sti/sti_crtc.c  |  5 ++--
 drivers/gpu/drm/stm/ltdc.c  |  5 ++--
 drivers/gpu/drm/sun4i/sun4i_crtc.c  |  5 ++--
 drivers/gpu/drm/tegra/dc.c  |  5 ++--
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c|  8 +-
 drivers/gpu/drm/vc4/vc4_crtc.c  |  5 ++--
 drivers/gpu/drm/virtio/virtgpu_display.c|  5 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  7 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  7 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|  5 ++--
 drivers/gpu/drm/zte/zx_vou.c|  5 ++--
 include/drm/drm_modeset_helper_vtables.h| 38 +
 31 files changed, 117 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 1f306781c9d5..c9bc6a90ac83 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -119,7 +119,8 @@ static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
clk_set_rate(arcpgu->clk, m->crtc_clock * 1000);
 }
 
-static void arc_pgu_crtc_enable(struct drm_crtc *crtc)
+static void arc_pgu_crtc_atomic_enable(struct drm_crtc *crtc,
+  struct drm_crtc_state *old_state)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
 
@@ -161,9 +162,9 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.mode_set   = drm_helper_crtc_mode_set,
.mode_set_base  = drm_helper_crtc_mode_set_base,
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
-   .enable = arc_pgu_crtc_enable,
.disable= arc_pgu_crtc_disable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
+   .atomic_enable  = arc_pgu_crtc_atomic_enable,
 };
 
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index d67b6f15e8b8..2b7f4f05d91f 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -165,7 +165,8 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
clk_set_rate(hdlcd->clk, m->crtc_clock * 1000);
 }
 
-static void hdlcd_crtc_enable(struct drm_crtc *crtc)
+static void hdlcd_crtc_atomic_enable(struct drm_crtc *crtc,
+struct drm_crtc_state *old_state)
 {
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
@@ -218,10 +219,10 @@ static void hdlcd_crtc_atomic_begin(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
-   .enable = hdlcd_crtc_enable,
.disable= hdlcd_crtc_disable,
.atomic_check   = hdlcd_crtc_atomic_check,
.atomic_begin   = hdlcd_crtc_atomic_begin,
+   .atomic_enable  = hdlcd_crtc_atomic_enable,
 };
 
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 4bb38a21efec..8e5b1c0181ab 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -46,7 +46,8 @@ static enum drm_mode_status malidp_crtc_mode_valid(struct 
drm_crtc *crtc,
return MODE_OK;
 }
 
-static void malidp_crtc_enable(struct drm_crtc *crtc)
+static void malidp_crtc_atomic_enable(struct drm_crtc *crtc,
+ struct 

[PATCH 4/8] drm: qxl: Replace CRTC .commit() helper operation with .enable()

2017-06-27 Thread Laurent Pinchart
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 19ba336ce096..7ede5f131a5c 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -447,7 +447,7 @@ static void qxl_mode_set_nofb(struct drm_crtc *crtc)
 
 }
 
-static void qxl_crtc_commit(struct drm_crtc *crtc)
+static void qxl_crtc_enable(struct drm_crtc *crtc)
 {
DRM_DEBUG("\n");
 }
@@ -466,7 +466,7 @@ static const struct drm_crtc_helper_funcs 
qxl_crtc_helper_funcs = {
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
.mode_set_nofb = qxl_mode_set_nofb,
-   .commit = qxl_crtc_commit,
+   .enable = qxl_crtc_enable,
.atomic_flush = qxl_crtc_atomic_flush,
 };
 
-- 
Regards,

Laurent Pinchart

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


[PATCH 8/8] drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()

2017-06-27 Thread Laurent Pinchart
The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo-cult use of
.disable() in new drivers.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   | 5 +++--
 drivers/gpu/drm/arm/hdlcd_crtc.c| 5 +++--
 drivers/gpu/drm/arm/malidp_crtc.c   | 5 +++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 5 +++--
 drivers/gpu/drm/drm_simple_kms_helper.c | 5 +++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 5 +++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 5 +++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 5 +++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +++--
 drivers/gpu/drm/meson/meson_crtc.c  | 5 +++--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 5 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 5 +++--
 drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +++--
 drivers/gpu/drm/qxl/qxl_display.c   | 5 +++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 5 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +++--
 drivers/gpu/drm/sti/sti_crtc.c  | 5 +++--
 drivers/gpu/drm/stm/ltdc.c  | 5 +++--
 drivers/gpu/drm/sun4i/sun4i_crtc.c  | 5 +++--
 drivers/gpu/drm/tegra/dc.c  | 5 +++--
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 8 +++-
 drivers/gpu/drm/vc4/vc4_crtc.c  | 5 +++--
 drivers/gpu/drm/virtio/virtgpu_display.c| 5 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 7 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 7 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 5 +++--
 drivers/gpu/drm/zte/zx_vou.c| 5 +++--
 27 files changed, 87 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index c9bc6a90ac83..1859dd3ad622 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -130,7 +130,8 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc 
*crtc,
  ARCPGU_CTRL_ENABLE_MASK);
 }
 
-static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
+static void arc_pgu_crtc_atomic_disable(struct drm_crtc *crtc,
+   struct drm_crtc_state *old_state)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
 
@@ -162,9 +163,9 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.mode_set   = drm_helper_crtc_mode_set,
.mode_set_base  = drm_helper_crtc_mode_set_base,
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
-   .disable= arc_pgu_crtc_disable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
.atomic_enable  = arc_pgu_crtc_atomic_enable,
+   .atomic_disable = arc_pgu_crtc_atomic_disable,
 };
 
 static void arc_pgu_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 2b7f4f05d91f..16e1e20cf04c 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -176,7 +176,8 @@ static void hdlcd_crtc_atomic_enable(struct drm_crtc *crtc,
drm_crtc_vblank_on(crtc);
 }
 
-static void hdlcd_crtc_disable(struct drm_crtc *crtc)
+static void hdlcd_crtc_atomic_disable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
 {
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
 
@@ -219,10 +220,10 @@ static void hdlcd_crtc_atomic_begin(struct drm_crtc *crtc,
 }
 
 static const struct drm_crtc_helper_funcs hdlcd_crtc_helper_funcs = {
-   .disable= hdlcd_crtc_disable,
.atomic_check   = hdlcd_crtc_atomic_check,
.atomic_begin   = hdlcd_crtc_atomic_begin,
.atomic_enable  = hdlcd_crtc_atomic_enable,
+   .atomic_disable = hdlcd_crtc_atomic_disable,
 };
 
 static int hdlcd_plane_atomic_check(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 8e5b1c0181ab..3615d18a7ddf 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -70,7 +70,8 @@ static void malidp_crtc_atomic_enable(struct drm_crtc *crtc,
drm_crtc_vblank_on(crtc);
 }
 
-static void malidp_crtc_disable(struct drm_crtc *crtc)
+static void malidp_crtc_atomic_disable(struct drm_crtc *crtc,
+  struct drm_crtc_state *old_state)
 {
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
@@ -409,9 +410,9 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
 
 static const struct drm_crtc_helper_funcs malidp_crtc_helper_funcs = {
.mode_valid = 

[PATCH 2/8] drm: arcpgu: Remove CRTC .prepare() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC helper .prepare() operation is legacy code, the atomic helpers
prefer the .disable() operation. As the arcpgu driver implements the
.disable() and .prepare() operations identicallly, .prepare() can be
removed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 51745608e09d..1f306781c9d5 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -163,7 +163,6 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.mode_set_nofb  = arc_pgu_crtc_mode_set_nofb,
.enable = arc_pgu_crtc_enable,
.disable= arc_pgu_crtc_disable,
-   .prepare= arc_pgu_crtc_disable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
 
-- 
Regards,

Laurent Pinchart

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


[PATCH 6/8] drm: vmwgfx: Replace CRTC .commit() helper operation with .enable()

2017-06-27 Thread Laurent Pinchart
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 639e16703b80..f8acd3a15523 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -203,7 +203,7 @@ static void vmw_ldu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 }
 
 /**
- * vmw_ldu_crtc_helper_commit - Noop
+ * vmw_ldu_crtc_helper_enable - Noop
  *
  * @crtc: CRTC associated with the new screen
  *
@@ -212,7 +212,7 @@ static void vmw_ldu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
  * but since for LDU the display plane is closely tied to the
  * CRTC, it makes more sense to do those at plane update time.
  */
-static void vmw_ldu_crtc_helper_commit(struct drm_crtc *crtc)
+static void vmw_ldu_crtc_helper_enable(struct drm_crtc *crtc)
 {
 }
 
@@ -376,7 +376,7 @@ drm_plane_helper_funcs vmw_ldu_primary_plane_helper_funcs = 
{
 };
 
 static const struct drm_crtc_helper_funcs vmw_ldu_crtc_helper_funcs = {
-   .commit = vmw_ldu_crtc_helper_commit,
+   .enable = vmw_ldu_crtc_helper_enable,
.disable = vmw_ldu_crtc_helper_disable,
.mode_set_nofb = vmw_ldu_crtc_mode_set_nofb,
.atomic_check = vmw_du_crtc_atomic_check,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 3b917c9b0c21..1cb826c503bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -270,13 +270,13 @@ static void vmw_sou_crtc_helper_prepare(struct drm_crtc 
*crtc)
 }
 
 /**
- * vmw_sou_crtc_helper_commit - Noop
+ * vmw_sou_crtc_helper_enable - Noop
  *
  * @crtc: CRTC associated with the new screen
  *
  * This is called after a mode set has been completed.
  */
-static void vmw_sou_crtc_helper_commit(struct drm_crtc *crtc)
+static void vmw_sou_crtc_helper_enable(struct drm_crtc *crtc)
 {
 }
 
@@ -573,7 +573,7 @@ drm_plane_helper_funcs vmw_sou_primary_plane_helper_funcs = 
{
 
 static const struct drm_crtc_helper_funcs vmw_sou_crtc_helper_funcs = {
.prepare = vmw_sou_crtc_helper_prepare,
-   .commit = vmw_sou_crtc_helper_commit,
+   .enable = vmw_sou_crtc_helper_enable,
.disable = vmw_sou_crtc_helper_disable,
.mode_set_nofb = vmw_sou_crtc_mode_set_nofb,
.atomic_check = vmw_du_crtc_atomic_check,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 6aecba6cd5e2..4eb93b47d6db 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -412,7 +412,7 @@ static void vmw_stdu_crtc_helper_prepare(struct drm_crtc 
*crtc)
 }
 
 
-static void vmw_stdu_crtc_helper_commit(struct drm_crtc *crtc)
+static void vmw_stdu_crtc_helper_enable(struct drm_crtc *crtc)
 {
struct vmw_private *dev_priv;
struct vmw_screen_target_display_unit *stdu;
@@ -1415,7 +1415,7 @@ drm_plane_helper_funcs 
vmw_stdu_primary_plane_helper_funcs = {
 
 static const struct drm_crtc_helper_funcs vmw_stdu_crtc_helper_funcs = {
.prepare = vmw_stdu_crtc_helper_prepare,
-   .commit = vmw_stdu_crtc_helper_commit,
+   .enable = vmw_stdu_crtc_helper_enable,
.disable = vmw_stdu_crtc_helper_disable,
.mode_set_nofb = vmw_stdu_crtc_mode_set_nofb,
.atomic_check = vmw_du_crtc_atomic_check,
-- 
Regards,

Laurent Pinchart

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


[PATCH 3/8] drm: qxl: Remove unused CRTC .dpms() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC .dpms() helper operation is called by the atomic helpers only
when no .prepare(), .atomic_disable() or .disable() operation is
provided. As the qxl driver provides a .disable() operation, the .dpms()
operation is unused and can be removed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/qxl/qxl_display.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 72dcaab84bba..19ba336ce096 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -378,10 +378,6 @@ qxl_framebuffer_init(struct drm_device *dev,
return 0;
 }
 
-static void qxl_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
-}
-
 static bool qxl_crtc_mode_fixup(struct drm_crtc *crtc,
  const struct drm_display_mode *mode,
  struct drm_display_mode *adjusted_mode)
@@ -467,7 +463,6 @@ static void qxl_crtc_disable(struct drm_crtc *crtc)
 }
 
 static const struct drm_crtc_helper_funcs qxl_crtc_helper_funcs = {
-   .dpms = qxl_crtc_dpms,
.disable = qxl_crtc_disable,
.mode_fixup = qxl_crtc_mode_fixup,
.mode_set_nofb = qxl_mode_set_nofb,
-- 
Regards,

Laurent Pinchart

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


[PATCH 5/8] drm: vmwgfx: Remove unneeded CRTC .prepare() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC .prepare() helper operation is part of the legacy helpers and
is deprecated in favour of the .disable() helper operation. As the
vmwgfx driver provides a .disable() helper operation, and as the
.prepare() helper operation implementation is empty, we can remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 449ed4fba0f2..639e16703b80 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -203,18 +203,6 @@ static void vmw_ldu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 }
 
 /**
- * vmw_ldu_crtc_helper_prepare - Noop
- *
- * @crtc: CRTC associated with the new screen
- *
- * Prepares the CRTC for a mode set, but we don't need to do anything here.
- *
- */
-static void vmw_ldu_crtc_helper_prepare(struct drm_crtc *crtc)
-{
-}
-
-/**
  * vmw_ldu_crtc_helper_commit - Noop
  *
  * @crtc: CRTC associated with the new screen
@@ -388,7 +376,6 @@ drm_plane_helper_funcs vmw_ldu_primary_plane_helper_funcs = 
{
 };
 
 static const struct drm_crtc_helper_funcs vmw_ldu_crtc_helper_funcs = {
-   .prepare = vmw_ldu_crtc_helper_prepare,
.commit = vmw_ldu_crtc_helper_commit,
.disable = vmw_ldu_crtc_helper_disable,
.mode_set_nofb = vmw_ldu_crtc_mode_set_nofb,
-- 
Regards,

Laurent Pinchart

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


[PATCH 0/8] Cleanup CRTC .enable()/.disable() cargo-cult

2017-06-27 Thread Laurent Pinchart
Hello,

The atomic helpers favour the .enable() and .atomic_disable() CRTC helper
operations, but still support the legacy .prepare(), .commit(), .disable() and
.dpms() operations. Some drivers have been updated, but most still use various
combination of new and legacy operations, leading to confusion among new
developers when they read the code.

To avoid cargo-cult use of the legacy operations, this patch series
mass-updates all atomic drivers to use the new CRTC atomic helper operations.

In addition, patch 7/8 adds an old state pointer argument to the CRTC
.enable() helper operation, and rename it to .atomic_enable() for consistency
with .atomic_disable(). These two changes could have been split in separate
patch, but as they are simple and touch the same large number of files,
keeping the two changes as one is simpler and less error-prone.

The patches are based on top of the drm-misc-next branch and have been
compile-tested only except for rcar-du-drm that has been tested on real
hardware. Given the high risk of conflicts I would like to get them merged as
soon as possible (after, of course, proper review and testing).

Laurent Pinchart (8):
  drm: arcpgu: Remove CRTC .commit() helper operation
  drm: arcpgu: Remove CRTC .prepare() helper operation
  drm: qxl: Remove unused CRTC .dpms() helper operation
  drm: qxl: Replace CRTC .commit() helper operation with .enable()
  drm: vmwgfx: Remove unneeded CRTC .prepare() helper operation
  drm: vmwgfx: Replace CRTC .commit() helper operation with .enable()
  drm: Add old state pointer to CRTC .enable() helper function
  drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()

 drivers/gpu/drm/arc/arcpgu_crtc.c   | 12 
 drivers/gpu/drm/arm/hdlcd_crtc.c| 10 ---
 drivers/gpu/drm/arm/malidp_crtc.c   | 10 ---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  | 10 ---
 drivers/gpu/drm/drm_atomic_helper.c |  7 +++--
 drivers/gpu/drm/drm_simple_kms_helper.c | 10 ---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c| 10 ---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c  |  5 ++--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  | 10 ---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 ---
 drivers/gpu/drm/imx/ipuv3-crtc.c|  5 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 ---
 drivers/gpu/drm/meson/meson_crtc.c  | 10 ---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c| 10 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 10 ---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 10 ---
 drivers/gpu/drm/qxl/qxl_display.c   | 15 --
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 10 ---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 ---
 drivers/gpu/drm/sti/sti_crtc.c  | 10 ---
 drivers/gpu/drm/stm/ltdc.c  | 10 ---
 drivers/gpu/drm/sun4i/sun4i_crtc.c  | 10 ---
 drivers/gpu/drm/tegra/dc.c  | 10 ---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 16 +--
 drivers/gpu/drm/vc4/vc4_crtc.c  | 10 ---
 drivers/gpu/drm/virtio/virtgpu_display.c| 10 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 27 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 14 +
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 10 ---
 drivers/gpu/drm/zte/zx_vou.c| 10 ---
 include/drm/drm_modeset_helper_vtables.h| 38 +
 31 files changed, 204 insertions(+), 155 deletions(-)

-- 
Regards,

Laurent Pinchart

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


[PATCH 1/8] drm: arcpgu: Remove CRTC .commit() helper operation

2017-06-27 Thread Laurent Pinchart
The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. As the arcpgu driver implements the
.enable() operation, .commit() is never used and can be removed.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 611af74a31c0..51745608e09d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -164,7 +164,6 @@ static const struct drm_crtc_helper_funcs 
arc_pgu_crtc_helper_funcs = {
.enable = arc_pgu_crtc_enable,
.disable= arc_pgu_crtc_disable,
.prepare= arc_pgu_crtc_disable,
-   .commit = arc_pgu_crtc_enable,
.atomic_begin   = arc_pgu_crtc_atomic_begin,
 };
 
-- 
Regards,

Laurent Pinchart

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


[PATCH 5/8] drm/vc4: Delay DSI host registration until the panel has probed.

2017-06-27 Thread Eric Anholt
The vc4 driver was unusual in that it was delaying the panel lookup
until the attach step, while most DSI hosts will -EPROBE_DEFER until
they get a panel.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 40 
 1 file changed, 16 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index fca4d7fd677e..31627522dd8c 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -504,7 +505,6 @@ struct vc4_dsi {
struct mipi_dsi_host dsi_host;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
-   bool is_panel_bridge;
 
void __iomem *regs;
 
@@ -1290,7 +1290,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
   struct mipi_dsi_device *device)
 {
struct vc4_dsi *dsi = host_to_dsi(host);
-   int ret = 0;
 
dsi->lanes = device->lanes;
dsi->channel = device->channel;
@@ -1325,34 +1324,12 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host 
*host,
return 0;
}
 
-   dsi->bridge = of_drm_find_bridge(device->dev.of_node);
-   if (!dsi->bridge) {
-   struct drm_panel *panel =
-   of_drm_find_panel(device->dev.of_node);
-
-   dsi->bridge = drm_panel_bridge_add(panel,
-  DRM_MODE_CONNECTOR_DSI);
-   if (IS_ERR(dsi->bridge)) {
-   ret = PTR_ERR(dsi->bridge);
-   dsi->bridge = NULL;
-   return ret;
-   }
-   dsi->is_panel_bridge = true;
-   }
-
return drm_bridge_attach(dsi->encoder, dsi->bridge, NULL);
 }
 
 static int vc4_dsi_host_detach(struct mipi_dsi_host *host,
   struct mipi_dsi_device *device)
 {
-   struct vc4_dsi *dsi = host_to_dsi(host);
-
-   if (dsi->is_panel_bridge) {
-   drm_panel_bridge_remove(dsi->bridge);
-   dsi->bridge = NULL;
-   }
-
return 0;
 }
 
@@ -1496,6 +1473,7 @@ static int vc4_dsi_bind(struct device *dev, struct device 
*master, void *data)
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_dsi *dsi;
struct vc4_dsi_encoder *vc4_dsi_encoder;
+   struct drm_panel *panel;
const struct of_device_id *match;
dma_cap_mask_t dma_mask;
int ret;
@@ -1599,6 +1577,20 @@ static int vc4_dsi_bind(struct device *dev, struct 
device *master, void *data)
return ret;
}
 
+   ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
+ , >bridge);
+   if (ret) {
+   dev_info(dev, "find panel: %d\n", ret);
+   return ret;
+   }
+
+   if (panel) {
+   dsi->bridge = devm_drm_panel_bridge_add(dev, panel,
+   DRM_MODE_CONNECTOR_DSI);
+   if (IS_ERR(dsi->bridge))
+   return PTR_ERR(dsi->bridge);
+   }
+
/* The esc clock rate is supposed to always be 100Mhz. */
ret = clk_set_rate(dsi->escape_clock, 100 * 100);
if (ret) {
-- 
2.11.0

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


[PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.

2017-06-27 Thread Eric Anholt
When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible strings.  Those get registered as DSI devices,
and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes.

There is one special case currently, the adv7533 bridge, where the
bridge probes on I2C, and during the bridge attach step it looks up
the mipi_dsi_host and registers the mipi_dsi_device (for its own stub
mipi_dsi_driver).

For the Raspberry Pi panel, though, we also need to attach on I2C (our
control bus), but don't have a bridge driver.  The lack of a bridge's
attach() step like adv7533 uses means that we aren't able to delay the
mipi_dsi_device creation until the mipi_dsi_host is present.

To fix this, we extend mipi_dsi_device_register_full() to allow being
called with a NULL host, which puts the device on a queue waiting for
a host to appear.  When a new host is registered, we fill in the host
value and finish the device creation process.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 49 --
 include/drm/drm_mipi_dsi.h |  3 +++
 2 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 1160a579e0dc..9cdd68a7dc0d 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -45,6 +45,13 @@
  * subset of the MIPI DCS command set.
  */
 
+static DEFINE_MUTEX(host_lock);
+static LIST_HEAD(host_list);
+/* List of struct mipi_dsi_device which were registered while no host
+ * was available.
+ */
+static LIST_HEAD(unattached_device_list);
+
 static int mipi_dsi_device_match(struct device *dev, struct device_driver *drv)
 {
struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);
@@ -138,10 +145,12 @@ static struct mipi_dsi_device 
*mipi_dsi_device_alloc(struct mipi_dsi_host *host)
 
dsi->host = host;
dsi->dev.bus = _dsi_bus_type;
-   dsi->dev.parent = host->dev;
dsi->dev.type = _dsi_device_type;
 
-   device_initialize(>dev);
+   if (dsi->host) {
+   dsi->dev.parent = host->dev;
+   device_initialize(>dev);
+   }
 
return dsi;
 }
@@ -206,7 +215,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
  const struct mipi_dsi_device_info *info)
 {
struct mipi_dsi_device *dsi;
-   struct device *dev = host->dev;
+   struct device *dev = host ? host->dev : NULL;
int ret;
 
if (!info) {
@@ -230,11 +239,17 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
dsi->channel = info->channel;
strlcpy(dsi->name, info->type, sizeof(dsi->name));
 
-   ret = mipi_dsi_device_add(dsi);
-   if (ret) {
-   dev_err(dev, "failed to add DSI device %d\n", ret);
-   kfree(dsi);
-   return ERR_PTR(ret);
+   if (!dsi->host) {
+   mutex_lock(_lock);
+   list_add(>list, _device_list);
+   mutex_unlock(_lock);
+   } else {
+   ret = mipi_dsi_device_add(dsi);
+   if (ret) {
+   dev_err(dev, "failed to add DSI device %d\n", ret);
+   kfree(dsi);
+   return ERR_PTR(ret);
+   }
}
 
return dsi;
@@ -251,9 +266,6 @@ void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi)
 }
 EXPORT_SYMBOL(mipi_dsi_device_unregister);
 
-static DEFINE_MUTEX(host_lock);
-static LIST_HEAD(host_list);
-
 /**
  * of_find_mipi_dsi_host_by_node() - find the MIPI DSI host matching a
  *  device tree node
@@ -285,6 +297,7 @@ EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
 int mipi_dsi_host_register(struct mipi_dsi_host *host)
 {
struct device_node *node;
+   struct mipi_dsi_device *dsi, *temp;
 
for_each_available_child_of_node(host->dev->of_node, node) {
/* skip nodes without reg property */
@@ -295,6 +308,20 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
 
mutex_lock(_lock);
list_add_tail(>list, _list);
+
+   /* If any DSI devices were registered under our OF node, then
+* connect our host to it and probe them now.
+*/
+   list_for_each_entry_safe(dsi, temp, _device_list, list) {
+   if (of_get_parent(dsi->dev.of_node) == host->dev->of_node) {
+   dsi->host = host;
+   dsi->dev.parent = host->dev;
+   device_initialize(>dev);
+
+   mipi_dsi_device_add(dsi);
+   list_del_init(>list);
+   }
+   }
mutex_unlock(_lock);
 
return 0;
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 4fef19064b0f..699ea4acd5b6 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -178,6 +178,9 @@ struct mipi_dsi_device {

[PATCH 8/8] drm/panel: Add support for the Raspberry Pi 7" Touchscreen.

2017-06-27 Thread Eric Anholt
This driver communicates with the Atmel microcontroller for sequencing
the poweron of the TC358762 DSI-DPI bridge and controlling the
backlight PWM.

v2: Set the same default orientation as the closed source firmware
used, which is the best for viewing angle.
v3: Rewrite as an i2c client driver after bridge driver rejection.
v4: Finish probe without the DSI host, using the new delayed
registration, and attach to the host during mipi_dsi_driver probe.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/panel/Kconfig  |   8 +
 drivers/gpu/drm/panel/Makefile |   1 +
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 505 +
 3 files changed, 514 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d84a031fae24..d6f1969b8a3b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -73,6 +73,14 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 
+config DRM_PANEL_RASPBERRYPI_TOUCHSCREEN
+   tristate "Raspberry Pi 7-inch touchscreen panel"
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for the Raspberry
+ Pi 7" Touchscreen.  To compile this driver as a module,
+ choose M here.
+
 config DRM_PANEL_SAMSUNG_S6E3HA2
tristate "Samsung S6E3HA2 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 9f6610d08b00..bd17fac21c7b 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += 
panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
+obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
new file mode 100644
index ..b23331051d79
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
@@ -0,0 +1,505 @@
+/*
+ * Copyright © 2016-2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Portions of this file (derived from panel-simple.c) are:
+ *
+ * Copyright (C) 2013, NVIDIA Corporation.  All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+/**
+ * Raspberry Pi 7" touchscreen panel driver.
+ *
+ * The 7" touchscreen consists of a DPI LCD panel, a Toshiba
+ * TC358762XBG DSI-DPI bridge, and an I2C-connected Atmel ATTINY88-MUR
+ * controlling power management, the LCD PWM, and initial register
+ * setup of the Tohsiba.
+ *
+ * This driver controls the TC358762 and ATTINY88, presenting a DSI
+ * device with a drm_panel.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RPI_DSI_DRIVER_NAME "rpi-ts-dsi"
+
+/* I2C registers of the Atmel microcontroller. */
+enum REG_ADDR {
+   REG_ID = 0x80,
+   REG_PORTA, /* BIT(2) for horizontal flip, BIT(3) for vertical flip */
+   REG_PORTB,
+   REG_PORTC,
+   REG_PORTD,
+   

[PATCH 7/8] dt-bindings: Document the Raspberry Pi Touchscreen nodes.

2017-06-27 Thread Eric Anholt
This doesn't yet cover input, but the driver does get the display
working when the firmware is disabled from talking to our I2C lines.

Signed-off-by: Eric Anholt 
Acked-by: Rob Herring 
---
 .../panel/raspberrypi,7inch-touchscreen.txt| 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
 
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
new file mode 100644
index ..e9e19c059260
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
@@ -0,0 +1,49 @@
+This binding covers the official 7" (800x480) Raspberry Pi touchscreen
+panel.
+
+This DSI panel contains:
+
+- TC358762 DSI->DPI bridge
+- Atmel microcontroller on I2C for power sequencing the DSI bridge and
+  controlling backlight
+- Touchscreen controller on I2C for touch input
+
+and this binding covers the DSI display parts but not its touch input.
+
+Required properties:
+- compatible:  Must be "raspberrypi,7inch-touchscreen-panel"
+- reg: Must be "45"
+- port:See panel-common.txt
+
+Example:
+
+dsi1: dsi@7e70 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   <...>
+
+   port {
+   dsi_out_port: endpoint {
+   remote-endpoint = <_dsi_port>;
+   };
+   };
+};
+
+i2c_dsi: i2c {
+   compatible = "i2c-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   gpios = < 28 0
+ 29 0>;
+
+   lcd@45 {
+   compatible = "raspberrypi,7inch-touchscreen-panel";
+   reg = <0x45>;
+
+   port {
+   panel_dsi_port: endpoint {
+   remote-endpoint = <_out_port>;
+   };
+   };
+   };
+};
-- 
2.11.0

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


[PATCH 3/8] drm/vc4: Use drm_mode_vrefresh() in DSI fixup, in case vrefresh is 0.

2017-06-27 Thread Eric Anholt
I'm not sure what changed where I started getting vrefresh=0 from the
mode to be fixed up.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 629d372633e6..fca4d7fd677e 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -866,7 +866,9 @@ static bool vc4_dsi_encoder_mode_fixup(struct drm_encoder 
*encoder,
adjusted_mode->clock = pixel_clock_hz / 1000 + 1;
 
/* Given the new pixel clock, adjust HFP to keep vrefresh the same. */
-   adjusted_mode->htotal = pixel_clock_hz / (mode->vrefresh * 
mode->vtotal);
+   adjusted_mode->htotal = pixel_clock_hz / (drm_mode_vrefresh(mode) *
+ mode->vtotal);
+
adjusted_mode->hsync_end += adjusted_mode->htotal - mode->htotal;
adjusted_mode->hsync_start += adjusted_mode->htotal - mode->htotal;
 
-- 
2.11.0

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


[PATCH 2/8] drm/vc4: Fix misleading name of the continuous flag.

2017-06-27 Thread Eric Anholt
The logic was all right in the end, the name was just backwards.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 15f6d5005ab9..629d372633e6 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -736,18 +736,18 @@ static void vc4_dsi_latch_ulps(struct vc4_dsi *dsi, bool 
latch)
 /* Enters or exits Ultra Low Power State. */
 static void vc4_dsi_ulps(struct vc4_dsi *dsi, bool ulps)
 {
-   bool continuous = dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS;
-   u32 phyc_ulps = ((continuous ? DSI_PORT_BIT(PHYC_CLANE_ULPS) : 0) |
+   bool non_continuous = dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS;
+   u32 phyc_ulps = ((non_continuous ? DSI_PORT_BIT(PHYC_CLANE_ULPS) : 0) |
 DSI_PHYC_DLANE0_ULPS |
 (dsi->lanes > 1 ? DSI_PHYC_DLANE1_ULPS : 0) |
 (dsi->lanes > 2 ? DSI_PHYC_DLANE2_ULPS : 0) |
 (dsi->lanes > 3 ? DSI_PHYC_DLANE3_ULPS : 0));
-   u32 stat_ulps = ((continuous ? DSI1_STAT_PHY_CLOCK_ULPS : 0) |
+   u32 stat_ulps = ((non_continuous ? DSI1_STAT_PHY_CLOCK_ULPS : 0) |
 DSI1_STAT_PHY_D0_ULPS |
 (dsi->lanes > 1 ? DSI1_STAT_PHY_D1_ULPS : 0) |
 (dsi->lanes > 2 ? DSI1_STAT_PHY_D2_ULPS : 0) |
 (dsi->lanes > 3 ? DSI1_STAT_PHY_D3_ULPS : 0));
-   u32 stat_stop = ((continuous ? DSI1_STAT_PHY_CLOCK_STOP : 0) |
+   u32 stat_stop = ((non_continuous ? DSI1_STAT_PHY_CLOCK_STOP : 0) |
 DSI1_STAT_PHY_D0_STOP |
 (dsi->lanes > 1 ? DSI1_STAT_PHY_D1_STOP : 0) |
 (dsi->lanes > 2 ? DSI1_STAT_PHY_D2_STOP : 0) |
-- 
2.11.0

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


[PATCH 4/8] drm/bridge: Add a devm_ allocator for panel bridge.

2017-06-27 Thread Eric Anholt
This will let drivers reduce the error cleanup they need, in
particular the "is_panel_bridge" flag.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/bridge/panel.c | 30 ++
 include/drm/drm_bridge.h   |  3 +++
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 67fe19e5a9c6..cdf367d2653a 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -198,3 +198,33 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
devm_kfree(panel_bridge->panel->dev, bridge);
 }
 EXPORT_SYMBOL(drm_panel_bridge_remove);
+
+static void devm_drm_panel_bridge_release(struct device *dev, void *res)
+{
+   struct drm_bridge *bridge = *(struct drm_bridge **)res;
+
+   drm_panel_bridge_remove(bridge);
+}
+
+struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
+struct drm_panel *panel,
+u32 connector_type)
+{
+   struct drm_bridge **ptr, *bridge;
+
+   ptr = devres_alloc(devm_drm_panel_bridge_release, sizeof(*ptr),
+  GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+
+   bridge = drm_panel_bridge_add(panel, connector_type);
+   if (!IS_ERR(bridge)) {
+   *ptr = bridge;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return bridge;
+}
+EXPORT_SYMBOL(devm_drm_panel_bridge_add);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 1dc94d5392e2..6522d4cbc9d9 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -268,6 +268,9 @@ void drm_bridge_enable(struct drm_bridge *bridge);
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type);
 void drm_panel_bridge_remove(struct drm_bridge *bridge);
+struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
+struct drm_panel *panel,
+u32 connector_type);
 #endif
 
 #endif
-- 
2.11.0

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


[PATCH 1/8] drm/vc4: Fix DSI T_INIT timing.

2017-06-27 Thread Eric Anholt
The DPHY spec requires a much larger T_INIT than I was specifying
before.  In the absence of clear specs from the slave of what their
timing is, just use the value that the firmware was using.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 5e8b81eaa168..15f6d5005ab9 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1035,7 +1035,17 @@ static void vc4_dsi_encoder_enable(struct drm_encoder 
*encoder)
 DSI_HS_DLT4_TRAIL) |
   VC4_SET_FIELD(0, DSI_HS_DLT4_ANLAT));
 
-   DSI_PORT_WRITE(HS_DLT5, VC4_SET_FIELD(dsi_hs_timing(ui_ns, 1000, 5000),
+   /* T_INIT is how long STOP is driven after power-up to
+* indicate to the slave (also coming out of power-up) that
+* master init is complete, and should be greater than the
+* maximum of two value: T_INIT,MASTER and T_INIT,SLAVE.  The
+* D-PHY spec gives a minimum 100us for T_INIT,MASTER and
+* T_INIT,SLAVE, while allowing protocols on top of it to give
+* greater minimums.  The vc4 firmware uses an extremely
+* conservative 5ms, and we maintain that here.
+*/
+   DSI_PORT_WRITE(HS_DLT5, VC4_SET_FIELD(dsi_hs_timing(ui_ns,
+   5 * 1000 * 1000, 0),
  DSI_HS_DLT5_INIT));
 
DSI_PORT_WRITE(HS_DLT6,
-- 
2.11.0

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


[PATCH 0/8] RPi touchscreen panel driver v4

2017-06-27 Thread Eric Anholt
The review for v3 was basically "no, the panel should probe first so
that we have the connector by the time KMS is done initializing."  To
do this, I needed to be able to register the custom (non-OF-generated)
DSI device without the host being present (patch 6).  Also check out
patch 4 for a new cleanup to panel-bridge.

Eric Anholt (8):
  drm/vc4: Fix DSI T_INIT timing.
  drm/vc4: Fix misleading name of the continuous flag.
  drm/vc4: Use drm_mode_vrefresh() in DSI fixup, in case vrefresh is 0.
  drm/bridge: Add a devm_ allocator for panel bridge.
  drm/vc4: Delay DSI host registration until the panel has probed.
  drm: Allow DSI devices to be registered before the host registers.
  dt-bindings: Document the Raspberry Pi Touchscreen nodes.
  drm/panel: Add support for the Raspberry Pi 7" Touchscreen.

 .../panel/raspberrypi,7inch-touchscreen.txt|  49 ++
 drivers/gpu/drm/bridge/panel.c |  30 ++
 drivers/gpu/drm/drm_mipi_dsi.c |  49 +-
 drivers/gpu/drm/panel/Kconfig  |   8 +
 drivers/gpu/drm/panel/Makefile |   1 +
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  | 505 +
 drivers/gpu/drm/vc4/vc4_dsi.c  |  64 +--
 include/drm/drm_bridge.h   |   3 +
 include/drm/drm_mipi_dsi.h |   3 +
 9 files changed, 671 insertions(+), 41 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.txt
 create mode 100644 drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c

-- 
2.11.0

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


Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

2017-06-27 Thread Dave Airlie
On 20 June 2017 at 18:49, Daniel Vetter  wrote:
> On Wed, Jun 07, 2017 at 01:07:33AM +, Brown, Aaron F wrote:
>> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On Behalf
>> > Of Jeff Kirsher
>> > Sent: Tuesday, June 6, 2017 1:46 PM
>> > To: David Miller ; Nikula, Jani
>> > 
>> > Cc: Ursulin, Tvrtko ; daniel.vet...@ffwll.ch; 
>> > intel-
>> > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
>> > jani.nik...@linux.intel.com; ch...@chris-wilson.co.uk; Ertman, David M
>> > ; intel-wired-...@lists.osuosl.org; dri-
>> > de...@lists.freedesktop.org; net...@vger.kernel.org; airl...@gmail.com
>> > Subject: Re: [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo
>> > e1000e_pm_freeze if __e1000_shutdown fails
>> >
>> > On Fri, 2017-06-02 at 14:14 -0400, David Miller wrote:
>> > > From: Jani Nikula 
>> > > Date: Wed, 31 May 2017 18:50:43 +0300
>> > >
>> > > > From: Chris Wilson 
>> > > >
>> > > > An error during suspend (e100e_pm_suspend),
>> > >
>> > >  ...
>> > > > lead to complete failure:
>> > >
>> > >  ...
>> > > > The unwind failures stems from commit 2800209994f8 ("e1000e:
>> > > > Refactor PM
>> > > > flows"), but it may be a later patch that introduced the non-
>> > > > recoverable
>> > > > behaviour.
>> > > >
>> > > > Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
>> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
>> > > > Cc: Tvrtko Ursulin 
>> > > > Cc: Jeff Kirsher 
>> > > > Cc: Dave Ertman 
>> > > > Cc: Bruce Allan 
>> > > > Cc: intel-wired-...@lists.osuosl.org
>> > > > Cc: net...@vger.kernel.org
>> > > > Signed-off-by: Chris Wilson 
>> > > > [Jani: bikeshed repainted]
>> > > > Signed-off-by: Jani Nikula 
>> > >
>> > > Jeff, please make sure this gets submitted to me soon.
>> >
>> > Expect it later tonight, just finishing up testing.
>>
>> Tested-by: Aaron Brown 
>
> Hm, I seem to be blind, but I can't find it anywhere in -rc6. Does someone
> have the sha1 from Linus' git for this patch?

Guys this is a pretty serious regression, just left blowing in the
wind, is anyone responsible for e1000e?

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


[Bug 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

2017-06-27 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=196197

--- Comment #2 from Andreas Brogle (an...@ok.de) ---
Hello,

Sorry, I've read the git dokumentation half the day, anyway I don't understand
how bisect works and how to use it.

Is the following what you need ?

# git bisect log 
git bisect start
# bad: [c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201] Linux 4.11-rc1
git bisect bad c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201
# good: [7089db84e356562f8ba737c29e472cc42d530dbc] Linux 4.10-rc8
git bisect good 7089db84e356562f8ba737c29e472cc42d530dbc


What I have done is downloading from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
the original kernel sources, compiled them and tested them
4.12-rc7 (bad)
4.11-rc1 (bad)
4.10-rc8 (good)

The bug arises with 4.11 and still persists in 4.12, so as I assumed the step
from 4.10 to 4.11 should be eamined.

Thanks,
Andreas

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


Re: [PATCH 13/13] drm/atomic-helper: Realign function parameters

2017-06-27 Thread Harry Wentland
On 2017-06-27 10:59 AM, Daniel Vetter wrote:
> Too jarring.
> 
> Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers 
> (v2)")
> Cc: Andrey Grodzovsky 
> Cc: Alex Deucher 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2f269e4267da..5a80b6960ae1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2964,12 +2964,11 @@ drm_atomic_helper_connector_set_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
>  
> -static int page_flip_common(
> - struct drm_atomic_state *state,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags)
> +static int page_flip_common(struct drm_atomic_state *state,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_plane_state *plane_state;
> @@ -3063,13 +3062,12 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip);
>   * Returns:
>   * Returns 0 on success, negative errno numbers on failure.
>   */
> -int drm_atomic_helper_page_flip_target(
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags,
> - uint32_t target,
> - struct drm_modeset_acquire_ctx *ctx)
> +int drm_atomic_helper_page_flip_target(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event *event,
> +uint32_t flags,
> +uint32_t target,
> +struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_atomic_state *state;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 101572] glMemoryBarrier is backwards

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101572

--- Comment #5 from Matias N. Goldberg  ---
(btw unsetting the FBO indeed fixes the issue)

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


[Bug 101572] glMemoryBarrier is backwards

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101572

--- Comment #4 from Matias N. Goldberg  ---
After careful thought; I realized I don't need to switch to a dummy FBO; just
unset the current one.

That DOES make sense to me as while the FBO is bound and I'm executing the
compute shader that reads from it, I could as well be telling the driver to do
both things at the same time.

I could see why unsetting the FBO would flush the necessary caches (due to
OpenGL guarantees, I'm saying "I'm done writing to this FBO" and now reads
should be guaranteed to be correct), so I'm going to take this for an answer.

I don't want to spend much more time on this matter either.

Thanks.

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


[Bug 101572] glMemoryBarrier is backwards

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101572

--- Comment #3 from Matias N. Goldberg  ---
I rather be told that I am wrong in how to interpret glMemoryBarrier, and that
I should be calling glMemoryBarrier( GL_FRAMEBUFFER_BARRIER_BIT ); because this
and that.

-- 
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 101572] glMemoryBarrier is backwards

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101572

--- Comment #2 from Matias N. Goldberg  ---
That can't be right.

You're suggesting that in order to synchronize writes from FBO with a Compute
Shader I am going to dispatch (which btw the Compute Shader is accessing this
fbo as a regular sample fetch, not via imageLoad/imageStore) then I either need
to:

1. Switch to a dummy FBO, something that is mentioned nowhere: neither on
manuals or online documentation, wikis, or tutorials; also it's not mentioned
to be a guarantee in the spec either.

2. Use a function that was added in OpenGL 4.5; when Compute Shaders were added
in 4.3.

I may be misinterpreting the spec; but these solution don't make any sense.
Best case Mesa should detect that I am trying to read from an FBO in a compute
shader being dispatched and issue a barrier for me; worst case one of the
functionality already present in 4.3 (like glMemoryBarrier) that doesn't look
esoteric (like switching FBOs) should be enough to synchronize.

-- 
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 13/13] drm/atomic-helper: Realign function parameters

2017-06-27 Thread Deucher, Alexander
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Tuesday, June 27, 2017 11:00 AM
> To: DRI Development
> Cc: Intel Graphics Development; Daniel Vetter; Grodzovsky, Andrey;
> Deucher, Alexander; Daniel Vetter
> Subject: [PATCH 13/13] drm/atomic-helper: Realign function parameters
> 
> Too jarring.
> 
> Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic
> helpers (v2)")
> Cc: Andrey Grodzovsky 
> Cc: Alex Deucher 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2f269e4267da..5a80b6960ae1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2964,12 +2964,11 @@
> drm_atomic_helper_connector_set_property(struct drm_connector
> *connector,
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
> 
> -static int page_flip_common(
> - struct drm_atomic_state *state,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags)
> +static int page_flip_common(struct drm_atomic_state *state,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_plane_state *plane_state;
> @@ -3063,13 +3062,12 @@
> EXPORT_SYMBOL(drm_atomic_helper_page_flip);
>   * Returns:
>   * Returns 0 on success, negative errno numbers on failure.
>   */
> -int drm_atomic_helper_page_flip_target(
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event,
> - uint32_t flags,
> - uint32_t target,
> - struct drm_modeset_acquire_ctx *ctx)
> +int drm_atomic_helper_page_flip_target(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event
> *event,
> +uint32_t flags,
> +uint32_t target,
> +struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_atomic_state *state;
> --
> 2.11.0

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


[Bug 101594] Blender doesn't detect OpenCL with Clover

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101594

--- Comment #1 from Vedran Miletić  ---
Can you post your clinfo?

-- 
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 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100289

--- Comment #11 from omegap...@startmail.com ---
Wow, thats one hell of a lot of output :) I'll keep running with
'drm.debug=0x01' until I get the problem next, thanks.

I'm on Devuan Testing rather than Ubuntu (RE the Padoka PPA) - looking at
https://packages.qa.debian.org/m/mesa.html , I can see that 17.1.3-2 is coming
to unstable shortly - is that still too old?

If yes, I'll look into building all the stuff myself (I'll look around for some
docs and probably base it off packages I can see on the Padoka PPA I'm
guessing.

Separately, https://bugs.freedesktop.org/show_bug.cgi?id=99769 is a great link
- I have recently (in recent months) enabled TearFree, so if some related
failure is the culprit that is at least some progress. I really like TearFree
(without it the top of the primary monitor tears with fullscreen videos), but
am perfectly happy to disable it to see if the issue goes away (TearFree is
more than worth the current failure state mind).

-- 
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 100242] radeon buffer allocation failure during startup of Factorio

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100242

--- Comment #11 from tnmailingli...@gmail.com ---
The game starts up fine without a crash now and handles the out of memory error
gracefully like before. Thanks!

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


[PATCH 11/13] drm/exynos: Remove custom FB helper deferred setup

2017-06-27 Thread Daniel Vetter
From: Thierry Reding 

The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.

v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Thierry Reding  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  6 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 26 +-
 2 files changed, 5 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 35a8dfc93836..cab9e12d7846 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -395,8 +395,9 @@ static int exynos_drm_bind(struct device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(drm);
 
-   /* force connectors detection */
-   drm_helper_hpd_irq_event(drm);
+   ret = exynos_drm_fbdev_init(drm);
+   if (ret)
+   goto err_cleanup_poll;
 
/* register the DRM device */
ret = drm_dev_register(drm, 0);
@@ -407,6 +408,7 @@ static int exynos_drm_bind(struct device *dev)
 
 err_cleanup_fbdev:
exynos_drm_fbdev_fini(drm);
+err_cleanup_poll:
drm_kms_helper_poll_fini(drm);
exynos_drm_device_subdrv_remove(drm);
 err_unbind_all:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 641531243e04..c3a068409b48 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -183,24 +183,6 @@ static const struct drm_fb_helper_funcs 
exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
 };
 
-static bool exynos_drm_fbdev_is_anything_connected(struct drm_device *dev)
-{
-   struct drm_connector *connector;
-   bool ret = false;
-
-   mutex_lock(>mode_config.mutex);
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
-   if (connector->status != connector_status_connected)
-   continue;
-
-   ret = true;
-   break;
-   }
-   mutex_unlock(>mode_config.mutex);
-
-   return ret;
-}
-
 int exynos_drm_fbdev_init(struct drm_device *dev)
 {
struct exynos_drm_fbdev *fbdev;
@@ -211,9 +193,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
if (!dev->mode_config.num_crtc || !dev->mode_config.num_connector)
return 0;
 
-   if (!exynos_drm_fbdev_is_anything_connected(dev))
-   return 0;
-
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev)
return -ENOMEM;
@@ -304,8 +283,5 @@ void exynos_drm_output_poll_changed(struct drm_device *dev)
struct exynos_drm_private *private = dev->dev_private;
struct drm_fb_helper *fb_helper = private->fb_helper;
 
-   if (fb_helper)
-   drm_fb_helper_hotplug_event(fb_helper);
-   else
-   exynos_drm_fbdev_init(dev);
+   drm_fb_helper_hotplug_event(fb_helper);
 }
-- 
2.11.0

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


Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

2017-06-27 Thread Daniel Vetter
On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote:
> Op 27-06-17 om 09:37 schreef Daniel Vetter:
> > On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
> >> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> >>> Problem : While running IGT kms_atomic_transition test suite i encountered
> >>> a hang in drmHandleEvent immediately following  an atomic_commit.
> >>> After dumping the atomic state I relized that in this case there was
> >>> not even one CRTC attached to the state and only disabled
> >>> planes. This probably due to a commit which hadn't changed any property
> >>> which would require attaching crtc state. This means drmHandleEvent
> >>> will never wake up from read since without CRTC in atomic state
> >>> the event fd will not be signaled.
> >>>
> >>> Fix: Protect against this issue by failing atomic_commit early in
> >>> drm_mode_atomic_commit where such probelm can be identified.
> >>>
> >>> v2:
> >>> Fix typos and extra newlines.
> >>>
> >>> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
> >>> Signed-off-by: Andrey Grodzovsky 
> >> Reviewed-by: Harry Wentland 
> > Stalling on this hoping for the igt patch. Does it exist already?
> > -Daniel
> >
> >> Harry
> >>
> >>> ---
> >>>  drivers/gpu/drm/drm_atomic.c | 11 ++-
> >>>  1 file changed, 10 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index a567310..48145bf 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> >>> *dev,
> >>>  {
> >>>   struct drm_crtc *crtc;
> >>>   struct drm_crtc_state *crtc_state;
> >>> - int i, ret;
> >>> + int i, c = 0, ret;
> >>>  
> >>>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
> >>>   return 0;
> >>> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct 
> >>> drm_device *dev,
> >>>  
> >>>   crtc_state->event->base.fence = fence;
> >>>   }
> >>> +
> >>> + c++;
> >>>   }
> >>>  
> >>> + /*
> >>> +  * Having this flag means user mode pends on event which will never
> >>> +  * reach due to lack of at least one CRTC for signaling
> >>> +  */
> >>> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> >>> + return -EINVAL;
> >>> +
> >>>   return 0;
> >>>  }
> >>>  
> >>>
> Just do it, and I'll commit this to igt?

Ack on both the kernel patch and the igt patch, feel free to push them
both with:

Acked-by: Daniel Vetter 

If you do, please add the Testcase: line to the kernel patch.

Thanks, Daniel

> 
> diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
> index 6375fede7179..77429b3db384 100644
> --- a/tests/kms_atomic.c
> +++ b/tests/kms_atomic.c
> @@ -1205,6 +1205,15 @@ static void crtc_invalid_params(struct 
> kms_atomic_crtc_state *crtc_old,
>   crtc_commit_atomic(, plane, req, ATOMIC_RELAX_NONE,
>  DRM_MODE_ATOMIC_TEST_ONLY);
>  
> + /*
> +  * TEST_ONLY cannot be combined with DRM_MODE_PAGE_FLIP_EVENT,
> +  * but DRM_MODE_PAGE_FLIP_EVENT will always generate EINVAL
> +  * without valid crtc, so test it here.
> +  */
> + crtc_commit_atomic_err(, plane, req, ATOMIC_RELAX_NONE,
> +DRM_MODE_ATOMIC_TEST_ONLY | 
> DRM_MODE_PAGE_FLIP_EVENT,
> +EINVAL);
> +
>   /* Create a blob which is the wrong size to be a valid mode. */
>   do_or_die(drmModeCreatePropertyBlob(crtc.state->desc->fd,
>   crtc.mode.data,
> @@ -1356,12 +1365,12 @@ static void atomic_invalid_params(struct 
> kms_atomic_crtc_state *crtc,
>   /* Valid pointers, but still should copy nothing. */
>   do_ioctl(desc->fd, DRM_IOCTL_MODE_ATOMIC, );
>  
> - /* Nonsense flags. */
> - ioc.flags = 0xdeadbeef;
> + /* Valid noop, but with event set should fail. */
> + ioc.flags = DRM_MODE_PAGE_FLIP_EVENT;
>   do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
>  
> - /* Specifically forbidden combination. */
> - ioc.flags = DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_PAGE_FLIP_EVENT;
> + /* Nonsense flags. */
> + ioc.flags = 0xdeadbeef;
>   do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
>  
>   ioc.flags = 0;
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


[PATCH 08/13] drm/fb-helper: Stop using mode_config.mutex for internals

2017-06-27 Thread Daniel Vetter
Those are now all protected using fb_helper->lock.

v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.

v3: I forgot to hold mode_config.mutex while looking at
connector->status and the mode list. Also, we need to patch up the
i915 ->initial_config callback to grab the locks it needs to inspect
the modeset state recovered from the fw.

Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c| 33 -
 drivers/gpu/drm/drm_vblank.c   |  2 +-
 drivers/gpu/drm/i915/intel_fbdev.c | 16 
 3 files changed, 21 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 400bbb07eff2..59e2916471b2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -106,7 +106,7 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  */
 
 #define drm_fb_helper_for_each_connector(fbh, i__) \
-   for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
+   for (({ lockdep_assert_held(&(fbh)->lock); }), \
 i__ = 0; i__ < (fbh)->connector_count; i__++)
 
 static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
@@ -120,7 +120,6 @@ static int __drm_fb_helper_add_one_connector(struct 
drm_fb_helper *fb_helper,
return 0;
 
lockdep_assert_held(_helper->lock);
-   lockdep_assert_held(_helper->dev->mode_config.mutex);
 
count = fb_helper->connector_count + 1;
 
@@ -152,11 +151,7 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper,
int err;
 
mutex_lock(_helper->lock);
-   mutex_lock(_helper->dev->mode_config.mutex);
-
err = __drm_fb_helper_add_one_connector(fb_helper, connector);
-
-   mutex_unlock(_helper->dev->mode_config.mutex);
mutex_unlock(_helper->lock);
 
return err;
@@ -188,7 +183,6 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
return 0;
 
mutex_lock(_helper->lock);
-   mutex_lock(>mode_config.mutex);
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
@@ -210,7 +204,6 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
fb_helper->connector_count = 0;
 out:
drm_connector_list_iter_end(_iter);
-   mutex_unlock(>mode_config.mutex);
mutex_unlock(_helper->lock);
 
return ret;
@@ -253,11 +246,7 @@ int drm_fb_helper_remove_one_connector(struct 
drm_fb_helper *fb_helper,
int err;
 
mutex_lock(_helper->lock);
-   mutex_lock(_helper->dev->mode_config.mutex);
-
err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
-
-   mutex_unlock(_helper->dev->mode_config.mutex);
mutex_unlock(_helper->lock);
 
return err;
@@ -1893,12 +1882,11 @@ void drm_fb_helper_fill_var(struct fb_info *info, 
struct drm_fb_helper *fb_helpe
 EXPORT_SYMBOL(drm_fb_helper_fill_var);
 
 static int drm_fb_helper_probe_connector_modes(struct drm_fb_helper *fb_helper,
-  uint32_t maxX,
-  uint32_t maxY)
+   uint32_t maxX,
+   uint32_t maxY)
 {
struct drm_connector *connector;
-   int count = 0;
-   int i;
+   int i, count = 0;
 
drm_fb_helper_for_each_connector(fb_helper, i) {
connector = fb_helper->connector_info[i]->connector;
@@ -2296,12 +2284,8 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
int i;
 
DRM_DEBUG_KMS("\n");
-   if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
-   DRM_DEBUG_KMS("No connectors reported connected with modes\n");
-
/* prevent concurrent modification of connector_count by hotplug */
lockdep_assert_held(_helper->lock);
-   lockdep_assert_held(_helper->dev->mode_config.mutex);
 
crtcs = kcalloc(fb_helper->connector_count,
sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
@@ -2316,7 +2300,10 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
goto out;
}
 
+   mutex_lock(_helper->dev->mode_config.mutex);
drm_enable_connectors(fb_helper, enabled);
+   if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
+   DRM_DEBUG_KMS("No connectors reported connected with modes\n");
 
if (!(fb_helper->funcs->initial_config &&
  fb_helper->funcs->initial_config(fb_helper, crtcs, modes,
@@ -2337,6 +2324,7 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
 
  

[PATCH 12/13] drm/hisilicon: Remove custom FB helper deferred setup

2017-06-27 Thread Daniel Vetter
From: Thierry Reding 

The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 8065d6cb1d7f..da51befa8246 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -54,14 +54,7 @@ static void kirin_fbdev_output_poll_changed(struct 
drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
-   if (priv->fbdev) {
-   drm_fbdev_cma_hotplug_event(priv->fbdev);
-   } else {
-   priv->fbdev = drm_fbdev_cma_init(dev, 32,
-
dev->mode_config.num_connector);
-   if (IS_ERR(priv->fbdev))
-   priv->fbdev = NULL;
-   }
+   drm_fbdev_cma_hotplug_event(priv->fbdev);
 }
 #endif
 
@@ -128,11 +121,19 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
 
-   /* force detection after connectors init */
-   (void)drm_helper_hpd_irq_event(dev);
+   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+dev->mode_config.num_connector);
+   if (IS_ERR(priv->fbdev)) {
+   DRM_ERROR("failed to initialize fbdev.\n");
+   ret = PTR_ERR(priv->fbdev);
+   goto err_cleanup_poll;
+   }
 
return 0;
 
+err_cleanup_poll:
+   drm_kms_helper_poll_fini(dev);
+   drm_vblank_cleanup(dev);
 err_unbind_all:
component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
-- 
2.11.0

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


[PATCH 10/13] drm/fb-helper: Support deferred setup

2017-06-27 Thread Daniel Vetter
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.

The fallback is in place because VGA connectors can happen to report an
unknown connection status even when they are in fact connected.

Some drivers have custom solutions in place to defer FB helper setup
until at least one output is connected. But the logic behind these
solutions is always the same and there is nothing driver-specific about
it, so a better alterative is to fix the FB helper core and add support
for all drivers automatically.

This patch adds support for deferred FB helper setup. It checks all the
connectors for their connection status, and if all of them report to be
disconnected marks the FB helper as needing deferred setup. Whet setup
is deferred, the FB helper core will automatically retry setup after a
hotplug event, and it will keep trying until it succeeds.

v2: Rebase onto my entirely reworked fbdev helper locking. One big
difference is that this version again drops the fbdev lock
(which is now fb_helper->lock, but before this patch series it was
mode_config->mutex), because register_framebuffer must be able to
recurse back into fbdev helper code for the initial screen setup.

v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon
return, I've fumbled that in the deferred setup case (Liviu).

v4: I was blind, redo this all. __drm_fb_helper_initial_config
shouldn't need to reacquire fb_helper->lock, that just confuses
callers. I myself got confused by kernel_fb_helper_lock and somehow
thought it's the same as fb_helper->lock. Tsk.

Also simplify the logic a bit (we don't need two functions to probe
connectors), we can stick much closer to the existing code. And update
some comments I've spotted that are outdated.

Cc: Liviu Dudau 
Cc: John Stultz 
Cc: Thierry Reding  (v1)
Tested-by: John Stultz 
Signed-off-by: Thierry Reding  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 100 ++--
 include/drm/drm_fb_helper.h |  23 +
 2 files changed, 88 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bbd4c6d0378d..d833eb2320d1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -521,6 +521,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return -ENODEV;
 
+   if (READ_ONCE(fb_helper->deferred_setup))
+   return 0;
+
mutex_lock(_helper->lock);
ret = restore_fbdev_mode(fb_helper);
 
@@ -1695,8 +1698,7 @@ EXPORT_SYMBOL(drm_fb_helper_pan_display);
 
 /*
  * Allocates the backing storage and sets up the fbdev info structure through
- * the ->fb_probe callback and then registers the fbdev and sets up the panic
- * notifier.
+ * the ->fb_probe callback.
  */
 static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
 int preferred_bpp)
@@ -1794,13 +1796,8 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
}
 
if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
-   /*
-* hmm everyone went away - assume VGA cable just fell out
-* and will come back later.
-*/
-   DRM_INFO("Cannot find any crtc or sizes - going 1024x768\n");
-   sizes.fb_width = sizes.surface_width = 1024;
-   sizes.fb_height = sizes.surface_height = 768;
+   DRM_INFO("Cannot find any crtc or sizes\n");
+   return -EAGAIN;
}
 
/* Handle our overallocation */
@@ -2429,6 +2426,57 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
kfree(enabled);
 }
 
+/* Note: Drops fb_helper->lock before returning. */
+static int __drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper,
+ int bpp_sel)
+{
+   struct drm_device *dev = fb_helper->dev;
+   struct fb_info *info;
+   unsigned int width, height;
+   int ret;
+
+   width = dev->mode_config.max_width;
+   height = dev->mode_config.max_height;
+
+   drm_setup_crtcs(fb_helper, width, height);
+   ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
+   if (ret < 0) {
+   if (ret == -EAGAIN) {
+   fb_helper->preferred_bpp = bpp_sel;
+   fb_helper->deferred_setup = true;
+   }
+   mutex_unlock(_helper->lock);
+
+   return ret;
+   }
+
+   

[PATCH 13/13] drm/atomic-helper: Realign function parameters

2017-06-27 Thread Daniel Vetter
Too jarring.

Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers 
(v2)")
Cc: Andrey Grodzovsky 
Cc: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 2f269e4267da..5a80b6960ae1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2964,12 +2964,11 @@ drm_atomic_helper_connector_set_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
 
-static int page_flip_common(
-   struct drm_atomic_state *state,
-   struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   struct drm_pending_vblank_event *event,
-   uint32_t flags)
+static int page_flip_common(struct drm_atomic_state *state,
+   struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   struct drm_pending_vblank_event *event,
+   uint32_t flags)
 {
struct drm_plane *plane = crtc->primary;
struct drm_plane_state *plane_state;
@@ -3063,13 +3062,12 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip);
  * Returns:
  * Returns 0 on success, negative errno numbers on failure.
  */
-int drm_atomic_helper_page_flip_target(
-   struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   struct drm_pending_vblank_event *event,
-   uint32_t flags,
-   uint32_t target,
-   struct drm_modeset_acquire_ctx *ctx)
+int drm_atomic_helper_page_flip_target(struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  struct drm_pending_vblank_event *event,
+  uint32_t flags,
+  uint32_t target,
+  struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_plane *plane = crtc->primary;
struct drm_atomic_state *state;
-- 
2.11.0

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


[PATCH 09/13] drm/fb-helper: Split dpms handling into legacy and atomic paths

2017-06-27 Thread Daniel Vetter
Like with panning and modesetting, and like with those, stick with
simple drm_modeset_locking_all for the legacy path, and the full
atomic dance for atomic drivers.

This means a bit more boilerplate since setting up the atomic state
machinery is rather verbose, but then this is shared code for 30+
drivers or so, so meh.

After this patch there's only the LUT/cmap path which is still using
drm_modeset_lock_all for an atomic driver. But Peter is already
locking into reworking that, so I'll leave that code as-is for now.

Cc: Peter Rosin 
Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 88 +++--
 1 file changed, 76 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 59e2916471b2..bbd4c6d0378d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -616,23 +616,13 @@ static struct sysrq_key_op sysrq_drm_fb_helper_restore_op 
= {
 static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
 #endif
 
-static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
+static void dpms_legacy(struct drm_fb_helper *fb_helper, int dpms_mode)
 {
-   struct drm_fb_helper *fb_helper = info->par;
struct drm_device *dev = fb_helper->dev;
struct drm_crtc *crtc;
struct drm_connector *connector;
int i, j;
 
-   /*
-* For each CRTC in this fb, turn the connectors on/off.
-*/
-   mutex_lock(_helper->lock);
-   if (!drm_fb_helper_is_bound(fb_helper)) {
-   mutex_unlock(_helper->lock);
-   return;
-   }
-
drm_modeset_lock_all(dev);
for (i = 0; i < fb_helper->crtc_count; i++) {
crtc = fb_helper->crtc_info[i].mode_set.crtc;
@@ -649,6 +639,81 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
}
}
drm_modeset_unlock_all(dev);
+}
+
+static void dpms_atomic(struct drm_fb_helper *fb_helper, int dpms_mode)
+{
+   struct drm_device *dev = fb_helper->dev;
+   struct drm_atomic_state *state;
+   int i, ret;
+
+   struct drm_modeset_acquire_ctx ctx;
+
+   drm_modeset_acquire_init(, 0);
+
+   state = drm_atomic_state_alloc(dev);
+   if (!state) {
+   ret = -ENOMEM;
+   goto out_ctx;
+   }
+
+   state->acquire_ctx = 
+retry:
+   for (i = 0; i < fb_helper->crtc_count; i++) {
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+
+   if (!fb_helper->crtc_info[i].mode_set.mode)
+   continue;
+
+   crtc = fb_helper->crtc_info[i].mode_set.crtc;
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   goto out_state;
+   }
+
+   crtc_state->active = dpms_mode == DRM_MODE_DPMS_ON;
+   }
+
+   ret = drm_atomic_commit(state);
+out_state:
+   if (ret == -EDEADLK)
+   goto backoff;
+
+   drm_atomic_state_put(state);
+out_ctx:
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
+   return;
+
+backoff:
+   drm_atomic_state_clear(state);
+   drm_modeset_backoff();
+
+   goto retry;
+
+}
+
+static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   /*
+* For each CRTC in this fb, turn the connectors on/off.
+*/
+   mutex_lock(_helper->lock);
+   if (!drm_fb_helper_is_bound(fb_helper)) {
+   mutex_unlock(_helper->lock);
+   return;
+   }
+
+   if (drm_drv_uses_atomic_modeset(fb_helper->dev))
+   dpms_atomic(fb_helper, dpms_mode);
+   else
+   dpms_legacy(fb_helper, dpms_mode);
mutex_unlock(_helper->lock);
 }
 
@@ -2467,7 +2532,6 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
  */
 int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
 {
-   struct drm_device *dev = fb_helper->dev;
int err = 0;
 
if (!drm_fbdev_emulation)
-- 
2.11.0

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


[PATCH 07/13] drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy

2017-06-27 Thread Daniel Vetter
Same game as with the panning function, use drm_modeset_lock_all for
legacy paths, and a proper acquire ctx w/w mutex dance for atomic.

Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 48 +
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5d8bf7dfa618..400bbb07eff2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -396,12 +396,17 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper)
struct drm_atomic_state *state;
int i, ret;
unsigned int plane_mask;
+   struct drm_modeset_acquire_ctx ctx;
+
+   drm_modeset_acquire_init(, 0);
 
state = drm_atomic_state_alloc(dev);
-   if (!state)
-   return -ENOMEM;
+   if (!state) {
+   ret = -ENOMEM;
+   goto out_ctx;
+   }
 
-   state->acquire_ctx = dev->mode_config.acquire_ctx;
+   state->acquire_ctx = 
 retry:
plane_mask = 0;
drm_for_each_plane(plane, dev) {
@@ -410,7 +415,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper)
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
-   goto fail;
+   goto out_state;
}
 
plane_state->rotation = DRM_MODE_ROTATE_0;
@@ -424,7 +429,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper)
 
ret = __drm_atomic_helper_disable_plane(plane, plane_state);
if (ret != 0)
-   goto fail;
+   goto out_state;
}
 
for (i = 0; i < fb_helper->crtc_count; i++) {
@@ -432,23 +437,27 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper)
 
ret = __drm_atomic_helper_set_config(mode_set, state);
if (ret != 0)
-   goto fail;
+   goto out_state;
}
 
ret = drm_atomic_commit(state);
 
-fail:
+out_state:
drm_atomic_clean_old_fb(dev, plane_mask, ret);
 
if (ret == -EDEADLK)
goto backoff;
 
drm_atomic_state_put(state);
+out_ctx:
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
return ret;
 
 backoff:
drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
+   drm_modeset_backoff();
 
goto retry;
 }
@@ -457,8 +466,9 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper 
*fb_helper)
 {
struct drm_device *dev = fb_helper->dev;
struct drm_plane *plane;
-   int i;
+   int i, ret = 0;
 
+   drm_modeset_lock_all(fb_helper->dev);
drm_for_each_plane(plane, dev) {
if (plane->type != DRM_PLANE_TYPE_PRIMARY)
drm_plane_force_disable(plane);
@@ -472,32 +482,31 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper 
*fb_helper)
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set = 
_helper->crtc_info[i].mode_set;
struct drm_crtc *crtc = mode_set->crtc;
-   int ret;
 
if (crtc->funcs->cursor_set2) {
ret = crtc->funcs->cursor_set2(crtc, NULL, 0, 0, 0, 0, 
0);
if (ret)
-   return ret;
+   goto out;
} else if (crtc->funcs->cursor_set) {
ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
if (ret)
-   return ret;
+   goto out;
}
 
ret = drm_mode_set_config_internal(mode_set);
if (ret)
-   return ret;
+   goto out;
}
+out:
+   drm_modeset_unlock_all(fb_helper->dev);
 
-   return 0;
+   return ret;
 }
 
 static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
 {
struct drm_device *dev = fb_helper->dev;
 
-   drm_warn_on_modeset_not_all_locked(dev);
-
if (drm_drv_uses_atomic_modeset(dev))
return restore_fbdev_mode_atomic(fb_helper);
else
@@ -517,7 +526,6 @@ static int restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
  */
 int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
 {
-   struct drm_device *dev = fb_helper->dev;
bool do_delayed;
int ret;
 
@@ -525,15 +533,11 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
return -ENODEV;
 
mutex_lock(_helper->lock);
-   

[PATCH 06/13] drm/fb-helper: Push locking into pan_display_atomic|legacy

2017-06-27 Thread Daniel Vetter
For the legacy path we'll keep drm_modeset_lock_all, for the atomic
one we drop the use of the magic implicit context and wire it up
properly.

Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 13330c22e6bf..5d8bf7dfa618 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1331,7 +1331,6 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned 
int cmd,
unsigned long arg)
 {
struct drm_fb_helper *fb_helper = info->par;
-   struct drm_device *dev = fb_helper->dev;
struct drm_mode_set *mode_set;
struct drm_crtc *crtc;
int ret = 0;
@@ -1522,12 +1521,17 @@ static int pan_display_atomic(struct fb_var_screeninfo 
*var,
struct drm_plane *plane;
int i, ret;
unsigned int plane_mask;
+   struct drm_modeset_acquire_ctx ctx;
+
+   drm_modeset_acquire_init(, 0);
 
state = drm_atomic_state_alloc(dev);
-   if (!state)
-   return -ENOMEM;
+   if (!state) {
+   ret = -ENOMEM;
+   goto out_ctx;
+   }
 
-   state->acquire_ctx = dev->mode_config.acquire_ctx;
+   state->acquire_ctx = 
 retry:
plane_mask = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
@@ -1540,7 +1544,7 @@ static int pan_display_atomic(struct fb_var_screeninfo 
*var,
 
ret = __drm_atomic_helper_set_config(mode_set, state);
if (ret != 0)
-   goto fail;
+   goto out_state;
 
plane = mode_set->crtc->primary;
plane_mask |= (1 << drm_plane_index(plane));
@@ -1549,23 +1553,27 @@ static int pan_display_atomic(struct fb_var_screeninfo 
*var,
 
ret = drm_atomic_commit(state);
if (ret != 0)
-   goto fail;
+   goto out_state;
 
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
 
-fail:
+out_state:
drm_atomic_clean_old_fb(dev, plane_mask, ret);
 
if (ret == -EDEADLK)
goto backoff;
 
drm_atomic_state_put(state);
+out_ctx:
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
return ret;
 
 backoff:
drm_atomic_state_clear(state);
-   drm_atomic_legacy_backoff(state);
+   drm_modeset_backoff();
 
goto retry;
 }
@@ -1578,6 +1586,7 @@ static int pan_display_legacy(struct fb_var_screeninfo 
*var,
int ret = 0;
int i;
 
+   drm_modeset_lock_all(fb_helper->dev);
for (i = 0; i < fb_helper->crtc_count; i++) {
modeset = _helper->crtc_info[i].mode_set;
 
@@ -1592,6 +1601,7 @@ static int pan_display_legacy(struct fb_var_screeninfo 
*var,
}
}
}
+   drm_modeset_unlock_all(fb_helper->dev);
 
return ret;
 }
@@ -1617,12 +1627,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo 
*var,
return -EBUSY;
}
 
-   drm_modeset_lock_all(dev);
if (drm_drv_uses_atomic_modeset(dev))
ret = pan_display_atomic(var, info);
else
ret = pan_display_legacy(var, info);
-   drm_modeset_unlock_all(dev);
mutex_unlock(_helper->lock);
 
return ret;
-- 
2.11.0

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


[PATCH 01/13] drm/fb-helper: Push down modeset lock into FB helpers

2017-06-27 Thread Daniel Vetter
From: Thierry Reding 

Move the modeset locking from drivers into FB helpers.

v2: Also handle intel_connector_add_to_fbdev.

Tested-by: John Stultz 
Signed-off-by: Thierry Reding  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c| 40 +-
 drivers/gpu/drm/i915/intel_dp_mst.c|  6 -
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  7 --
 3 files changed, 34 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 574af01d3ce9..5e73cc9f51e3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -109,8 +109,8 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
 i__ = 0; i__ < (fbh)->connector_count; i__++)
 
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
-   struct drm_connector *connector)
+static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+struct drm_connector *connector)
 {
struct drm_fb_helper_connector *fb_conn;
struct drm_fb_helper_connector **temp;
@@ -141,8 +141,23 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper,
drm_connector_get(connector);
fb_conn->connector = connector;
fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
+
return 0;
 }
+
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+   struct drm_connector *connector)
+{
+   int err;
+
+   mutex_lock(_helper->dev->mode_config.mutex);
+
+   err = __drm_fb_helper_add_one_connector(fb_helper, connector);
+
+   mutex_unlock(_helper->dev->mode_config.mutex);
+
+   return err;
+}
 EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
 
 /**
@@ -172,8 +187,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
mutex_lock(>mode_config.mutex);
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
-   ret = drm_fb_helper_add_one_connector(fb_helper, connector);
-
+   ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
if (ret)
goto fail;
}
@@ -198,8 +212,8 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
 
-int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
-  struct drm_connector *connector)
+static int __drm_fb_helper_remove_one_connector(struct drm_fb_helper 
*fb_helper,
+   struct drm_connector *connector)
 {
struct drm_fb_helper_connector *fb_helper_connector;
int i, j;
@@ -227,6 +241,20 @@ int drm_fb_helper_remove_one_connector(struct 
drm_fb_helper *fb_helper,
 
return 0;
 }
+
+int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
+  struct drm_connector *connector)
+{
+   int err;
+
+   mutex_lock(_helper->dev->mode_config.mutex);
+
+   err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
+
+   mutex_unlock(_helper->dev->mode_config.mutex);
+
+   return err;
+}
 EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
 
 static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct 
drm_fb_helper *helper)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 2cf046beae0f..5b78165882ce 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -501,11 +501,8 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 static void intel_dp_register_mst_connector(struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
-   struct drm_device *dev = connector->dev;
 
-   drm_modeset_lock_all(dev);
intel_connector_add_to_fbdev(intel_connector);
-   drm_modeset_unlock_all(dev);
 
drm_connector_register(_connector->base);
 }
@@ -514,15 +511,12 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
   struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
-   struct drm_device *dev = connector->dev;
 
drm_connector_unregister(connector);
 
/* need to nuke the connector */
-   drm_modeset_lock_all(dev);
intel_connector_remove_from_fbdev(intel_connector);
intel_connector->mst_port = NULL;
-   drm_modeset_unlock_all(dev);
 

[PATCH 04/13] drm/fb-helper: Push locking in fb_is_bound

2017-06-27 Thread Daniel Vetter
That function only needs to take the individual crtc locks, not all
the kms locks. Push down the locking and then minimize it.

Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a0d4603857d8..14b3f885a01f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -557,10 +557,12 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
*fb_helper)
return false;
 
drm_for_each_crtc(crtc, dev) {
+   drm_modeset_lock(>mutex, NULL);
if (crtc->primary->fb)
crtcs_bound++;
if (crtc->primary->fb == fb_helper->fb)
bound++;
+   drm_modeset_unlock(>mutex);
}
 
if (bound < crtcs_bound)
@@ -635,13 +637,12 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
 * For each CRTC in this fb, turn the connectors on/off.
 */
mutex_lock(_helper->lock);
-   drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
-   drm_modeset_unlock_all(dev);
mutex_unlock(_helper->lock);
return;
}
 
+   drm_modeset_lock_all(dev);
for (i = 0; i < fb_helper->crtc_count; i++) {
crtc = fb_helper->crtc_info[i].mode_set.crtc;
 
@@ -1277,13 +1278,12 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
fb_info *info)
return -EBUSY;
 
mutex_lock(_helper->lock);
-   drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
-   drm_modeset_unlock_all(dev);
mutex_unlock(_helper->lock);
return -EBUSY;
}
 
+   drm_modeset_lock_all(dev);
for (i = 0; i < fb_helper->crtc_count; i++) {
crtc = fb_helper->crtc_info[i].mode_set.crtc;
crtc_funcs = crtc->helper_private;
@@ -1337,12 +1337,12 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned 
int cmd,
int ret = 0;
 
mutex_lock(_helper->lock);
-   mutex_lock(>mode_config.mutex);
if (!drm_fb_helper_is_bound(fb_helper)) {
ret = -EBUSY;
goto unlock;
}
 
+   mutex_lock(>mode_config.mutex);
switch (cmd) {
case FBIO_WAITFORVSYNC:
/*
@@ -1614,13 +1614,12 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo 
*var,
return -EBUSY;
 
mutex_lock(_helper->lock);
-   drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
-   drm_modeset_unlock_all(dev);
mutex_unlock(_helper->lock);
return -EBUSY;
}
 
+   drm_modeset_lock_all(dev);
if (drm_drv_uses_atomic_modeset(dev))
ret = pan_display_atomic(var, info);
else
@@ -2481,16 +2480,15 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
return 0;
 
mutex_lock(_helper->lock);
-   mutex_lock(>mode_config.mutex);
-
if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
-   mutex_unlock(>mode_config.mutex);
-   goto unlock;
+   mutex_unlock(_helper->lock);
+   return err;
}
 
DRM_DEBUG_KMS("\n");
 
+   mutex_lock(>mode_config.mutex);
drm_setup_crtcs(fb_helper, fb_helper->fb->width, fb_helper->fb->height);
 
mutex_unlock(>mode_config.mutex);
@@ -2499,10 +2497,6 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper 
*fb_helper)
drm_fb_helper_set_par(fb_helper->fbdev);
 
return 0;
-
-unlock:
-   mutex_unlock(_helper->lock);
-   return err;
 }
 EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
 
-- 
2.11.0

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


[PATCH 05/13] drm/fb-helper: Drop locking from the vsync wait ioctl code

2017-06-27 Thread Daniel Vetter
Like with the drm-native vblank wait ioctl we can entirely rely on the
spinlocks in drm_vblank.c, no need at all to take expensive mutexes.
The only reason we had to take mode_config.mutex was to protect the
fbdev helper's data-structures, but that's now done by
fb_helper->lock.

Cc: John Stultz 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 14b3f885a01f..13330c22e6bf 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1342,7 +1342,6 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned 
int cmd,
goto unlock;
}
 
-   mutex_lock(>mode_config.mutex);
switch (cmd) {
case FBIO_WAITFORVSYNC:
/*
@@ -1382,7 +1381,6 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned 
int cmd,
}
 
 unlock:
-   mutex_unlock(>mode_config.mutex);
mutex_unlock(_helper->lock);
return ret;
 }
-- 
2.11.0

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


[PATCH 02/13] drm/i915: Drop FBDEV #ifdev in mst code

2017-06-27 Thread Daniel Vetter
Since

commit a03fdcb1863297481a4b817c2a759cafcbdfa0ae
Author: Archit Taneja 
Date:   Wed Aug 5 12:28:57 2015 +0530

drm: Add top level Kconfig option for DRM fbdev emulation

this is properly handled using dummy functions. This essentially
undoes

commit 7296c849bf2eca2bd7d34a4686a53e3089150ac1
Author: Chris Wilson 
Date:   Tue Jul 22 20:10:28 2014 +1000

drm/i915: fix build without fbde

Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 37 ++---
 1 file changed, 10 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 5b78165882ce..c43ed29995b3 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -443,28 +443,6 @@ static bool intel_dp_mst_get_hw_state(struct 
intel_connector *connector)
return false;
 }
 
-static void intel_connector_add_to_fbdev(struct intel_connector *connector)
-{
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-
-   if (dev_priv->fbdev)
-   drm_fb_helper_add_one_connector(_priv->fbdev->helper,
-   >base);
-#endif
-}
-
-static void intel_connector_remove_from_fbdev(struct intel_connector 
*connector)
-{
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
-
-   if (dev_priv->fbdev)
-   drm_fb_helper_remove_one_connector(_priv->fbdev->helper,
-  >base);
-#endif
-}
-
 static struct drm_connector *intel_dp_add_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port, const char 
*pathprop)
 {
struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
@@ -500,25 +478,30 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 
 static void intel_dp_register_mst_connector(struct drm_connector *connector)
 {
-   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->dev);
 
-   intel_connector_add_to_fbdev(intel_connector);
+   if (dev_priv->fbdev)
+   drm_fb_helper_add_one_connector(_priv->fbdev->helper,
+   connector);
 
-   drm_connector_register(_connector->base);
+   drm_connector_register(connector);
 }
 
 static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr *mgr,
   struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct drm_i915_private *dev_priv = to_i915(connector->dev);
 
drm_connector_unregister(connector);
 
/* need to nuke the connector */
-   intel_connector_remove_from_fbdev(intel_connector);
+   if (dev_priv->fbdev)
+   drm_fb_helper_remove_one_connector(_priv->fbdev->helper,
+  connector);
intel_connector->mst_port = NULL;
 
-   drm_connector_unreference(_connector->base);
+   drm_connector_unreference(connector);
DRM_DEBUG_KMS("\n");
 }
 
-- 
2.11.0

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


[PATCH 00/13] fbdev locking rework and deferred setup, take 2

2017-06-27 Thread Daniel Vetter
Hi all,

Thanks to Liviu's help I realized that I fumbled the locking rework completely.
This one here should be better, but somehow I'm having a real bad day today and
I spent all day typing shit code, and then making it worse.

This here seems to work at first glance, but please test and review carefully.

Thanks a lot.

Cheers, Daniel

Daniel Vetter (9):
  drm/i915: Drop FBDEV #ifdev in mst code
  drm/fb-helper: Push locking in fb_is_bound
  drm/fb-helper: Drop locking from the vsync wait ioctl code
  drm/fb-helper: Push locking into pan_display_atomic|legacy
  drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy
  drm/fb-helper: Stop using mode_config.mutex for internals
  drm/fb-helper: Split dpms handling into legacy and atomic paths
  drm/fb-helper: Support deferred setup
  drm/atomic-helper: Realign function parameters

Thierry Reding (4):
  drm/fb-helper: Push down modeset lock into FB helpers
  drm/fb-helper: Add top-level lock
  drm/exynos: Remove custom FB helper deferred setup
  drm/hisilicon: Remove custom FB helper deferred setup

 drivers/gpu/drm/drm_atomic_helper.c |  24 +-
 drivers/gpu/drm/drm_fb_helper.c | 362 +---
 drivers/gpu/drm/drm_vblank.c|   2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |  26 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  21 +-
 drivers/gpu/drm/i915/intel_dp_mst.c |  43 +--
 drivers/gpu/drm/i915/intel_fbdev.c  |  16 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c  |   7 -
 include/drm/drm_fb_helper.h |  42 ++-
 10 files changed, 345 insertions(+), 204 deletions(-)

-- 
2.11.0

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


[PATCH 03/13] drm/fb-helper: Add top-level lock

2017-06-27 Thread Daniel Vetter
From: Thierry Reding 

Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.

This patch just adds the new lock everywhere we currently grab
mode_config->mutex (explicitly, or through drm_modeset_lock_all).
Follow-up patches will push the kms locking down into only the places
that need it.

v2:
- use lockdep_assert_held
- use drm_fb_helper_for_each_connector where possible
- use the new top-level lock consistently, i.e. in all the places
  we're currently acquiring mode_config.mutex.
- small polish to the kerneldoc

Tested-by: John Stultz 
Signed-off-by: Thierry Reding  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 47 +
 include/drm/drm_fb_helper.h | 19 -
 2 files changed, 61 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5e73cc9f51e3..a0d4603857d8 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -119,7 +119,8 @@ static int __drm_fb_helper_add_one_connector(struct 
drm_fb_helper *fb_helper,
if (!drm_fbdev_emulation)
return 0;
 
-   WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
+   lockdep_assert_held(_helper->lock);
+   lockdep_assert_held(_helper->dev->mode_config.mutex);
 
count = fb_helper->connector_count + 1;
 
@@ -150,11 +151,13 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper,
 {
int err;
 
+   mutex_lock(_helper->lock);
mutex_lock(_helper->dev->mode_config.mutex);
 
err = __drm_fb_helper_add_one_connector(fb_helper, connector);
 
mutex_unlock(_helper->dev->mode_config.mutex);
+   mutex_unlock(_helper->lock);
 
return err;
 }
@@ -184,6 +187,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return 0;
 
+   mutex_lock(_helper->lock);
mutex_lock(>mode_config.mutex);
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
@@ -207,6 +211,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
 out:
drm_connector_list_iter_end(_iter);
mutex_unlock(>mode_config.mutex);
+   mutex_unlock(_helper->lock);
 
return ret;
 }
@@ -221,9 +226,9 @@ static int __drm_fb_helper_remove_one_connector(struct 
drm_fb_helper *fb_helper,
if (!drm_fbdev_emulation)
return 0;
 
-   WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
+   lockdep_assert_held(_helper->lock);
 
-   for (i = 0; i < fb_helper->connector_count; i++) {
+   drm_fb_helper_for_each_connector(fb_helper, i) {
if (fb_helper->connector_info[i]->connector == connector)
break;
}
@@ -247,11 +252,13 @@ int drm_fb_helper_remove_one_connector(struct 
drm_fb_helper *fb_helper,
 {
int err;
 
+   mutex_lock(_helper->lock);
mutex_lock(_helper->dev->mode_config.mutex);
 
err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
 
mutex_unlock(_helper->dev->mode_config.mutex);
+   mutex_unlock(_helper->lock);
 
return err;
 }
@@ -517,16 +524,21 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return -ENODEV;
 
+   mutex_lock(_helper->lock);
drm_modeset_lock_all(dev);
+
ret = restore_fbdev_mode(fb_helper);
 
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
fb_helper->delayed_hotplug = false;
+
drm_modeset_unlock_all(dev);
+   mutex_unlock(_helper->lock);
 
if (do_delayed)
drm_fb_helper_hotplug_event(fb_helper);
+
return ret;
 }
 EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
@@ -576,11 +588,13 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
 
+   mutex_lock(>lock);
drm_modeset_lock_all(dev);
ret = restore_fbdev_mode(helper);
if (ret)
error = true;
drm_modeset_unlock_all(dev);
+   mutex_unlock(>lock);
}
return error;
 }
@@ -620,9 +634,11 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
/*
 * For each CRTC in this fb, turn the connectors on/off.
 */
+   mutex_lock(_helper->lock);
drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
+   

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

2017-06-27 Thread Maarten Lankhorst
Op 27-06-17 om 09:37 schreef Daniel Vetter:
> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote:
>> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
>>> Problem : While running IGT kms_atomic_transition test suite i encountered
>>> a hang in drmHandleEvent immediately following  an atomic_commit.
>>> After dumping the atomic state I relized that in this case there was
>>> not even one CRTC attached to the state and only disabled
>>> planes. This probably due to a commit which hadn't changed any property
>>> which would require attaching crtc state. This means drmHandleEvent
>>> will never wake up from read since without CRTC in atomic state
>>> the event fd will not be signaled.
>>>
>>> Fix: Protect against this issue by failing atomic_commit early in
>>> drm_mode_atomic_commit where such probelm can be identified.
>>>
>>> v2:
>>> Fix typos and extra newlines.
>>>
>>> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
>>> Signed-off-by: Andrey Grodzovsky 
>> Reviewed-by: Harry Wentland 
> Stalling on this hoping for the igt patch. Does it exist already?
> -Daniel
>
>> Harry
>>
>>> ---
>>>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> index a567310..48145bf 100644
>>> --- a/drivers/gpu/drm/drm_atomic.c
>>> +++ b/drivers/gpu/drm/drm_atomic.c
>>> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
>>> *dev,
>>>  {
>>> struct drm_crtc *crtc;
>>> struct drm_crtc_state *crtc_state;
>>> -   int i, ret;
>>> +   int i, c = 0, ret;
>>>  
>>> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>>> return 0;
>>> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
>>> *dev,
>>>  
>>> crtc_state->event->base.fence = fence;
>>> }
>>> +
>>> +   c++;
>>> }
>>>  
>>> +   /*
>>> +* Having this flag means user mode pends on event which will never
>>> +* reach due to lack of at least one CRTC for signaling
>>> +*/
>>> +   if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>>> +   return -EINVAL;
>>> +
>>> return 0;
>>>  }
>>>  
>>>
Just do it, and I'll commit this to igt?

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 6375fede7179..77429b3db384 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -1205,6 +1205,15 @@ static void crtc_invalid_params(struct 
kms_atomic_crtc_state *crtc_old,
crtc_commit_atomic(, plane, req, ATOMIC_RELAX_NONE,
   DRM_MODE_ATOMIC_TEST_ONLY);
 
+   /*
+* TEST_ONLY cannot be combined with DRM_MODE_PAGE_FLIP_EVENT,
+* but DRM_MODE_PAGE_FLIP_EVENT will always generate EINVAL
+* without valid crtc, so test it here.
+*/
+   crtc_commit_atomic_err(, plane, req, ATOMIC_RELAX_NONE,
+  DRM_MODE_ATOMIC_TEST_ONLY | 
DRM_MODE_PAGE_FLIP_EVENT,
+  EINVAL);
+
/* Create a blob which is the wrong size to be a valid mode. */
do_or_die(drmModeCreatePropertyBlob(crtc.state->desc->fd,
crtc.mode.data,
@@ -1356,12 +1365,12 @@ static void atomic_invalid_params(struct 
kms_atomic_crtc_state *crtc,
/* Valid pointers, but still should copy nothing. */
do_ioctl(desc->fd, DRM_IOCTL_MODE_ATOMIC, );
 
-   /* Nonsense flags. */
-   ioc.flags = 0xdeadbeef;
+   /* Valid noop, but with event set should fail. */
+   ioc.flags = DRM_MODE_PAGE_FLIP_EVENT;
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
 
-   /* Specifically forbidden combination. */
-   ioc.flags = DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_PAGE_FLIP_EVENT;
+   /* Nonsense flags. */
+   ioc.flags = 0xdeadbeef;
do_ioctl_err(desc->fd, DRM_IOCTL_MODE_ATOMIC, , EINVAL);
 
ioc.flags = 0;

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


[PATCH 4.11 52/58] drm: Fix GETCONNECTOR regression

2017-06-27 Thread Greg Kroah-Hartman
4.11-stable review patch.  If anyone has any objections, please let me know.

--

From: Daniel Vetter 

commit e94ac3510b6a0f696f2c442c4fc4051c8101ef12 upstream.

In

commit 91eefc05f0ac71902906b2058360e61bd25137fe
Author: Daniel Vetter 
Date:   Wed Dec 14 00:08:10 2016 +0100

drm: Tighten locking in drm_mode_getconnector

I reordered the logic a bit in that IOCTL, but that broke userspace
since it'll get the new mode list, but not the new property values.
Fix that again.

v2: Fix up the error path handling when copy_to_user for the modes
failes (Dhinakaran).

Fixes: 91eefc05f0ac ("drm: Tighten locking in drm_mode_getconnector")
Cc: Sean Paul 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Reported-by: "H.J. Lu" 
Tested-by: "H.J. Lu" 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100576
Cc: "H.J. Lu" 
Cc: "Pandiyan, Dhinakaran" 
Reviewed-by: Sean Paul 
Reviewed-by: Dhinakaran Pandiyan 
Signed-off-by: Daniel Vetter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170620202837.1701-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/drm_connector.c |   38 --
 1 file changed, 20 insertions(+), 18 deletions(-)

--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1169,21 +1169,6 @@ int drm_mode_getconnector(struct drm_dev
if (!connector)
return -ENOENT;
 
-   drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   encoder = drm_connector_get_encoder(connector);
-   if (encoder)
-   out_resp->encoder_id = encoder->base.id;
-   else
-   out_resp->encoder_id = 0;
-
-   ret = drm_mode_object_get_properties(>base, 
file_priv->atomic,
-   (uint32_t __user *)(unsigned long)(out_resp->props_ptr),
-   (uint64_t __user *)(unsigned 
long)(out_resp->prop_values_ptr),
-   _resp->count_props);
-   drm_modeset_unlock(>mode_config.connection_mutex);
-   if (ret)
-   goto out_unref;
-
for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
if (connector->encoder_ids[i] != 0)
encoders_count++;
@@ -1196,7 +1181,7 @@ int drm_mode_getconnector(struct drm_dev
if (put_user(connector->encoder_ids[i],
 encoder_ptr + copied)) {
ret = -EFAULT;
-   goto out_unref;
+   goto out;
}
copied++;
}
@@ -1240,15 +1225,32 @@ int drm_mode_getconnector(struct drm_dev
if (copy_to_user(mode_ptr + copied,
 _mode, sizeof(u_mode))) {
ret = -EFAULT;
+   mutex_unlock(>mode_config.mutex);
+
goto out;
}
copied++;
}
}
out_resp->count_modes = mode_count;
-out:
mutex_unlock(>mode_config.mutex);
-out_unref:
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   encoder = drm_connector_get_encoder(connector);
+   if (encoder)
+   out_resp->encoder_id = encoder->base.id;
+   else
+   out_resp->encoder_id = 0;
+
+   /* Only grab properties after probing, to make sure EDID and other
+* properties reflect the latest status. */
+   ret = drm_mode_object_get_properties(>base, 
file_priv->atomic,
+   (uint32_t __user *)(unsigned long)(out_resp->props_ptr),
+   (uint64_t __user *)(unsigned 
long)(out_resp->prop_values_ptr),
+   _resp->count_props);
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+out:
drm_connector_unreference(connector);
 
return ret;


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


[Bug 92715] [IGT] [BYT-M/KBL/BSW/BXT/BDW] gem_reset_stats sub tests fail

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92715

Elizabeth  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #26 from Elizabeth  ---
(In reply to Michel Thierry from comment #24)
> Hi,
> 
> Can you try with this igt patch?
> https://patchwork.freedesktop.org/patch/161335/

Changing to REOPEN, since the patch had been tested and the bug is still
present on some platforms.

-- 
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 92715] [IGT] [BYT-M/KBL/BSW/BXT/BDW] gem_reset_stats sub tests fail

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92715

Elizabeth  changed:

   What|Removed |Added

 Status|NEEDINFO|REOPENED

-- 
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/i915: Fix an error checking test

2017-06-27 Thread Chris Wilson
Quoting Christophe JAILLET (2017-06-27 06:38:54)
> 'dma_buf_vmap' returns NULL on error, not an error pointer.
> 
> Fixes: 6cca22ede8a4 ("drm/i915: Add some mock tests for dmabuf interop")
> Signed-off-by: Christophe JAILLET 

Thanks for the fix, reviewed and pushed.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/i915: Print pwm device-name when using pwm for backlight control

2017-06-27 Thread Hans de Goede

Hi,

On 06/27/2017 11:52 AM, Ville Syrjälä wrote:

On Fri, Jun 23, 2017 at 09:42:44AM +0200, Hans de Goede wrote:

On Bay Trail devices either the Crystal Cove PMIC's pwm or the LPSS'
pwm is used to control the backlight. Other drivers take core of
providing a backlight_pwm alias through pwm_add_table, but it is
still useful to know which pwm device actually ends up being used
for debugging backlight issues, so add a DRM_INFO logging the
pwm device-name.

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/intel_panel.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index cb50c527401f..7936a64af393 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1670,6 +1670,9 @@ static int pwm_setup_backlight(struct intel_connector 
*connector,
 CRC_PMIC_PWM_PERIOD_NS);
panel->backlight.enabled = panel->backlight.level != 0;
  
+	DRM_INFO("Using %s pwm-device for backlight control\n",

+dev_name(panel->backlight.pwm->chip->dev));


Is DRM_DEBUG_KMS() not enough?


I prefer DRM_INFO so that I can just ask users with backlight issues
to do a dmesg and then see which pwm controller is being used.

Regards,

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


Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD

2017-06-27 Thread David Weinehall
On Mon, Jun 26, 2017 at 05:18:19PM +0300, David Weinehall wrote:
> On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> > This patch adds option to enable dynamic backlight for eDP
> > panel that supports this feature via DPCD register and
> > set minimum / maximum brightness to 0% and 100% of the
> > normal brightness.
> 
> This patch causes a regression on my ThinkPad X1 Carbon Gen 4;
> with enable_dbc = true the backlight stays off; setting i915.enable_dbc=0
> on boot makes things work properly again.

Some more testing indicates that while i915.enable_dbc=0 solves the
initial issue of backlight not coming on, it's not enough--after
suspend/resume the backlight stays off.

Passing i915.enable_dpcd_backlight=0 seems to work both for the initial
case of backlight not coming on at boot, and the issue with backlight
not coming on after suspend/resume.

So:

DBC:1, DPCD: -1: blank screen on boot
DBC:0, DPCD: -1: screen OK on boot, blank after suspend/resume
DBC:1, DPCD:  0: screen OK on boot, screen OK after suspend/resume
DBC:0, DPCD:  0: screen OK on boot, screen OK after suspend/resume

So it seems that at least for the ThinkPad X1 Carbon Gen 4 (possibly
limited to the 2560x1440 model) DPCD backlight isn't supported.

Or possibly something is wrong with the DPCD backlight patch.

> > Signed-off-by: Puthikorn Voravootivat 
> > Reviewed-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_params.c|  5 +
> >  drivers/gpu/drm/i915/i915_params.h|  3 ++-
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26 
> > ++
> >  3 files changed, 33 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_params.c 
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 5b5ab15d191f..88b9d3e6713a 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
> > .inject_load_failure = 0,
> > .enable_dpcd_backlight = -1,
> > .enable_gvt = false,
> > +   .enable_dbc = true,
> >  };
> >  
> >  module_param_named(modeset, i915.modeset, int, 0400);
> > @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> >  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> >  MODULE_PARM_DESC(enable_gvt,
> > "Enable support for Intel GVT-g graphics virtualization host 
> > support(default:false)");
> > +
> > +module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> > +MODULE_PARM_DESC(enable_dbc,
> > +   "Enable support for dynamic backlight control (default:true)");
> > diff --git a/drivers/gpu/drm/i915/i915_params.h 
> > b/drivers/gpu/drm/i915/i915_params.h
> > index 0d6cf9138dc4..057e203e6bda 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -67,7 +67,8 @@
> > func(bool, verbose_state_checks); \
> > func(bool, nuclear_pageflip); \
> > func(bool, enable_dp_mst); \
> > -   func(bool, enable_gvt)
> > +   func(bool, enable_gvt); \
> > +   func(bool, enable_dbc)
> >  
> >  #define MEMBER(T, member) T member
> >  struct i915_params {
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index fea161727c6e..b25cd88fc1c5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -173,6 +173,24 @@ static bool intel_dp_aux_set_pwm_freq(struct 
> > intel_connector *connector)
> > return true;
> >  }
> >  
> > +/*
> > +* Set minimum / maximum dynamic brightness percentage. This value is 
> > expressed
> > +* as the percentage of normal brightness in 5% increments.
> > +*/
> > +static bool
> > +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> > +  u32 min, u32 max)
> > +{
> > +   u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> > +
> > +   if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> > + dbc, sizeof(dbc)) < 0) {
> > +   DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> > +   return false;
> > +   }
> > +   return true;
> > +}
> > +
> >  static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
> > *crtc_state,
> >   const struct drm_connector_state 
> > *conn_state)
> >  {
> > @@ -208,6 +226,14 @@ static void intel_dp_aux_enable_backlight(const struct 
> > intel_crtc_state *crtc_st
> > if (intel_dp_aux_set_pwm_freq(connector))
> > new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
> >  
> > +   if (i915.enable_dbc &&
> > +   (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
> > +   if(intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 
> > 100)) {
> > +   new_dpcd_buf |= 

xilinx_drm and atomic modesetting

2017-06-27 Thread Jean-Francois Dagenais
Hi guys,

Note: I was a total DRM newbie at the beginning of this exercise. Now I would 
say I'm just newbie. ;)

I am trying to implement our lvds panel using xilinx_drm on zynqmp. We are 
composing our pipeline starting with the xilinx-vdma, then a few logic parts 
from the ALI3 on zedboard ref design. The only configurable bits in this 
pipeline are the vdma registers at one end, then an enable GPIO and PWM going 
to the panel itself. The rest (resolution, etc.) are hard-coded at synthesis 
time.

This makes things simpler, in theory.

I opted to use the lvds-encoder.c (found upstream) which is actually a 
drm_bridge (!??), and the panel-lvds.c(also upstream) driver which take 
resolution and timings from dts and create a drm_panel. All I was missing is an 
encoder (xilinx_drm_encoder would not do). I created a somewhat dummy encoder 
which binds the crtc to the bridge just by being present. It is discovered by 
xilinx_drm_drv by the component subsys using the endpoints in dts.

From what I now understand, there are two "worlds" in the DRM/KMS framework, 
legacy and atomic. From what I gather, xilinx_drm stands on the legacy side. 
Whereas the drm_bridge and drm_panel are more on the atomic side.

I believe this is what's causing a few OOPS and exceptions here and there that 
I had to "patch" by adding "if" statements for null objects. For example, one 
is struct drm_connector_state missing on the crtc. This is used by atomic 
helpers invoked by the drm_bridge (if I remember correctly).

In 
https://github.com/Xilinx/linux-xlnx/commit/d5733539adba1c509cb82bd3d4d418a3dbfbfd68
 there is suggestion that xilinx_drm be converted to atomic modesetting.

Is this work started? I would like to contribute by testing and submitting 
patches. Maybe a topic branch on github in linux-xlnx would help us out, and 
help you out as well to get the driver more polished sooner.

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


Re: [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset

2017-06-27 Thread Ander Conselvan De Oliveira
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
> 
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for ycbcr420 output.
> - Adds a new scaler user "HDMI output" to plug-into existing
>   scaler framework. This output type is identified using bit
>   30 of the scaler users bitmap.
> 
> V2: rebase
> V3: rebase
> V4: rebase
> 
> Cc: Ville Syrjala 
> Cc: Ander Conselvan De Oliveira 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c  |  6 ++
>  drivers/gpu/drm/i915/intel_display.c | 26 ++
>  drivers/gpu/drm/i915/intel_drv.h | 10 +-
>  drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
>  drivers/gpu/drm/i915/intel_panel.c   |  3 ++-
>  5 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 36d4e63..a8c9ac5 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private 
> *dev_priv,
>  
>   /* panel fitter case: assign as a crtc scaler */
>   scaler_id = _state->scaler_id;
> + } else if (i == SKL_HDMI_OUTPUT_INDEX) {
> + name = "HDMI-OUTPUT";
> + idx = intel_crtc->base.base.id;
> +
> + /* hdmi output case: needs a pipe scaler */
> + scaler_id = _state->scaler_id;
>   } else {
>   name = "PLANE";
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index da29536..983f581 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
> bool force_detach,
>*/
>   need_scaling = src_w != dst_w || src_h != dst_h;
>  
> + if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
> + && scaler_user == SKL_HDMI_OUTPUT_INDEX)

Is it really necessary to check for both? If it is, what's the point of creating
SKL_HDMI_OUTPUT_INDEX?


> + /* YCBCR 444 -> 420 conversion needs a scaler */
> + need_scaling = true;
> +
>   /*
>* if plane is being disabled or scaler is no more required or force 
> detach
>*  - free scaler binded to this plane/crtc
> @@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
> bool force_detach,
>  }
>  
>  /**
> + * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
> + * HDMI YCBCR 420 output needs a scaler, for downsampling.
> + *
> + * @state: crtc's scaler state
> + *
> + * Return
> + * 0 - scaler_usage updated successfully
> + *error - requested scaling cannot be supported or other error condition
> + */
> +int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
> +{
> + const struct drm_display_mode *mode = >base.adjusted_mode;
> +
> + return skl_update_scaler(state, !state->base.active,
> + SKL_HDMI_OUTPUT_INDEX, >scaler_state.scaler_id,
> + state->pipe_src_w, state->pipe_src_h,
> + mode->crtc_hdisplay, mode->crtc_vdisplay);
> +}
> +
> +/**
>   * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
>   *
>   * @state: crtc's scaler state
> @@ -8058,6 +8083,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
>  {
>   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
>  
>   if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
>   u32 val = 0;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 38fe56c..2206aa8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
>*
>* If a bit is set, a user is using a scaler.
>* Here user can be a plane or crtc as defined below:
> -  *   bits 0-30 - plane (bit position is index from drm_plane_index)
> +  *   bits 0-29 - plane (bit position is index from drm_plane_index)
> +  *   bit 30- hdmi output
>*   bit 31- crtc
>*
>* Instead of creating a new index to cover planes and crtc, using
> @@ -484,6 +485,12 @@ struct intel_crtc_scaler_state {
>* avilability.
>*/
>  #define SKL_CRTC_INDEX 31
> +
> + /*
> +  * HDMI YCBCR 420 output consume a scaler. So adding a user
> +   

Re: [PATCH v5 7/7] drm: create hdmi output property

2017-06-27 Thread Ville Syrjälä
On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote:
> HDMI displays can support various output types, based on
> the color space and subsampling type. The possible
> outputs from a HDMI 2.0 monitor could be:
>  - RGB
>  - YCBCR 444
>  - YCBCR 422
>  - YCBCR 420
> 
> This patch adds a drm property "hdmi_output_format", using which,
> a user can specify its preference, for the HDMI output type. The
> output type enums are similar to the mentioned outputs above. To
> handle various subsampling of YCBCR output types, this property
> allows two special cases:
>  - DRM_HDMI_OUTPUT_YCBCR_HQ
>This indicates preferred output should be YCBCR output, with highest
>subsampling rate by the source/sink, which can be typically:
>   - ycbcr444
>   - ycbcr422
>   - ycbcr420
>  - DRM_HDMI_OUTPUT_YCBCR_LQ
>This indicates preferred output should be YCBCR output, with lowest
>subsampling rate supported by source/sink, which can be:
>   - ycbcr420
>   - ycbcr422
>   - ycbcr444

I think we'll eventually need something more thorough than this to
allow full control over the AVI infoframe/MSA MISC/VSC SDP colormietry
stuff.

So I think we need to control at least these things:
- max bpc (some people seem to have some real needs to avoid deep color)
- rgb->ycbcr conversion (yes/no)
- ycbcr subsampling for the conversion and infoframe
- ycbcr encoding for the conversion and infoframe
- infoframe colorimetry

I've not really figured out how we'll tie all that together in a way
that doesn't get super confusing.

One idea might be that the infoframe stuff is totally independent of
the rest (ie. we'll define just an enum property for the infoframe
stuff in say this way:
"Automatic", "sRGB", "AdobeRGB", "YCbCr BT.601 4:2:2",
"xvYCC709 4:4:4", etc.

So none of the YCbCr output properties would actually affect the
infoframe unless the user has selected the default "Automatic" mode.
That should allow the user to output any kind of data through the pipe
in a pass through fashion (or with manually set up gamma/degamma/csc).
And configuring the inforame property would not affect the data passing
through the pipe in any way.

But I probably need to think more about this. So for now I think I'll
just want to get the automagic "use YCbCr 4:2:0 if we must" thing
working without any new properties getting in the way. We just have
to keep in mind that this automagic conversion thing must still work
when we add some properties, but I think that can generally be achieved
with some "Automatic" default property values.

> 
> Default value of the property is set to 0 = RGB, so no changes if you
> dont set the property.
> 
> PS: While doing modeset for YCBCR 420 only modes, this property is
> ignored, as those timings can be supported only in YCBCR 420
> output mode.
> 
> V2: Added description for the new variable to address build warning
> V3: Rebase
> V4: Rebase
> V5: Added get_property counterpart to fix IGT BAT failures
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Daniel Vetter 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_atomic.c|  4 
>  drivers/gpu/drm/drm_atomic_helper.c |  4 
>  drivers/gpu/drm/drm_connector.c | 32 
>  include/drm/drm_connector.h | 18 ++
>  include/drm/drm_mode_config.h   |  5 +
>  5 files changed, 63 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 77dcef0..ea90f8e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->picture_aspect_ratio = val;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
> + } else if (property == config->hdmi_output_property) {
> + state->hdmi_output = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1272,6 +1274,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->picture_aspect_ratio;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
> + } else if (property == config->hdmi_output_property) {
> + *val = state->hdmi_output;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 86d3093..1356b3f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ 

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Simplify commit tracking locking

2017-06-27 Thread Daniel Vetter
On Wed, Jun 21, 2017 at 10:30:51AM -0400, Sean Paul wrote:
> On Wed, Jun 21, 2017 at 11:16:27AM +0200, Daniel Vetter wrote:
> > The crtc->commit_lock only protects commit_list and commit_entry. If
> > we chase the pointer from the drm_atomic_state update structure, then
> > we don't need any locks (since we hold a reference already).
> > 
> > Simplify the locking accordingly.
> > 
> > Noticed while reviewing a patch from Boris.
> > 
> > Cc: Boris Brezillon 
> > Signed-off-by: Daniel Vetter 
> 
> After reading this over a few times, I've convinced myself that it does
> the right thing.
> 
> Reviewed-by: Sean Paul 

Pushed to -misc, thanks for your review.
-Daniel

> 
> 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 7 +--
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 86d3093c6c9b..9bf86eb87fe1 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1680,9 +1680,7 @@ void drm_atomic_helper_commit_hw_done(struct 
> > drm_atomic_state *old_state)
> >  
> > /* backend must have consumed any event by now */
> > WARN_ON(new_crtc_state->event);
> > -   spin_lock(>commit_lock);
> > complete_all(>hw_done);
> > -   spin_unlock(>commit_lock);
> > }
> >  }
> >  EXPORT_SYMBOL(drm_atomic_helper_commit_hw_done);
> > @@ -1711,7 +1709,6 @@ void drm_atomic_helper_commit_cleanup_done(struct 
> > drm_atomic_state *old_state)
> > if (WARN_ON(!commit))
> > continue;
> >  
> > -   spin_lock(>commit_lock);
> > complete_all(>cleanup_done);
> > WARN_ON(!try_wait_for_completion(>hw_done));
> >  
> > @@ -1721,8 +1718,6 @@ void drm_atomic_helper_commit_cleanup_done(struct 
> > drm_atomic_state *old_state)
> > if (try_wait_for_completion(>flip_done))
> > goto del_commit;
> >  
> > -   spin_unlock(>commit_lock);
> > -
> > /* We must wait for the vblank event to signal our completion
> >  * before releasing our reference, since the vblank work does
> >  * not hold a reference of its own. */
> > @@ -1732,8 +1727,8 @@ void drm_atomic_helper_commit_cleanup_done(struct 
> > drm_atomic_state *old_state)
> > DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
> >   crtc->base.id, crtc->name);
> >  
> > -   spin_lock(>commit_lock);
> >  del_commit:
> > +   spin_lock(>commit_lock);
> > list_del(>commit_entry);
> > spin_unlock(>commit_lock);
> > }
> > -- 
> > 2.11.0
> > 
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

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


Re: [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks

2017-06-27 Thread Ville Syrjälä
On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote:
> CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
> This block contains a map of indexes of CEA modes, which can
> support YCBCR 420 output also. To avoid multiple parsing of same
> CEA block, let's parse the sink information and get this map, before
> parsing CEA modes.
> 
> This patch moves the call to drm_add_display_info function, before the
> mode parsing block.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index b4583f6..42934b2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4605,6 +4605,13 @@ int drm_add_edid_modes(struct drm_connector 
> *connector, struct edid *edid)
>   quirks = edid_get_quirks(edid);
>  
>   /*
> +  * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
> +  * To avoid multiple parsing of same block, lets parse that map
> +  * from sink info, before parsing CEA modes.
> +  */
> + drm_add_display_info(connector, edid);
> +

This patch should come before the 4:2:0 mode parsing, no?

Otherwise I think this should be fine so
Reviewed-by: Ville Syrjälä 

> + /*
>* EDID spec says modes should be preferred in this order:
>* - preferred detailed mode
>* - other detailed modes from base block
> @@ -4632,8 +4639,6 @@ int drm_add_edid_modes(struct drm_connector *connector, 
> struct edid *edid)
>   if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
>   edid_fixup_preferred(connector, quirks);
>  
> - drm_add_display_info(connector, edid);
> -
>   if (quirks & EDID_QUIRK_FORCE_6BPC)
>   connector->display_info.bpc = 6;
>  
> -- 
> 2.7.4

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


Re: [RESEND-CI v4 05/15] drm/edid: parse ycbcr 420 deep color information

2017-06-27 Thread Ville Syrjälä
On Wed, Jun 21, 2017 at 04:04:03PM +0530, Shashank Sharma wrote:
> CEA-861-F spec adds ycbcr420 deep color support information
> in hf-vsdb block. This patch extends the existing hf-vsdb parsing
> function by adding parsing of ycbcr420 deep color support from the
> EDID and adding it into display information stored.
> 
> V2: Rebase
> V3: Rebase
> V4: Moved definition of y420_dc_modes into this patch, where its used
> (Ville)
> 
> Cc: Ville Syrjälä 
> Cc: Jose Abreu 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 15 +++
>  include/drm/drm_connector.h |  3 +++
>  include/drm/drm_edid.h  |  5 +
>  3 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 8c7e73b..b4583f6 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4196,6 +4196,19 @@ drm_default_rgb_quant_range(const struct 
> drm_display_mode *mode)
>  }
>  EXPORT_SYMBOL(drm_default_rgb_quant_range);
>  
> +static void drm_parse_ycbcr420_deep_color_info(struct drm_connector 
> *connector,
> +  const u8 *db)
> +{
> + struct drm_hdmi_info *info = >display_info.hdmi;
> +
> + if (db[7] & DRM_EDID_YCBCR420_DC_48)
> + info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
> + if (db[7] & DRM_EDID_YCBCR420_DC_36)
> + info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
> + if (db[7] & DRM_EDID_YCBCR420_DC_30)
> + info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_30;

y420_dc_modes = db[7] & (...);

will do if you plan to just copy the bits over.

> +}
> +
>  static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>const u8 *hf_vsdb)
>  {
> @@ -4236,6 +4249,8 @@ static void drm_parse_hdmi_forum_vsdb(struct 
> drm_connector *connector,
>   scdc->scrambling.low_rates = true;
>   }
>   }
> +
> + drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
>  }
>  
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ce2212d..1305fe9 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -156,6 +156,9 @@ struct drm_hdmi_info {
>  
>   /** @y420_cmdb_map: bitmap of SVD index, to extraxt vcb modes */
>   unsigned long y420_cmdb_map;
> +
> + /** @y420_dc_modes: bitmap of deep color support index */
> + u8 y420_dc_modes;
>  };
>  
>  /**
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 89c0062..d4ff17c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -213,6 +213,11 @@ struct detailed_timing {
>  #define DRM_EDID_HDMI_DC_30   (1 << 4)
>  #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
>  
> +/* YCBCR 420 deep color modes */
> +#define DRM_EDID_YCBCR420_DC_48(1 << 6)
> +#define DRM_EDID_YCBCR420_DC_36(1 << 5)
> +#define DRM_EDID_YCBCR420_DC_30(1 << 4)
> +
>  /* ELD Header Block */
>  #define DRM_ELD_HEADER_BLOCK_SIZE4
>  
> -- 
> 2.7.4

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


Re: [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID

2017-06-27 Thread Ville Syrjälä
On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
> CEA-861-F adds two new blocks in EDID's CEA extension blocks,
> to provide information about sink's YCBCR420 output capabilities.
> 
> These blocks are:
> 
> - YCBCR420vdb(YCBCR 420 video data block):
> This block contains VICs of video modes, which can be sopported only
> in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
> SVD block, valid for YCBCR420 modes only.
> 
> - YCBCR420cmdb(YCBCR 420 capability map data block):
> This block gives information about video modes which can support
> YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
> block contains a bitmap index of normal svd videomodes, which can
> support YCBCR420 output too.
> So if bit 0 from first vcb byte is set, first video mode in the svd
> list can support YCBCR420 output too. Bit 1 means second video mode
> from svd list can support YCBCR420 output too, and so on.
> 
> This patch adds two bitmaps in display's hdmi_info structure, one each
> for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
> adds:
> - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
>   an entry in the vdb_bitmap per vic.
> - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Emil Velikov 
> 
> V2: Addressed
> Review comments from Emil:
> - Use 1ULL< - Use the suggested method for updating dbmap.
> - Add documentation for YCBCR420_vcb_map to fix kbuild warning.
> 
> Review comments from Ville:
> - Do not expose the YCBCR420 flags in uabi layer, keep it internal.
> - Save a map of YCBCR420 modes for future reference.
> - Check db length before trying to parse extended tag.
> - Add a warning if there are > 64 modes in capability map block.
> - Use y420cmdb in function names and macros while dealing with vcb
>   to be aligned with spec.
> - Move the display information parsing block ahead of mode parsing
>   blocks.
> 
> V3: Addressed design/review comments from Ville
> - Do not add flags in video modes, else we have to expose them to user
> - There should not be a UABI change, and kernel should detect the
>   choice of the output based on type of mode, and the bitmaps.
> - Use standard bitops from kernel bitmap header, instead of calculating
>   bit positions manually.
> 
> V4: Addressed review comments from Ville:
> - s/ycbcr_420_vdb/y420vdb
> - s/ycbcr_420_vcb/y420cmdb
> - Be less verbose on description of do_y420vdb_modes
> - Move newmode variable in the loop scope.
> - Use svd_to_vic() to get a VIC, instead of 0x7f
> - Remove bitmap description for CMDB modes & VDB modes
> - Dont add connector->ycbcr_420_allowed check for cmdb modes
> - Remove 'len' variable, in is_y420cmdb function, which is used
>   only once
> - Add length check in is_y420vdb function
> - Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
> - Do not add print about YCBCR 420 modes
> - Fix indentation in few places
> - Move ycbcr420_dc_modes in next patch, where its used
> - Add a separate patch for movement of drm_add_display_info()
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c  | 157 
> +++-
>  include/drm/drm_connector.h |  20 ++
>  2 files changed, 174 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e2d1b30..8c7e73b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>  #define VIDEO_BLOCK 0x02
>  #define VENDOR_BLOCK0x03
>  #define SPEAKER_BLOCK0x04
> -#define VIDEO_CAPABILITY_BLOCK   0x07
> +#define VIDEO_CAPABILITY_BLOCK 0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
>  #define EDID_BASIC_AUDIO (1 << 6)
>  #define EDID_CEA_YCRCB444(1 << 5)
>  #define EDID_CEA_YCRCB422(1 << 4)
> @@ -3153,15 +3155,79 @@ drm_display_mode_from_vic_index(struct drm_connector 
> *connector,
>   return newmode;
>  }
>  
> +/*
> + * do_y420vdb_modes - Parse YCBCR 420 only modes
> + * @connector: connector corresponding to the HDMI sink
> + * @svds: start of the data block of CEA YCBCR 420 VDB
> + * @len: length of the CEA YCBCR 420 VDB
> + *
> + * Parse the CEA-861-F YCBCR 420 Video Data Block (Y420VDB)
> + * which contains modes which can be supported in YCBCR 420
> + * output format only.
> + */
> +static int do_y420vdb_modes(struct drm_connector *connector,
> +const u8 *svds, u8 svds_len)
> +{
> + int modes = 0, i;
> + struct drm_device *dev = 

Re: [RESEND-CI v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)

2017-06-27 Thread Ville Syrjälä
On Wed, Jun 21, 2017 at 04:04:01PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new video modes to be used with
> HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
> 1-107.
> 
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse new CEA modes using the existing methods, we have
> to complete the modedb (VIC=65 onwards).
> 
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
> 
> The patch was originaly discussed and reviewed here:
> https://patchwork.freedesktop.org/patch/135810/
> 
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> 
> V2: Rebase
> V3: Rebase
> V4: Added native bit handling as per CEA-861-F spec (Ville)
> 
> Reviewed-by: Jose Abreu 
> Reviewed-by: Alex Deucher 
> Acked-by: Harry Wentland 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/drm_edid.c | 227 
> -
>  1 file changed, 226 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d312fe1..e2d1b30 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] 
> = {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
...
> + /* 77 - 1920x1080@100Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +  .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
...
> + /* 104 - 3840x2160p@25Hz 64:27 */
> + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
> + 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
> + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},

https://lists.freedesktop.org/archives/dri-devel/2016-November/122669.html

> @@ -2902,6 +3117,16 @@ add_alternate_cea_modes(struct drm_connector 
> *connector, struct edid *edid)
>   return modes;
>  }
>  
> +static u8 svd_to_vic(u8 svd)
> +{
> +
> + /* 0-6 bit vic, 7th bit native mode indicator */
> + if (((svd >= 1) && (svd <= 64)) || ((svd >= 129) && (svd <= 192)))

Too many parentheses. lgtm otherwise.

> + return svd & 127;
> +
> + return svd;
> +}
> +
>  static struct drm_display_mode *
>  drm_display_mode_from_vic_index(struct drm_connector *connector,
>   const u8 *video_db, u8 video_len,
> @@ -2915,7 +3140,7 @@ drm_display_mode_from_vic_index(struct drm_connector 
> *connector,
>   return NULL;
>  
>   /* CEA modes are numbered 1..127 */
> - vic = (video_db[video_index] & 127);
> + vic = svd_to_vic(video_db[video_index]);
>   if (!drm_valid_cea_vic(vic))
>   return NULL;
>  
> -- 
> 2.7.4

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


[Bug 101499] Black screen when detaching HDMI cable (AMD A10-9620P)

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101499

Carlo Caione  changed:

   What|Removed |Added

 Attachment #132130|0   |1
is obsolete||

--- Comment #20 from Carlo Caione  ---
Created attachment 132281
  --> https://bugs.freedesktop.org/attachment.cgi?id=132281=edit
dm_plane_helper_prepare_fb with AMDGPU_GEM_DOMAIN_GTT

> Do you also get those errors with AMDGPU_GEM_DOMAIN_GTT? If so, it might be 
> interesting to track down the origin of the errors. Otherwise, it looks like
> there's still something missing.

The error is not reproducible anymore using the latest amd-staging-4.11 branch
and the master HEAD of xf86-video-amdgpu using AMDGPU_GEM_DOMAIN_GTT in
dm_plane_helper_prepare_fb, but I still have the weird corruption with a white
background screen and a corrupted square as pointer as in the previous
attachment. In the attachment the journal when attaching and detaching the HDMI
cable.

The only concerning errors I can see in there are:

[drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from
Adapter Service for connector index:2!
[drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!   
[drm:dc_create [amdgpu]] *ERROR* DC: Number of connectors is zero!

-- 
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] mediatek drm next for 4.13

2017-06-27 Thread CK Hu
Hi, Dave:

This include new color format support and some fixups.
Please kindly let me know if there is any problem.

Regards,
CK

The following changes since commit
6d61e70ccc21606ffb8a0a03bd3aba24f659502b:

  Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000)

are available in the git repository at:


  https://github.com/ckhu-mediatek/linux.git-tags.git
mediatek-drm-next-4.13

for you to fetch changes up to 5ac5895a84d92bd2b3db490f8ee242ccb4d77e96:

  drm/mediatek: separate color module to fixup error memory reallocation
(2017-06-27 17:34:53 +0800)


Bibby Hsieh (1):
  drm/mediatek: Support UYVY and YUYV format for overlay

Christophe Jaillet (1):
  drm/mediatek: check for memory allocation failure

Colin Ian King (1):
  drm/mediatek: re-phrase DRM_INFO error message

Philipp Zabel (1):
  drm/mediatek: use platform_register_drivers

yt.s...@mediatek.com (1):
  drm/mediatek: separate color module to fixup error memory
reallocation

 drivers/gpu/drm/mediatek/Makefile   |   3 +-
 drivers/gpu/drm/mediatek/mtk_disp_color.c   | 176

 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |   7 ++
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  80 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  33 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|   2 +
 drivers/gpu/drm/mediatek/mtk_dsi.c  |   2 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c |  27 +
 10 files changed, 205 insertions(+), 128 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_color.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

2017-06-27 Thread Andrzej Hajda
On 27.06.2017 11:13, Inki Dae wrote:
> Hi Andrzej,
>
> 2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글:
>> Hi Shuah,
>>
>>
>> On 24.06.2017 02:56, Shuah Khan wrote:
>>> Fix to call of_node_put() right after of_drm_find_bridge() instead of
>>> holding on to it until exynos_dsi_remove().
>> I think the current implementation is OK, node is get in probe and put
>> in remove.
>> There could be many bind/unbind during lifetime of the bound driver.
>> For example, there is possible sequence:
>> 1. probe -
>> 2. bind
>> 3. unbind
>> 4. bind
>>
>> With this patch on 2nd bind (point 4) driver will call
>> of_drm_find_bridge on dsi->bridge_node which was put earlier (point 2.).
>>
> Right. This is a problem.
>
> How about moving of_drm_find_bridge function call to probe and keeping 
> drm_bridge_attach call in bind for cleanup?
> Seems it doesn't need to call of_drm_find_bridge function every time bind 
> callback is called.

I think the reason to call of_drm_find_bridge in bind is to avoid probe
deferring, and with current code it will probably defer forever,
explanation below:

The only bridge connected to DSI is bridge provided by MIC driver, and
MIC driver is componentized, but it registers his bridge in bind callback.
So with drm_bridge_attach moved to probe of DSI initialization would
never succeed because:
1. MIC->bind will be called only if all DRM components are present.
2. DSI driver will defer probing because the bridge is not present, thus
DSI component will never be present.

So the current code looks better to me, but there are two thing which
could be improved:
A. Maybe it would be good thing to move MIC bridge registration to
probe, I see no reason to postpone it to bind phase, this way it should
be safer if for some reason DSI->bind callback would be called before
MIC->bind.
B. Add error checking to of_drm_find_bridge in DSI driver, I know MIC is
generally optional, but if the graph link is present (ie. 
dsi->bridge_node is valid) MIC bridge should be present, if it is not,
it indicates some problem.

Regards
Andrzej

>
> Thanks,
> Inki Dae
>
>> Regards
>> Andrzej
>>
>>
>>> Suggested-by: Inki Dae 
>>> Signed-off-by: Shuah Khan 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +
>>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> index e337cd2..7513b88 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>>> @@ -1689,6 +1689,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
>>> device *master,
>>>  
>>> if (dsi->bridge_node) {
>>> bridge = of_drm_find_bridge(dsi->bridge_node);
>>> +   of_node_put(dsi->bridge_node);
>>> if (bridge)
>>> drm_bridge_attach(encoder, bridge, NULL);
>>> }
>>> @@ -1807,10 +1808,6 @@ static int exynos_dsi_probe(struct platform_device 
>>> *pdev)
>>>  
>>>  static int exynos_dsi_remove(struct platform_device *pdev)
>>>  {
>>> -   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>>> -
>>> -   of_node_put(dsi->bridge_node);
>>> -
>>> pm_runtime_disable(>dev);
>>>  
>>> component_del(>dev, _dsi_component_ops);
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>

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


Re: [Nouveau] [PATCH] drm/nouveau/therm: fix spelling mistake on array thresolds

2017-06-27 Thread Martin Peres

On 27/06/17 11:08, Colin King wrote:

From: Colin Ian King 

Array thresolds should be named thresholds, rename it. Also make it static
static const char * const

Signed-off-by: Colin Ian King 


Thanks for doing this,

Reviewed-by: Martin Peres 


---
  drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
index e93b2410c38b..6449771b9dc6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
@@ -83,7 +83,7 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum 
nvkm_therm_thrs thrs,
  {
struct nvkm_subdev *subdev = >subdev;
bool active;
-   const char *thresolds[] = {
+   static const char * const thresholds[] = {
"fanboost", "downclock", "critical", "shutdown"
};
int temperature = therm->func->temp_get(therm);
@@ -94,10 +94,10 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum 
nvkm_therm_thrs thrs,
if (dir == NVKM_THERM_THRS_FALLING)
nvkm_info(subdev,
  "temperature (%i C) went below the '%s' threshold\n",
- temperature, thresolds[thrs]);
+ temperature, thresholds[thrs]);
else
nvkm_info(subdev, "temperature (%i C) hit the '%s' threshold\n",
- temperature, thresolds[thrs]);
+ temperature, thresholds[thrs]);
  
  	active = (dir == NVKM_THERM_THRS_RISING);

switch (thrs) {



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


Re: [PATCH] drm/i915: Print pwm device-name when using pwm for backlight control

2017-06-27 Thread Ville Syrjälä
On Fri, Jun 23, 2017 at 09:42:44AM +0200, Hans de Goede wrote:
> On Bay Trail devices either the Crystal Cove PMIC's pwm or the LPSS'
> pwm is used to control the backlight. Other drivers take core of
> providing a backlight_pwm alias through pwm_add_table, but it is
> still useful to know which pwm device actually ends up being used
> for debugging backlight issues, so add a DRM_INFO logging the
> pwm device-name.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index cb50c527401f..7936a64af393 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1670,6 +1670,9 @@ static int pwm_setup_backlight(struct intel_connector 
> *connector,
>CRC_PMIC_PWM_PERIOD_NS);
>   panel->backlight.enabled = panel->backlight.level != 0;
>  
> + DRM_INFO("Using %s pwm-device for backlight control\n",
> +  dev_name(panel->backlight.pwm->chip->dev));

Is DRM_DEBUG_KMS() not enough?

> +
>   return 0;
>  }
>  
> -- 
> 2.13.0

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


Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

2017-06-27 Thread Jyri Sarha
On 06/27/17 12:27, Hans Verkuil wrote:
> On 27/06/17 11:14, Tony Lindgren wrote:
>> * Hans Verkuil  [170627 01:39]:
>>> On 26/06/17 13:07, Tony Lindgren wrote:
 Tomi,

 * Tomi Valkeinen  [170428 04:15]:
> On 14/04/17 13:25, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> The CEC pin was always pulled up, making it impossible to use it.
 ...

> Tony, can you queue this? It's safe to apply separately from the rest of
> the HDMI CEC work.

 So the dts changes are merged now but what's the status of the CEC driver
 changes? Were there some issues as I don't see them in next?
>>>
>>> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the
>>> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago)
>>> this was still pending review.
>>
>> OK thanks for the update.
>>
>> Adding Jyri to Cc, hopefully the CEC support allows also setting the
>> HDMI audio volume level on devices implementing it? Or am I too
>> optimistic? :)
> 
> I'm not quite sure what you mean. Do you want CEC to change the volume on the
> TV, or use the TV's remote to change the volume of the HDMI audio output of 
> the
> omap4?
> 

There is no real volume on HDMI audio output as it is a digital
interface, but it should be possible to provide some volume control
using TV's volume trough CEC.

> Anyway, either is supported, but it requires a userspace implementation.
> 

A module to pulseaudio or some extra features to alsa-lib should be
generic enough (who knows, maybe there is already something).

Just an idea. If someone really needs this, the pieces to put it
together should be there.

Best regards,
Jyri

> Although TV remote control messages will be mapped to an input device, and if
> those are hooked up to the alsa audio volume, then this already works.
>> Regards,
> 
>   Hans
> 
>>
>>> Tomi, any updates on this? It would be nice to get this in for 4.14.
>>
>> Yeah seems like we have real mainline kernel user needs for this one.
>>
>> Regards,
>>
>> Tony
>>
> 

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


Re: [PATCH][drm-next] drm/i915: fix spelling mistake: "CouarPoint" -> "CougarPoint"

2017-06-27 Thread Daniel Vetter
On Tue, Jun 27, 2017 at 08:30:09AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in DRM_DEBUG_KMS message
> 
> Signed-off-by: Colin Ian King 

I have this already queued for 4.14, from Ville. I'll show up in
linux-next after 4.13-rc1.

Thanks anyway.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ee2325b180e7..aa99619bfc1b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -132,7 +132,7 @@ static enum intel_pch intel_virt_detect_pch(struct 
> drm_i915_private *dev_priv)
>   DRM_DEBUG_KMS("Assuming Ibex Peak PCH\n");
>   } else if (IS_GEN6(dev_priv) || IS_IVYBRIDGE(dev_priv)) {
>   ret = PCH_CPT;
> - DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> + DRM_DEBUG_KMS("Assuming CougarPoint PCH\n");
>   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>   ret = PCH_LPT;
>   DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

2017-06-27 Thread Hans Verkuil
On 27/06/17 11:14, Tony Lindgren wrote:
> * Hans Verkuil  [170627 01:39]:
>> On 26/06/17 13:07, Tony Lindgren wrote:
>>> Tomi,
>>>
>>> * Tomi Valkeinen  [170428 04:15]:
 On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> The CEC pin was always pulled up, making it impossible to use it.
>>> ...
>>>
 Tony, can you queue this? It's safe to apply separately from the rest of
 the HDMI CEC work.
>>>
>>> So the dts changes are merged now but what's the status of the CEC driver
>>> changes? Were there some issues as I don't see them in next?
>>
>> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the
>> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago)
>> this was still pending review.
> 
> OK thanks for the update.
> 
> Adding Jyri to Cc, hopefully the CEC support allows also setting the
> HDMI audio volume level on devices implementing it? Or am I too
> optimistic? :)

I'm not quite sure what you mean. Do you want CEC to change the volume on the
TV, or use the TV's remote to change the volume of the HDMI audio output of the
omap4?

Anyway, either is supported, but it requires a userspace implementation.

Although TV remote control messages will be mapped to an input device, and if
those are hooked up to the alsa audio volume, then this already works.

Regards,

Hans

> 
>> Tomi, any updates on this? It would be nice to get this in for 4.14.
> 
> Yeah seems like we have real mainline kernel user needs for this one.
> 
> Regards,
> 
> Tony
> 

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


Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

2017-06-27 Thread Jyri Sarha
On 06/27/17 12:14, Tony Lindgren wrote:
> * Hans Verkuil  [170627 01:39]:
>> On 26/06/17 13:07, Tony Lindgren wrote:
>>> Tomi,
>>>
>>> * Tomi Valkeinen  [170428 04:15]:
 On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil 
>
> The CEC pin was always pulled up, making it impossible to use it.
>>> ...
>>>
 Tony, can you queue this? It's safe to apply separately from the rest of
 the HDMI CEC work.
>>>
>>> So the dts changes are merged now but what's the status of the CEC driver
>>> changes? Were there some issues as I don't see them in next?
>>
>> Tomi advised me to wait until a 'hotplug-interrupt-handling series' for the
>> omap driver is merged to prevent conflicts. Last I heard (about 3 weeks ago)
>> this was still pending review.
> 
> OK thanks for the update.
> 
> Adding Jyri to Cc, hopefully the CEC support allows also setting the
> HDMI audio volume level on devices implementing it? Or am I too
> optimistic? :)
> 

As long as you do not expect a regular ALSA-volume to work.. But I don't
see why some CEC application would not work. However, I guess one could
implement this as feature to ALSA too but AFAIK no such thing exists at
the moment.

Best regards,
Jyri

>> Tomi, any updates on this? It would be nice to get this in for 4.14.
> 
> Yeah seems like we have real mainline kernel user needs for this one.
> 
> Regards,
> 
> Tony
> 

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


Re: [PATCH] drm: exynos: dsi: release DSI_PORT_OUT node right after of_drm_find_bridge()

2017-06-27 Thread Inki Dae
Hi Andrzej,

2017년 06월 26일 16:02에 Andrzej Hajda 이(가) 쓴 글:
> Hi Shuah,
> 
> 
> On 24.06.2017 02:56, Shuah Khan wrote:
>> Fix to call of_node_put() right after of_drm_find_bridge() instead of
>> holding on to it until exynos_dsi_remove().
> 
> I think the current implementation is OK, node is get in probe and put
> in remove.
> There could be many bind/unbind during lifetime of the bound driver.
> For example, there is possible sequence:
> 1. probe -
> 2. bind
> 3. unbind
> 4. bind
> 
> With this patch on 2nd bind (point 4) driver will call
> of_drm_find_bridge on dsi->bridge_node which was put earlier (point 2.).
> 

Right. This is a problem.

How about moving of_drm_find_bridge function call to probe and keeping 
drm_bridge_attach call in bind for cleanup?
Seems it doesn't need to call of_drm_find_bridge function every time bind 
callback is called.

Thanks,
Inki Dae

> Regards
> Andrzej
> 
> 
>>
>> Suggested-by: Inki Dae 
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 5 +
>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index e337cd2..7513b88 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1689,6 +1689,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
>> device *master,
>>  
>>  if (dsi->bridge_node) {
>>  bridge = of_drm_find_bridge(dsi->bridge_node);
>> +of_node_put(dsi->bridge_node);
>>  if (bridge)
>>  drm_bridge_attach(encoder, bridge, NULL);
>>  }
>> @@ -1807,10 +1808,6 @@ static int exynos_dsi_probe(struct platform_device 
>> *pdev)
>>  
>>  static int exynos_dsi_remove(struct platform_device *pdev)
>>  {
>> -struct exynos_dsi *dsi = platform_get_drvdata(pdev);
>> -
>> -of_node_put(dsi->bridge_node);
>> -
>>  pm_runtime_disable(>dev);
>>  
>>  component_del(>dev, _dsi_component_ops);
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 101572] glMemoryBarrier is backwards

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101572

Nicolai Hähnle  changed:

   What|Removed |Added

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

--- Comment #1 from Nicolai Hähnle  ---
You're misinterpreting the spec.

glMemoryBarrier ensures that **writes from shaders** are visible to whatever
consumer you indicate with the given flag bits.

What you seem to be trying to do is ensure that **writes via the framebuffer**
are visible in subsequent compute shader invocations. For that, you need to
either:

(1) Bind a different framebuffer, or (probably more appropriate to what you're
trying to do)
(2) use glTextureBarrier.

-- 
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 98619] amdgpu 0000:01:00.0: GPU fault detected: 146 0x09d88404

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=98619

--- Comment #9 from Nicolai Hähnle  ---
Since this is almost certainly an entirely different problem -- looks like
you're using Vulkan -- could you please open a separate bug report? Thanks.

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


[Bug 101484] [regression, bisected] Steam fails to render content, if mesa is compiled with -O2 -march=haswell

2017-06-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101484

--- Comment #12 from Mika  ---
Hi,
I tried with both clang and gcc on Haswell / Pitcairn with "-O2 -march=native",
and I obtained the very same broken display

clang version 5.0.0 (trunk 306114)
gcc version 7.1.1 20170528 (GCC)

-- 
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 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

2017-06-27 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=196197

--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
Can you bisect between 4.10 and 4.11?

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


[Bug 196197] New: [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

2017-06-27 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=196197

Bug ID: 196197
   Summary: [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0
test failed (scratch(0x8504)=0xCAFEDEAD)
   Product: Drivers
   Version: 2.5
Kernel Version: linux-image-4.11.7-towo.1-siduction-amd64
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: an...@ok.de
Regression: No

Created attachment 257191
  --> https://bugzilla.kernel.org/attachment.cgi?id=257191=edit
Bug report as a text file with line feed

Dear maintainer,

Every time the system is booting it will hang, when trying to start Xorg every
5 seconds in an endless loop. The keyboard is locked too.
Only possibility to get a console is via ssh from another machine.

The bug is reproducible always and can always be avoided by downgrading to a
kernel 4.10, leaving the rest of the system unchanged.
That bug comes with the step from kernel 4.10 to kernel 4.11.

Hardware:
AMD Opteron Board with graphics card in a PCI-E 8x Slot.
06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV630
XT [Radeon HD 2600 XT]

Relevant sections of kern.log:
Jun  4 09:19:41 a1 kernel: [   46.719247] radeon :06:00.0: ring 0 stalled
for more than 10093msec
Jun  4 09:19:41 a1 kernel: [   46.719253] radeon :06:00.0: GPU lockup
(current fence id 0x000e last fence id 0x0
012 on ring 0)
Jun  4 09:19:41 a1 kernel: [   46.729651] radeon :06:00.0: Saved 121 dwords
of commands on ring 0.
Jun  4 09:19:41 a1 kernel: [   46.729666] radeon :06:00.0: GPU softreset:
0x0019
Jun  4 09:19:41 a1 kernel: [   46.729669] radeon :06:00.0:  
R_008010_GRBM_STATUS  = 0xE57C24E0
Jun  4 09:19:41 a1 kernel: [   46.729672] radeon :06:00.0:  
R_008014_GRBM_STATUS2 = 0x00113303
Jun  4 09:19:41 a1 kernel: [   46.729674] radeon :06:00.0:  
R_000E50_SRBM_STATUS  = 0x200030C0
Jun  4 09:19:41 a1 kernel: [   46.729676] radeon :06:00.0:  
R_008674_CP_STALLED_STAT1 = 0x0100
Jun  4 09:19:41 a1 kernel: [   46.729678] radeon :06:00.0:  
R_008678_CP_STALLED_STAT2 = 0x1002
Jun  4 09:19:41 a1 kernel: [   46.729680] radeon :06:00.0:  
R_00867C_CP_BUSY_STAT = 0x00028C86
Jun  4 09:19:41 a1 kernel: [   46.729683] radeon :06:00.0:  
R_008680_CP_STAT  = 0x808386C5
Jun  4 09:19:41 a1 kernel: [   46.729685] radeon :06:00.0:  
R_00D034_DMA_STATUS_REG   = 0x44C83D57
Jun  4 09:19:41 a1 kernel: [   46.965016] radeon :06:00.0:
R_008020_GRBM_SOFT_RESET=0x7FEF
Jun  4 09:19:41 a1 kernel: [   46.965070] radeon :06:00.0:
SRBM_SOFT_RESET=0x0100
Jun  4 09:19:41 a1 kernel: [   46.967176] radeon :06:00.0:  
R_008010_GRBM_STATUS  = 0xA0003030
Jun  4 09:19:41 a1 kernel: [   46.967178] radeon :06:00.0:  
R_008014_GRBM_STATUS2 = 0x0003
Jun  4 09:19:41 a1 kernel: [   46.967181] radeon :06:00.0:  
R_000E50_SRBM_STATUS  = 0x2000B0C0
Jun  4 09:19:41 a1 kernel: [   46.967183] radeon :06:00.0:  
R_008674_CP_STALLED_STAT1 = 0x
Jun  4 09:19:41 a1 kernel: [   46.967185] radeon :06:00.0:  
R_008678_CP_STALLED_STAT2 = 0x
Jun  4 09:19:41 a1 kernel: [   46.967187] radeon :06:00.0:  
R_00867C_CP_BUSY_STAT = 0x
Jun  4 09:19:41 a1 kernel: [   46.967189] radeon :06:00.0:  
R_008680_CP_STAT  = 0x8010
Jun  4 09:19:41 a1 kernel: [   46.967191] radeon :06:00.0:  
R_00D034_DMA_STATUS_REG   = 0x44C83D57
Jun  4 09:19:41 a1 kernel: [   46.967200] radeon :06:00.0: GPU reset
succeeded, trying to resume
Jun  4 09:19:41 a1 kernel: [   47.139539] [drm] PCIE GART of 512M enabled
(table at 0x00142000).
Jun  4 09:19:41 a1 kernel: [   47.139556] radeon :06:00.0: WB enabled
Jun  4 09:19:41 a1 kernel: [   47.139559] radeon :06:00.0: fence driver on
ring 0 use gpu addr 0x1c00 and cpu addr 0x880
33fc2cc00
Jun  4 09:19:41 a1 kernel: [   47.140372] radeon :06:00.0: fence driver on
ring 5 use gpu addr 0x000521d0 and cpu addr 0xc90
004a121d0
Jun  4 09:19:42 a1 kernel: [   47.343830] [drm:r600_ring_test [radeon]] *ERROR*
radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
Jun  4 09:19:42 a1 kernel: [   47.343855] [drm:r600_resume [radeon]] *ERROR*
r600 startup failed on resume
Jun  4 09:19:52 a1 kernel: [   57.358140] radeon :06:00.0: ring 0 stalled
for more than 10186msec
Jun  4 09:19:52 a1 kernel: [   57.358148] radeon :06:00.0: GPU lockup
(current fence id 0x000e last fence id 0x0
012 on ring 0)
Jun  4 09:19:52 a1 kernel: [   57.367850] radeon :06:00.0: Saved 261817
dwords of commands on ring 0.
Jun  4 09:19:52 a1 kernel: [   57.367866] radeon :06:00.0: GPU softreset:
0x0008
Jun  4 09:19:52 a1 

  1   2   >