[DPU PATCH v2 5/6] drm/msm: hook up DPU with upstream DSI

[Jeykumar Sankaran]

Switch DPU from dsi-staging to upstream dsi driver. To make
the switch atomic, this change includes:
- remove dpu connector layers
- clean up dpu connector dependencies in encoder/crtc
- compile out writeback and display port drivers
- compile out dsi-staging driver (separate patch submitted to
  remove the driver)
- adapt upstream device hierarchy

changes in v2:
- remove files not applicable upstream (Sean Paul)
- remove compiled out non-dsi display init (Sean Paul)
- split unrelated changes into separate patch set (Sean Paul)

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/Makefile   |1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  | 1184 
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h  |  555 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |9 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  179 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   10 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |8 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |6 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  489 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |   54 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   11 +
 drivers/gpu/drm/msm/dpu_dbg.c  |3 -
 drivers/gpu/drm/msm/msm_drv.c  |   47 +-
 drivers/gpu/drm/msm/msm_drv.h  |   39 -
 15 files changed, 158 insertions(+), 2443 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index b23a001..a8d8ad9 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -48,7 +48,6 @@ msm-y := \
disp/mdp5/mdp5_plane.o \
disp/mdp5/mdp5_smp.o \
disp/dpu1/dpu_color_processing.o \
-   disp/dpu1/dpu_connector.o \
disp/dpu1/dpu_core_irq.o \
disp/dpu1/dpu_core_perf.o \
disp/dpu1/dpu_crtc.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
deleted file mode 100644
index dc0978d..000
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ /dev/null
@@ -1,1184 +0,0 @@
-/* Copyright (c) 2016-2018, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
-#include "msm_drv.h"
-#include "dpu_dbg.h"
-
-#include "dpu_kms.h"
-#include "dpu_connector.h"
-#ifdef CONFIG_DRM_MSM_DSI_STAGING
-#include 
-#include "dsi_drm.h"
-#include "dsi_display.h"
-#endif
-
-#define BL_NODE_NAME_SIZE 32
-
-#define DPU_DEBUG_CONN(c, fmt, ...) DPU_DEBUG("conn%d " fmt,\
-   (c) ? (c)->base.base.id : -1, ##__VA_ARGS__)
-
-#define DPU_ERROR_CONN(c, fmt, ...) DPU_ERROR("conn%d " fmt,\
-   (c) ? (c)->base.base.id : -1, ##__VA_ARGS__)
-static u32 dither_matrix[DITHER_MATRIX_SZ] = {
-   15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
-};
-
-static const struct drm_prop_enum_list e_topology_name[] = {
-   {DPU_RM_TOPOLOGY_NONE,  "dpu_none"},
-   {DPU_RM_TOPOLOGY_SINGLEPIPE,"dpu_singlepipe"},
-   {DPU_RM_TOPOLOGY_DUALPIPE,  "dpu_dualpipe"},
-   {DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE,  "dpu_dualpipemerge"},
-};
-
-static const struct drm_prop_enum_list e_topology_control[] = {
-   {DPU_RM_TOPCTL_RESERVE_LOCK,"reserve_lock"},
-   {DPU_RM_TOPCTL_RESERVE_CLEAR,   "reserve_clear"},
-   {DPU_RM_TOPCTL_DSPP,"dspp"},
-};
-static const struct drm_prop_enum_list e_power_mode[] = {
-   {DPU_MODE_DPMS_ON,  "ON"},
-   {DPU_MODE_DPMS_LP1, "LP1"},
-   {DPU_MODE_DPMS_LP2, "LP2"},
-   {DPU_MODE_DPMS_OFF, "OFF"},
-};
-
-#ifdef CONFIG_DRM_MSM_DSI_STAGING
-static int dpu_backlight_device_update_status(struct backlight_device *bd)
-{
-   int brightness;
-   struct dsi_display *display;
-   struct dpu_connector *c_conn;
-   int bl_lvl;
-   struct drm_event event;
-
-   brightness = bd->props.brightness;
-
-   if ((bd->props.power != FB_BLANK_UNBLANK) ||
-   (bd->props.state & BL_CORE_FBBLANK) ||
-   (bd->props.state & BL_CORE_SUSPENDED))
-   brightness = 0;
-
-   c_conn = bl_get_data(bd);
-   display = 

[DPU PATCH v2 4/6] drm/msm: strip down custom event ioctl's

[Jeykumar Sankaran]

Remove custom ioctl support in SDM845 which allows
user space to register/unregister for hw events.

changes in v2:
- none

Reviewed-by: Sean Paul 
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 218 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  31 -
 drivers/gpu/drm/msm/msm_drv.c| 201 
 drivers/gpu/drm/msm/msm_kms.h|   2 -
 5 files changed, 1 insertion(+), 452 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 8e464fa..387919a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -39,31 +39,6 @@
 #include "dpu_core_perf.h"
 #include "dpu_trace.h"
 
-struct dpu_crtc_irq_info {
-   struct dpu_irq_callback irq;
-   u32 event;
-   int (*func)(struct drm_crtc *crtc, bool en,
-   struct dpu_irq_callback *irq);
-   struct list_head list;
-};
-
-struct dpu_crtc_custom_events {
-   u32 event;
-   int (*func)(struct drm_crtc *crtc, bool en,
-   struct dpu_irq_callback *irq);
-};
-
-static int dpu_crtc_power_interrupt_handler(struct drm_crtc *crtc_drm,
-   bool en, struct dpu_irq_callback *ad_irq);
-static int dpu_crtc_idle_interrupt_handler(struct drm_crtc *crtc_drm,
-   bool en, struct dpu_irq_callback *idle_irq);
-
-static struct dpu_crtc_custom_events custom_events[] = {
-   {DRM_EVENT_AD_BACKLIGHT, dpu_cp_ad_interrupt},
-   {DRM_EVENT_CRTC_POWER, dpu_crtc_power_interrupt_handler},
-   {DRM_EVENT_IDLE_NOTIFY, dpu_crtc_idle_interrupt_handler}
-};
-
 /* layer mixer index on dpu_crtc */
 #define LEFT_MIXER 0
 #define RIGHT_MIXER 1
@@ -2455,9 +2430,6 @@ static void dpu_crtc_handle_power_event(u32 event_type, 
void *arg)
struct drm_encoder *encoder;
struct dpu_crtc_mixer *m;
u32 i, misr_status;
-   unsigned long flags;
-   struct dpu_crtc_irq_info *node = NULL;
-   int ret = 0;
 
if (!crtc) {
DPU_ERROR("invalid crtc\n");
@@ -2479,17 +2451,6 @@ static void dpu_crtc_handle_power_event(u32 event_type, 
void *arg)
dpu_encoder_virt_restore(encoder);
}
 
-   spin_lock_irqsave(_crtc->spin_lock, flags);
-   list_for_each_entry(node, _crtc->user_event_list, list) {
-   ret = 0;
-   if (node->func)
-   ret = node->func(crtc, true, >irq);
-   if (ret)
-   DPU_ERROR("%s failed to enable event %x\n",
-   dpu_crtc->name, node->event);
-   }
-   spin_unlock_irqrestore(_crtc->spin_lock, flags);
-
dpu_cp_crtc_post_ipc(crtc);
 
for (i = 0; i < dpu_crtc->num_mixers; ++i) {
@@ -2514,18 +2475,6 @@ static void dpu_crtc_handle_power_event(u32 event_type, 
void *arg)
dpu_crtc->misr_data[i];
}
 
-   spin_lock_irqsave(_crtc->spin_lock, flags);
-   node = NULL;
-   list_for_each_entry(node, _crtc->user_event_list, list) {
-   ret = 0;
-   if (node->func)
-   ret = node->func(crtc, false, >irq);
-   if (ret)
-   DPU_ERROR("%s failed to disable event %x\n",
-   dpu_crtc->name, node->event);
-   }
-   spin_unlock_irqrestore(_crtc->spin_lock, flags);
-
dpu_cp_crtc_pre_ipc(crtc);
break;
case DPU_POWER_EVENT_POST_DISABLE:
@@ -2553,8 +2502,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
struct drm_display_mode *mode;
struct drm_encoder *encoder;
struct msm_drm_private *priv;
-   unsigned long flags;
-   struct dpu_crtc_irq_info *node = NULL;
struct drm_event event;
u32 power_on;
int ret;
@@ -2614,17 +2561,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
atomic_set(_crtc->frame_pending, 0);
}
 
-   spin_lock_irqsave(_crtc->spin_lock, flags);
-   list_for_each_entry(node, _crtc->user_event_list, list) {
-   ret = 0;
-   if (node->func)
-   ret = node->func(crtc, false, >irq);
-   if (ret)
-   DPU_ERROR("%s failed to disable event %x\n",
-   dpu_crtc->name, node->event);
-   }
-   spin_unlock_irqrestore(_crtc->spin_lock, flags);
-
dpu_core_perf_crtc_update(crtc, 0, true);
 
drm_for_each_encoder(encoder, crtc->dev) {
@@ -2656,8 +2592,6 @@ 

[DPU PATCH v2 3/6] drm/msm: remove panel autorefresh support for SDM845

[Jeykumar Sankaran]

Remove autorefresh support for smart panels in SDM845 for now.
It needs more discussion to figure out the user space
communication to set preference for the feature.

changes in v2:
- none

Reviewed-by: Sean Paul 
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  37 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |  20 --
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 298 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|  41 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|  18 --
 6 files changed, 11 insertions(+), 410 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index f7e9f76..dc0978d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -24,9 +24,6 @@
 
 #define BL_NODE_NAME_SIZE 32
 
-/* Autorefresh will occur after FRAME_CNT frames. Large values are unlikely */
-#define AUTOREFRESH_MAX_FRAME_CNT 6
-
 #define DPU_DEBUG_CONN(c, fmt, ...) DPU_DEBUG("conn%d " fmt,\
(c) ? (c)->base.base.id : -1, ##__VA_ARGS__)
 
@@ -1126,10 +1123,6 @@ struct drm_connector *dpu_connector_init(struct 
drm_device *dev,
CONNECTOR_PROP_AD_BL_SCALE);
 #endif
 
-   msm_property_install_range(_conn->property_info, "autorefresh",
-   0x0, 0, AUTOREFRESH_MAX_FRAME_CNT, 0,
-   CONNECTOR_PROP_AUTOREFRESH);
-
/* enum/bitmask properties */
msm_property_install_enum(_conn->property_info, "topology_name",
DRM_MODE_PROP_IMMUTABLE, 0, e_topology_name,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index d04095b..3854410 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -813,7 +813,6 @@ static void _dpu_encoder_resource_control_helper(struct 
drm_encoder *drm_enc,
 static int dpu_encoder_resource_control(struct drm_encoder *drm_enc,
u32 sw_event)
 {
-   bool autorefresh_enabled = false;
unsigned int lp, idle_timeout;
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
@@ -920,13 +919,6 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
return 0;
}
 
-   /* schedule delayed off work if autorefresh is disabled */
-   if (dpu_enc->cur_master &&
-   dpu_enc->cur_master->ops.is_autorefresh_enabled)
-   autorefresh_enabled =
-   dpu_enc->cur_master->ops.is_autorefresh_enabled(
-   dpu_enc->cur_master);
-
/* set idle timeout based on master connector's lp value */
if (dpu_enc->cur_master)
lp = dpu_connector_get_lp(
@@ -939,13 +931,12 @@ static int dpu_encoder_resource_control(struct 
drm_encoder *drm_enc,
else
idle_timeout = dpu_enc->idle_timeout;
 
-   if (!autorefresh_enabled)
-   kthread_queue_delayed_work(
-   _thread->worker,
-   _enc->delayed_off_work,
-   msecs_to_jiffies(idle_timeout));
+   kthread_queue_delayed_work(
+   _thread->worker,
+   _enc->delayed_off_work,
+   msecs_to_jiffies(idle_timeout));
+
DPU_EVT32(DRMID(drm_enc), sw_event, dpu_enc->rc_state,
-   autorefresh_enabled,
idle_timeout, DPU_EVTLOG_FUNC_CASE2);
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work scheduled\n",
sw_event);
@@ -1988,7 +1979,6 @@ static void dpu_encoder_vsync_event_handler(struct 
timer_list *t)
struct drm_encoder *drm_enc = _enc->base;
struct msm_drm_private *priv;
struct msm_drm_thread *event_thread;
-   bool autorefresh_enabled = false;
 
if (!drm_enc->dev || !drm_enc->dev->dev_private ||
!drm_enc->crtc) {
@@ -2009,22 +1999,7 @@ static void dpu_encoder_vsync_event_handler(struct 
timer_list *t)
return;
}
 
-   if (dpu_enc->cur_master &&
-   dpu_enc->cur_master->ops.is_autorefresh_enabled)
-   autorefresh_enabled =
-   dpu_enc->cur_master->ops.is_autorefresh_enabled(
-   dpu_enc->cur_master);
-
-   /*
-* Queue work to update the vsync event timer
-* if autorefresh is enabled.
-*/
-   DPU_EVT32_VERBOSE(autorefresh_enabled);
-   if 

[DPU PATCH v2 2/6] drm/msm: remove support for ping pong split topology

[Jeykumar Sankaran]

ping pong split topology was meant for low end soc's which
doesn't have enough layer mixers to support split panels.
Considering how uncommon the topology is for current chipset's and
also to simply the driver programming, striping off the support
for SDM845.

changes in v2:
- none

Reviewed-by: Sean Paul 
Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  19 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 179 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   5 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   | 110 +
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  21 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |  33 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |  11 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h   |   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  37 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   2 -
 13 files changed, 15 insertions(+), 415 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index 1237efc..f7e9f76 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -41,8 +41,8 @@
{DPU_RM_TOPOLOGY_SINGLEPIPE,"dpu_singlepipe"},
{DPU_RM_TOPOLOGY_DUALPIPE,  "dpu_dualpipe"},
{DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE,  "dpu_dualpipemerge"},
-   {DPU_RM_TOPOLOGY_PPSPLIT,   "dpu_ppsplit"},
 };
+
 static const struct drm_prop_enum_list e_topology_control[] = {
{DPU_RM_TOPCTL_RESERVE_LOCK,"reserve_lock"},
{DPU_RM_TOPCTL_RESERVE_CLEAR,   "reserve_clear"},
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 516458e..8e464fa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1914,23 +1914,6 @@ static void _dpu_crtc_setup_mixers(struct drm_crtc *crtc)
mutex_unlock(_crtc->crtc_lock);
 }
 
-static void _dpu_crtc_setup_is_ppsplit(struct drm_crtc_state *state)
-{
-   int i;
-   struct dpu_crtc_state *cstate;
-
-   cstate = to_dpu_crtc_state(state);
-
-   cstate->is_ppsplit = false;
-   for (i = 0; i < cstate->num_connectors; i++) {
-   struct drm_connector *conn = cstate->connectors[i];
-
-   if (dpu_connector_get_topology_name(conn) ==
-   DPU_RM_TOPOLOGY_PPSPLIT)
-   cstate->is_ppsplit = true;
-   }
-}
-
 static void _dpu_crtc_setup_lm_bounds(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
@@ -1993,7 +1976,6 @@ static void dpu_crtc_atomic_begin(struct drm_crtc *crtc,
 
if (!dpu_crtc->num_mixers) {
_dpu_crtc_setup_mixers(crtc);
-   _dpu_crtc_setup_is_ppsplit(crtc->state);
_dpu_crtc_setup_lm_bounds(crtc, crtc->state);
}
 
@@ -2901,7 +2883,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
 
mixer_width = dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
 
-   _dpu_crtc_setup_is_ppsplit(state);
_dpu_crtc_setup_lm_bounds(crtc, state);
 
 /* get plane state for all drm planes associated with crtc state */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 151889b..d04095b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,6 @@ void dpu_encoder_helper_split_config(
struct dpu_encoder_virt *dpu_enc;
struct split_pipe_cfg cfg = { 0 };
struct dpu_hw_mdp *hw_mdptop;
-   enum dpu_rm_topology_name topology;
struct msm_display_info *disp_info;
 
if (!phys_enc || !phys_enc->hw_mdptop || !phys_enc->parent) {
@@ -569,8 +568,6 @@ void dpu_encoder_helper_split_config(
if (phys_enc->split_role == ENC_ROLE_SOLO) {
if (hw_mdptop->ops.setup_split_pipe)
hw_mdptop->ops.setup_split_pipe(hw_mdptop, );
-   if (hw_mdptop->ops.setup_pp_split)
-   hw_mdptop->ops.setup_pp_split(hw_mdptop, );
return;
}
 
@@ -582,29 +579,11 @@ void dpu_encoder_helper_split_config(
phys_enc->ops.needs_single_flush(phys_enc))
cfg.split_flush_en = true;
 
-   topology = dpu_connector_get_topology_name(phys_enc->connector);
-   if (topology == DPU_RM_TOPOLOGY_PPSPLIT)
-   cfg.pp_split_slave = cfg.intf;
-   else
-   cfg.pp_split_slave = INTF_MAX;
-
if (phys_enc->split_role == ENC_ROLE_MASTER) {
  

[DPU PATCH v2 1/6] drm/msm: remove display stream compression(DSC) support for SM845

[Jeykumar Sankaran]

Upstream DSI driver doesn't support DSC panels yet. Remove
the support for compression from DPU for now.

changes in v2:
- indents and unrelated change clean up (Sean Paul)
- fix compilation dependency in dsi-staging

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/Makefile   |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  |   4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 476 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|  14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   7 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   1 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  25 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  16 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 252 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 100 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|  17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|  48 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|  22 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |  13 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  55 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   8 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c |   2 -
 drivers/gpu/drm/msm/dsi-staging/dsi_drm.c  |   7 -
 drivers/gpu/drm/msm/msm_drv.h  |  16 -
 21 files changed, 5 insertions(+), 1093 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 9c27991..b23a001 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -64,7 +64,6 @@ msm-y := \
disp/dpu1/dpu_hw_color_processing_v1_7.o \
disp/dpu1/dpu_hw_ctl.o \
disp/dpu1/dpu_hw_ds.o \
-   disp/dpu1/dpu_hw_dsc.o \
disp/dpu1/dpu_hw_dspp.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
index 36607e3..1237efc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c
@@ -39,12 +39,8 @@
 static const struct drm_prop_enum_list e_topology_name[] = {
{DPU_RM_TOPOLOGY_NONE,  "dpu_none"},
{DPU_RM_TOPOLOGY_SINGLEPIPE,"dpu_singlepipe"},
-   {DPU_RM_TOPOLOGY_SINGLEPIPE_DSC,"dpu_singlepipe_dsc"},
{DPU_RM_TOPOLOGY_DUALPIPE,  "dpu_dualpipe"},
-   {DPU_RM_TOPOLOGY_DUALPIPE_DSC,  "dpu_dualpipe_dsc"},
{DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE,  "dpu_dualpipemerge"},
-   {DPU_RM_TOPOLOGY_DUALPIPE_3DMERGE_DSC,  "dpu_dualpipemerge_dsc"},
-   {DPU_RM_TOPOLOGY_DUALPIPE_DSCMERGE, "dpu_dualpipe_dscmerge"},
{DPU_RM_TOPOLOGY_PPSPLIT,   "dpu_ppsplit"},
 };
 static const struct drm_prop_enum_list e_topology_control[] = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 198c618..151889b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -32,7 +32,6 @@
 #include "dpu_formats.h"
 #include "dpu_encoder_phys.h"
 #include "dpu_power_handle.h"
-#include "dpu_hw_dsc.h"
 #include "dpu_crtc.h"
 #include "dpu_trace.h"
 #include "dpu_core_irq.h"
@@ -152,7 +151,6 @@ enum dpu_enc_rc_states {
  * Only valid after enable. Cleared as disable.
  * @hw_pp  Handle to the pingpong blocks used for the display. No.
  * pingpong blocks can be different than num_phys_encs.
- * @hw_dsc:Array of DSC block handles used for the display.
  * @intfs_swapped  Whether or not the phys_enc interfaces have been swapped
  * for partial update right-only cases, such as pingpong
  * split where virtual pingpong does not generate IRQs
@@ -199,7 +197,6 @@ struct dpu_encoder_virt {
struct dpu_encoder_phys *phys_encs[MAX_PHYS_ENCODERS_PER_VIRTUAL];
struct dpu_encoder_phys *cur_master;
struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
-   struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
 
bool intfs_swapped;
 
@@ -234,21 +231,6 @@ struct dpu_encoder_virt {
 
 #define to_dpu_encoder_virt(x) container_of(x, struct dpu_encoder_virt, base)
 
-bool dpu_encoder_is_dsc_enabled(struct drm_encoder *drm_enc)
-
-{
-   struct dpu_encoder_virt *dpu_enc;
-   struct msm_compression_info *comp_info;
-
-   if (!drm_enc)
-   return false;
-
-   dpu_enc = to_dpu_encoder_virt(drm_enc);
-   comp_info = _enc->mode_info.comp_info;
-
-   return 

[DPU PATCH v2 0/6] Switch DPU to use upstream DSI driver for SDM845

[Jeykumar Sankaran]

SDM845 DPU driver was talking to dsi-staging driver for its dsi 
operations through the customized dpu_connector layer. The following 
series of patches removes DPU dependency from various dpu
connector API's before purging the dpu_connector altogether. It
also completes the switch to upstream DSI driver by removing
the dsi-staging driver and it's dependent sources.

The patch series is based on:
[1]https://www.spinics.net/lists/dri-devel/msg172315.html
[2]https://www.spinics.net/lists/dri-devel/msg172395.html

changes in v2:
- addressed comments on indentation (Sean Paul)
- removed compiled out non-dsi display init (Sean Paul)
- removed file changes not applicable upstream (Sean Paul)
- Split unrelated changes into seperate patch sets (Sean Paul)

Jeykumar Sankaran (6):
  drm/msm: remove display stream compression(DSC) support for SM845
  drm/msm: remove support for ping pong split topology
  drm/msm: remove panel autorefresh support for SDM845
  drm/msm: strip down custom event ioctl's
  drm/msm: hook up DPU with upstream DSI
  drm/msm: remove dsi-staging driver

 drivers/gpu/drm/msm/Kconfig|   12 -
 drivers/gpu/drm/msm/Makefile   |   23 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.c  | 1195 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_connector.h  |  555 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  246 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  867 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|   24 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   38 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  409 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   32 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   30 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   18 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c |  252 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h |  100 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   89 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|   40 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |   46 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |   18 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hwio.h   |4 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  520 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  146 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |   21 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c |2 -
 drivers/gpu/drm/msm/dpu_dbg.c  |3 -
 drivers/gpu/drm/msm/dsi-staging/dsi_catalog.c  |  241 --
 drivers/gpu/drm/msm/dsi-staging/dsi_catalog.h  |  201 -
 drivers/gpu/drm/msm/dsi-staging/dsi_clk.h  |  276 --
 drivers/gpu/drm/msm/dsi-staging/dsi_clk_manager.c  | 1235 --
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl.c | 2846 -
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl.h |  623 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw.h  |  752 
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_1_4.c  |  480 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_2_0.c  |  234 --
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_2_2.c  |   42 -
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_cmn.c  | 1312 --
 drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_reg.h |  196 -
 drivers/gpu/drm/msm/dsi-staging/dsi_defs.h |  579 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_display.c  | 4221 
 drivers/gpu/drm/msm/dsi-staging/dsi_display.h  |  556 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_display_test.c |  114 -
 drivers/gpu/drm/msm/dsi-staging/dsi_display_test.h |   31 -
 drivers/gpu/drm/msm/dsi-staging/dsi_drm.c  |  688 
 drivers/gpu/drm/msm/dsi-staging/dsi_drm.h  |  127 -
 drivers/gpu/drm/msm/dsi-staging/dsi_hw.h   |   48 -
 drivers/gpu/drm/msm/dsi-staging/dsi_panel.c| 3321 ---
 drivers/gpu/drm/msm/dsi-staging/dsi_panel.h|  257 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy.c  |  937 -
 drivers/gpu/drm/msm/dsi-staging/dsi_phy.h  |  235 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw.h   |  260 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw_v2_0.c  |  252 --
 drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw_v3_0.c  |  447 ---
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_calc.c  |  676 
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_calc.h  |  144 -
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_v2_0.c  |  126 -
 .../gpu/drm/msm/dsi-staging/dsi_phy_timing_v3_0.c  |  107 -
 drivers/gpu/drm/msm/dsi-staging/dsi_pwr.c  |  365 --
 drivers/gpu/drm/msm/dsi-staging/dsi_pwr.h  |   93 -
 drivers/gpu/drm/msm/msm_drv.c  |  248 +-
 drivers/gpu/drm/msm/msm_drv.h  |  

[DPU PATCH] drm/msm: populate aspace in msm_kms

[Jeykumar Sankaran]

display drivers may need to access aspace to
allocate internal buffers (e.g. DSI to allocate cmd buffer)
This change populates the needed info.

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 2c187e9..f6fea21 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1835,8 +1835,6 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
goto fail;
}
 
-   dpu_kms->aspace[0] = aspace;
-
ret = aspace->mmu->funcs->attach(aspace->mmu,
(const char **)iommu_ports,
ARRAY_SIZE(iommu_ports));
@@ -1845,7 +1843,9 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
msm_gem_address_space_put(aspace);
goto fail;
}
+
aspace->domain_attached = true;
+   dpu_kms->aspace[0] = aspace;
 #endif
return 0;
 fail:
@@ -2004,6 +2004,9 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
goto power_error;
}
 
+   if (dpu_kms->aspace[0])
+   kms->aspace = dpu_kms->aspace[0];
+
 #ifdef CONFIG_CHROME_REGDMA
/* Initialize reg dma block which is a singleton */
rc = dpu_reg_dma_init(dpu_kms->reg_dma, dpu_kms->catalog,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

[Alex Deucher]

On Thu, Apr 19, 2018 at 6:08 PM, drake  wrote:
> On Tue, Apr 3, 2018 at 11:31 AM, Daniel Drake  wrote:
>> On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake  wrote:
>>> On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher  
>>> wrote:
> It seems that we are not alone seeing amdgpu-induced stability
> problems on multiple Raven Ridge platforms.
> https://www.phoronix.com/scan.php?page=news_item=AMD-Raven-Ridge-Mobo-Linux
>
> AMD, what can we do to help?

 Please file bugs:
 https://bugs.freedesktop.org
>>>
>>> Sorry for the delayed response. We're still seeing serious instability
>>> here even on the latest kernel. Filed
>>> https://bugs.freedesktop.org/show_bug.cgi?id=105684
>>
>> No progress made on that bug report so far.
>> What can we do to help this advance?
>
> Ping, any news here? How can we help advance on this bug?

Can you try one of these branches?
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.18-wip
do they work any better?

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

Re: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

[drake]

On Tue, Apr 3, 2018 at 11:31 AM, Daniel Drake  wrote:
> On Thu, Mar 22, 2018 at 3:09 AM, Daniel Drake  wrote:
>> On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher  wrote:
 It seems that we are not alone seeing amdgpu-induced stability
 problems on multiple Raven Ridge platforms.
 https://www.phoronix.com/scan.php?page=news_item=AMD-Raven-Ridge-Mobo-Linux

 AMD, what can we do to help?
>>>
>>> Please file bugs:
>>> https://bugs.freedesktop.org
>>
>> Sorry for the delayed response. We're still seeing serious instability
>> here even on the latest kernel. Filed
>> https://bugs.freedesktop.org/show_bug.cgi?id=105684
>
> No progress made on that bug report so far.
> What can we do to help this advance?

Ping, any news here? How can we help advance on this bug?

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

[PATCH] drm/panel: simple: fix data type in KEO TX31D200VM0BAA timings

[Stefan Agner]

All values in a struct struct timing_entry (every entry in
struct display_timing) require an integer. Choose the closest
safe integer of 32.

This avoids a warning seen with clang:
  drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit
   conversion from 'double' to 'u32' (aka 'unsigned int')
   changes value from 33.5 to 33 [-Wliteral-conversion]
 .vfront_porch = { 6, 21, 33.5 },
 ~^~~~
  drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit
conversion from 'double' to 'u32' (aka 'unsigned int')
changes value from 33.5 to 33 [-Wliteral-conversion]
  .vback_porch = { 6, 21, 33.5 },
 ~^~~~

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/panel/panel-simple.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..12bcbd1dd77b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1247,8 +1247,8 @@ static const struct display_timing 
koe_tx31d200vm0baa_timing = {
.hback_porch = { 16, 36, 56 },
.hsync_len = { 8, 8, 8 },
.vactive = { 480, 480, 480 },
-   .vfront_porch = { 6, 21, 33.5 },
-   .vback_porch = { 6, 21, 33.5 },
+   .vfront_porch = { 6, 21, 33 },
+   .vback_porch = { 6, 21, 33 },
.vsync_len = { 8, 8, 8 },
.flags = DISPLAY_FLAGS_DE_HIGH,
 };
-- 
2.17.0

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

Re: [DPU PATCH 5/6] drm/msm: hook up DPU with upstream DSI

[Jeykumar Sankaran]

On 2018-04-19 08:38, Sean Paul wrote:

On Mon, Apr 16, 2018 at 11:22:20AM -0700, Jeykumar Sankaran wrote:

Switch DPU from dsi-staging to upstream dsi driver. To make
the switch atomic, this change includes:
- remove dpu connector layers
- clean up dpu connector dependencies in encoder/crtc
- compile out writeback and display port drivers
- compile out dsi-staging driver (separate patch submitted to
  remove the driver)
- adapt upstream device hierarchy

Signed-off-by: Jeykumar Sankaran 
---
 .../config/arm64/chromiumos-arm64.flavour.config   |4 +-
 .../arm64/chromiumos-qualcomm.flavour.config   |4 +-


These files aren't in upstream.




+
+struct drm_encoder *dpu_encoder_init(struct drm_device *dev,
+   int drm_enc_mode)
+{
+   struct dpu_encoder_virt *dpu_enc = NULL;
+
+   dpu_enc = kzalloc(sizeof(*dpu_enc), GFP_KERNEL);


You should probably use devm_kzalloc.


+   if (!dpu_enc)
+   return ERR_PTR(ENOMEM);
+
+   drm_encoder_init(dev, _enc->base, _encoder_funcs,
+   drm_enc_mode, NULL);


Check the return value?



-#ifdef CONFIG_DRM_MSM_DSI_STAGING
 static void _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
-   struct dpu_kms *dpu_kms,
-   unsigned max_encoders)
+   struct dpu_kms *dpu_kms)
 {
-   static const struct dpu_connector_ops dsi_ops = {
-   .post_init =  dsi_conn_post_init,
-   .detect = dsi_conn_detect,
-   .get_modes =  dsi_connector_get_modes,
-   .put_modes =  dsi_connector_put_modes,
-   .mode_valid = dsi_conn_mode_valid,
-   .get_info =   dsi_display_get_info,
-   .set_backlight = dsi_display_set_backlight,
-   .soft_reset   = dsi_display_soft_reset,
-   .pre_kickoff  = dsi_conn_pre_kickoff,
-   .clk_ctrl = dsi_display_clk_ctrl,
-   .set_power = dsi_display_set_power,
-   .get_mode_info = dsi_conn_get_mode_info,
-   .get_dst_format = dsi_display_get_dst_format,
-   .post_kickoff = dsi_conn_post_kickoff
-   };
-   struct msm_display_info info;
-   struct drm_encoder *encoder;
-   void *display, *connector;
+   struct drm_encoder *encoder = NULL;
int i, rc;

-   /* dsi */
-   for (i = 0; i < dpu_kms->dsi_display_count &&
-   priv->num_encoders < max_encoders; ++i) {
-   display = dpu_kms->dsi_displays[i];
-   encoder = NULL;
+   /*TODO: Support two independent DSI connectors */
+   encoder = dpu_encoder_init(dev, DRM_MODE_CONNECTOR_DSI);
+   if (IS_ERR_OR_NULL(encoder)) {
+   DPU_ERROR("encoder init failed for dsi %d\n", i);


Is i meaningful here? It seems like it's uninitialized...


+   return;
+   }

-   memset(, 0x0, sizeof(info));
-   rc = dsi_display_get_info(, display);
-   if (rc) {
-   DPU_ERROR("dsi get_info %d failed\n", i);
-   continue;
-   }
+   priv->encoders[priv->num_encoders++] = encoder;

-   encoder = dpu_encoder_init(dev, );
-   if (IS_ERR_OR_NULL(encoder)) {
-   DPU_ERROR("encoder init failed for dsi %d\n", i);
-   continue;
+   for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+   if (!priv->dsi[i]) {
+   DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
+   return;
}

-   rc = dsi_display_drm_bridge_init(display, encoder);
+   rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
if (rc) {
-   DPU_ERROR("dsi bridge %d init failed, %d\n", i,

rc);

-   dpu_encoder_destroy(encoder);
+   DPU_ERROR("modeset_init failed for dsi[%d]\n", i);


Printing rc would be nice here, same for above.


continue;
}
-
-   connector = dpu_connector_init(dev,
-   encoder,
-   0,
-   display,
-   _ops,
-   DRM_CONNECTOR_POLL_HPD,
-   DRM_MODE_CONNECTOR_DSI);
-   if (connector) {
-   priv->encoders[priv->num_encoders++] = encoder;
-   } else {
-   DPU_ERROR("dsi %d connector init failed\n", i);
-   dsi_display_drm_bridge_deinit(display);
-   dpu_encoder_destroy(encoder);
-   }
}
 }
-#endif
+

 #ifdef CONFIG_DRM_MSM_WRITEBACK
 static void 

[radeon-alex:drm-next-4.18-wip 169/185] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:917:39: sparse: constant 0x1B8000000 is so big it is long

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head:   42386402a815771c50788038c101dd530ac729d2
commit: 7bdb3db410d25b815a0b8d9387accee3da12b376 [169/185] drm/amdgpu: Reserved 
vram for smu to save debug info.
reproduce:
# apt-get install sparse
git checkout 7bdb3db410d25b815a0b8d9387accee3da12b376
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:917:39: sparse: constant 
>> 0x1B800 is so big it is long
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:320:39: sparse: cast removes 
address space of expression
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:340:31: sparse: cast removes 
address space of expression
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1425:65: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1427:55: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1428:50: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1429:50: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1430:56: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1432:25: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1433:45: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1434:51: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1435:55: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1436:57: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1438:25: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1439:53: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1441:25: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1443:25: sparse: cast to 
restricted __le32
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1444:46: sparse: cast to 
restricted __le32

vim +917 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

   911  
   912  static void amdgpu_device_check_smu_prv_buffer_size(struct 
amdgpu_device *adev)
   913  {
   914  struct sysinfo si;
   915  bool is_os_64 = (sizeof(void *) == 8) ? true : false;
   916  uint64_t total_memory;
 > 917  uint64_t dram_size_seven_GB = 0x1B800;
   918  uint64_t dram_size_three_GB = 0xB800;
   919  
   920  if (amdgpu_smu_memory_pool_size == 0)
   921  return;
   922  
   923  if (!is_os_64) {
   924  DRM_WARN("Not 64-bit OS, feature not supported\n");
   925  goto def_value;
   926  }
   927  si_meminfo();
   928  total_memory = (uint64_t)si.totalram * si.mem_unit;
   929  
   930  if ((amdgpu_smu_memory_pool_size == 1) ||
   931  (amdgpu_smu_memory_pool_size == 2)) {
   932  if (total_memory < dram_size_three_GB)
   933  goto def_value1;
   934  } else if ((amdgpu_smu_memory_pool_size == 4) ||
   935  (amdgpu_smu_memory_pool_size == 8)) {
   936  if (total_memory < dram_size_seven_GB)
   937  goto def_value1;
   938  } else {
   939  DRM_WARN("Smu memory pool size not supported\n");
   940  goto def_value;
   941  }
   942  adev->pm.smu_prv_buffer_size = amdgpu_smu_memory_pool_size << 
28;
   943  
   944  return;
   945  
   946  def_value1:
   947  DRM_WARN("No enough system memory\n");
   948  def_value:
   949  adev->pm.smu_prv_buffer_size = 0;
   950  }
   951  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mi0283qt driver issues

[Noralf Trønnes]

Den 18.04.2018 17.52, skrev Tom Callaway:


On 04/18/2018 06:22 AM, Noralf Trønnes wrote:

It turns out that the reason for this is that the pitft has a hw reset
circuit that resets only on power-on and not on each reboot through a
gpio like rpi-display does.

When the driver is enabling the display pipeline it checks if the
controller is already initialized, and skips setup if it is. This means
that the rotation value is only applied after power-on on the pitft and
not on each reboot.

Turning off the "display" before rebooting should also work:

$ # change rotation value
$ echo "28" | sudo tee /sys/kernel/debug/dri/0/command
$ sudo reboot

Rotation/mirror/flip/bgr is controlled by commmand 0x36. The current
value is returned by command 0x0b:

$ sudo cat /sys/kernel/debug/dri/0/command | grep "0b:"
0b: f8

So to fix this in the driver the rotation value has to always be applied
regardless of display "on" state. This can be done by moving the rotation
code in mi0283qt_enable() down after the out: label.

Confirmed, turning off the display before rebooting works, thanks.

To fix this correctly, it seems like there are two paths:

* If it is always safe to apply the rotation value regardless of display
state, move the rotation code down after out: in the mi0283qt driver.


This is fine, it's reset, sleep in/out and display on/off that's disruptive.



* If this fix is only safe on the pitft (and not on the other panels
driven by the mi0283qt driver), either conditionalizing this behavior
somehow, or making a separate ili9340 driver with this change.

I'm willing to make patches if necessary here, but it is not clear which
path is the correct one.


Thanks, a patch a much appreciated.

Noralf.



~tom


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

[PATCH 2/2] drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

[Eric Anholt]

 return ret;
+
+   ident0 = V3D_READ(V3D_HUB_IDENT0);
+   ident1 = V3D_READ(V3D_HUB_IDENT1);
+   ident2 = V3D_READ(V3D_HUB_IDENT2);
+   ident3 = V3D_READ(V3D_HUB_IDENT3);
+   cores = V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_NCORES);
+
+   seq_printf(m, "Revision:   %d.%d.%d.%d\n",
+  V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_TVER),
+  V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_REV),
+  V3D_GET_FIELD(ident3, V3D_HUB_IDENT3_IPREV),
+  V3D_GET_FIELD(ident3, V3D_HUB_IDENT3_IPIDX));
+   seq_printf(m, "MMU:%s\n",
+  (ident2 & V3D_HUB_IDENT2_WITH_MMU) ? "yes" : "no");
+   seq_printf(m, "TFU:%s\n",
+  (ident1 & V3D_HUB_IDENT1_WITH_TFU) ? "yes" : "no");
+   seq_printf(m, "TSY:%s\n",
+  (ident1 & V3D_HUB_IDENT1_WITH_TSY) ? "yes" : "no");
+   seq_printf(m, "MSO:%s\n",
+  (ident1 & V3D_HUB_IDENT1_WITH_MSO) ? "yes" : "no");
+   seq_printf(m, "L3C:%s (%dkb)\n",
+  (ident1 & V3D_HUB_IDENT1_WITH_L3C) ? "yes" : "no",
+  V3D_GET_FIELD(ident2, V3D_HUB_IDENT2_L3C_NKB));
+
+   for (core = 0; core < cores; core++) {
+   u32 misccfg;
+   u32 nslc, ntmu, qups;
+
+   ident0 = V3D_CORE_READ(core, V3D_CTL_IDENT0);
+   ident1 = V3D_CORE_READ(core, V3D_CTL_IDENT1);
+   ident2 = V3D_CORE_READ(core, V3D_CTL_IDENT2);
+   misccfg = V3D_CORE_READ(core, V3D_CTL_MISCCFG);
+
+   nslc = V3D_GET_FIELD(ident1, V3D_IDENT1_NSLC);
+   ntmu = V3D_GET_FIELD(ident1, V3D_IDENT1_NTMU);
+   qups = V3D_GET_FIELD(ident1, V3D_IDENT1_QUPS);
+
+   seq_printf(m, "Core %d:\n", core);
+   seq_printf(m, "  Revision: %d.%d\n",
+  V3D_GET_FIELD(ident0, V3D_IDENT0_VER),
+  V3D_GET_FIELD(ident1, V3D_IDENT1_REV));
+   seq_printf(m, "  Slices:   %d\n", nslc);
+   seq_printf(m, "  TMUs: %d\n", nslc * ntmu);
+   seq_printf(m, "  QPUs: %d\n", nslc * qups);
+   seq_printf(m, "  Semaphores:   %d\n",
+  V3D_GET_FIELD(ident1, V3D_IDENT1_NSEM));
+   seq_printf(m, "  BCG int:  %d\n",
+  (ident2 & V3D_IDENT2_BCG_INT) != 0);
+   seq_printf(m, "  Override TMU: %d\n",
+  (misccfg & V3D_MISCCFG_OVRTMUOUT) != 0);
+   }
+
+   pm_runtime_mark_last_busy(v3d->dev);
+   pm_runtime_put_autosuspend(v3d->dev);
+
+   return 0;
+}
+
+static int v3d_debugfs_bo_stats(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct v3d_dev *v3d = to_v3d_dev(dev);
+
+   mutex_lock(>bo_lock);
+   seq_printf(m, "allocated bos:  %d\n",
+  v3d->bo_stats.num_allocated);
+   seq_printf(m, "allocated bo size (kb): %ld\n",
+  (long)v3d->bo_stats.pages_allocated << (PAGE_SHIFT - 10));
+   mutex_unlock(>bo_lock);
+
+   return 0;
+}
+
+static const struct drm_info_list v3d_debugfs_list[] = {
+   {"v3d_ident", v3d_v3d_debugfs_ident, 0},
+   {"v3d_regs", v3d_v3d_debugfs_regs, 0},
+   {"bo_stats", v3d_debugfs_bo_stats, 0},
+};
+
+int
+v3d_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(v3d_debugfs_list,
+   ARRAY_SIZE(v3d_debugfs_list),
+   minor->debugfs_root, minor);
+}
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
new file mode 100644
index ..02a3d2895f95
--- /dev/null
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2014-2018 Broadcom */
+
+/**
+ * DOC: Broadcom V3D Graphics Driver
+ *
+ * This driver supports the Broadcom V3D 3.3 and 4.1 OpenGL ES GPUs.
+ * For V3D 2.x support, see the VC4 driver.
+ *
+ * Currently only single-core rendering using the binner and renderer
+ * is supported.  The TFU (texture formatting unit) and V3D 4.x's CSD
+ * (compute shader dispatch) are not yet supported.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "uapi/drm/v3d_drm.h"
+#include "v3d_drv.h"
+#include "v3d_regs.h"
+
+#define DRIVER_NAME "v3d"
+#define DRIVER_DESC "Broadcom V3D graphics"

[PATCH 0/2] Broadcom V3D driver (7268/7278)

[Eric Anholt]

Here's my first pass at submitting the DRM driver for V3D 3.x/4.x,
"v3d".  I've previously been calling this project "vc5", but given
that I also support a device that's called "vc6" already, I figured it
was time to rename.

I'm quite happy with the ABI.  My only concern as far as merging is
that without GMP support, clients can access each other's memory even
without having a GEM handle.  Authenticated DRI clients on other
platforms have been able to do so, but I would like to prevent that if
possible.  Given that I was planning on having the GMP, I didn't flag
my ioctls as requiring authentication.  If this seems like a problem,
I'd be happy to slap the authentication flag on BO submit, which I
think would be enough to match the security provided by other drivers.
I have a branch for GMP, but it's going to be a while before I finish
it, I think.

Userspace for this driver is currently merged to Mesa but the build is
disabled.  I figure I'll rename its driver to "v3d" and enable it once
this is merged.

Eric Anholt (2):
  dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.
  drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+

 .../bindings/display/brcm,bcm-v3d.txt |  28 +
 Documentation/gpu/drivers.rst |   1 +
 MAINTAINERS   |   9 +
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/v3d/Kconfig   |   9 +
 drivers/gpu/drm/v3d/Makefile  |  18 +
 drivers/gpu/drm/v3d/v3d_bo.c  | 392 ++
 drivers/gpu/drm/v3d/v3d_debugfs.c | 191 +
 drivers/gpu/drm/v3d/v3d_drv.c | 371 ++
 drivers/gpu/drm/v3d/v3d_drv.h | 305 
 drivers/gpu/drm/v3d/v3d_fence.c   |  58 ++
 drivers/gpu/drm/v3d/v3d_gem.c | 671 ++
 drivers/gpu/drm/v3d/v3d_irq.c | 211 ++
 drivers/gpu/drm/v3d/v3d_mmu.c | 122 
 drivers/gpu/drm/v3d/v3d_regs.h| 295 
 drivers/gpu/drm/v3d/v3d_sched.c   | 230 ++
 drivers/gpu/drm/v3d/v3d_trace.h   |  82 +++
 drivers/gpu/drm/v3d/v3d_trace_points.c|   9 +
 include/uapi/drm/v3d_drm.h| 191 +
 20 files changed, 3196 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
 create mode 100644 drivers/gpu/drm/v3d/Kconfig
 create mode 100644 drivers/gpu/drm/v3d/Makefile
 create mode 100644 drivers/gpu/drm/v3d/v3d_bo.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_debugfs.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_drv.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_drv.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_fence.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_gem.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_irq.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_mmu.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_regs.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_sched.c
 create mode 100644 drivers/gpu/drm/v3d/v3d_trace.h
 create mode 100644 drivers/gpu/drm/v3d/v3d_trace_points.c
 create mode 100644 include/uapi/drm/v3d_drm.h

-- 
2.17.0

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

[PATCH 1/2] dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.

[Eric Anholt]

These OpenGL ES GPUs are present in the 7268 and 7278 set top box
chips.

Signed-off-by: Eric Anholt 
---
 .../bindings/display/brcm,bcm-v3d.txt | 28 +++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
new file mode 100644
index ..1c814714de0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
@@ -0,0 +1,28 @@
+Broadcom V3D GPU
+
+Only the Broadcom V3D 3.x and newer GPUs are covered by this binding.
+For V3D 2.x, see brcm,bcm-vc4.txt.
+
+Required properties:
+- compatible:  Should be "brcm,7268-v3d" or "brcm,7278-v3d"
+- reg: Physical base addresses and lengths of the register areas
+- reg-names:   Names for the register areas.  The "hub", "bridge", and "core0"
+ register areas are always required.  The "gca" register area
+ is required if the GCA cache controller is present.
+- interrupts:  The interrupt numbers.  The first interrupt is for the hub,
+ while the following inerrupts are for the cores.
+ See bindings/interrupt-controller/interrupts.txt
+
+Optional properties:
+- clocks:  The core clock the unit runs on
+
+v3d {
+   compatible = "brcm,7268-v3d";
+   reg = <0xf1204000 0x100>,
+ <0xf120 0x4000>,
+ <0xf1208000 0x4000>,
+ <0xf1204100 0x100>;
+   reg-names = "bridge", "hub", "core0", "gca";
+   interrupts = <0 78 4>,
+<0 77 4>;
+};
-- 
2.17.0

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

Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Dongwon Kim]

On Thu, Apr 19, 2018 at 11:14:02AM +0300, Oleksandr Andrushchenko wrote:
> On 04/18/2018 08:01 PM, Dongwon Kim wrote:
> >On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> >>On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> >>>On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
> On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
> >Yeah, I definitely agree on the idea of expanding the use case to the
> >general domain where dmabuf sharing is used. However, what you are
> >targetting with proposed changes is identical to the core design of
> >hyper_dmabuf.
> >
> >On top of this basic functionalities, hyper_dmabuf has driver level
> >inter-domain communication, that is needed for dma-buf remote tracking
> >(no fence forwarding though), event triggering and event handling, extra
> >meta data exchange and hyper_dmabuf_id that represents grefs
> >(grefs are shared implicitly on driver level)
> This really isn't a positive design aspect of hyperdmabuf imo. The core
> code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is
> very simple & clean.
> 
> If there's a clear need later on we can extend that. But for now xen-zcopy
> seems to cover the basic use-case needs, so gets the job done.
> 
> >Also it is designed with frontend (common core framework) + backend
> >(hyper visor specific comm and memory sharing) structure for portability.
> >We just can't limit this feature to Xen because we want to use the same
> >uapis not only for Xen but also other applicable hypervisor, like ACORN.
> See the discussion around udmabuf and the needs for kvm. I think trying to
> make an ioctl/uapi that works for multiple hypervisors is misguided - it
> likely won't work.
> 
> On top of that the 2nd hypervisor you're aiming to support is ACRN. That's
> not even upstream yet, nor have I seen any patches proposing to land linux
> support for ACRN. Since it's not upstream, it doesn't really matter for
> upstream consideration. I'm doubting that ACRN will use the same grant
> references as xen, so the same uapi won't work on ACRN as on Xen anyway.
> >>>Yeah, ACRN doesn't have grant-table. Only Xen supports it. But that is why
> >>>hyper_dmabuf has been architectured with the concept of backend.
> >>>If you look at the structure of backend, you will find that
> >>>backend is just a set of standard function calls as shown here:
> >>>
> >>>struct hyper_dmabuf_bknd_ops {
> >>> /* backend initialization routine (optional) */
> >>> int (*init)(void);
> >>>
> >>> /* backend cleanup routine (optional) */
> >>> int (*cleanup)(void);
> >>>
> >>> /* retreiving id of current virtual machine */
> >>> int (*get_vm_id)(void);
> >>>
> >>> /* get pages shared via hypervisor-specific method */
> >>> int (*share_pages)(struct page **pages, int vm_id,
> >>>int nents, void **refs_info);
> >>>
> >>> /* make shared pages unshared via hypervisor specific method */
> >>> int (*unshare_pages)(void **refs_info, int nents);
> >>>
> >>> /* map remotely shared pages on importer's side via
> >>>  * hypervisor-specific method
> >>>  */
> >>> struct page ** (*map_shared_pages)(unsigned long ref, int vm_id,
> >>>int nents, void **refs_info);
> >>>
> >>> /* unmap and free shared pages on importer's side via
> >>>  * hypervisor-specific method
> >>>  */
> >>> int (*unmap_shared_pages)(void **refs_info, int nents);
> >>>
> >>> /* initialize communication environment */
> >>> int (*init_comm_env)(void);
> >>>
> >>> void (*destroy_comm)(void);
> >>>
> >>> /* upstream ch setup (receiving and responding) */
> >>> int (*init_rx_ch)(int vm_id);
> >>>
> >>> /* downstream ch setup (transmitting and parsing responses) */
> >>> int (*init_tx_ch)(int vm_id);
> >>>
> >>> int (*send_req)(int vm_id, struct hyper_dmabuf_req *req, int 
> >>> wait);
> >>>};
> >>>
> >>>All of these can be mapped with any hypervisor specific implementation.
> >>>We designed backend implementation for Xen using grant-table, Xen event
> >>>and ring buffer communication. For ACRN, we have another backend using 
> >>>Virt-IO
> >>>for both memory sharing and communication.
> >>>
> >>>We tried to define this structure of backend to make it general enough (or
> >>>it can be even modified or extended to support more cases.) so that it can
> >>>fit to other hypervisor cases. Only requirements/expectation on the 
> >>>hypervisor
> >>>are page-level memory sharing and inter-domain communication, which I think
> >>>are standard features of modern hypervisor.
> >>>
> >>>And please review common UAPIs that hyper_dmabuf and xen-zcopy supports. 
> >>>They
> >>>are very 

Re: [PATCH] amdkfd: always select MMU_NOTIFIER

[Felix Kuehling]

On 2018-04-19 06:56 AM, Anders Roxell wrote:
> On 28 March 2018 at 18:04, Christian König  wrote:
>> Am 28.03.2018 um 17:53 schrieb Arnd Bergmann:
>>> Building amdkfd without MMU notifiers is broken:
>>>
>>> In file included from drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c:28:
>>> drivers/gpu/drm/amd/amdkfd/kfd_priv.h:584:22: error: field 'mmu_notifier'
>>> has incomplete type
>>>
>>> This adds the missing 'select MMU_NOTIFIER' line to make it build
>>> cleanly all the time.
>>>
>>> Signed-off-by: Arnd Bergmann 
>>
>> Acked-by: Christian König , but I would wait on
>> what Felix says to that.
> Tested-by: Anders Roxell 
>
> Randy sent the same patch [1] and its still required.
>
> Cheers,
> Anders
> [1] https://patchwork.kernel.org/patch/10340885/
Yes, looks good. I think this probably broke when we relaxed the
dependency on iommuv2.

Reviewed-by: Felix Kuehling 

Regards,
  Felix


>
>>
>>> ---
>>>   drivers/gpu/drm/amd/amdkfd/Kconfig | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig
>>> b/drivers/gpu/drm/amd/amdkfd/Kconfig
>>> index ed2f06c9f346..5a26acb90e19 100644
>>> --- a/drivers/gpu/drm/amd/amdkfd/Kconfig
>>> +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig
>>> @@ -4,6 +4,7 @@
>>> config HSA_AMD
>>> tristate "HSA kernel driver for AMD GPU devices"
>>> +   select MMU_NOTIFIER
>>> depends on DRM_AMDGPU && X86_64
>>> imply AMD_IOMMU_V2
>>> help
>>

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

Re: [DPU PATCH v2 1/2] drm/panel: Add Truly NT35597 panel

[Archit Taneja]

Hi,

On Saturday 14 April 2018 12:55 PM, Abhinav Kumar wrote:

From: Archit Taneja 


You can drop DPU from the subject. Also, you'd need to add
Theirry Reading for panel related patches, and Rob Herring
for an Ack on the DT bindings.

I think you can change the author to yourself. You've had to
make plenty of changes to get this in upstream state. You
can keep my Signed-off-by, though.



Add support for Truly NT35597 panel used
in MSM reference platforms.


You can mention here that the panel supports both single
and dual DSI modes, and that we support only dual-DSI
mode for now.



Changes in v2:
- Renamed panel to truly,nt35597
- Added SPDX license
- Used endpoints instead of custom node
- Renamed and cleaned up power supplies

Signed-off-by: Archit Taneja 
Signed-off-by: Abhinav Kumar 
---
  .../devicetree/bindings/display/truly,nt35597.txt  |  47 ++
  drivers/gpu/drm/panel/Kconfig  |   7 +
  drivers/gpu/drm/panel/Makefile |   1 +
  drivers/gpu/drm/panel/panel-truly-nt35597.c| 597 +
  4 files changed, 652 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/display/truly,nt35597.txt
  create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c

diff --git a/Documentation/devicetree/bindings/display/truly,nt35597.txt 
b/Documentation/devicetree/bindings/display/truly,nt35597.txt
new file mode 100644
index 000..22b6f19
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/truly,nt35597.txt
@@ -0,0 +1,47 @@
+Truly model NT35597 1440x2560 DSI Panel
+
+Required properties:
+- compatible: should be "truly,nt35597"
+- vdda-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply
+- vdispp-supply: phandle of the regulator that provides the supply voltage
+  for positive LCD bias
+- vdispn-supply: phandle of the regulator that provides the supply voltage
+  for negative LCD bias
+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+- mode-gpios: phandle of the gpio for choosing the mode of the display
+  for single DSI or Dual DSI
+  This should be low for dual DSI and high for single DSI mode
+- display-timings: Node for the Panel timings
+


You need to specify the of-graph bindings here. Especially, what port #
corresponds to master DSI, and what # for slave DSI.


+Example:
+
+   dsi@ae94000 {
+   panel@0 {
+   compatible = "truly,nt35597";
+   reg = <0>;
+   vdda-supply = <_l14>;
+   vdispp-supply = <_regulator>;
+   vdispn-supply = <_regulator>;
+   pinctrl-names = "default", "suspend";
+   pinctrl-0 = <_dsi_active>;
+   pinctrl-1 = <_dsi_suspend>;
+
+   reset-gpios = < 6 0>;
+   mode-gpios = < 52 0>;
+   display-timings {
+   timing0: timing-0 {
+   clock-frequency = <268316138>;
+   hactive = <1440>;
+   vactie = <2560>;
+   hfront-porch = <200>;
+   hback-porch = <64>;
+   hsync-len = <32>;
+   vfront-porch = <8>;
+   vback-porch = <7>;
+   vsync-len = <1>;
+   };
+   };
+   };


The example should specify the port too.


+   };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 988048e..9f0c490 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -168,4 +168,11 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
  
+config DRM_PANEL_TRULY_NT35597_WQXGA

+   tristate "Truly WQXGA"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Truly NT35597 WQXGA Dual 
DSI
+ Video Mode panel
  endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 3d2a88d..b5b4b60 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git 

Re: [PATCH v1 2/4] dt-bindings: clock: mediatek: add g3dsys bindings

[Stephen Boyd]

Quoting Sean Wang (2018-04-18 20:50:02)
> On Wed, 2018-04-18 at 20:18 -0700, Stephen Boyd wrote:
> > Quoting sean.w...@mediatek.com (2018-04-18 03:24:54)
> > > From: Sean Wang 
> > > 
> > > Add bindings to g3dsys providing necessary clock and reset control to
> > > Mali-450.
> > > 
> > > Signed-off-by: Sean Wang 
> > > ---
> > >  .../bindings/arm/mediatek/mediatek,g3dsys.txt  | 30 
> > > ++
> > 
> > Why isn't this under bindings/clock/ ?
> > 
> 
> Tons of bindings for clock controller have been present at
> binding/arm/mediatek. g3dsys just have a follow-up to them.
> 
> It's worth another patch moving them all from bindings/arm/mediatek/ to
> bindings/clock/mediatek.
> 
> what's your opinion for either doing it prior to g3dsys binding being
> added or doing it in the future ?
> 

Doing it at a later time is fine. Just wondering why they're all getting
dumped into the arm/ directory.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH v3 2/2] drm/msm/dsi: Use one connector for dual DSI mode

[Archit Taneja]

On Thursday 19 April 2018 01:15 AM, Chandan Uddaraju wrote:

Current DSI driver uses two connectors for dual DSI case even
though we only have one panel. Fix this by implementing one
connector/bridge for dual DSI use case. Use master DSI
controllers to register one connector/bridge.

Changes in V2:
 -Removed Change-Id from the commit text tags.
 -Remove extra parentheses

Changes in V3:
 -None


Reviewed-by: Archit Taneja 



Signed-off-by: Chandan Uddaraju 
---
  drivers/gpu/drm/msm/dsi/dsi.c |   3 +
  drivers/gpu/drm/msm/dsi/dsi.h |   1 +
  drivers/gpu/drm/msm/dsi/dsi_manager.c | 110 --
  3 files changed, 29 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index b744bcc..ff8164c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,6 +208,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}
  
+	if (!msm_dsi_manager_validate_current_config(msm_dsi->id))

+   goto fail;
+
msm_dsi->encoder = encoder;
  
  	msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 01c38f6..c858e8e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -100,6 +100,7 @@ struct msm_dsi {
  void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
  int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
  void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
+bool msm_dsi_manager_validate_current_config(u8 id);
  
  /* msm dsi */

  static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 3bb506b..2a11f82 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -306,67 +306,6 @@ static void dsi_mgr_connector_destroy(struct drm_connector 
*connector)
kfree(dsi_connector);
  }
  
-static void dsi_dual_connector_fix_modes(struct drm_connector *connector)

-{
-   struct drm_display_mode *mode, *m;
-
-   /* Only support left-right mode */
-   list_for_each_entry_safe(mode, m, >probed_modes, head) {
-   mode->clock >>= 1;
-   mode->hdisplay >>= 1;
-   mode->hsync_start >>= 1;
-   mode->hsync_end >>= 1;
-   mode->htotal >>= 1;
-   drm_mode_set_name(mode);
-   }
-}
-
-static int dsi_dual_connector_tile_init(
-   struct drm_connector *connector, int id)
-{
-   struct drm_display_mode *mode;
-   /* Fake topology id */
-   char topo_id[8] = {'M', 'S', 'M', 'D', 'U', 'D', 'S', 'I'};
-
-   if (connector->tile_group) {
-   DBG("Tile property has been initialized");
-   return 0;
-   }
-
-   /* Use the first mode only for now */
-   mode = list_first_entry(>probed_modes,
-   struct drm_display_mode,
-   head);
-   if (!mode)
-   return -EINVAL;
-
-   connector->tile_group = drm_mode_get_tile_group(
-   connector->dev, topo_id);
-   if (!connector->tile_group)
-   connector->tile_group = drm_mode_create_tile_group(
-   connector->dev, topo_id);
-   if (!connector->tile_group) {
-   pr_err("%s: failed to create tile group\n", __func__);
-   return -ENOMEM;
-   }
-
-   connector->has_tile = true;
-   connector->tile_is_single_monitor = true;
-
-   /* mode has been fixed */
-   connector->tile_h_size = mode->hdisplay;
-   connector->tile_v_size = mode->vdisplay;
-
-   /* Only support left-right mode */
-   connector->num_h_tile = 2;
-   connector->num_v_tile = 1;
-
-   connector->tile_v_loc = 0;
-   connector->tile_h_loc = (id == DSI_RIGHT) ? 1 : 0;
-
-   return 0;
-}
-
  static int dsi_mgr_connector_get_modes(struct drm_connector *connector)
  {
int id = dsi_mgr_connector_get_id(connector);
@@ -377,31 +316,15 @@ static int dsi_mgr_connector_get_modes(struct 
drm_connector *connector)
if (!panel)
return 0;
  
-	/* Since we have 2 connectors, but only 1 drm_panel in dual DSI mode,

-* panel should not attach to any connector.
-* Only temporarily attach panel to the current connector here,
-* to let panel set mode to this connector.
+   /*
+* In dual DSI mode, we have one connector that can be
+* attached to the drm_panel.
 */
drm_panel_attach(panel, connector);
num = drm_panel_get_modes(panel);
-   drm_panel_detach(panel);
if (!num)
return 0;
  
-	if (IS_DUAL_DSI()) {

- 

Re: [DPU PATCH v3 1/2] drm/msm/dsi: adjust dsi timing for dual dsi mode

[Archit Taneja]

On Thursday 19 April 2018 01:15 AM, Chandan Uddaraju wrote:

For dual dsi mode, the horizontal timing needs
to be divided by half since both the dsi controllers
will be driving this panel. Adjust the pixel clock and
DSI timing accordingly.


Reviewed-by: Archit Taneja 



Changes in V2:
--Removed Change-Id from the commit text tags.

Changes in V3:
--Instead of adjusting the DRM mode structure, divide
   the clocks and horizontal timings in DSI host just
   before configuring the values.

Signed-off-by: Chandan Uddaraju 
---
  drivers/gpu/drm/msm/dsi/dsi.h |  6 ++--
  drivers/gpu/drm/msm/dsi/dsi_host.c| 55 ---
  drivers/gpu/drm/msm/dsi/dsi_manager.c |  7 +++--
  3 files changed, 52 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a..01c38f6 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -162,7 +162,8 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host 
*host,
  int msm_dsi_host_enable(struct mipi_dsi_host *host);
  int msm_dsi_host_disable(struct mipi_dsi_host *host);
  int msm_dsi_host_power_on(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_shared_timings *phy_shared_timings);
+   struct msm_dsi_phy_shared_timings *phy_shared_timings,
+   bool is_dual_dsi);
  int msm_dsi_host_power_off(struct mipi_dsi_host *host);
  int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
struct drm_display_mode *mode);
@@ -175,7 +176,8 @@ int msm_dsi_host_set_src_pll(struct mipi_dsi_host *host,
struct msm_dsi_pll *src_pll);
  void msm_dsi_host_reset_phy(struct mipi_dsi_host *host);
  void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host *host,
-   struct msm_dsi_phy_clk_request *clk_req);
+   struct msm_dsi_phy_clk_request *clk_req,
+   bool is_dual_dsi);
  void msm_dsi_host_destroy(struct mipi_dsi_host *host);
  int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
struct drm_device *dev);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7a03a94..75d527e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -118,6 +118,7 @@ struct msm_dsi_host {
struct clk *byte_intf_clk;
  
  	u32 byte_clk_rate;

+   u32 pixel_clk_rate;
u32 esc_clk_rate;
  
  	/* DSI v2 specific clocks */

@@ -510,7 +511,7 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -591,7 +592,7 @@ static int dsi_link_clk_enable_v2(struct msm_dsi_host 
*msm_host)
goto error;
}
  
-	ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);

+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
if (ret) {
pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
goto error;
@@ -661,7 +662,7 @@ static void dsi_link_clk_disable(struct msm_dsi_host 
*msm_host)
}
  }
  
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)

+static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host, bool is_dual_dsi)
  {
struct drm_display_mode *mode = msm_host->mode;
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -675,14 +676,28 @@ static int dsi_calc_clk_rate(struct msm_dsi_host 
*msm_host)
}
  
  	pclk_rate = mode->clock * 1000;

+
+   /*
+* For dual DSI mode, the current DRM mode has
+* the complete width of the panel. Since, the complete
+* panel is driven by two DSI controllers, the
+* the clock rates have to be split between
+* the two dsi controllers. Adjust the byte and
+* pixel clock rates for each dsi host accordingly.
+*/
+   if (is_dual_dsi)
+   pclk_rate /= 2;
+
if (lanes > 0) {
msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
} else {
pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
}
+   msm_host->pixel_clk_rate = pclk_rate;
  
-	DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate);

+   DBG("pclk=%d, bclk=%d", msm_host->pixel_clk_rate,
+   msm_host->byte_clk_rate);
  
  	msm_host->esc_clk_rate = clk_get_rate(msm_host->esc_clk);
  
@@ -884,7 +899,7 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool enable,

Re: [PATCH] drm: clarify adjusted_mode documentation for bridges

[Archit Taneja]

On Thursday 19 April 2018 09:20 PM, Philippe CORNU wrote:

Hi Archit & Andrzej,

May I ask you please a short review of this documentation update.
Many thanks
Philippe :-)

On 04/09/2018 05:24 PM, Philippe Cornu wrote:

This patch clarifies the adjusted_mode documentation
for bridges.



Reviewed-by: Archit Taneja 


Signed-off-by: Philippe Cornu 
Signed-off-by: Laurent Pinchart 
---
This patch follows discussions in:
- "drm: clarify adjusted_mode for a bridge connected to a crtc"
https://patchwork.freedesktop.org/patch/206801/
- "drm: bridge: Constify mode arguments to bridge .mode_set() operation"
https://patchwork.freedesktop.org/patch/215449/

   include/drm/drm_bridge.h | 16 
   include/drm/drm_crtc.h   | 11 +++
   2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7d632c6a9214 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -178,6 +178,22 @@ struct drm_bridge_funcs {
 * then this would be _encoder_helper_funcs.mode_set. The display
 * pipe (i.e.  clocks and timing signals) is off when this function is
 * called.
+*
+* The adjusted_mode parameter corresponds to the mode output by the 
CRTC
+* for the first bridge in the chain. It can be different from the mode
+* parameter that contains the desired mode for the connector at the end
+* of the bridges chain, for instance when the first bridge in the chain
+* performs scaling. The adjusted mode is mostly useful for the first
+* bridge in the chain and is likely irrelevant for the other bridges.
+*
+* For atomic drivers the adjusted_mode is the mode stored in
+* _crtc_state.adjusted_mode.
+*
+* NOTE:
+*
+* If a need arises to store and access modes adjusted for other 
locations
+* than the connection between the CRTC and the first bridge, the DRM
+* framework will have to be extended with DRM bridge states.
 */
void (*mode_set)(struct drm_bridge *bridge,
 struct drm_display_mode *mode,
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a2d81d2907a9..65f749a9e9d3 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -134,10 +134,13 @@ struct drm_crtc_state {
 *
 * Internal display timings which can be used by the driver to handle
 * differences between the mode requested by userspace in @mode and what
-* is actually programmed into the hardware. It is purely driver
-* implementation defined what exactly this adjusted mode means. Usually
-* it is used to store the hardware display timings used between the
-* CRTC and encoder blocks.
+* is actually programmed into the hardware.
+*
+* For drivers using drm_bridge, this stores the hardware display 
timings
+* used between the CRTC and the first bridge. For other drivers, the
+* meaning of the adjusted_mode field is purely driver implementation
+* defined information, and will usually be used to store the hardware
+* display timings used between the CRTC and encoder blocks.
 */
struct drm_display_mode adjusted_mode;
   

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

Re: [PATCH] drm/amd/display: Disallow enabling CRTC without primary plane with FB

[Michel Dänzer]

On 2018-04-19 04:38 PM, Harry Wentland wrote:
> On 2018-04-19 03:43 AM, Michel Dänzer wrote:
>> On 2018-04-18 10:26 PM, Harry Wentland wrote:
>>> The below commit
>>>
>>> "drm/atomic: Try to preserve the crtc enabled state in 
>>> drm_atomic_remove_fb, v2"
>>>
>>> introduces a slight behavioral change to rmfb. Instead of disabling a crtc
>>> when the primary plane is disabled, it now preserves it.
>>>
>>> Since DC is currently not equipped to handle this we need to fail such
>>> a commit, otherwise we might see a corrupted screen.
>>
>> How does the caller react to failing such a commit?
> 
> The caller (drm_atomic_remove_fb in this case) will retry with the old 
> behavior and disable the CRTC.

I see, thanks.

FWIW, stopping gdm3 works fine with this patch as well.

Tested-by: Michel Dänzer 


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

Re: [PATCH v2 3/6] drm: of: introduce drm_of_media_bus_fmt

[Rob Herring]

On Tue, Apr 17, 2018 at 8:10 AM, Peter Rosin  wrote:
> Add a central function to parse a node according to the video
> interface binding and get a media bus format.
>
> Start with only supporting a very limited set of a few basic media
> bus formats.
>
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_of.c | 38 ++
>  include/drm/drm_of.h |  7 +++
>  2 files changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 4c191c050e7d..f9473edb60a7 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -212,6 +212,44 @@ int drm_of_encoder_active_endpoint(struct device_node 
> *node,
>  EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
>
>  /*
> + * drm_of_media_bus_fmt - return the media bus format described in the node
> + * @node: device tree node containing the media bus format
> + *
> + * @node is presumably an of-graph endpoint node.
> + *
> + * Return the media bus format, or zero if none is described. Or one of the
> + * standard error codes.
> + */
> +int drm_of_media_bus_fmt(struct device_node *node)

Should use endpoint or ep here instead of node to be clear what node
this function operates on.

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

Re: [DPU PATCH v3 2/2] drm/msm/dsi: Use one connector for dual DSI mode

[Sean Paul]

On Wed, Apr 18, 2018 at 12:45:15PM -0700, Chandan Uddaraju wrote:
> Current DSI driver uses two connectors for dual DSI case even
> though we only have one panel. Fix this by implementing one
> connector/bridge for dual DSI use case. Use master DSI
> controllers to register one connector/bridge.
> 
> Changes in V2:
> -Removed Change-Id from the commit text tags.
> -Remove extra parentheses
> 
> Changes in V3:
> -None
> 
> Signed-off-by: Chandan Uddaraju 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/dsi/dsi.c |   3 +
>  drivers/gpu/drm/msm/dsi/dsi.h |   1 +
>  drivers/gpu/drm/msm/dsi/dsi_manager.c | 110 
> --
>  3 files changed, 29 insertions(+), 85 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> index b744bcc..ff8164c 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -208,6 +208,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
> drm_device *dev,
>   goto fail;
>   }
>  
> + if (!msm_dsi_manager_validate_current_config(msm_dsi->id))
> + goto fail;
> +
>   msm_dsi->encoder = encoder;
>  
>   msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> index 01c38f6..c858e8e 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> @@ -100,6 +100,7 @@ struct msm_dsi {
>  void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
>  int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
>  void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
> +bool msm_dsi_manager_validate_current_config(u8 id);
>  
>  /* msm dsi */
>  static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi)
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
> b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> index 3bb506b..2a11f82 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> @@ -306,67 +306,6 @@ static void dsi_mgr_connector_destroy(struct 
> drm_connector *connector)
>   kfree(dsi_connector);
>  }
>  
> -static void dsi_dual_connector_fix_modes(struct drm_connector *connector)
> -{
> - struct drm_display_mode *mode, *m;
> -
> - /* Only support left-right mode */
> - list_for_each_entry_safe(mode, m, >probed_modes, head) {
> - mode->clock >>= 1;
> - mode->hdisplay >>= 1;
> - mode->hsync_start >>= 1;
> - mode->hsync_end >>= 1;
> - mode->htotal >>= 1;
> - drm_mode_set_name(mode);
> - }
> -}
> -
> -static int dsi_dual_connector_tile_init(
> - struct drm_connector *connector, int id)
> -{
> - struct drm_display_mode *mode;
> - /* Fake topology id */
> - char topo_id[8] = {'M', 'S', 'M', 'D', 'U', 'D', 'S', 'I'};
> -
> - if (connector->tile_group) {
> - DBG("Tile property has been initialized");
> - return 0;
> - }
> -
> - /* Use the first mode only for now */
> - mode = list_first_entry(>probed_modes,
> - struct drm_display_mode,
> - head);
> - if (!mode)
> - return -EINVAL;
> -
> - connector->tile_group = drm_mode_get_tile_group(
> - connector->dev, topo_id);
> - if (!connector->tile_group)
> - connector->tile_group = drm_mode_create_tile_group(
> - connector->dev, topo_id);
> - if (!connector->tile_group) {
> - pr_err("%s: failed to create tile group\n", __func__);
> - return -ENOMEM;
> - }
> -
> - connector->has_tile = true;
> - connector->tile_is_single_monitor = true;
> -
> - /* mode has been fixed */
> - connector->tile_h_size = mode->hdisplay;
> - connector->tile_v_size = mode->vdisplay;
> -
> - /* Only support left-right mode */
> - connector->num_h_tile = 2;
> - connector->num_v_tile = 1;
> -
> - connector->tile_v_loc = 0;
> - connector->tile_h_loc = (id == DSI_RIGHT) ? 1 : 0;
> -
> - return 0;
> -}
> -
>  static int dsi_mgr_connector_get_modes(struct drm_connector *connector)
>  {
>   int id = dsi_mgr_connector_get_id(connector);
> @@ -377,31 +316,15 @@ static int dsi_mgr_connector_get_modes(struct 
> drm_connector *connector)
>   if (!panel)
>   return 0;
>  
> - /* Since we have 2 connectors, but only 1 drm_panel in dual DSI mode,
> -  * panel should not attach to any connector.
> -  * Only temporarily attach panel to the current connector here,
> -  * to let panel set mode to this connector.
> + /*
> +  * In dual DSI mode, we have one connector that can be
> +  * attached to the drm_panel.
>*/
>   drm_panel_attach(panel, connector);
>   num = 

Re: [DPU PATCH v3 2/2] drm/msm/dsi: Use one connector for dual DSI mode

[Sean Paul]

On Wed, Apr 18, 2018 at 12:45:15PM -0700, Chandan Uddaraju wrote:
> Current DSI driver uses two connectors for dual DSI case even
> though we only have one panel. Fix this by implementing one
> connector/bridge for dual DSI use case. Use master DSI
> controllers to register one connector/bridge.
> 
> Changes in V2:
> -Removed Change-Id from the commit text tags.
> -Remove extra parentheses
> 
> Changes in V3:
> -None
> 
> Signed-off-by: Chandan Uddaraju 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/dsi/dsi.c |   3 +
>  drivers/gpu/drm/msm/dsi/dsi.h |   1 +
>  drivers/gpu/drm/msm/dsi/dsi_manager.c | 110 
> --
>  3 files changed, 29 insertions(+), 85 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
> index b744bcc..ff8164c 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -208,6 +208,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
> drm_device *dev,
>   goto fail;
>   }
>  
> + if (!msm_dsi_manager_validate_current_config(msm_dsi->id))
> + goto fail;
> +
>   msm_dsi->encoder = encoder;
>  
>   msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> index 01c38f6..c858e8e 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> @@ -100,6 +100,7 @@ struct msm_dsi {
>  void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
>  int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
>  void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
> +bool msm_dsi_manager_validate_current_config(u8 id);
>  
>  /* msm dsi */
>  static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi)
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
> b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> index 3bb506b..2a11f82 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> @@ -306,67 +306,6 @@ static void dsi_mgr_connector_destroy(struct 
> drm_connector *connector)
>   kfree(dsi_connector);
>  }
>  
> -static void dsi_dual_connector_fix_modes(struct drm_connector *connector)
> -{
> - struct drm_display_mode *mode, *m;
> -
> - /* Only support left-right mode */
> - list_for_each_entry_safe(mode, m, >probed_modes, head) {
> - mode->clock >>= 1;
> - mode->hdisplay >>= 1;
> - mode->hsync_start >>= 1;
> - mode->hsync_end >>= 1;
> - mode->htotal >>= 1;
> - drm_mode_set_name(mode);
> - }
> -}
> -
> -static int dsi_dual_connector_tile_init(
> - struct drm_connector *connector, int id)
> -{
> - struct drm_display_mode *mode;
> - /* Fake topology id */
> - char topo_id[8] = {'M', 'S', 'M', 'D', 'U', 'D', 'S', 'I'};
> -
> - if (connector->tile_group) {
> - DBG("Tile property has been initialized");
> - return 0;
> - }
> -
> - /* Use the first mode only for now */
> - mode = list_first_entry(>probed_modes,
> - struct drm_display_mode,
> - head);
> - if (!mode)
> - return -EINVAL;
> -
> - connector->tile_group = drm_mode_get_tile_group(
> - connector->dev, topo_id);
> - if (!connector->tile_group)
> - connector->tile_group = drm_mode_create_tile_group(
> - connector->dev, topo_id);
> - if (!connector->tile_group) {
> - pr_err("%s: failed to create tile group\n", __func__);
> - return -ENOMEM;
> - }
> -
> - connector->has_tile = true;
> - connector->tile_is_single_monitor = true;
> -
> - /* mode has been fixed */
> - connector->tile_h_size = mode->hdisplay;
> - connector->tile_v_size = mode->vdisplay;
> -
> - /* Only support left-right mode */
> - connector->num_h_tile = 2;
> - connector->num_v_tile = 1;
> -
> - connector->tile_v_loc = 0;
> - connector->tile_h_loc = (id == DSI_RIGHT) ? 1 : 0;
> -
> - return 0;
> -}
> -
>  static int dsi_mgr_connector_get_modes(struct drm_connector *connector)
>  {
>   int id = dsi_mgr_connector_get_id(connector);
> @@ -377,31 +316,15 @@ static int dsi_mgr_connector_get_modes(struct 
> drm_connector *connector)
>   if (!panel)
>   return 0;
>  
> - /* Since we have 2 connectors, but only 1 drm_panel in dual DSI mode,
> -  * panel should not attach to any connector.
> -  * Only temporarily attach panel to the current connector here,
> -  * to let panel set mode to this connector.
> + /*
> +  * In dual DSI mode, we have one connector that can be
> +  * attached to the drm_panel.
>*/
>   drm_panel_attach(panel, connector);
>   num = 

Re: [DPU PATCH v3 1/2] drm/msm/dsi: adjust dsi timing for dual dsi mode

[Sean Paul]

On Wed, Apr 18, 2018 at 12:45:14PM -0700, Chandan Uddaraju wrote:
> For dual dsi mode, the horizontal timing needs
> to be divided by half since both the dsi controllers
> will be driving this panel. Adjust the pixel clock and
> DSI timing accordingly.
> 
> Changes in V2:
> --Removed Change-Id from the commit text tags.
> 
> Changes in V3:
> --Instead of adjusting the DRM mode structure, divide
>   the clocks and horizontal timings in DSI host just
>   before configuring the values.
> 
> Signed-off-by: Chandan Uddaraju 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/dsi/dsi.h |  6 ++--
>  drivers/gpu/drm/msm/dsi/dsi_host.c| 55 
> ---
>  drivers/gpu/drm/msm/dsi/dsi_manager.c |  7 +++--
>  3 files changed, 52 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> index 70d9a9a..01c38f6 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> @@ -162,7 +162,8 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host 
> *host,
>  int msm_dsi_host_enable(struct mipi_dsi_host *host);
>  int msm_dsi_host_disable(struct mipi_dsi_host *host);
>  int msm_dsi_host_power_on(struct mipi_dsi_host *host,
> - struct msm_dsi_phy_shared_timings *phy_shared_timings);
> + struct msm_dsi_phy_shared_timings *phy_shared_timings,
> + bool is_dual_dsi);
>  int msm_dsi_host_power_off(struct mipi_dsi_host *host);
>  int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
>   struct drm_display_mode *mode);
> @@ -175,7 +176,8 @@ int msm_dsi_host_set_src_pll(struct mipi_dsi_host *host,
>   struct msm_dsi_pll *src_pll);
>  void msm_dsi_host_reset_phy(struct mipi_dsi_host *host);
>  void msm_dsi_host_get_phy_clk_req(struct mipi_dsi_host *host,
> - struct msm_dsi_phy_clk_request *clk_req);
> + struct msm_dsi_phy_clk_request *clk_req,
> + bool is_dual_dsi);
>  void msm_dsi_host_destroy(struct mipi_dsi_host *host);
>  int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
>   struct drm_device *dev);
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 7a03a94..75d527e 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -118,6 +118,7 @@ struct msm_dsi_host {
>   struct clk *byte_intf_clk;
>  
>   u32 byte_clk_rate;
> + u32 pixel_clk_rate;
>   u32 esc_clk_rate;
>  
>   /* DSI v2 specific clocks */
> @@ -510,7 +511,7 @@ static int dsi_link_clk_enable_6g(struct msm_dsi_host 
> *msm_host)
>   goto error;
>   }
>  
> - ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);
> + ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
>   if (ret) {
>   pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
>   goto error;
> @@ -591,7 +592,7 @@ static int dsi_link_clk_enable_v2(struct msm_dsi_host 
> *msm_host)
>   goto error;
>   }
>  
> - ret = clk_set_rate(msm_host->pixel_clk, msm_host->mode->clock * 1000);
> + ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
>   if (ret) {
>   pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
>   goto error;
> @@ -661,7 +662,7 @@ static void dsi_link_clk_disable(struct msm_dsi_host 
> *msm_host)
>   }
>  }
>  
> -static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
> +static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host, bool is_dual_dsi)
>  {
>   struct drm_display_mode *mode = msm_host->mode;
>   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
> @@ -675,14 +676,28 @@ static int dsi_calc_clk_rate(struct msm_dsi_host 
> *msm_host)
>   }
>  
>   pclk_rate = mode->clock * 1000;
> +
> + /*
> +  * For dual DSI mode, the current DRM mode has
> +  * the complete width of the panel. Since, the complete
> +  * panel is driven by two DSI controllers, the
> +  * the clock rates have to be split between
> +  * the two dsi controllers. Adjust the byte and
> +  * pixel clock rates for each dsi host accordingly.
> +  */
> + if (is_dual_dsi)
> + pclk_rate /= 2;
> +
>   if (lanes > 0) {
>   msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
>   } else {
>   pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
>   msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
>   }
> + msm_host->pixel_clk_rate = pclk_rate;
>  
> - DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate);
> + DBG("pclk=%d, bclk=%d", msm_host->pixel_clk_rate,
> + msm_host->byte_clk_rate);
>  
>   msm_host->esc_clk_rate = 

Re: [PATCH] drm: clarify adjusted_mode documentation for bridges

[Philippe CORNU]

Hi Archit & Andrzej,

May I ask you please a short review of this documentation update.
Many thanks
Philippe :-)

On 04/09/2018 05:24 PM, Philippe Cornu wrote:
> This patch clarifies the adjusted_mode documentation
> for bridges.
> 
> Signed-off-by: Philippe Cornu 
> Signed-off-by: Laurent Pinchart 
> ---
> This patch follows discussions in:
> - "drm: clarify adjusted_mode for a bridge connected to a crtc"
>https://patchwork.freedesktop.org/patch/206801/
> - "drm: bridge: Constify mode arguments to bridge .mode_set() operation"
>https://patchwork.freedesktop.org/patch/215449/
> 
>   include/drm/drm_bridge.h | 16 
>   include/drm/drm_crtc.h   | 11 +++
>   2 files changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 3270fec46979..7d632c6a9214 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -178,6 +178,22 @@ struct drm_bridge_funcs {
>* then this would be _encoder_helper_funcs.mode_set. The display
>* pipe (i.e.  clocks and timing signals) is off when this function is
>* called.
> +  *
> +  * The adjusted_mode parameter corresponds to the mode output by the 
> CRTC
> +  * for the first bridge in the chain. It can be different from the mode
> +  * parameter that contains the desired mode for the connector at the end
> +  * of the bridges chain, for instance when the first bridge in the chain
> +  * performs scaling. The adjusted mode is mostly useful for the first
> +  * bridge in the chain and is likely irrelevant for the other bridges.
> +  *
> +  * For atomic drivers the adjusted_mode is the mode stored in
> +  * _crtc_state.adjusted_mode.
> +  *
> +  * NOTE:
> +  *
> +  * If a need arises to store and access modes adjusted for other 
> locations
> +  * than the connection between the CRTC and the first bridge, the DRM
> +  * framework will have to be extended with DRM bridge states.
>*/
>   void (*mode_set)(struct drm_bridge *bridge,
>struct drm_display_mode *mode,
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a2d81d2907a9..65f749a9e9d3 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -134,10 +134,13 @@ struct drm_crtc_state {
>*
>* Internal display timings which can be used by the driver to handle
>* differences between the mode requested by userspace in @mode and what
> -  * is actually programmed into the hardware. It is purely driver
> -  * implementation defined what exactly this adjusted mode means. Usually
> -  * it is used to store the hardware display timings used between the
> -  * CRTC and encoder blocks.
> +  * is actually programmed into the hardware.
> +  *
> +  * For drivers using drm_bridge, this stores the hardware display 
> timings
> +  * used between the CRTC and the first bridge. For other drivers, the
> +  * meaning of the adjusted_mode field is purely driver implementation
> +  * defined information, and will usually be used to store the hardware
> +  * display timings used between the CRTC and encoder blocks.
>*/
>   struct drm_display_mode adjusted_mode;
>   
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/rockchip: Disable blending for win0

[Sean Paul]

On Wed, Apr 18, 2018 at 02:53:08PM -0700, Kristian Kristensen wrote:
> On Wed, Apr 18, 2018 at 11:23 AM, Sean Paul  wrote:
> 
> > On Wed, Apr 18, 2018 at 10:31:52AM -0700, Kristian H. Kristensen wrote:
> > > Blending win0 with the background color doesn't seem to work
> > > correctly.
> >
> > Did you come to a conclusion about whether this applies across all Rk
> > vops, or
> > just 3399 big?
> >
> 
> It didn't work on either big or little VOP on 3399, but oddly, 3288 seemed
> to work fine. Either way, what the patch is doing is correct and simpler,
> so I'm not sure it makes sense to try to be more specific about when we
> turn off blending.

Yeah, fair enough. We'll need to revisit if we ever support anything more than
pre-mult/black bg anyways, so

Reviewed-by: Sean Paul 

Sean


> 
> Kristian
> 
> 
> > Sean
> >
> > > We only get the background color, no matter the contents of
> > > the win0 framebuffer.  However, blending pre-multiplied color with the
> > > default opaque black default background color is a no-op, so we can
> > > just disable blending to get the correct result.
> > >
> > > Signed-off-by: Kristian H. Kristensen 
> > > Cc: Sandy Huang 
> > > Cc: Sean Paul 
> > > ---
> > >
> > > v2: Drop CHROMIUM: prefix, rebase on Linus' master
> > >
> > >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 -
> > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > index 53d4afe15278..753a7548da84 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > > @@ -76,6 +76,9 @@
> > >  #define VOP_WIN_GET_YRGBADDR(vop, win) \
> > >   vop_readl(vop, win->base + win->phy->yrgb_mst.offset)
> > >
> > > +#define VOP_WIN_TO_INDEX(vop_win) \
> > > + ((vop_win) - (vop_win)->vop->win)
> > > +
> > >  #define to_vop(x) container_of(x, struct vop, crtc)
> > >  #define to_vop_win(x) container_of(x, struct vop_win, base)
> > >
> > > @@ -708,6 +711,7 @@ static void vop_plane_atomic_update(struct drm_plane
> > *plane,
> > >   dma_addr_t dma_addr;
> > >   uint32_t val;
> > >   bool rb_swap;
> > > + int win_index = VOP_WIN_TO_INDEX(vop_win);
> > >   int format;
> > >
> > >   /*
> > > @@ -777,7 +781,14 @@ static void vop_plane_atomic_update(struct
> > drm_plane *plane,
> > >   rb_swap = has_rb_swapped(fb->format->format);
> > >   VOP_WIN_SET(vop, win, rb_swap, rb_swap);
> > >
> > > - if (fb->format->has_alpha) {
> > > + /*
> > > +  * Blending win0 with the background color doesn't seem to work
> > > +  * correctly. We only get the background color, no matter the
> > contents
> > > +  * of the win0 framebuffer.  However, blending pre-multiplied color
> > > +  * with the default opaque black default background color is a
> > no-op,
> > > +  * so we can just disable blending to get the correct result.
> > > +  */
> > > + if (fb->format->has_alpha && win_index > 0) {
> > >   VOP_WIN_SET(vop, win, dst_alpha_ctl,
> > >   DST_FACTOR_M0(ALPHA_SRC_INVERSE));
> > >   val = SRC_ALPHA_EN(1) | SRC_COLOR_M0(ALPHA_SRC_PRE_MUL) |
> > > --
> > > 2.17.0.484.g0c8726318c-goog
> > >
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >

-- 
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: [DPU PATCH 6/6] drm/msm: remove dsi-staging driver

[Sean Paul]

On Mon, Apr 16, 2018 at 11:22:21AM -0700, Jeykumar Sankaran wrote:
> SDM845 has switched from dsi-staging to dsi driver. Removing
> stale code.
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  .../config/arm64/chromiumos-arm64.flavour.config   |1 -
>  .../arm64/chromiumos-qualcomm.flavour.config   |1 -
>  drivers/gpu/drm/msm/Kconfig|   12 -
>  drivers/gpu/drm/msm/Makefile   |   21 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_catalog.c  |  241 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_catalog.h  |  201 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_clk.h  |  276 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_clk_manager.c  | 1235 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl.c | 2846 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl.h |  623 ---
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw.h  |  752 
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_1_4.c  |  480 ---
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_2_0.c  |  234 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_2_2.c  |   42 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_hw_cmn.c  | 1312 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_ctrl_reg.h |  196 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_defs.h |  579 ---
>  drivers/gpu/drm/msm/dsi-staging/dsi_display.c  | 4221 
> 
>  drivers/gpu/drm/msm/dsi-staging/dsi_display.h  |  556 ---
>  drivers/gpu/drm/msm/dsi-staging/dsi_display_test.c |  114 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_display_test.h |   31 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_drm.c  |  688 
>  drivers/gpu/drm/msm/dsi-staging/dsi_drm.h  |  127 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_hw.h   |   48 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_panel.c| 3321 ---
>  drivers/gpu/drm/msm/dsi-staging/dsi_panel.h|  257 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_phy.c  |  937 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_phy.h  |  235 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw.h   |  260 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw_v2_0.c  |  252 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_phy_hw_v3_0.c  |  447 ---
>  .../gpu/drm/msm/dsi-staging/dsi_phy_timing_calc.c  |  676 
>  .../gpu/drm/msm/dsi-staging/dsi_phy_timing_calc.h  |  144 -
>  .../gpu/drm/msm/dsi-staging/dsi_phy_timing_v2_0.c  |  126 -
>  .../gpu/drm/msm/dsi-staging/dsi_phy_timing_v3_0.c  |  107 -
>  drivers/gpu/drm/msm/dsi-staging/dsi_pwr.c  |  365 --
>  drivers/gpu/drm/msm/dsi-staging/dsi_pwr.h  |   93 -
>  37 files changed, 22057 deletions(-)

Awesome!

Reviewed-by: Sean Paul 



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

[pull] amdgpu drm-next-4.17

[Alex Deucher]

Hi Dave,

A few fixes for 4.17:
- Fix a dark screen issue in DC
- Fix clk/voltage dependency tracking for wattman
- Update SMU interface for vega12

The following changes since commit a10beabba213924d876f2d10ca9351aeab93f58a:

  Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2018-04-13 09:25:21 +1000)

are available in the git repository at:

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

for you to fetch changes up to cc9e992dfb5bb48f59f3fbc1268d3f38d2c86ef3:

  drm/amd/powerplay: header file interface to SMU update (2018-04-19 10:25:06 
-0500)


Harry Wentland (1):
  drm/amd/display: Don't program bypass on linear regamma LUT

Kenneth Feng (1):
  drm/amd/powerplay: header file interface to SMU update

Rex Zhu (1):
  drm/amd/pp: Fix bug voltage can't be OD separately on VI

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c  |  7 ---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 16 ++--
 .../gpu/drm/amd/powerplay/inc/vega12/smu9_driver_if.h|  4 +++-
 3 files changed, 13 insertions(+), 14 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH 5/6] drm/msm: hook up DPU with upstream DSI

[Sean Paul]

On Mon, Apr 16, 2018 at 11:22:20AM -0700, Jeykumar Sankaran wrote:
> Switch DPU from dsi-staging to upstream dsi driver. To make
> the switch atomic, this change includes:
> - remove dpu connector layers
> - clean up dpu connector dependencies in encoder/crtc
> - compile out writeback and display port drivers
> - compile out dsi-staging driver (separate patch submitted to
>   remove the driver)
> - adapt upstream device hierarchy
> 
> Signed-off-by: Jeykumar Sankaran 
> ---
>  .../config/arm64/chromiumos-arm64.flavour.config   |4 +-
>  .../arm64/chromiumos-qualcomm.flavour.config   |4 +-

These files aren't in upstream.



> +
> +struct drm_encoder *dpu_encoder_init(struct drm_device *dev,
> + int drm_enc_mode)
> +{
> + struct dpu_encoder_virt *dpu_enc = NULL;
> +
> + dpu_enc = kzalloc(sizeof(*dpu_enc), GFP_KERNEL);

You should probably use devm_kzalloc.

> + if (!dpu_enc)
> + return ERR_PTR(ENOMEM);
> +
> + drm_encoder_init(dev, _enc->base, _encoder_funcs,
> + drm_enc_mode, NULL);

Check the return value?


> -#ifdef CONFIG_DRM_MSM_DSI_STAGING
>  static void _dpu_kms_initialize_dsi(struct drm_device *dev,
>   struct msm_drm_private *priv,
> - struct dpu_kms *dpu_kms,
> - unsigned max_encoders)
> + struct dpu_kms *dpu_kms)
>  {
> - static const struct dpu_connector_ops dsi_ops = {
> - .post_init =  dsi_conn_post_init,
> - .detect = dsi_conn_detect,
> - .get_modes =  dsi_connector_get_modes,
> - .put_modes =  dsi_connector_put_modes,
> - .mode_valid = dsi_conn_mode_valid,
> - .get_info =   dsi_display_get_info,
> - .set_backlight = dsi_display_set_backlight,
> - .soft_reset   = dsi_display_soft_reset,
> - .pre_kickoff  = dsi_conn_pre_kickoff,
> - .clk_ctrl = dsi_display_clk_ctrl,
> - .set_power = dsi_display_set_power,
> - .get_mode_info = dsi_conn_get_mode_info,
> - .get_dst_format = dsi_display_get_dst_format,
> - .post_kickoff = dsi_conn_post_kickoff
> - };
> - struct msm_display_info info;
> - struct drm_encoder *encoder;
> - void *display, *connector;
> + struct drm_encoder *encoder = NULL;
>   int i, rc;
>  
> - /* dsi */
> - for (i = 0; i < dpu_kms->dsi_display_count &&
> - priv->num_encoders < max_encoders; ++i) {
> - display = dpu_kms->dsi_displays[i];
> - encoder = NULL;
> + /*TODO: Support two independent DSI connectors */
> + encoder = dpu_encoder_init(dev, DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR_OR_NULL(encoder)) {
> + DPU_ERROR("encoder init failed for dsi %d\n", i);

Is i meaningful here? It seems like it's uninitialized...

> + return;
> + }
>  
> - memset(, 0x0, sizeof(info));
> - rc = dsi_display_get_info(, display);
> - if (rc) {
> - DPU_ERROR("dsi get_info %d failed\n", i);
> - continue;
> - }
> + priv->encoders[priv->num_encoders++] = encoder;
>  
> - encoder = dpu_encoder_init(dev, );
> - if (IS_ERR_OR_NULL(encoder)) {
> - DPU_ERROR("encoder init failed for dsi %d\n", i);
> - continue;
> + for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
> + if (!priv->dsi[i]) {
> + DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
> + return;
>   }
>  
> - rc = dsi_display_drm_bridge_init(display, encoder);
> + rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
>   if (rc) {
> - DPU_ERROR("dsi bridge %d init failed, %d\n", i, rc);
> - dpu_encoder_destroy(encoder);
> + DPU_ERROR("modeset_init failed for dsi[%d]\n", i);

Printing rc would be nice here, same for above.

>   continue;
>   }
> -
> - connector = dpu_connector_init(dev,
> - encoder,
> - 0,
> - display,
> - _ops,
> - DRM_CONNECTOR_POLL_HPD,
> - DRM_MODE_CONNECTOR_DSI);
> - if (connector) {
> - priv->encoders[priv->num_encoders++] = encoder;
> - } else {
> - DPU_ERROR("dsi %d connector init failed\n", i);
> - dsi_display_drm_bridge_deinit(display);
> - dpu_encoder_destroy(encoder);
> - }
>   }
>  }
> -#endif
> +
>  
>  #ifdef CONFIG_DRM_MSM_WRITEBACK
>  static 

Re: [[RFC]DPU PATCH 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[Jordan Crouse]

On Wed, Apr 18, 2018 at 05:49:59PM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
> 
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all the control registers
> are being accessed through i2c interface only.
> Also as of now HPD support has not been added to bridge
> chip driver.
> 
> Signed-off-by: Sandeep Panda 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 742 
> ++
>  1 file changed, 742 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> new file mode 100644
> index 000..c798f2f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -0,0 +1,742 @@
> +/* SPDX-License-Identifier: GPL-2.0 */

There should be a copyright here.

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SN_BRIDGE_REVISION_ID 0x2
> +
> +/* Link Training specific registers */
> +#define SN_DEVICE_REV_REG0x08
> +#define SN_REFCLK_FREQ_REG   0x0A
> +#define SN_DSI_LANES_REG 0x10
> +#define SN_DSIA_CLK_FREQ_REG 0x12
> +#define SN_ENH_FRAME_REG 0x5A
> +#define SN_SSC_CONFIG_REG0x93
> +#define SN_DATARATE_CONFIG_REG   0x94
> +#define SN_PLL_ENABLE_REG0x0D
> +#define SN_SCRAMBLE_CONFIG_REG   0x95
> +#define SN_AUX_WDATA0_REG0x64
> +#define SN_AUX_ADDR_19_16_REG0x74
> +#define SN_AUX_ADDR_15_8_REG 0x75
> +#define SN_AUX_ADDR_7_0_REG  0x76
> +#define SN_AUX_LENGTH_REG0x77
> +#define SN_AUX_CMD_REG   0x78
> +#define SN_ML_TX_MODE_REG0x96
> +#define SN_PAGE_SELECT_REG   0xFF
> +#define SN_AUX_RDATA0_REG0x79
> +/* video config specific registers */
> +#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG0x20
> +#define SN_CHA_ACTIVE_LINE_LENGTH_HIGH_REG   0x21
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_LOW_REG 0x24
> +#define SN_CHA_VERTICAL_DISPLAY_SIZE_HIGH_REG0x25
> +#define SN_CHA_HSYNC_PULSE_WIDTH_LOW_REG 0x2C
> +#define SN_CHA_HSYNC_PULSE_WIDTH_HIGH_REG0x2D
> +#define SN_CHA_VSYNC_PULSE_WIDTH_LOW_REG 0x30
> +#define SN_CHA_VSYNC_PULSE_WIDTH_HIGH_REG0x31
> +#define SN_CHA_HORIZONTAL_BACK_PORCH_REG 0x34
> +#define SN_CHA_VERTICAL_BACK_PORCH_REG   0x36
> +#define SN_CHA_HORIZONTAL_FRONT_PORCH_REG0x38
> +#define SN_CHA_VERTICAL_FRONT_PORCH_REG  0x3A
> +#define SN_DATA_FORMAT_REG   0x5B
> +#define SN_COLOR_BAR_CONFIG_REG  0x3C
> +
> +#define DPPLL_CLK_SRC_REFCLK 0
> +#define DPPLL_CLK_SRC_DSICLK 1
> +#define MIN_DSI_CLK_FREQ_MHZ 40
> +
> +enum ti_sn_bridge_ref_clks {
> + SN_REF_CLK_12_MHZ = 0,
> + SN_REF_CLK_19_2_MHZ,
> + SN_REF_CLK_26_MHZ,
> + SN_REF_CLK_27_MHZ,
> + SN_REF_CLK_38_4_MHZ,
> + SN_REF_CLK_MAX,
> +};
> +
> +struct ti_sn_bridge {
> + struct device *dev;
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> + struct device_node *host_node;
> + struct mipi_dsi_device *dsi;
> + /* handle to the connected eDP panel */
> + struct drm_panel *panel;
> + int irq;
> + struct gpio_desc *irq_gpio;
> + /* list of gpios needed to enable the bridge functionality */
> + struct gpio_descs *enable_gpios;
> + unsigned int num_supplies;
> + struct regulator_bulk_data *supplies;
> + struct i2c_client *i2c_client;
> + struct i2c_adapter *ddc;
> + bool power_on;
> + u32 num_modes;
> + struct drm_display_mode curr_mode;
> +};
> +
> +static int ti_sn_bridge_write(struct ti_sn_bridge *pdata, u8 reg, u8 val)
> +{
> + struct i2c_client *client = pdata->i2c_client;
> + u8 buf[2] = {reg, val};
> + struct i2c_msg msg = {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 2,
> + .buf = buf,
> + };
> +
> + if (i2c_transfer(client->adapter, , 1) < 1) {
> + DRM_ERROR("i2c write failed\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int ti_sn_bridge_read(struct ti_sn_bridge *pdata,
> + u8 reg, char *buf, u32 size)
> +{
> + struct i2c_client *client = pdata->i2c_client;
> + struct i2c_msg msg[2] = {
> + {
> + .addr = client->addr,
> + .flags = 0,
> +  

Re: [PATCH] drm/sun4i: Add missing frontend compatibles for A10, A13, A20 and A31

[Maxime Ripard]

On Thu, Apr 19, 2018 at 02:56:38PM +0200, Paul Kocialkowski wrote:
> Although frontend nodes are defined in the device-trees of the
> aforementioned platforms, there are no matching compatibles defined in
> the driver. This makes it impossible to probe the frontend on these
> platforms.
> 
> Adding the appropriate compatibles to the driver fixes the issue.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_frontend.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
> b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> index 85f75046712c..c5a3de11817d 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> @@ -658,6 +658,10 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
>  };
>  
>  const struct of_device_id sun4i_frontend_of_table[] = {
> + { .compatible = "allwinner,sun7i-a10-display-frontend" },
> + { .compatible = "allwinner,sun7i-a13-display-frontend" },
> + { .compatible = "allwinner,sun7i-a20-display-frontend" },
> + { .compatible = "allwinner,sun7i-a31-display-frontend" },

Most of these compatibles are wrong, so it won't really work :)

If you only tested it on the A20, just add it. We didn't add all of
them because there's some slight variations between the generations
that are not yet taken into account.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

[Maarten Lankhorst]

Op 19-04-18 om 13:05 schreef Fengguang Wu:
> Hi Maarten,
>
>> What extra dmesg output do you get when you boot with drm.debug=0x1f ?
>
> Attached is the dmesg with drm.debug=0x1f.
>
> Thanks,
> Fengguang

Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768:

kern  :debug : [   74.880444] [drm:i9xx_get_initial_plane_config [i915]] pipe 
A/primary A with fb: size=1366x768@32, offset=61000, pitch 5504, size 0x408000
kern  :debug : [   74.881187] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x00408000
kern  :debug : [   74.882197] [drm:intel_alloc_initial_plane_obj.isra.126 
[i915]] initial plane fb obj 5efa24f9

kern  :debug : [   74.883532] [drm:i9xx_get_initial_plane_config [i915]] pipe 
B/primary B with fb: size=1280x1024@32, offset=61000, pitch 5504, size 0x56
kern  :debug : [   74.884260] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating 
preallocated stolen object: stolen_offset=0x00061000, 
gtt_offset=0x00061000, size=0x0056
kern  :debug : [   74.885295] 
[drm:i915_gem_object_create_stolen_for_preallocated [i915]] failed to allocate 
stolen space

Which of course fails, but should be an interesting case to handle right. :)

~Maarten

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

Re: [PATCH] drm/amd/display: Disallow enabling CRTC without primary plane with FB

[Harry Wentland]

On 2018-04-19 03:43 AM, Michel Dänzer wrote:
> 
> [ Dropping stable@ (fixes with Cc: stable are picked up for stable
> branches once they land in Linus' tree, there's no point sending them to
> stable@ during review), adding dri-devel ]
> 
> On 2018-04-18 10:26 PM, Harry Wentland wrote:
>> The below commit
>>
>> "drm/atomic: Try to preserve the crtc enabled state in 
>> drm_atomic_remove_fb, v2"
>>
>> introduces a slight behavioral change to rmfb. Instead of disabling a crtc
>> when the primary plane is disabled, it now preserves it.
>>
>> Since DC is currently not equipped to handle this we need to fail such
>> a commit, otherwise we might see a corrupted screen.
> 
> How does the caller react to failing such a commit?

The caller (drm_atomic_remove_fb in this case) will retry with the old behavior 
and disable the CRTC.

Harry

> 
> 
>> This is based on Shirish's previous approach but avoids adding all
>> planes to the new atomic state which leads to a full update in DC for
>> any commit, and is not what we intend.
>>
>> Theoretically DM should be able to deal with states with fully populated 
>> planes,
>> even for simple updates, such as cursor updates. This should still be
>> addressed in the future.
>>
>> Signed-off-by: Harry Wentland 
>> Cc: sta...@vger.kernel.org
>> ---
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 6f92a19bebd6..0bdc6b484bad 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -4683,6 +4683,7 @@ static int dm_update_crtcs_state(struct 
>> amdgpu_display_manager *dm,
>>  struct amdgpu_dm_connector *aconnector = NULL;
>>  struct drm_connector_state *new_con_state = NULL;
>>  struct dm_connector_state *dm_conn_state = NULL;
>> +struct drm_plane_state *new_plane_state = NULL;
>>  
>>  new_stream = NULL;
>>  
>> @@ -4690,6 +4691,13 @@ static int dm_update_crtcs_state(struct 
>> amdgpu_display_manager *dm,
>>  dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
>>  acrtc = to_amdgpu_crtc(crtc);
>>  
>> +new_plane_state = drm_atomic_get_new_plane_state(state, 
>> new_crtc_state->crtc->primary);
>> +
>> +if (new_crtc_state->enable && new_plane_state && 
>> !new_plane_state->fb) {
>> +ret = -EINVAL;
>> +goto fail;
>> +}
>> +
>>  aconnector = 
>> amdgpu_dm_find_first_crtc_matching_connector(state, crtc);
>>  
>>  /* TODO This hack should go away */
>> @@ -4894,7 +4902,7 @@ static int dm_update_planes_state(struct dc *dc,
>>  if (!dm_old_crtc_state->stream)
>>  continue;
>>  
>> -DRM_DEBUG_DRIVER("Disabling DRM plane: %d on DRM crtc 
>> %d\n",
>> +DRM_DEBUG_ATOMIC("Disabling DRM plane: %d on DRM crtc 
>> %d\n",
>>  plane->base.id, 
>> old_plane_crtc->base.id);
>>  
>>  if (!dc_remove_plane_from_context(
>>
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v2] drm/sun4i: add lvds mode_valid function

[Giulio Benetti]

Hi everybody,

Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto:

On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman
 wrote:

Hello Giulio,

this patch breaks LVDS output on A83T. Without it, modesetting works,
with it there's no output.

Some more info below...

On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:

mode_valid function is missing for lvds.

Add it making it pointed by encoder helper functions.

Signed-off-by: Giulio Benetti 
---
  drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 ++
  1 file changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index be3f14d..b4c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
*encoder)
   }
  }

+static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct drm_encoder 
*crtc,
+   const struct 
drm_display_mode *mode)
+{
+ struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
+ struct sun4i_tcon *tcon = lvds->tcon;
+ u32 hsync = mode->hsync_end - mode->hsync_start;
+ u32 vsync = mode->vsync_end - mode->vsync_start;
+ unsigned long rate = mode->clock * 1000;
+ long rounded_rate;
+
+ DRM_DEBUG_DRIVER("Validating modes...\n");
+
+ if (hsync < 1)
+ return MODE_HSYNC_NARROW;
+
+ if (hsync > 0x3ff)
+ return MODE_HSYNC_WIDE;
+
+ if ((mode->hdisplay < 1) || (mode->htotal < 1))
+ return MODE_H_ILLEGAL;
+
+ if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
+ return MODE_BAD_HVALUE;
+
+ DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
+
+ if (vsync < 1)
+ return MODE_VSYNC_NARROW;
+
+ if (vsync > 0x3ff)
+ return MODE_VSYNC_WIDE;
+
+ if ((mode->vdisplay < 1) || (mode->vtotal < 1))
+ return MODE_V_ILLEGAL;
+
+ if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
+ return MODE_BAD_VVALUE;
+
+ DRM_DEBUG_DRIVER("Vertical parameters OK\n");
+
+ tcon->dclk_min_div = 7;
+ tcon->dclk_max_div = 7;


Why would validation function change any state anywhere?


+ rounded_rate = clk_round_rate(tcon->dclk, rate);


The issue is here, on A83T TBS A711 tablet, I get...

sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 htotal=1384
   vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142


+ if (rounded_rate < rate)
+ return MODE_CLOCK_LOW;
+
+ if (rounded_rate > rate)
+ return MODE_CLOCK_HIGH;


... while the previous conditions require an exact match for some reason.

But HW works fine without an exact rate match. Why is exact match required here?


This thread might provide some more info, though we could never get an
agreement.

https://patchwork.kernel.org/patch/9446385/


Thanks for pointing that Thread ChenYu.
So the only chance is to trim frequency according to encoder capabilities.
I agree to block when encoder can't provide frequency specified,
otherwise you could drive you panel at the near the lowest(highest)
frequency and get out of limits for a few without knowing it.

Best regards

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642



ChenYu



thank you,
   Ondrej


+ DRM_DEBUG_DRIVER("Clock rate OK\n");
+
+ return MODE_OK;
+}
+
  static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
   .disable= sun4i_lvds_encoder_disable,
   .enable = sun4i_lvds_encoder_enable,
+ .mode_valid = sun4i_lvds_encoder_mode_valid,
  };

  static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {

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




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

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Hi,

On 05-04-18 15:26, Daniel Vetter wrote:

On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede  wrote:

Hi,


On 05-04-18 09:14, Daniel Vetter wrote:


On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote:


Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range
passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try
and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to
fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).

Signed-off-by: Hans de Goede 



I think this is worth a shot. The only explanation I can think of why the
GOP could get away with this and still follow the w/a is if it doesn't
have a 1:1 mapping between GGTT and stolen.



My guess is that the GOP does not care about the w/a because the w/a
states that the command-streamers sometimes do a spurious flush (write)
to the first page, and the command-streamers are not used until much
later, so the GOP is probably ignoring the w/a all together.

At least that is my theory.


Atm we do not know whether the GOP actually implements the wa or not.
That it doesn't care is just a conjecture, but we have no proof. On
previous platforms the 1:1 mapping did hold, but there's no
fundamental reason why it sitll does.


Right.


Atm we hardcode that
assumption in intel_alloc_initial_plane_obj by passing the base_aligned as
both the stolen_offset and the gtt_offset (but it's only the gtt_offset
really). And since we're not re-writing the ptes it's not noticeable.

I think to decide whether this is the right approach we should
double-check whether that 1:1 assumption really holds true: Either read
back the ggtt ptes and check their addresses (but iirc on some platforms
their write-only, readback doesn't work), or we also rewrite the ptes
again for preallocated stuff, like when binding a normal object into the
gtt. If either of these approaches confirms that those affected gen8+
machines still use the 1:1 mapping, then I'm happy to put my r-b on this
patch. If not, well then we at least know what to fix: We need to read out
the real stolen_offset, instead of making assumptions.



I'm happy to give this a try on one or more affected machines, I can e.g.
try this on both a skylake desktop and a cherry-trail based tablet.

But I'm clueless about the whole PTE stuff, so I'm going to need someone
to provide me with a patch following either approach. If readback of the
PTEs works on skylake / cherrytrail I guess that would be the best way.

Note to test this I'm currently booting the kernel with the machine's
UEFI vendor logo still being displayed when efifb kicks in. I've added:
"fbcon=vc:2-62" to the kernel commandline to make fbcon not bind to
VC0 / VC1, so that the framebuffer contents stays intact, combined with
the patch we are discussing now, this makes the vendor logo stay on
the screen all the way till GDM loads, which looks rather nice actually :)

And on shutdown we fall back to the original framebuffer and the vendor
logo is back again. I cannot see any corruption in the display at either
boot or shutdown time.


It shouldn't matter whether efifb takes over or not, it's still the
GOP's framebuffer we're taking over. Different content for sure, logo
is gone, but we only care about which pages we're using.

Wrt the code:
- (Re)binding happens by calling i915_vma_bind, if you put a call to
that at the end of the stolen_preallocated functions you should get
that. Ofc needs the logo still there so you can see it jump/get
mangled.
- GGTT PTEs for gen8+ are written through e.g. gen8_ggttt_insert_page
or gen8_ggtt_insert_entries (which takes the vma). Since we only care
about 

Re: [v2] drm/sun4i: add lvds mode_valid function

[Chen-Yu Tsai]

On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman
 wrote:
> Hello Giulio,
>
> this patch breaks LVDS output on A83T. Without it, modesetting works,
> with it there's no output.
>
> Some more info below...
>
> On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:
>> mode_valid function is missing for lvds.
>>
>> Add it making it pointed by encoder helper functions.
>>
>> Signed-off-by: Giulio Benetti 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 
>> ++
>>  1 file changed, 55 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
>> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
>> index be3f14d..b4c 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
>> @@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
>> *encoder)
>>   }
>>  }
>>
>> +static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct 
>> drm_encoder *crtc,
>> +   const struct 
>> drm_display_mode *mode)
>> +{
>> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
>> + struct sun4i_tcon *tcon = lvds->tcon;
>> + u32 hsync = mode->hsync_end - mode->hsync_start;
>> + u32 vsync = mode->vsync_end - mode->vsync_start;
>> + unsigned long rate = mode->clock * 1000;
>> + long rounded_rate;
>> +
>> + DRM_DEBUG_DRIVER("Validating modes...\n");
>> +
>> + if (hsync < 1)
>> + return MODE_HSYNC_NARROW;
>> +
>> + if (hsync > 0x3ff)
>> + return MODE_HSYNC_WIDE;
>> +
>> + if ((mode->hdisplay < 1) || (mode->htotal < 1))
>> + return MODE_H_ILLEGAL;
>> +
>> + if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
>> + return MODE_BAD_HVALUE;
>> +
>> + DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
>> +
>> + if (vsync < 1)
>> + return MODE_VSYNC_NARROW;
>> +
>> + if (vsync > 0x3ff)
>> + return MODE_VSYNC_WIDE;
>> +
>> + if ((mode->vdisplay < 1) || (mode->vtotal < 1))
>> + return MODE_V_ILLEGAL;
>> +
>> + if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
>> + return MODE_BAD_VVALUE;
>> +
>> + DRM_DEBUG_DRIVER("Vertical parameters OK\n");
>> +
>> + tcon->dclk_min_div = 7;
>> + tcon->dclk_max_div = 7;
>
> Why would validation function change any state anywhere?
>
>> + rounded_rate = clk_round_rate(tcon->dclk, rate);
>
> The issue is here, on A83T TBS A711 tablet, I get...
>
> sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 htotal=1384
>   vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142
>
>> + if (rounded_rate < rate)
>> + return MODE_CLOCK_LOW;
>> +
>> + if (rounded_rate > rate)
>> + return MODE_CLOCK_HIGH;
>
> ... while the previous conditions require an exact match for some reason.
>
> But HW works fine without an exact rate match. Why is exact match required 
> here?

This thread might provide some more info, though we could never get an
agreement.

https://patchwork.kernel.org/patch/9446385/

ChenYu

>
> thank you,
>   Ondrej
>
>> + DRM_DEBUG_DRIVER("Clock rate OK\n");
>> +
>> + return MODE_OK;
>> +}
>> +
>>  static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
>>   .disable= sun4i_lvds_encoder_disable,
>>   .enable = sun4i_lvds_encoder_enable,
>> + .mode_valid = sun4i_lvds_encoder_mode_valid,
>>  };
>>
>>  static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/6] drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels

[Maxime Ripard]

Hi,

On Thu, Apr 19, 2018 at 05:32:22PM +0800, Chen-Yu Tsai wrote:
> From: Jonathan Liu 
> 
> The hardware supports dithering on TCON channel 0 which is used for LCD
> panels.
> 
> Dithering is a method of approximating a color from a mixture of other
> colors when the required color isn't available. It reduces color
> banding artifacts that can be observed when displaying gradients
> (e.g. grayscale gradients). This may occur when the image that needs
> to be displayed is 24-bit but the LCD panel is a lower bit depth and
> does not perform dithering on its own.
> 
> Signed-off-by: Jonathan Liu 
> [w...@csie.org: check display_info.bpc first; handle LVDS and MIPI DSI]
> Signed-off-by: Chen-Yu Tsai 
> ---
> 
> Hi Maxime,
> 
> The dithering parameters used here are different from the ones you used
> in your MIPI DSI series. You might want to check if it still works for
> you.
> 
> ---
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 63 +-
>  1 file changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 2bd53ef7d4b8..827518f4790e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -12,6 +12,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -276,8 +277,59 @@ static void sun4i_tcon0_mode_set_common(struct 
> sun4i_tcon *tcon,
>SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
>  }
>  
> +static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon,
> +const struct drm_connector 
> *connector)
> +{
> + u32 bus_format = 0;
> + u32 val = 0;
> +
> + /* XXX Would this ever happen? */
> + if (!connector)
> + return;
> +
> + /*
> +  * FIXME: Undocumented bits
> +  *
> +  * The whole dithering process and these parameters are not
> +  * explained in the vendor documents or BSP kernel code.
> +  */
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PR_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PG_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PB_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LR_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LG_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LB_REG, 0x);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL0_REG, 0x0101);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL1_REG, 0x1515);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL2_REG, 0x5757);
> + regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL3_REG, 0x7f7f);
> +
> + /* Do dithering if panel only supports 6 bits per color */
> + if (connector->display_info.bpc == 6)
> + val |= SUN4I_TCON0_FRM_CTL_EN;
> +
> + if (connector->display_info.num_bus_formats == 1)
> + bus_format = connector->display_info.bus_formats[0];
> +
> + /* Check the connection format */
> + switch (bus_format) {
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + /* R and B components are only 5 bits deep */
> + val |= SUN4I_TCON0_FRM_CTL_MODE_R;
> + val |= SUN4I_TCON0_FRM_CTL_MODE_B;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + /* Fall through: enable dithering */
> + val |= SUN4I_TCON0_FRM_CTL_EN;
> + break;
> + }
> +
> + /* Write dithering settings */
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_CTL_REG, val);
> +}
> +
>  static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
> -  struct drm_encoder *encoder,
> +  const struct drm_encoder *encoder,

The whole serie looks good, but that should probbaly be part of the
first patch?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

[PATCH] drm/stm: ltdc: fix warnings in ltdc_plane_create()

[Philippe Cornu]

"make C=1" returns 2 warnings in ltdc_plane_create()
("Using plain integer as NULL pointer"). This patch
fixes them.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/ltdc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 616191fe98ae..d997a6014d6c 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -860,13 +860,13 @@ static struct drm_plane *ltdc_plane_create(struct 
drm_device *ddev,
 
plane = devm_kzalloc(dev, sizeof(*plane), GFP_KERNEL);
if (!plane)
-   return 0;
+   return NULL;
 
ret = drm_universal_plane_init(ddev, plane, possible_crtcs,
   _plane_funcs, formats, nb_fmt,
   NULL, type, NULL);
if (ret < 0)
-   return 0;
+   return NULL;
 
drm_plane_helper_add(plane, _plane_helper_funcs);
 
-- 
2.15.1

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

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

[Giulio Benetti]

Hi,

Il 19/04/2018 14:45, Chen-Yu Tsai ha scritto:

On Thu, Apr 19, 2018 at 8:31 PM, Giulio Benetti
 wrote:

Hi,

Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:


This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.



Judging from the code, the real vendor should be CDTech.
Take a look at their website:
http://www.cdtech-lcd.com/en/standardscreen.html

I point you my patch for inserting another similar panel:
https://patchwork.freedesktop.org/patch/211914/

Maybe it would make sense to use CDTech as the vendor,
because maybe Bananapi resells only it.
Or maybe it is a custom panel done for them,
but the same is for other panels I've submitted patches.
Micronova srl custom, but vendor is CDTech.

What do you think?


That might be true. But for people without access to the vendors,
this is horribly hard to figure out. People are only going to look
at whatever marking there is on the LCD panel, and whatever the
seller says. This panel has the model number stickered on, but the
PCB attached to it only has the Banana Pi logo.


Ah ok, my fault, I didn't see it has a PCB attached with Banana Pi logo.
Also it makes a lot of sense what you say about people looking for display.



And given it's a custom piece, probably OEM or ODM, the real
manufacturer matters less. You don't mention "Foxconn" as the
vendor of the iPhone, do you?


:) that's right.

Best regards

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642



ChenYu



--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642




This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.

Signed-off-by: Chen-Yu Tsai 
---
   .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
   drivers/gpu/drm/panel/panel-simple.c  | 25 +++
   2 files changed, 32 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt

diff --git
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-ct16"
+
+This binding is compatible with the simple-panel binding, which is
specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
 },
   };
   +static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 40,
+   .hsync_end = 800 + 40 + 48,
+   .htotal = 800 + 40 + 48 + 40,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 3,
+   .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+   .modes = _s070wv20_ct16_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+};
+
   static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
 {
 .clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[]
= {
 }, {
 .compatible = "avic,tm070ddh03",
 .data = _tm070ddh03,
+   }, {
+   .compatible = "bananapi,s070wv20-ct16",
+   .data = _s070wv20_ct16,
 }, {
 .compatible = "boe,nv101wxmn51",
 .data = _nv101wxmn51,






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




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

Re: [PATCH] drm/rockchip: vop: fixup linebuffer mode calc error

[Sandy Huang]

在 2018/4/17 19:14, Heiko Stuebner 写道:

Hi Sandy,

Am Dienstag, 17. April 2018, 12:15:07 CEST schrieb Sandy Huang:

When video width is bigger than 3840 the linebuffer mode
should be LB_YUV_3840X5.


Can you explain that a bit better?

I.e. when looking at the code, the very first check is width > 2560.

So it seems your change targets some YUV mode with width > 3840
which should be mentioned in the commit message, so people like
me don't scratch their head in confusion ;-)

Similarly that check is actually width > 1280 to set LB_YUV_3840X5,
so I guess you're actually wanting any YUV mode bigger than
1280px should use LB_YUV_3840X5?


Heiko



Thanks heiko,
I will make more description for this path at next version.


Signed-off-by: Sandy Huang 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e..3e7501b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -332,7 +332,7 @@ static inline int scl_vop_cal_lb_mode(int width, bool 
is_yuv)
  
  	if (width > 2560)

lb_mode = LB_RGB_3840X2;
-   else if (width > 1920)
+   else if (!is_yuv && width > 1920)
lb_mode = LB_RGB_2560X4;
else if (!is_yuv)
lb_mode = LB_RGB_1920X5;









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

[PATCH] drm/sun4i: Add missing frontend compatibles for A10, A13, A20 and A31

[Paul Kocialkowski]

Although frontend nodes are defined in the device-trees of the
aforementioned platforms, there are no matching compatibles defined in
the driver. This makes it impossible to probe the frontend on these
platforms.

Adding the appropriate compatibles to the driver fixes the issue.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 85f75046712c..c5a3de11817d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -658,6 +658,10 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
 };
 
 const struct of_device_id sun4i_frontend_of_table[] = {
+   { .compatible = "allwinner,sun7i-a10-display-frontend" },
+   { .compatible = "allwinner,sun7i-a13-display-frontend" },
+   { .compatible = "allwinner,sun7i-a20-display-frontend" },
+   { .compatible = "allwinner,sun7i-a31-display-frontend" },
{ .compatible = "allwinner,sun8i-a33-display-frontend" },
{ }
 };
-- 
2.16.3

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

Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Laurent Pinchart]

Hi Philippe,

On Thursday, 19 April 2018 15:41:20 EEST Philippe CORNU wrote:
> On 04/19/2018 01:09 PM, Laurent Pinchart wrote:
> > On Thursday, 19 April 2018 12:31:15 EEST Philippe CORNU wrote:
> >> On 04/19/2018 10:11 AM, Laurent Pinchart wrote:
> >>> On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote:
>  Add the 3 optional power supplies using the exact description
>  found in the document named
>  "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> 
>  Signed-off-by: Philippe Cornu 
>  ---
> 
>  Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
>  diff --git
>  a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>  b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index
>  56a3e68ccb80..cf53678fe574 100644
>  --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>  +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>  @@ -8,6 +8,9 @@ Optional properties:
>   - interrupts-extended or interrupt-parent + interrupts: describe
> the interrupt line used to inform the host about hotplug 
>  events.
>   - reset-gpios: OF device-tree gpio specification for RST_N pin.
>  +- iovcc-supply: I/O supply voltage (1.8V or 3.3V, 
>  host-dependent).
>  +- avcc12-supply: TMDS analog supply voltage (1.2V).
>  +- cvcc12-supply: Digital core supply voltage (1.2V).
> >>>
> >>> It seems that the AVCC12 and CVCC12 power supplies are usually derived
> >>> from the same source. How about starting with one DT property for both,
> >>> and adding a second one later if needed ?
> >>
> >> Well, I do not know what is the best. Here I took the description from
> >> the documentation, and to allow all possible board configurations, I
> >> added these supplies as "optional" properties: if there is only one 1v2
> >> regulator on the board, the dt will contain only avcc12 or cvcc12 and
> >> everything will work fine (we will have a dummy regulator for the
> >> missing optional 1v2 reg), if both regulators are there for any reasons
> >> (stability, noise, whatever...) then both entries will be in the dt.
> >>
> >> If you confirm you prefer a single 1v2 supply (named for instance
> >> "vcc12-supply") then I will do :-)
> > 
> > Please see https://lists.freedesktop.org/archives/dri-devel/2018-April/
> > 172400.html (and the messages that lead to it) and https://
> > lists.freedesktop.org/archives/dri-devel/2018-March/170763.html.
> 
> Thanks for this discussion thread.
> 
> On my side, I found "CVCC12 and AVCC12 can be derived from the same 
> power source" written with a small font (august 2016 datasheet p13) so 
> then your advice is clearly what we have to do :-)
> I will add this info in v2 too.

I have seen that too. While the datasheet only says that the two supplies 
*can* be derived from the same power source, I expect that to be the case in 
practice for a really vast majority of cases (I wouldn't be surprised to never 
hear of a system using two different supplies). That's why I think starting 
with one supply would be better.

> Optional subnodes:
> 
>   - video input: this subnode can contain a video input port node

-- 
Regards,

Laurent Pinchart



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

[PATCH v5 0/2] Enabling content-type setting for HDMI displays.

[StanLis]

From: Stanislav Lisovskiy 

Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c|  4 +++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 9 files changed, 107 insertions(+)

-- 
2.17.0

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

[PATCH v5 1/2] drm: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 7 files changed, 101 insertions(+)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..a91c9211b8d6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   state->content_type = val & 3;
+   state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct 

Re: [PATCH v5 1/2] drm: content-type property for HDMI connector

[Hans Verkuil]

On 04/19/18 14:38, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
> 
> v2:
>  * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
> 
> v3:
>  * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
> 
> v4:
>  * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
> 
> v5:
>  * Moved patch revision's description to commit messages.
> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c | 17 ++
>  drivers/gpu/drm/drm_connector.c  | 51 
>  drivers/gpu/drm/drm_edid.c   |  2 ++
>  include/drm/drm_connector.h  | 18 ++
>  include/drm/drm_mode_config.h|  5 +++
>  include/uapi/drm/drm_mode.h  |  7 
>  7 files changed, 101 insertions(+)
> 
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 6b28b014cb7d..a91c9211b8d6 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property 
> to suggest an X offset for a connector
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest 
> an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
> ""Cinema"", ""Game"" }",Connector,TBD
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7d25c42f22db..479499f5848e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->link_status = val;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio = val;
> + } else if (property == config->content_type_property) {
> + /*
> +  * Lowest two bits of content_type property control
> +  * content_type, bit 2 controls itc bit.
> +  * It was decided to have a single property called
> +  * content_type, instead of content_type and itc.
> +  */
> + state->content_type = val & 3;
> + state->it_content = val >> 2;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
>   } else if (property == connector->content_protection_property) {
> @@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->link_status;
>   } else if (property == config->aspect_ratio_property) {
>   *val = state->picture_aspect_ratio;
> + } else if (property == config->content_type_property) {
> + /*
> +  * Lowest two bits of content_type property control
> +  * content_type, bit 2 controls itc bit.
> +  * It was decided to have a single property called
> +  * content_type, instead of content_type and itc.
> +  */
> + *val = state->content_type | (state->it_content << 2);
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
>   } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b3cde897cd80..757a0712f7c1 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c

Re: [PATCH v5 2/2] i915: content-type property for HDMI connector

[Hans Verkuil]

On 04/19/18 14:38, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added encoding of drm content_type property from drm_connector_state
> within AVI infoframe in order to properly handle external HDMI TV
> content-type setting.
> 
> This requires also manipulationg ITC bit, as stated in
> HDMI spec.
> 
> v2:
>  * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
> 
> v3:
>  * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
> 
> v4:
>  * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
> 
> v5:
>  * Moved patch revision's description to commit messages.
> 
> Signed-off-by: Stanislav Lisovskiy 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/gpu/drm/i915/intel_atomic.c | 2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c   | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 40285d1b91b7..96a42eb457c5 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct 
> drm_connector *conn,
>   if (new_conn_state->force_audio != old_conn_state->force_audio ||
>   new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
>   new_conn_state->base.picture_aspect_ratio != 
> old_conn_state->base.picture_aspect_ratio ||
> + new_conn_state->base.content_type != 
> old_conn_state->base.content_type ||
> + new_conn_state->base.it_content != old_conn_state->base.it_content 
> ||
>   new_conn_state->base.scaling_mode != 
> old_conn_state->base.scaling_mode)
>   crtc_state->mode_changed = true;
>  
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ee929f31f7db..078200908b7a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>  
> intel_hdmi->rgb_quant_range_selectable,
>  is_hdmi2_sink);
>  
> + frame.avi.content_type = connector->state->content_type;
> + frame.avi.itc = connector->state->it_content;
> +
>   /* TODO: handle pixel repetition for YCBCR420 outputs */
>   intel_write_infoframe(encoder, crtc_state, );
>  }
> @@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi 
> *intel_hdmi, struct drm_connector *c
>   intel_attach_force_audio_property(connector);
>   intel_attach_broadcast_rgb_property(connector);
>   intel_attach_aspect_ratio_property(connector);
> + drm_connector_attach_content_type_property(connector);
>   connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  }
>  
> 

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

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

[Chen-Yu Tsai]

On Thu, Apr 19, 2018 at 8:31 PM, Giulio Benetti
 wrote:
> Hi,
>
> Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:
>>
>> This panel is marketed as Banana Pi 7" LCD display. On the back is
>> a sticker denoting the model name S070WV20-CT16.
>
>
> Judging from the code, the real vendor should be CDTech.
> Take a look at their website:
> http://www.cdtech-lcd.com/en/standardscreen.html
>
> I point you my patch for inserting another similar panel:
> https://patchwork.freedesktop.org/patch/211914/
>
> Maybe it would make sense to use CDTech as the vendor,
> because maybe Bananapi resells only it.
> Or maybe it is a custom panel done for them,
> but the same is for other panels I've submitted patches.
> Micronova srl custom, but vendor is CDTech.
>
> What do you think?

That might be true. But for people without access to the vendors,
this is horribly hard to figure out. People are only going to look
at whatever marking there is on the LCD panel, and whatever the
seller says. This panel has the model number stickered on, but the
PCB attached to it only has the Banana Pi logo.

And given it's a custom piece, probably OEM or ODM, the real
manufacturer matters less. You don't mention "Foxconn" as the
vendor of the iPhone, do you?

ChenYu

>
> --
> Giulio Benetti
> CTO
>
> MICRONOVA SRL
> Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
> Tel. 049/8931563 - Fax 049/8931346
> Cod.Fiscale - P.IVA 02663420285
> Capitale Sociale € 26.000 i.v.
> Iscritta al Reg. Imprese di Padova N. 02663420285
> Numero R.E.A. 258642
>
>
>>
>> This is a 7" 800x480 panel connected through a 24-bit RGB interface.
>> However the panel only does 262k colors.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>   .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
>>   drivers/gpu/drm/panel/panel-simple.c  | 25 +++
>>   2 files changed, 32 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>> new file mode 100644
>> index ..2ec35ce36e9a
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
>> @@ -0,0 +1,7 @@
>> +Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
>> +
>> +Required properties:
>> +- compatible: should be "bananapi,s070wv20-ct16"
>> +
>> +This binding is compatible with the simple-panel binding, which is
>> specified
>> +in simple-panel.txt in this directory.
>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>> b/drivers/gpu/drm/panel/panel-simple.c
>> index cbf1ab404ee7..9bc037f74d6c 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
>> },
>>   };
>>   +static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
>> +   .clock = 3,
>> +   .hdisplay = 800,
>> +   .hsync_start = 800 + 40,
>> +   .hsync_end = 800 + 40 + 48,
>> +   .htotal = 800 + 40 + 48 + 40,
>> +   .vdisplay = 480,
>> +   .vsync_start = 480 + 13,
>> +   .vsync_end = 480 + 13 + 3,
>> +   .vtotal = 480 + 13 + 3 + 29,
>> +};
>> +
>> +static const struct panel_desc bananapi_s070wv20_ct16 = {
>> +   .modes = _s070wv20_ct16_mode,
>> +   .num_modes = 1,
>> +   .bpc = 6,
>> +   .size = {
>> +   .width = 154,
>> +   .height = 86,
>> +   },
>> +};
>> +
>>   static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
>> {
>> .clock = 71900,
>> @@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[]
>> = {
>> }, {
>> .compatible = "avic,tm070ddh03",
>> .data = _tm070ddh03,
>> +   }, {
>> +   .compatible = "bananapi,s070wv20-ct16",
>> +   .data = _s070wv20_ct16,
>> }, {
>> .compatible = "boe,nv101wxmn51",
>> .data = _nv101wxmn51,
>>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Philippe CORNU]

Hi Laurent,


On 04/19/2018 01:09 PM, Laurent Pinchart wrote:
> Hi Philippe,
> 
> On Thursday, 19 April 2018 12:31:15 EEST Philippe CORNU wrote:
>> On 04/19/2018 10:11 AM, Laurent Pinchart wrote:
>>> On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote:
>>>
 Add the 3 optional power supplies using the exact description
 found in the document named
 "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".

 Signed-off-by: Philippe Cornu 
 ---

Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
1 file changed, 3 insertions(+)

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
 b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index
 56a3e68ccb80..cf53678fe574 100644
 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
 @@ -8,6 +8,9 @@ Optional properties:
- interrupts-extended or interrupt-parent + interrupts: describe
  the interrupt line used to inform the host about hotplug 
 events.
- reset-gpios: OF device-tree gpio specification for RST_N pin.
 +  - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent).
 +  - avcc12-supply: TMDS analog supply voltage (1.2V).
 +  - cvcc12-supply: Digital core supply voltage (1.2V).
>>>
>>> It seems that the AVCC12 and CVCC12 power supplies are usually derived
>>> from the same source. How about starting with one DT property for both,
>>> and adding a second one later if needed ?
>>
>> Well, I do not know what is the best. Here I took the description from
>> the documentation, and to allow all possible board configurations, I
>> added these supplies as "optional" properties: if there is only one 1v2
>> regulator on the board, the dt will contain only avcc12 or cvcc12 and
>> everything will work fine (we will have a dummy regulator for the
>> missing optional 1v2 reg), if both regulators are there for any reasons
>> (stability, noise, whatever...) then both entries will be in the dt.
>>
>> If you confirm you prefer a single 1v2 supply (named for instance
>> "vcc12-supply") then I will do :-)
> 
> Please see https://lists.freedesktop.org/archives/dri-devel/2018-April/
> 172400.html (and the messages that lead to it) and https://
> lists.freedesktop.org/archives/dri-devel/2018-March/170763.html.
> 

Thanks for this discussion thread.

On my side, I found "CVCC12 and AVCC12 can be derived from the same 
power source" written with a small font (august 2016 datasheet p13) so 
then your advice is clearly what we have to do :-)
I will add this info in v2 too.
Thank you,
Philippe :-)

Optional subnodes:
- video input: this subnode can contain a video input port node
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/2] i915: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.

This requires also manipulationg ITC bit, as stated in
HDMI spec.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c | 2 ++
 drivers/gpu/drm/i915/intel_hdmi.c   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..96a42eb457c5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
+   new_conn_state->base.it_content != old_conn_state->base.it_content 
||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..078200908b7a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   frame.avi.content_type = connector->state->content_type;
+   frame.avi.itc = connector->state->it_content;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+   drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 }
 
-- 
2.17.0

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

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

[Giulio Benetti]

Hi,

Il 19/04/2018 11:32, Chen-Yu Tsai ha scritto:

This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.


Judging from the code, the real vendor should be CDTech.
Take a look at their website:
http://www.cdtech-lcd.com/en/standardscreen.html

I point you my patch for inserting another similar panel:
https://patchwork.freedesktop.org/patch/211914/

Maybe it would make sense to use CDTech as the vendor,
because maybe Bananapi resells only it.
Or maybe it is a custom panel done for them,
but the same is for other panels I've submitted patches.
Micronova srl custom, but vendor is CDTech.

What do you think?

--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642



This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.

Signed-off-by: Chen-Yu Tsai 
---
  .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
  drivers/gpu/drm/panel/panel-simple.c  | 25 +++
  2 files changed, 32 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt 
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-ct16"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
  };
  
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {

+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 40,
+   .hsync_end = 800 + 40 + 48,
+   .htotal = 800 + 40 + 48 + 40,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 3,
+   .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+   .modes = _s070wv20_ct16_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+};
+
  static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
+   }, {
+   .compatible = "bananapi,s070wv20-ct16",
+   .data = _s070wv20_ct16,
}, {
.compatible = "boe,nv101wxmn51",
.data = _nv101wxmn51,





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

Re: [PATCH v8 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[jacopo mondi]

Hi Vladimir,

On Thu, Apr 19, 2018 at 02:18:30PM +0300, Vladimir Zapolskiy wrote:
> Hi Jacopo,
>
> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output converter.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
>
> Reviewed-by: Vladimir Zapolskiy 
>

Thanks. FYI I sent v9 yesterday with a minimal change compared to v8.

> Generally I have only one pretty ignorable comment.
>
> > +
> > +enum thc63_ports {
> > +   THC63_LVDS_IN0,
> > +   THC63_LVDS_IN1,
> > +   THC63_RGB_OUT0,
> > +   THC63_RGB_OUT1,
> > +};
> > +
>
> The driver uses only THC63_RGB_OUT0 value, or port@2, and MODE{0,1,2} IC
> configuration is ignored.
>
> I don't know if right from the beginning it would be better to support
> dual-out modes, preferably both single-in and dual-in ones. Will it
> impact port enumeration?

The bindings have been designed to support dual in/out modes, as you
can see there are 4 possible ports described there:

Required video port nodes:
- port@0: First LVDS input port
- port@2: First digital CMOS/TTL parallel output

Optional video port nodes:
- port@1: Second LVDS input port
- port@3: Second digital CMOS/TTL parallel output

Future extension should not require changing the port enumeration,
just add a property to specify the selected mode.

>
> I do understand that the extension is possible, and likely only hardware
> accessibility postpones it.

Yes, hardware on one side, but also what I think is a shortcoming of
DRM (which exists in other sub-systems, say v4l2) that matches devices
on their OF device nodes and makes cumbersome handling drivers wanting
to register on 'port' nodes instead, as it would happen if you have 2
input endpoints.

See my [1] note here: https://lkml.org/lkml/2018/3/9/422
And this reply to Archit's comment which has been left floating as it
is not a real issue (yet): https://lkml.org/lkml/2018/3/10/214

Thanks
   j

>
> --
> With best wishes,
> Vladimir


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

Re: [PATCH] drm/rockchip: vop: fixup linebuffer mode calc error

[Sandy Huang]

在 2018/4/17 19:14, Heiko Stuebner 写道:

Hi Sandy,

Am Dienstag, 17. April 2018, 12:15:07 CEST schrieb Sandy Huang:

When video width is bigger than 3840 the linebuffer mode
should be LB_YUV_3840X5.

Can you explain that a bit better?

I.e. when looking at the code, the very first check is width > 2560.

So it seems your change targets some YUV mode with width > 3840
which should be mentioned in the commit message, so people like
me don't scratch their head in confusion ;-)

Similarly that check is actually width > 1280 to set LB_YUV_3840X5,
so I guess you're actually wanting any YUV mode bigger than
1280px should use LB_YUV_3840X5?


Heiko

Thanks heiko,
I will make more description for this path at next version.



Signed-off-by: Sandy Huang 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 56bbd2e..3e7501b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -332,7 +332,7 @@ static inline int scl_vop_cal_lb_mode(int width, bool 
is_yuv)
  
  	if (width > 2560)

lb_mode = LB_RGB_3840X2;
-   else if (width > 1920)
+   else if (!is_yuv && width > 1920)
lb_mode = LB_RGB_2560X4;
else if (!is_yuv)
lb_mode = LB_RGB_1920X5;








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

Re: [PATCH v3 0/2] Enabling content-type setting for HDMI displays.

[Ville Syrjälä]

On Thu, Apr 19, 2018 at 10:58:44AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Rev 1:
> Added content type setting property to drm_connector(part 1)
> and enabled transmitting it with HDMI AVI infoframes
> for i915(part 2).
> 
> Rev 2:
> Moved helper function which attaches content type property
> to the drm core, as was suggested.
> Removed redundant connector state initialization.
> 
> Rev 3:
> Removed caps in drm_content_type_enum_list.
> After some discussion it turned out that HDMI Spec 1.4
> was wrongly assuming that IT Content(itc) bit doesn't affect
> Content type states, however itc bit needs to be manupulated
> as well. In order to not expose additional property for itc,
> for sake of simplicity it was decided to bind those together
> in same "content type" property.

Please put these changelogs into the commit messages themselves.
Plenty of examples of that practice in git log -- drivers/gpu/drm

> 
> Stanislav Lisovskiy (2):
>   drm: content-type property for HDMI connector
>   i915: content-type property for HDMI connector
> 
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c |  5 +++
>  drivers/gpu/drm/drm_connector.c  | 51 
>  drivers/gpu/drm/drm_edid.c   |  2 ++
>  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
>  drivers/gpu/drm/i915/intel_hdmi.c|  4 +++
>  include/drm/drm_connector.h  | 17 ++
>  include/drm/drm_mode_config.h|  5 +++
>  include/uapi/drm/drm_mode.h  |  7 
>  9 files changed, 93 insertions(+)
> 
> -- 
> 2.17.0

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

Re: [PATCH v8 2/2] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Vladimir Zapolskiy]

Hi Jacopo,

On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 

Reviewed-by: Vladimir Zapolskiy 

Generally I have only one pretty ignorable comment.

> +
> +enum thc63_ports {
> + THC63_LVDS_IN0,
> + THC63_LVDS_IN1,
> + THC63_RGB_OUT0,
> + THC63_RGB_OUT1,
> +};
> +

The driver uses only THC63_RGB_OUT0 value, or port@2, and MODE{0,1,2} IC
configuration is ignored.

I don't know if right from the beginning it would be better to support
dual-out modes, preferably both single-in and dual-in ones. Will it
impact port enumeration?

I do understand that the extension is possible, and likely only hardware
accessibility postpones it.

--
With best wishes,
Vladimir
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Laurent Pinchart]

Hi Philippe,

On Thursday, 19 April 2018 12:31:15 EEST Philippe CORNU wrote:
> On 04/19/2018 10:11 AM, Laurent Pinchart wrote:
> > On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote:
> > 
> >> Add the 3 optional power supplies using the exact description
> >> found in the document named
> >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> >>
> >> Signed-off-by: Philippe Cornu 
> >> ---
> >> 
> >>   Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
> >>   1 file changed, 3 insertions(+)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> >> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index
> >> 56a3e68ccb80..cf53678fe574 100644
> >> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> >> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> >> @@ -8,6 +8,9 @@ Optional properties:
> >>- interrupts-extended or interrupt-parent + interrupts: describe
> >>  the interrupt line used to inform the host about hotplug events.
> >>- reset-gpios: OF device-tree gpio specification for RST_N pin.
> >> +  - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent).
> >> +  - avcc12-supply: TMDS analog supply voltage (1.2V).
> >> +  - cvcc12-supply: Digital core supply voltage (1.2V).
> > 
> > It seems that the AVCC12 and CVCC12 power supplies are usually derived
> > from the same source. How about starting with one DT property for both,
> > and adding a second one later if needed ?
> 
> Well, I do not know what is the best. Here I took the description from 
> the documentation, and to allow all possible board configurations, I 
> added these supplies as "optional" properties: if there is only one 1v2 
> regulator on the board, the dt will contain only avcc12 or cvcc12 and 
> everything will work fine (we will have a dummy regulator for the 
> missing optional 1v2 reg), if both regulators are there for any reasons 
> (stability, noise, whatever...) then both entries will be in the dt.
> 
> If you confirm you prefer a single 1v2 supply (named for instance 
> "vcc12-supply") then I will do :-)

Please see https://lists.freedesktop.org/archives/dri-devel/2018-April/
172400.html (and the messages that lead to it) and https://
lists.freedesktop.org/archives/dri-devel/2018-March/170763.html.

> >>   Optional subnodes:
> >>- video input: this subnode can contain a video input port node

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH 2/2] drm/bridge: sii902x: add optional power supplies

[Laurent Pinchart]

Hi Philippe,

On Thursday, 19 April 2018 12:46:31 EEST Philippe CORNU wrote:
> On 04/19/2018 10:20 AM, Laurent Pinchart wrote:
> > On Tuesday, 10 April 2018 08:19:27 EEST Philippe Cornu wrote:
> > 
> >> Add the 3 optional power supplies using the exact description
> >> found in the document named
> >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> >>
> >> Signed-off-by: Philippe Cornu 
> >> ---
> >> drivers/gpu/drm/bridge/sii902x.c | 39 +++
> >> 1 file changed, 35 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> >> b/drivers/gpu/drm/bridge/sii902x.c index 60373d7eb220..e17ba6db1ec8
> >> 100644
> >> --- a/drivers/gpu/drm/bridge/sii902x.c
> >> +++ b/drivers/gpu/drm/bridge/sii902x.c

[snip]

> >> @@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client)
> >>
> >>drm_bridge_remove(>bridge);
> >>
> >> +  regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> >> + sii902x->supplies);
> >> +
> > 
> > While this seems functionally correct, would it be useful to only enable
> > power supplies when needed to save power ?
 
> that is a good point. I do not know well (yet) this bridge. Maybe I can 
> add a 3rd patch with bridge pre_enable() and post_disable() containing 
> reset & supplies management. Or I can put reset in bridge 
> enable() & disable() but it could be a little messy.
> 
> Any opinion/advice?

I'm not familiar with this bridge yet, so we need to be careful. The first 
point you need to check is the hardware requirements regarding power supply 
sequencing. For instance could it damage the chip if the I/O supply is turned 
off while the I/O pins are externally driven ? Can the core supplies be turned 
off with the I/O supply on ? Then, based on the hardware limitations, you 
should pick the appropriate location for power handling.

> >>return 0;
> >>   }

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v2] drm/bridge/synopsys: dsi: Adopt SPDX identifiers

[Philippe CORNU]

Applied on drm-misc-next.
Many thanks,
Philippe :-)

On 02/08/2018 05:46 PM, Laurent Pinchart wrote:
> Hi Philippe,
> 
> Thank you for the patch.
> 
> On Thursday, 8 February 2018 16:58:05 EET Philippe Cornu wrote:
>> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI
>> host controller driver.
>>
>> Signed-off-by: Philippe Cornu 
> 
> Reviewed-by: Laurent Pinchart 
> 
>> ---
>> Changes in v2: Update to "GPL-2.0+" following comments from Laurent
>> Pinchart, Benjamin Gaignard & Philippe Ombredanne.
>>
>>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +-
>>   1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index
>> 7bac101c285c..99f0e4f51716 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -1,12 +1,8 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>>   /*
>>* Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>>* Copyright (C) STMicroelectronics SA 2017
>>*
>> - * This program is free software; you can redistribute it and/or modify
>> - * it under the terms of the GNU General Public License as published by
>> - * the Free Software Foundation; either version 2 of the License, or
>> - * (at your option) any later version.
>> - *
>>* Modified by Philippe Cornu 
>>* This generic Synopsys DesignWare MIPI DSI host driver is based on the
>>* Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: fix warning in ltdc_crtc_update_clut()

[Philippe CORNU]

Applied on drm-misc-next.
Many thanks,
Philippe :-)

On 04/16/2018 11:18 AM, Yannick FERTRE wrote:
> Reviewed-by: yannick fertre 
> 
> 
> On 04/10/2018 03:53 PM, Philippe Cornu wrote:
>> Fix the warning
>> "warn: variable dereferenced before check 'crtc' (see line 390)"
>> by removing unnecessary checks as ltdc_crtc_update_clut() is
>> only called from ltdc_crtc_atomic_flush() where crtc and
>> crtc->state are not NULL.
>>
>> Many thanks to Dan Carpenter for the bug report
>> https://lists.freedesktop.org/archives/dri-devel/2018-February/166918.html
>>
>> Signed-off-by: Philippe Cornu 
>> Reported-by: Dan Carpenter 
>> ---
>>drivers/gpu/drm/stm/ltdc.c | 3 ---
>>1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 061d2b6e5157..e3121d9e4230 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -392,9 +392,6 @@ static void ltdc_crtc_update_clut(struct drm_crtc *crtc)
>>  u32 val;
>>  int i;
>>
>> -if (!crtc || !crtc->state)
>> -return;
>> -
>>  if (!crtc->state->color_mgmt_changed || !crtc->state->gamma_lut)
>>  return;
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: add user update info in plane print state

[Philippe CORNU]

Applied on drm-misc-next.
Many thanks,
Philippe :-)

On 04/16/2018 11:14 AM, Vincent ABRIOU wrote:
> Hi Philippe,
> 
> Reviewed-by: Vincent Abriou 
> 
> On 04/07/2018 11:35 PM, Philippe Cornu wrote:
>> This patch adds the user update information in
>> frames-per-second into the drm debugfs plane state.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>drivers/gpu/drm/stm/ltdc.c | 22 ++
>>drivers/gpu/drm/stm/ltdc.h |  8 
>>2 files changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 2b745cfc9000..061d2b6e5157 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -729,6 +729,8 @@ static void ltdc_plane_atomic_update(struct drm_plane 
>> *plane,
>>  reg_update_bits(ldev->regs, LTDC_L1CR + lofs,
>>  LXCR_LEN | LXCR_CLUTEN, val);
>>
>> +ldev->plane_fpsi[plane->index].counter++;
>> +
>>  mutex_lock(>err_lock);
>>  if (ldev->error_status & ISR_FUIF) {
>>  DRM_DEBUG_DRIVER("Fifo underrun\n");
>> @@ -754,6 +756,25 @@ static void ltdc_plane_atomic_disable(struct drm_plane 
>> *plane,
>>   oldstate->crtc->base.id, plane->base.id);
>>}
>>
>> +static void ltdc_plane_atomic_print_state(struct drm_printer *p,
>> +  const struct drm_plane_state *state)
>> +{
>> +struct drm_plane *plane = state->plane;
>> +struct ltdc_device *ldev = plane_to_ltdc(plane);
>> +struct fps_info *fpsi = >plane_fpsi[plane->index];
>> +int ms_since_last;
>> +ktime_t now;
>> +
>> +now = ktime_get();
>> +ms_since_last = ktime_to_ms(ktime_sub(now, fpsi->last_timestamp));
>> +
>> +drm_printf(p, "\tuser_updates=%dfps\n",
>> +   DIV_ROUND_CLOSEST(fpsi->counter * 1000, ms_since_last));
>> +
>> +fpsi->last_timestamp = now;
>> +fpsi->counter = 0;
>> +}
>> +
>>static const struct drm_plane_funcs ltdc_plane_funcs = {
>>  .update_plane = drm_atomic_helper_update_plane,
>>  .disable_plane = drm_atomic_helper_disable_plane,
>> @@ -761,6 +782,7 @@ static const struct drm_plane_funcs ltdc_plane_funcs = {
>>  .reset = drm_atomic_helper_plane_reset,
>>  .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
>>  .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
>> +.atomic_print_state = ltdc_plane_atomic_print_state,
>>};
>>
>>static const struct drm_plane_helper_funcs ltdc_plane_helper_funcs = {
>> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
>> index 61a80d00bc3b..1e16d6afb0d2 100644
>> --- a/drivers/gpu/drm/stm/ltdc.h
>> +++ b/drivers/gpu/drm/stm/ltdc.h
>> @@ -20,6 +20,13 @@ struct ltdc_caps {
>>  bool non_alpha_only_l1; /* non-native no-alpha formats on layer 1 */
>>};
>>
>> +#define LTDC_MAX_LAYER  4
>> +
>> +struct fps_info {
>> +unsigned int counter;
>> +ktime_t last_timestamp;
>> +};
>> +
>>struct ltdc_device {
>>  void __iomem *regs;
>>  struct clk *pixel_clk;  /* lcd pixel clock */
>> @@ -27,6 +34,7 @@ struct ltdc_device {
>>  struct ltdc_caps caps;
>>  u32 error_status;
>>  u32 irq_status;
>> +struct fps_info plane_fpsi[LTDC_MAX_LAYER];
>>};
>>
>>int ltdc_load(struct drm_device *ddev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: move enable/disable_vblank to crtc

[Philippe CORNU]

Applied on drm-misc-next.
Many thanks,
Philippe :-)

On 04/16/2018 11:07 AM, Vincent ABRIOU wrote:
> Hi Philippe,
> 
> Patch looks good to me.
> 
> Reviewed-by: Vincent Abriou 
> 
> On 04/07/2018 11:29 PM, Philippe Cornu wrote:
>> enable/disable_vblank() functions at drm_driver level
>> are deprecated. Move them to the ltdc drm_crtc_funcs
>> structure.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>drivers/gpu/drm/stm/drv.c  |  2 --
>>drivers/gpu/drm/stm/ltdc.c | 10 ++
>>drivers/gpu/drm/stm/ltdc.h |  2 --
>>3 files changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
>> index 9ab00a87f7cc..8698e08313e1 100644
>> --- a/drivers/gpu/drm/stm/drv.c
>> +++ b/drivers/gpu/drm/stm/drv.c
>> @@ -72,8 +72,6 @@ static struct drm_driver drv_driver = {
>>  .gem_prime_vmap = drm_gem_cma_prime_vmap,
>>  .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
>>  .gem_prime_mmap = drm_gem_cma_prime_mmap,
>> -.enable_vblank = ltdc_crtc_enable_vblank,
>> -.disable_vblank = ltdc_crtc_disable_vblank,
>>};
>>
>>static int drv_load(struct drm_device *ddev)
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 1a3277e483d5..2b745cfc9000 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -569,9 +569,9 @@ static const struct drm_crtc_helper_funcs 
>> ltdc_crtc_helper_funcs = {
>>  .atomic_disable = ltdc_crtc_atomic_disable,
>>};
>>
>> -int ltdc_crtc_enable_vblank(struct drm_device *ddev, unsigned int pipe)
>> +static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
>>{
>> -struct ltdc_device *ldev = ddev->dev_private;
>> +struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>>
>>  DRM_DEBUG_DRIVER("\n");
>>  reg_set(ldev->regs, LTDC_IER, IER_LIE);
>> @@ -579,9 +579,9 @@ int ltdc_crtc_enable_vblank(struct drm_device *ddev, 
>> unsigned int pipe)
>>  return 0;
>>}
>>
>> -void ltdc_crtc_disable_vblank(struct drm_device *ddev, unsigned int pipe)
>> +static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
>>{
>> -struct ltdc_device *ldev = ddev->dev_private;
>> +struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>>
>>  DRM_DEBUG_DRIVER("\n");
>>  reg_clear(ldev->regs, LTDC_IER, IER_LIE);
>> @@ -594,6 +594,8 @@ static const struct drm_crtc_funcs ltdc_crtc_funcs = {
>>  .reset = drm_atomic_helper_crtc_reset,
>>  .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>>  .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>> +.enable_vblank = ltdc_crtc_enable_vblank,
>> +.disable_vblank = ltdc_crtc_disable_vblank,
>>  .gamma_set = drm_atomic_helper_legacy_gamma_set,
>>};
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
>> index edb268129c54..61a80d00bc3b 100644
>> --- a/drivers/gpu/drm/stm/ltdc.h
>> +++ b/drivers/gpu/drm/stm/ltdc.h
>> @@ -29,8 +29,6 @@ struct ltdc_device {
>>  u32 irq_status;
>>};
>>
>> -int ltdc_crtc_enable_vblank(struct drm_device *dev, unsigned int pipe);
>> -void ltdc_crtc_disable_vblank(struct drm_device *dev, unsigned int pipe);
>>int ltdc_load(struct drm_device *ddev);
>>void ltdc_unload(struct drm_device *ddev);
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

On Thu, Apr 19, 2018 at 12:44:32PM +0300, Vladimir Zapolskiy wrote:
Hi Vladimir,

> Hi Jacopo, Laurent,
>
> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi 
> > Reviewed-by: Andrzej Hajda 
> > Reviewed-by: Niklas Söderlund 
> > Reviewed-by: Laurent Pinchart 
>
> Reviewed-by: Vladimir Zapolskiy 
>
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 
> > ++
> >  1 file changed, 60 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..0b23e70
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,60 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS 
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two LVDS input streams and up to two digital CMOS/TTL 
> > outputs.
> > +
> > +Single or dual operation mode, output data mapping and DDR output modes are
> > +configured through input signals and the chip does not expose any control 
> > bus.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024"
> > +- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
> > +  PPL and digital circuitry
> > +
> > +Optional properties:
> > +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
>
> Thank you for the change.
>
> I would suggest to rename 'pwdn-gpios' property of THC63LVDM83D as well,
> as far as I understand it is only described in DT bindings documentation,
> and the property is unused in the driver or board DTS files at the moment.

Thanks for the suggestion, I'll do that!

>
> > +- oe-gpios: Output enable GPIO signal, pin name "OE". Active high
>
> Okay :)

Yeah, please see Rob's and Laurent's reply to v7, where I renamed this
to 'enable'.

Thanks
   j
>
> --
> With best wishes,
> Vladimir


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

Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 04/19/2018 12:48 PM, Vladimir Zapolskiy wrote:
> Hi Jacopo,
> 
> On 04/19/2018 12:44 PM, Vladimir Zapolskiy wrote:
>> Hi Jacopo, Laurent,
>>
>> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>
>>> Signed-off-by: Jacopo Mondi 
>>> Reviewed-by: Andrzej Hajda 
>>> Reviewed-by: Niklas Söderlund 
>>> Reviewed-by: Laurent Pinchart 
>>
>> Reviewed-by: Vladimir Zapolskiy 
>>
>>> ---

[snip]

>>> +Optional properties:
>>> +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
>>
> 
> sorry for a follow-up, I've just noticed it, could you please double check
> spelling PDWN vs PWDN? Thank you in advance.
> 

please ignore it, I did it myself and the datasheet describes pin as /PDWN,
I won't exclude a typo in the datasheet though...

--
With best wishes,
Vladimir
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo,

On 04/19/2018 12:44 PM, Vladimir Zapolskiy wrote:
> Hi Jacopo, Laurent,
> 
> On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>
>> Signed-off-by: Jacopo Mondi 
>> Reviewed-by: Andrzej Hajda 
>> Reviewed-by: Niklas Söderlund 
>> Reviewed-by: Laurent Pinchart 
> 
> Reviewed-by: Vladimir Zapolskiy 
> 
>> ---
>>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 
>> ++
>>  1 file changed, 60 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>> new file mode 100644
>> index 000..0b23e70
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>> @@ -0,0 +1,60 @@
>> +Thine Electronics THC63LVD1024 LVDS decoder
>> +---
>> +
>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS 
>> streams
>> +to parallel data outputs. The chip supports single/dual input/output modes,
>> +handling up to two LVDS input streams and up to two digital CMOS/TTL 
>> outputs.
>> +
>> +Single or dual operation mode, output data mapping and DDR output modes are
>> +configured through input signals and the chip does not expose any control 
>> bus.
>> +
>> +Required properties:
>> +- compatible: Shall be "thine,thc63lvd1024"
>> +- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
>> +  PPL and digital circuitry
>> +
>> +Optional properties:
>> +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
> 

sorry for a follow-up, I've just noticed it, could you please double check
spelling PDWN vs PWDN? Thank you in advance.

--
With best wishes,
Vladimir
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/bridge: sii902x: add optional power supplies

[Philippe CORNU]

Hi Laurent :-)

On 04/19/2018 10:20 AM, Laurent Pinchart wrote:
> Hi Philippe,
> 
> Thank you for the patch.
> 
> On Tuesday, 10 April 2018 08:19:27 EEST Philippe Cornu wrote:
>> Add the 3 optional power supplies using the exact description
>> found in the document named
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>> drivers/gpu/drm/bridge/sii902x.c | 39 +
>> 1 file changed, 35 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
>> b/drivers/gpu/drm/bridge/sii902x.c index 60373d7eb220..e17ba6db1ec8 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -24,6 +24,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>
>>   #include 
>>   #include 
>> @@ -86,6 +87,7 @@ struct sii902x {
>>  struct drm_bridge bridge;
>>  struct drm_connector connector;
>>  struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[3];
>>   };
>>
>>   static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
>> @@ -392,23 +394,43 @@ static int sii902x_probe(struct i2c_client *client,
>>  return PTR_ERR(sii902x->reset_gpio);
>>  }
>>
>> +sii902x->supplies[0].supply = "iovcc";
>> +sii902x->supplies[1].supply = "avcc12";
>> +sii902x->supplies[2].supply = "cvcc12";
>> +ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
>> +  sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "regulator_bulk_get failed\n");
> 
> Maybe "failed to get power supplies" to be a bit more explicit ? And while at
> it, printing the value of ret too ?
> 

good point, I will do that in v2


>> +return ret;
>> +}
>> +
>> +ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
>> +sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "regulator_bulk_enable failed\n");
> 
> Same here ?
> 

agreed

>> +return ret;
>> +}
>> +
>> +usleep_range(1, 2);
>> +
>>  sii902x_reset(sii902x);
>>
>>  ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>>  if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>
>>  ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>> , 4);
>>  if (ret) {
>>  dev_err(dev, "regmap_read failed %d\n", ret);
>> -return ret;
>> +goto err_disable_regulator;
>>  }
>>
>>  if (chipid[0] != 0xb0) {
>>  dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>>  chipid[0]);
>> -return -EINVAL;
>> +ret = -EINVAL;
>> +goto err_disable_regulator;
>>  }
>>
>>  /* Clear all pending interrupts */
>> @@ -424,7 +446,7 @@ static int sii902x_probe(struct i2c_client *client,
>>  IRQF_ONESHOT, dev_name(dev),
>>  sii902x);
>>  if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>  }
>>
>>  sii902x->bridge.funcs = _bridge_funcs;
>> @@ -434,6 +456,12 @@ static int sii902x_probe(struct i2c_client *client,
>>  i2c_set_clientdata(client, sii902x);
>>
>>  return 0;
>> +
>> +err_disable_regulator:
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> +   sii902x->supplies);
>> +
>> +return ret;
>>   }
>>
>>   static int sii902x_remove(struct i2c_client *client)
>> @@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client)
>>
>>  drm_bridge_remove(>bridge);
>>
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> +   sii902x->supplies);
>> +
> 
> While this seems functionally correct, would it be useful to only enable power
> supplies when needed to save power ?
> 

that is a good point. I do not know well (yet) this bridge. Maybe I can 
add a 3rd patch with bridge pre_enable() and post_disable() containing 
reset & supplies management. Or I can put reset in bridge 
enable() & disable() but it could be a little messy.

Any opinion/advice?
Many thanks,
Philippe :-)

>>  return 0;
>>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Vladimir Zapolskiy]

Hi Jacopo, Laurent,

On 04/10/2018 01:53 PM, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> Reviewed-by: Laurent Pinchart 

Reviewed-by: Vladimir Zapolskiy 

> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..0b23e70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,60 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS 
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two LVDS input streams and up to two digital CMOS/TTL outputs.
> +
> +Single or dual operation mode, output data mapping and DDR output modes are
> +configured through input signals and the chip does not expose any control 
> bus.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024"
> +- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
> +  PPL and digital circuitry
> +
> +Optional properties:
> +- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low

Thank you for the change.

I would suggest to rename 'pwdn-gpios' property of THC63LVDM83D as well,
as far as I understand it is only described in DT bindings documentation,
and the property is unused in the driver or board DTS files at the moment.

> +- oe-gpios: Output enable GPIO signal, pin name "OE". Active high

Okay :)

--
With best wishes,
Vladimir
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/2] Enabling content-type setting for HDMI displays.

[StanLis]

From: Stanislav Lisovskiy 

Rev 1:
Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Rev 2:
Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.

Rev 3:
Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.

Rev 4:
Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c|  4 +++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 9 files changed, 107 insertions(+)

-- 
2.17.0

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

[PATCH v4 1/2] drm: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added content_type  property to
drm_connector_state in order to properly handle
external HDMI TV content-type setting.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c | 17 ++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 include/drm/drm_connector.h  | 18 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 7 files changed, 101 insertions(+)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..a91c9211b8d6 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..479499f5848e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,15 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   state->content_type = val & 3;
+   state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1360,14 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+   } else if (property == config->content_type_property) {
+   /*
+* Lowest two bits of content_type property control
+* content_type, bit 2 controls itc bit.
+* It was decided to have a single property called
+* content_type, instead of content_type and itc.
+*/
+   *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
+   { DRM_MODE_CONTENT_TYPE_NO_DATA, "No data" },
+   { DRM_MODE_CONTENT_TYPE_GRAPHICS, "Graphics" },
+   { DRM_MODE_CONTENT_TYPE_PHOTO, "Photo" },
+   { DRM_MODE_CONTENT_TYPE_CINEMA, "Cinema" },
+   { DRM_MODE_CONTENT_TYPE_GAME, "Game" },
+};
+
 static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
@@ -996,6 +1004,22 @@ int drm_mode_create_dvi_i_properties(struct drm_device 
*dev)
 }
 EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
 
+/**
+ * drm_connector_attach_content_type_property - attach content-type property
+ 

[PATCH v4 2/2] i915: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from
drm_connector_state within AVI infoframe in order to properly handle
external HDMI TV content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c | 2 ++
 drivers/gpu/drm/i915/intel_hdmi.c   | 4 
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..96a42eb457c5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,8 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
+   new_conn_state->base.it_content != old_conn_state->base.it_content 
||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..078200908b7a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   frame.avi.content_type = connector->state->content_type;
+   frame.avi.itc = connector->state->it_content;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+   drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 }
 
-- 
2.17.0

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

[PATCH 0/6] drm/sun4i: Support color dithering for LCD panels

[Chen-Yu Tsai]

Dithering is a method of approximating a color from a mixture of other
colors when the required color isn't available. It reduces color
banding artifacts that can be observed when displaying gradients
(e.g. grayscale gradients). This may occur when the image that needs
to be displayed is 24-bit but the LCD panel is a lower bit depth and
does not perform dithering on its own.

The TCON (LCD controller) found in Allwinner SoCs has hardware support
for dithering on channel 0, the channel used to feed LCD panels. This
series adds support for it.

Patch 1 reworks the mode set function for the CPU interface to pass
the encoder object, so it can be passed to other helper functions.

Patch 2 renames the dithering related register macros to reflect the
fact that dithering is only supported on channel 0.

Patch 3 adds support for dithering on all LCD panel output types.

Patch 4 adds support for Banana Pi's 7" DPI LCD panel.

Patch 5 adds a pinmux setting for RGB888 for the Allwinner A20 SoC.
This change has been sent by others before.

Patch 6 provides an example for enabling the Banana Pi 7" DPI LCD panel
on the Banana Pi M1+. This should not be merged. I will likely rework
this into an overlay in the future.

Note that I was only able to test dithering with DPI, as I do not have
other panel types. However the underlying concept and core code is the
same, as are the drm objects accessed. Nevertheless I'm hoping Jonathan
can test LVDS and Maxime can test MIPI DSI.

Also it seems pwm-backlight hardware is unusable at the moment. I'm not
sure whether the pwm-backlight or sun4i-pwm driver is to blame. I had to
manually poke the pwm registers so the LCD backlight wouldn't be
completely black.


Regards
ChenYu

Chen-Yu Tsai (5):
  drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu
  drm/sun4i: tcon: Rename Dithering related register macros
  drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel
  ARM: dts: sun7i: add pinmux setting for RGB888 output for LCD0
  [DO NOT MERGE] ARM: dts: sun7i: bananapi-m1-plus: Enable Bananapi 7"
800x480 RGB LCD panel

Jonathan Liu (1):
  drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels

 .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
 .../boot/dts/sun7i-a20-bananapi-m1-plus.dts   | 61 +++
 arch/arm/boot/dts/sun7i-a20.dtsi  | 11 +++
 drivers/gpu/drm/panel/panel-simple.c  | 25 ++
 drivers/gpu/drm/sun4i/sun4i_tcon.c| 76 ---
 drivers/gpu/drm/sun4i/sun4i_tcon.h| 27 ---
 6 files changed, 186 insertions(+), 21 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt

-- 
2.17.0

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

[PATCH 1/6] drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu

[Chen-Yu Tsai]

sun4i_tcon0_mode_set_cpu() currently accepts struct mipi_dsi_device *
as its second parameter. This is derived from drm_encoder.

The DSI encoder is tied to the CPU interface mode of the TCON as a
special case. In theory, if hardware were available, we could also
support normal CPU interface modes. It is better to pass the generic
encoder instead of the specialized mipi_dsi_device, and handle the
differences inside the function.

Passing the encoder would also enable the function to pass it, or any
other data structures related to it, to other functions expecting it.
One such example would be dithering support that will be added in a
later patch, which looks at properties tied to the connector to
determine whether dithering should be enabled or not.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 08747fc3ee71..2bd53ef7d4b8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -277,9 +277,12 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon 
*tcon,
 }
 
 static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
-struct mipi_dsi_device *device,
+struct drm_encoder *encoder,
 const struct drm_display_mode *mode)
 {
+   /* TODO support normal CPU interface modes */
+   struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
+   struct mipi_dsi_device *device = dsi->device;
u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
u8 lanes = device->lanes;
u32 block_space, start_delay;
@@ -606,16 +609,10 @@ void sun4i_tcon_mode_set(struct sun4i_tcon *tcon,
 const struct drm_encoder *encoder,
 const struct drm_display_mode *mode)
 {
-   struct sun6i_dsi *dsi;
-
switch (encoder->encoder_type) {
case DRM_MODE_ENCODER_DSI:
-   /*
-* This is not really elegant, but it's the "cleaner"
-* way I could think of...
-*/
-   dsi = encoder_to_sun6i_dsi(encoder);
-   sun4i_tcon0_mode_set_cpu(tcon, dsi->device, mode);
+   /* DSI is tied to special case of CPU interface */
+   sun4i_tcon0_mode_set_cpu(tcon, encoder, mode);
break;
case DRM_MODE_ENCODER_LVDS:
sun4i_tcon0_mode_set_lvds(tcon, encoder, mode);
-- 
2.17.0

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

[PATCH 5/6] ARM: dts: sun7i: add pinmux setting for RGB888 output for LCD0

[Chen-Yu Tsai]

On the A20, as well as many other Allwinner SoCs, the PD pingroup has
the LCD0 RGB output functions.

Add a pinmux setting for RGB888 output from LCD0, so boards and tablets
with parallel RGB LCD panels may reference it.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..e06c14649d22 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -920,6 +920,17 @@
pins = "PI20", "PI21";
function = "uart7";
};
+
+   lcd0_rgb888_pins: lcd0-rgb888-pins {
+   pins = "PD0", "PD1", "PD2", "PD3", "PD4",
+  "PD5", "PD6", "PD7", "PD8", "PD9",
+  "PD10", "PD11", "PD12", "PD13",
+  "PD14", "PD15", "PD16", "PD17",
+  "PD18", "PD19", "PD20", "PD21",
+  "PD22", "PD23", "PD24", "PD25",
+  "PD26", "PD27";
+   function = "lcd0";
+   };
};
 
timer@1c20c00 {
-- 
2.17.0

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

[PATCH 6/6] [DO NOT MERGE] ARM: dts: sun7i: bananapi-m1-plus: Enable Bananapi 7" 800x480 RGB LCD panel

[Chen-Yu Tsai]

The BPI-M1+ has an FPC connector for connecting an RGB (parallel) or
LVDS LCD panel. One of the compatible panels is a 7" 800x480 RGB panel
from Bananapi. The backlight can be controlled by driving a PWM signal
from the SoC at different duty cycles. The LCD enable pin does not seem
to do anything, but it is nevertheless included for completeness. There
is also a FT5306 capacitive touchscreen controller.

This should not be confused with the other 7" LCD that is LVDS based
and has a resolution of 1024x600.

This patch enables all of the above for the BPI-M1+.

Signed-off-by: Chen-Yu Tsai 
---
 .../boot/dts/sun7i-a20-bananapi-m1-plus.dts   | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
index 763cb03033c4..58a923bfa6ef 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
@@ -47,6 +47,7 @@
 #include "sunxi-common-regulators.dtsi"
 #include 
 #include 
+#include 
 
 / {
model = "Banana Pi BPI-M1-Plus";
@@ -71,6 +72,34 @@
};
};
 
+   lcd_backlight: lcd-backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 2 PWM_POLARITY_INVERTED>; /* 50 kHz */
+   enable-gpios = < 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   };
+
+   lcd_panel: lcd-panel {
+   compatible = "bananapi,s070wv20-ct16", "simple-panel";
+   /* This doesn't do anything for this particular panel */
+   enable-gpios = < 7 12 GPIO_ACTIVE_HIGH>; /* PH12 */
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   backlight = <_backlight>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lcd_panel_input: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lcd>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -173,6 +202,20 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   touchscreen@38 {
+   compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+   reg = <0x38>;
+   interrupt-parent = <>;
+   interrupts = <7 7 IRQ_TYPE_EDGE_FALLING>; /* PH7 */
+   reset-gpios = < 7 8 GPIO_ACTIVE_LOW>; /* PH8 */
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_rx_pins_a>;
@@ -249,6 +292,12 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
 _dcdc2 {
regulator-always-on;
regulator-min-microvolt = <100>;
@@ -278,6 +327,18 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_rgb888_pins>;
+};
+
+_out {
+   tcon0_out_lcd: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_panel_input>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
2.17.0

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

[PATCH 2/6] drm/sun4i: tcon: Rename Dithering related register macros

[Chen-Yu Tsai]

Dithering is only supported for TCON channel 0. Throughout the datasheet
all the names associated with these register are prefixed "TCON0",
instead of "TCON". The only exception is the control register
"TCON_FRM_CTL_REG".

Rename the macros to reflect this.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f6a071cd5a6f..3d492c8be1fc 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -37,18 +37,21 @@
 #define SUN4I_TCON_GINT1_REG   0x8
 
 #define SUN4I_TCON_FRM_CTL_REG 0x10
-#define SUN4I_TCON_FRM_CTL_EN  BIT(31)
-
-#define SUN4I_TCON_FRM_SEED_PR_REG 0x14
-#define SUN4I_TCON_FRM_SEED_PG_REG 0x18
-#define SUN4I_TCON_FRM_SEED_PB_REG 0x1c
-#define SUN4I_TCON_FRM_SEED_LR_REG 0x20
-#define SUN4I_TCON_FRM_SEED_LG_REG 0x24
-#define SUN4I_TCON_FRM_SEED_LB_REG 0x28
-#define SUN4I_TCON_FRM_TBL0_REG0x2c
-#define SUN4I_TCON_FRM_TBL1_REG0x30
-#define SUN4I_TCON_FRM_TBL2_REG0x34
-#define SUN4I_TCON_FRM_TBL3_REG0x38
+#define SUN4I_TCON0_FRM_CTL_EN BIT(31)
+#define SUN4I_TCON0_FRM_CTL_MODE_R BIT(6)
+#define SUN4I_TCON0_FRM_CTL_MODE_G BIT(5)
+#define SUN4I_TCON0_FRM_CTL_MODE_B BIT(4)
+
+#define SUN4I_TCON0_FRM_SEED_PR_REG0x14
+#define SUN4I_TCON0_FRM_SEED_PG_REG0x18
+#define SUN4I_TCON0_FRM_SEED_PB_REG0x1c
+#define SUN4I_TCON0_FRM_SEED_LR_REG0x20
+#define SUN4I_TCON0_FRM_SEED_LG_REG0x24
+#define SUN4I_TCON0_FRM_SEED_LB_REG0x28
+#define SUN4I_TCON0_FRM_TBL0_REG   0x2c
+#define SUN4I_TCON0_FRM_TBL1_REG   0x30
+#define SUN4I_TCON0_FRM_TBL2_REG   0x34
+#define SUN4I_TCON0_FRM_TBL3_REG   0x38
 
 #define SUN4I_TCON0_CTL_REG0x40
 #define SUN4I_TCON0_CTL_TCON_ENABLEBIT(31)
-- 
2.17.0

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

[PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

[Chen-Yu Tsai]

This panel is marketed as Banana Pi 7" LCD display. On the back is
a sticker denoting the model name S070WV20-CT16.

This is a 7" 800x480 panel connected through a 24-bit RGB interface.
However the panel only does 262k colors.

Signed-off-by: Chen-Yu Tsai 
---
 .../display/panel/bananapi,s070wv20-ct16.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c  | 25 +++
 2 files changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt 
b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
new file mode 100644
index ..2ec35ce36e9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt
@@ -0,0 +1,7 @@
+Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
+
+Required properties:
+- compatible: should be "bananapi,s070wv20-ct16"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..9bc037f74d6c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -745,6 +745,28 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };
 
+static const struct drm_display_mode bananapi_s070wv20_ct16_mode = {
+   .clock = 3,
+   .hdisplay = 800,
+   .hsync_start = 800 + 40,
+   .hsync_end = 800 + 40 + 48,
+   .htotal = 800 + 40 + 48 + 40,
+   .vdisplay = 480,
+   .vsync_start = 480 + 13,
+   .vsync_end = 480 + 13 + 3,
+   .vtotal = 480 + 13 + 3 + 29,
+};
+
+static const struct panel_desc bananapi_s070wv20_ct16 = {
+   .modes = _s070wv20_ct16_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+};
+
 static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
{
.clock = 71900,
@@ -2112,6 +2134,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
+   }, {
+   .compatible = "bananapi,s070wv20-ct16",
+   .data = _s070wv20_ct16,
}, {
.compatible = "boe,nv101wxmn51",
.data = _nv101wxmn51,
-- 
2.17.0

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

[PATCH 3/6] drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels

[Chen-Yu Tsai]

From: Jonathan Liu 

The hardware supports dithering on TCON channel 0 which is used for LCD
panels.

Dithering is a method of approximating a color from a mixture of other
colors when the required color isn't available. It reduces color
banding artifacts that can be observed when displaying gradients
(e.g. grayscale gradients). This may occur when the image that needs
to be displayed is 24-bit but the LCD panel is a lower bit depth and
does not perform dithering on its own.

Signed-off-by: Jonathan Liu 
[w...@csie.org: check display_info.bpc first; handle LVDS and MIPI DSI]
Signed-off-by: Chen-Yu Tsai 
---

Hi Maxime,

The dithering parameters used here are different from the ones you used
in your MIPI DSI series. You might want to check if it still works for
you.

---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 63 +-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2bd53ef7d4b8..827518f4790e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -276,8 +277,59 @@ static void sun4i_tcon0_mode_set_common(struct sun4i_tcon 
*tcon,
 SUN4I_TCON0_BASIC0_Y(mode->crtc_vdisplay));
 }
 
+static void sun4i_tcon0_mode_set_dithering(struct sun4i_tcon *tcon,
+  const struct drm_connector 
*connector)
+{
+   u32 bus_format = 0;
+   u32 val = 0;
+
+   /* XXX Would this ever happen? */
+   if (!connector)
+   return;
+
+   /*
+* FIXME: Undocumented bits
+*
+* The whole dithering process and these parameters are not
+* explained in the vendor documents or BSP kernel code.
+*/
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PR_REG, 0x);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PG_REG, 0x);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_PB_REG, 0x);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LR_REG, 0x);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LG_REG, 0x);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED_LB_REG, 0x);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL0_REG, 0x0101);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL1_REG, 0x1515);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL2_REG, 0x5757);
+   regmap_write(tcon->regs, SUN4I_TCON0_FRM_TBL3_REG, 0x7f7f);
+
+   /* Do dithering if panel only supports 6 bits per color */
+   if (connector->display_info.bpc == 6)
+   val |= SUN4I_TCON0_FRM_CTL_EN;
+
+   if (connector->display_info.num_bus_formats == 1)
+   bus_format = connector->display_info.bus_formats[0];
+
+   /* Check the connection format */
+   switch (bus_format) {
+   case MEDIA_BUS_FMT_RGB565_1X16:
+   /* R and B components are only 5 bits deep */
+   val |= SUN4I_TCON0_FRM_CTL_MODE_R;
+   val |= SUN4I_TCON0_FRM_CTL_MODE_B;
+   case MEDIA_BUS_FMT_RGB666_1X18:
+   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+   /* Fall through: enable dithering */
+   val |= SUN4I_TCON0_FRM_CTL_EN;
+   break;
+   }
+
+   /* Write dithering settings */
+   regmap_write(tcon->regs, SUN4I_TCON_FRM_CTL_REG, val);
+}
+
 static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon *tcon,
-struct drm_encoder *encoder,
+const struct drm_encoder *encoder,
 const struct drm_display_mode *mode)
 {
/* TODO support normal CPU interface modes */
@@ -293,6 +345,9 @@ static void sun4i_tcon0_mode_set_cpu(struct sun4i_tcon 
*tcon,
 
sun4i_tcon0_mode_set_common(tcon, mode);
 
+   /* Set dithering if needed */
+   sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
   SUN4I_TCON0_CTL_IF_MASK,
   SUN4I_TCON0_CTL_IF_8080);
@@ -358,6 +413,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
tcon->dclk_max_div = 7;
sun4i_tcon0_mode_set_common(tcon, mode);
 
+   /* Set dithering if needed */
+   sun4i_tcon0_mode_set_dithering(tcon, sun4i_tcon_get_connector(encoder));
+
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
@@ -434,6 +492,9 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon 
*tcon,
tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
 
+   /* Set dithering if needed */
+   sun4i_tcon0_mode_set_dithering(tcon, 

Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Philippe CORNU]

Hi Laurent : )

On 04/19/2018 10:11 AM, Laurent Pinchart wrote:
> Hi Philippe,
> 
> Thank you for the patch.
> 
> On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote:
>> Add the 3 optional power supplies using the exact description
>> found in the document named
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>   Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index
>> 56a3e68ccb80..cf53678fe574 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> @@ -8,6 +8,9 @@ Optional properties:
>>  - interrupts-extended or interrupt-parent + interrupts: describe
>>the interrupt line used to inform the host about hotplug events.
>>  - reset-gpios: OF device-tree gpio specification for RST_N pin.
>> +- iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent).
>> +- avcc12-supply: TMDS analog supply voltage (1.2V).
>> +- cvcc12-supply: Digital core supply voltage (1.2V).
> 
> It seems that the AVCC12 and CVCC12 power supplies are usually derived from
> the same source. How about starting with one DT property for both, and adding
> a second one later if needed ?
> 

Well, I do not know what is the best. Here I took the description from 
the documentation, and to allow all possible board configurations, I 
added these supplies as "optional" properties: if there is only one 1v2 
regulator on the board, the dt will contain only avcc12 or cvcc12 and 
everything will work fine (we will have a dummy regulator for the 
missing optional 1v2 reg), if both regulators are there for any reasons 
(stability, noise, whatever...) then both entries will be in the dt.

If you confirm you prefer a single 1v2 supply (named for instance 
"vcc12-supply") then I will do :-)

Many thanks,
Philippe


>>   Optional subnodes:
>>  - video input: this subnode can contain a video input port node
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Hi Dave,

I was travelling last week, and thought you wouldn't be back until this week,
but you were :) So, my PR is against older drm-next for that I don't want to
make GVT folks redo their PR twice.

It's looking good on CI. Biggest things are the fix to be tolerant against bad
BIOSes (FDO #105549) and fix on GVT regression.

Next week should be a normal PR, then!

Regards, Joonas

drm-intel-next-fixes-2018-04-19:
- Fix for FDO #105549: Avoid OOPS on bad VBT (Jani)
- Fix rare pre-emption race (Chris)
- Fix RC6 race against PM transitions (Tvrtko)

gvt-fixes-2018-04-03

- fix unhandled vfio ioctl return value (Gerd)
- no-op user interrupt for vGPU (Zhipeng)
- fix ggtt dma unmap (Changbin)
- fix warning in fb decoder (Xiong)
- dmabuf drm_format_mod fix (Tina)
- misc cleanup

The following changes since commit 694f54f680f7fd8e9561928fbfc537d9afbc3d79:

  Merge branch 'drm-misc-next-fixes' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-03-29 09:25:13 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2018-04-19

for you to fetch changes up to b4615730530be85fc45ab4631c2ad6d8e2d0b97d:

  drm/i915/audio: Fix audio detection issue on GLK (2018-04-18 14:26:15 +0300)


- Fix for FDO #105549: Avoid OOPS on bad VBT (Jani)
- Fix rare pre-emption race (Chris)
- Fix RC6 race against PM transitions (Tvrtko)


Changbin Du (2):
  drm/i915/gvt: Missed to cancel dma map for ggtt entries
  drm/i915/gvt: Cancel dma map when resetting ggtt entries

Chris Wilson (2):
  drm/i915/execlists: Clear user-active flag on preemption completion
  drm/i915: Call i915_perf_fini() on init_hw error unwind

Gaurav K Singh (1):
  drm/i915/audio: Fix audio detection issue on GLK

Gerd Hoffmann (1):
  drm/i915/gvt: throw error on unhandled vfio ioctls

Gustavo A. R. Silva (1):
  drm/i915/gvt: Mark expected switch fall-through in handle_g2v_notification

Jani Nikula (1):
  drm/i915/bios: filter out invalid DDC pins from VBT child devices

Joonas Lahtinen (1):
  Merge tag 'gvt-fixes-2018-04-03' of https://github.com/intel/gvt-linux 
into drm-intel-next-fixes

Tina Zhang (1):
  drm/i915/gvt: Add drm_format_mod update

Tvrtko Ursulin (1):
  drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6

Xidong Wang (1):
  drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value

Xiong Zhang (2):
  drm/i915/gvt: Delete redundant error message in fb_decode.c
  drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
initialization

Zhipeng Gong (1):
  drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser

 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  1 +
 drivers/gpu/drm/i915/gvt/display.c | 10 ++
 drivers/gpu/drm/i915/gvt/dmabuf.c  |  1 +
 drivers/gpu/drm/i915/gvt/fb_decoder.c  | 27 ++--
 drivers/gpu/drm/i915/gvt/gtt.c | 52 ++
 drivers/gpu/drm/i915/gvt/gtt.h |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c|  1 +
 drivers/gpu/drm/i915/gvt/kvmgt.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.c| 27 +---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_pmu.c| 37 +++--
 drivers/gpu/drm/i915/intel_audio.c |  2 +-
 drivers/gpu/drm/i915/intel_bios.c  | 13 +---
 drivers/gpu/drm/i915/intel_lrc.c   |  9 ++
 14 files changed, 131 insertions(+), 55 deletions(-)

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

Re: [PATCH] drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs

[Greg KH]

On Thu, Apr 19, 2018 at 10:18:35AM +0200, Neil Armstrong wrote:
> Hi Greg,
> 
> On 23/02/2018 12:44, Neil Armstrong wrote:
> > The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
> > identified needing this workaround.
> > This patch adds the corresponding version to enable a single iteration for
> > this specific version.
> > 
> > Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround 
> > based on device version")
> > Signed-off-by: Neil Armstrong 
> 
> This patch is now present in linux master as commit 
> 9c305eb442f3b371fc722ade827bbf673514123e
> Could it be selected for 4.14 ?
> The patch has been reworked to apply for 4.17 as indicated in the commit log, 
> but the original patch will apply over 4.14.

I don't have any "original" patch here, I just tried applying it to
4.16.y and 4.14.y and it did not work.  Can you please provide a working
backport?

thanks,

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

Re: [PATCH 2/2] drm/bridge: sii902x: add optional power supplies

[Laurent Pinchart]

Hi Philippe,

Thank you for the patch.

On Tuesday, 10 April 2018 08:19:27 EEST Philippe Cornu wrote:
> Add the 3 optional power supplies using the exact description
> found in the document named
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> 
> Signed-off-by: Philippe Cornu 
> ---
> drivers/gpu/drm/bridge/sii902x.c | 39 +
> 1 file changed, 35 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c index 60373d7eb220..e17ba6db1ec8 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -86,6 +87,7 @@ struct sii902x {
>   struct drm_bridge bridge;
>   struct drm_connector connector;
>   struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data supplies[3];
>  };
> 
>  static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> @@ -392,23 +394,43 @@ static int sii902x_probe(struct i2c_client *client,
>   return PTR_ERR(sii902x->reset_gpio);
>   }
> 
> + sii902x->supplies[0].supply = "iovcc";
> + sii902x->supplies[1].supply = "avcc12";
> + sii902x->supplies[2].supply = "cvcc12";
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
> +   sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "regulator_bulk_get failed\n");

Maybe "failed to get power supplies" to be a bit more explicit ? And while at 
it, printing the value of ret too ?

> + return ret;
> + }
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "regulator_bulk_enable failed\n");

Same here ?

> + return ret;
> + }
> +
> + usleep_range(1, 2);
> +
>   sii902x_reset(sii902x);
> 
>   ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>   if (ret)
> - return ret;
> + goto err_disable_regulator;
> 
>   ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>  , 4);
>   if (ret) {
>   dev_err(dev, "regmap_read failed %d\n", ret);
> - return ret;
> + goto err_disable_regulator;
>   }
> 
>   if (chipid[0] != 0xb0) {
>   dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>   chipid[0]);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto err_disable_regulator;
>   }
> 
>   /* Clear all pending interrupts */
> @@ -424,7 +446,7 @@ static int sii902x_probe(struct i2c_client *client,
>   IRQF_ONESHOT, dev_name(dev),
>   sii902x);
>   if (ret)
> - return ret;
> + goto err_disable_regulator;
>   }
> 
>   sii902x->bridge.funcs = _bridge_funcs;
> @@ -434,6 +456,12 @@ static int sii902x_probe(struct i2c_client *client,
>   i2c_set_clientdata(client, sii902x);
> 
>   return 0;
> +
> +err_disable_regulator:
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +
> + return ret;
>  }
> 
>  static int sii902x_remove(struct i2c_client *client)
> @@ -443,6 +471,9 @@ static int sii902x_remove(struct i2c_client *client)
> 
>   drm_bridge_remove(>bridge);
> 
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +

While this seems functionally correct, would it be useful to only enable power 
supplies when needed to save power ?

>   return 0;
>  }

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Laurent Pinchart]

Hi Philippe,

Thank you for the patch.

On Tuesday, 10 April 2018 08:19:26 EEST Philippe Cornu wrote:
> Add the 3 optional power supplies using the exact description
> found in the document named
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> 
> Signed-off-by: Philippe Cornu 
> ---
>  Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index
> 56a3e68ccb80..cf53678fe574 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -8,6 +8,9 @@ Optional properties:
>   - interrupts-extended or interrupt-parent + interrupts: describe
> the interrupt line used to inform the host about hotplug events.
>   - reset-gpios: OF device-tree gpio specification for RST_N pin.
> + - iovcc-supply: I/O supply voltage (1.8V or 3.3V, host-dependent).
> + - avcc12-supply: TMDS analog supply voltage (1.2V).
> + - cvcc12-supply: Digital core supply voltage (1.2V).

It seems that the AVCC12 and CVCC12 power supplies are usually derived from 
the same source. How about starting with one DT property for both, and adding 
a second one later if needed ?

>  Optional subnodes:
>   - video input: this subnode can contain a video input port node

-- 
Regards,

Laurent Pinchart



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

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/18/2018 07:01 PM, Dongwon Kim wrote:

On Wed, Apr 18, 2018 at 03:42:29PM +0300, Oleksandr Andrushchenko wrote:

On 04/18/2018 01:55 PM, Roger Pau Monné wrote:

On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:

On 04/18/2018 01:18 PM, Paul Durrant wrote:

-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
Of Roger Pau Monné
Sent: 18 April 2018 11:11
To: Oleksandr Andrushchenko 
Cc: jgr...@suse.com; Artem Mygaiev ;
Dongwon Kim ; airl...@linux.ie;
oleksandr_andrushche...@epam.com; linux-ker...@vger.kernel.org; dri-
de...@lists.freedesktop.org; Potrola, MateuszX
; xen-de...@lists.xenproject.org;
daniel.vet...@intel.com; boris.ostrov...@oracle.com; Matt Roper

Subject: Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy
helper DRM driver

On Wed, Apr 18, 2018 at 11:01:12AM +0300, Oleksandr Andrushchenko
wrote:

On 04/18/2018 10:35 AM, Roger Pau Monné wrote:

After speaking with Oleksandr on IRC, I think the main usage of the
gntdev extension is to:

1. Create a dma-buf from a set of grant references.
2. Share dma-buf and get a list of grant references.

I think this set of operations could be broken into:

1.1 Map grant references into user-space using the gntdev.
1.2 Create a dma-buf out of a set of user-space virtual addresses.

2.1 Map a dma-buf into user-space.
2.2 Get grefs out of the user-space addresses where the dma-buf is
  mapped.

So it seems like what's actually missing is a way to:

   - Create a dma-buf from a list of user-space virtual addresses.
   - Allow to map a dma-buf into user-space, so it can then be used with
 the gntdev.

I think this is generic enough that it could be implemented by a
device not tied to Xen. AFAICT the hyper_dma guys also wanted
something similar to this.

Ok, so just to summarize, xen-zcopy/hyper-dmabuf as they are now,
are no go from your POV?

FYI,

our use-case is "surface sharing" or "graphic obj sharing" where a client
application in one guest renders and export this render target(e.g. EGL surface)
as dma-buf. This dma-buf is then exported to another guest/host via hyper_dmabuf
drv where a compositor is running. This importing domain creates a dmabuf with
shared reference then it is imported as EGL image that later can be used as
texture object via EGL api.



  Mapping dmabuf to the userspace or vice versa
might be possible with modifying user space drivers/applications but it is an
unnecessary extra step from our perspective.

+1. I also feel like if it is implemented in the kernel space it
will be *much* more easier then inventing workarounds with
gntdev, user-space and helper dma-buf driver (which obviously can be
implemented). Of course, this approach is easier for Xen as we do not
touch its kernel code ;)
But there is a demand for changes as number of embedded/multimedia use-cases
is constantly growing and we have to react.

Also, we want to keep all objects
in the kernel level.


My opinion is that there seems to be a more generic way to implement
this, and thus I would prefer that one.


Instead, we have to make all that fancy stuff
with VAs <-> device-X and have that device-X driver live out of drivers/xen
as it is not a Xen specific driver?

That would be my preference if feasible, simply because it can be
reused by other use-cases that need to create dma-bufs in user-space.

There is a use-case I have: a display unit on my target has a DMA
controller which can't do scatter-gather, e.g. it only expects a
single starting address of the buffer.
In order to create a dma-buf from grefs in this case
I allocate memory with dma_alloc_xxx and then balloon pages of the
buffer and finally map grefs onto this DMA buffer.
This way I can give this shared buffer to the display unit as its bus
addresses are contiguous.

With the proposed solution (gntdev + device-X) I won't be able to achieve
this,
as I have no control over from where gntdev/balloon drivers get the pages
(even more, those can easily be out of DMA address space of the display
unit).

Thus, even if implemented, I can't use this approach.

In any case I just knew about dma-bufs this morning, there might be
things that I'm missing.

Roger.


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

Re: [PATCH] drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs

[Neil Armstrong]

Hi Greg,

On 23/02/2018 12:44, Neil Armstrong wrote:
> The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
> identified needing this workaround.
> This patch adds the corresponding version to enable a single iteration for
> this specific version.
> 
> Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based 
> on device version")
> Signed-off-by: Neil Armstrong 

This patch is now present in linux master as commit 
9c305eb442f3b371fc722ade827bbf673514123e
Could it be selected for 4.14 ?
The patch has been reworked to apply for 4.17 as indicated in the commit log, 
but the original patch will apply over 4.14.

Thanks,
Neil

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a38db40..f5018f9 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1637,6 +1637,8 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
>* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
>* i.MX6DL (v1.31a) have been identified as needing the workaround, with
>* 4 and 1 iterations respectively.
> +  * The Amlogic Meson GX SoCs (v2.01a) have been identifies as needing
> +  * the workaround with a single iteration.
>*/
>  
>   switch (hdmi->version) {
> @@ -1644,6 +1646,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
>   count = 4;
>   break;
>   case 0x131a:
> + case 0x201a:
>   count = 1;
>   break;
>   default:
> 

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

Re: [PATCH 4/8] dma-buf: add peer2peer flag

[Christoph Hellwig]

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote:
> We've broken that assumption in i915 years ago. Not struct page backed
> gpu memory is very real.
> 
> Of course we'll never feed such a strange sg table to a driver which
> doesn't understand it, but allowing sg_page == NULL works perfectly
> fine. At least for gpu drivers.

For GPU drivers on x86 with no dma coherency problems, sure.  But not
all the world is x86.  We already have problems due to dmabugs use
of the awkward get_sgtable interface (see the common on
arm_dma_get_sgtable that I fully agree with), and doing this for memory
that doesn't have a struct page at all will make things even worse.

> If that's not acceptable then I guess we could go over the entire tree
> and frob all the gpu related code to switch over to a new struct
> sg_table_might_not_be_struct_page_backed, including all the other
> functions we added over the past few years to iterate over sg tables.
> But seems slightly silly, given that sg tables seem to do exactly what
> we need.

It isn't silly.  We will have to do some surgery like that anyway
because the current APIs don't work.  So relax, sit back and come up
with an API that solves the existing issues and serves us well in
the future.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/18/2018 08:01 PM, Dongwon Kim wrote:

On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:

On 04/17/2018 11:57 PM, Dongwon Kim wrote:

On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:

On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:

Yeah, I definitely agree on the idea of expanding the use case to the
general domain where dmabuf sharing is used. However, what you are
targetting with proposed changes is identical to the core design of
hyper_dmabuf.

On top of this basic functionalities, hyper_dmabuf has driver level
inter-domain communication, that is needed for dma-buf remote tracking
(no fence forwarding though), event triggering and event handling, extra
meta data exchange and hyper_dmabuf_id that represents grefs
(grefs are shared implicitly on driver level)

This really isn't a positive design aspect of hyperdmabuf imo. The core
code in xen-zcopy (ignoring the ioctl side, which will be cleaned up) is
very simple & clean.

If there's a clear need later on we can extend that. But for now xen-zcopy
seems to cover the basic use-case needs, so gets the job done.


Also it is designed with frontend (common core framework) + backend
(hyper visor specific comm and memory sharing) structure for portability.
We just can't limit this feature to Xen because we want to use the same
uapis not only for Xen but also other applicable hypervisor, like ACORN.

See the discussion around udmabuf and the needs for kvm. I think trying to
make an ioctl/uapi that works for multiple hypervisors is misguided - it
likely won't work.

On top of that the 2nd hypervisor you're aiming to support is ACRN. That's
not even upstream yet, nor have I seen any patches proposing to land linux
support for ACRN. Since it's not upstream, it doesn't really matter for
upstream consideration. I'm doubting that ACRN will use the same grant
references as xen, so the same uapi won't work on ACRN as on Xen anyway.

Yeah, ACRN doesn't have grant-table. Only Xen supports it. But that is why
hyper_dmabuf has been architectured with the concept of backend.
If you look at the structure of backend, you will find that
backend is just a set of standard function calls as shown here:

struct hyper_dmabuf_bknd_ops {
 /* backend initialization routine (optional) */
 int (*init)(void);

 /* backend cleanup routine (optional) */
 int (*cleanup)(void);

 /* retreiving id of current virtual machine */
 int (*get_vm_id)(void);

 /* get pages shared via hypervisor-specific method */
 int (*share_pages)(struct page **pages, int vm_id,
int nents, void **refs_info);

 /* make shared pages unshared via hypervisor specific method */
 int (*unshare_pages)(void **refs_info, int nents);

 /* map remotely shared pages on importer's side via
  * hypervisor-specific method
  */
 struct page ** (*map_shared_pages)(unsigned long ref, int vm_id,
int nents, void **refs_info);

 /* unmap and free shared pages on importer's side via
  * hypervisor-specific method
  */
 int (*unmap_shared_pages)(void **refs_info, int nents);

 /* initialize communication environment */
 int (*init_comm_env)(void);

 void (*destroy_comm)(void);

 /* upstream ch setup (receiving and responding) */
 int (*init_rx_ch)(int vm_id);

 /* downstream ch setup (transmitting and parsing responses) */
 int (*init_tx_ch)(int vm_id);

 int (*send_req)(int vm_id, struct hyper_dmabuf_req *req, int wait);
};

All of these can be mapped with any hypervisor specific implementation.
We designed backend implementation for Xen using grant-table, Xen event
and ring buffer communication. For ACRN, we have another backend using Virt-IO
for both memory sharing and communication.

We tried to define this structure of backend to make it general enough (or
it can be even modified or extended to support more cases.) so that it can
fit to other hypervisor cases. Only requirements/expectation on the hypervisor
are page-level memory sharing and inter-domain communication, which I think
are standard features of modern hypervisor.

And please review common UAPIs that hyper_dmabuf and xen-zcopy supports. They
are very general. One is getting FD (dmabuf) and get those shared. The other
is generating dmabuf from global handle (secure handle hiding gref behind it).
On top of this, hyper_dmabuf has "unshare" and "query" which are also useful
for any cases.

So I don't know why we wouldn't want to try to make these standard in most of
hypervisor cases instead of limiting it to certain hypervisor like Xen.
Frontend-backend structre is optimal for this I think.


So I am wondering we can start with this hyper_dmabuf then modify it for
your use-case if needed and polish and fix any glitches if we want to
to use this 

[PATCH v3 0/2] Enabling content-type setting for HDMI displays.

[StanLis]

From: Stanislav Lisovskiy 

Rev 1:
Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Rev 2:
Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.

Rev 3:
Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  5 +++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 drivers/gpu/drm/i915/intel_atomic.c  |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c|  4 +++
 include/drm/drm_connector.h  | 17 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 9 files changed, 93 insertions(+)

-- 
2.17.0

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

[PATCH v3 2/2] i915: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from
drm_connector_state within AVI infoframe in order to properly handle
external HDMI TV content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c | 1 +
 drivers/gpu/drm/i915/intel_hdmi.c   | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..61ddb5871d8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..078200908b7a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -491,6 +491,9 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   frame.avi.content_type = connector->state->content_type;
+   frame.avi.itc = connector->state->it_content;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -2065,6 +2068,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+   drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
 }
 
-- 
2.17.0

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

[PATCH v3 1/2] drm: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added content_type  property to
drm_connector_state in order to properly handle
external HDMI TV content-type setting.

Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  5 +++
 drivers/gpu/drm/drm_connector.c  | 51 
 drivers/gpu/drm/drm_edid.c   |  2 ++
 include/drm/drm_connector.h  | 17 ++
 include/drm/drm_mode_config.h|  5 +++
 include/uapi/drm/drm_mode.h  |  7 
 7 files changed, 88 insertions(+)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 6b28b014cb7d..ba71184708f3 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""Graphics"", ""Photo"", ""Cinema"", 
""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..8e0f788283f8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1266,6 +1266,9 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   state->content_type = val & 3;
+   state->it_content = val >> 2;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -1351,6 +1354,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->link_status;
} else if (property == config->aspect_ratio_property) {
*val = state->picture_aspect_ratio;
+   } else if (property == config->content_type_property) {
+   *val = state->content_type | (state->it_content << 2);
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde897cd80..757a0712f7c1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -720,6 +720,14 @@ static const struct drm_prop_enum_list 
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
 };
 
+static const struct drm_prop_enum_list drm_content_type_enum_list[] = {
+   { DRM_MODE_CONTENT_TYPE_NO_DATA, "No data" },
+   { DRM_MODE_CONTENT_TYPE_GRAPHICS, "Graphics" },
+   { DRM_MODE_CONTENT_TYPE_PHOTO, "Photo" },
+   { DRM_MODE_CONTENT_TYPE_CINEMA, "Cinema" },
+   { DRM_MODE_CONTENT_TYPE_GAME, "Game" },
+};
+
 static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
@@ -996,6 +1004,22 @@ int drm_mode_create_dvi_i_properties(struct drm_device 
*dev)
 }
 EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
 
+/**
+ * drm_connector_attach_content_type_property - attach content-type property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time a HDMI connector is made.
+ */
+int drm_connector_attach_content_type_property(struct drm_connector *connector)
+{
+   if (!drm_mode_create_content_type_property(connector->dev))
+   drm_object_attach_property(>base,
+   connector->dev->mode_config.content_type_property,
+   DRM_MODE_CONTENT_TYPE_NO_DATA);
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_content_type_property);
+
 /**
  * drm_create_tv_properties - create TV specific connector properties
  * @dev: DRM device
@@ -1260,6 

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

[bugzilla-daemon]

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

--- Comment #14 from Krystian Gałaj  ---
(In reply to Gregor Münch from comment #10)
> Some comments from a VP dev:
> https://www.gamingonlinux.com/articles/the-linux-beta-of-arma-3-has-been-
> updated-to-180-compatible-with-windows-again-for-a-time.11349/
> comment_id=118838
> 
> Seems to be that it's not clear if the bug is on Mesa or VPs side. Maybe
> some Mesa dev could comment.

I am not sure what we could do on VP side to work around the bug. It happens in
a single execution of fragment shader on a multisampled color buffer and depth
buffer. The same execution is writing a color value, and it's supposed to write
a depth value into the corresponding sample of depth buffer. I don't know of
any additional keywords in GLSL that we could specify to make sure this is the
case. If anyone knows about something we're specifying wrong, please advise.

As for rendering techniques used, we are only converting the rendering
technique used by the original Arma 3 developer team from Direct3D API to
OpenGL. So one way of working around the problem would be to ask them to do LOD
switching in another way in future release - and then we could port that new
version. But since it's not happening on the same graphics cards on Windows or
Mac, only on Linux, it isn't likely this rework would be given any high
priority. And we are good at API knowledge and conversion between them, but
inventing another technique to swap in for existing technique in not our game
requires slightly different approach, and, above all, good knowledge of the
entire complicated rendering engine used in the game, so as not to break
anything.

I don't think that working around the problem is a good thing to mention in a
bug ticket... this thing might be happening in other games, maybe not so high
profile, so it would make sense to fix it in driver. It can be done, if it's
working on the same cards using Windows drivers...

-- 
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/amd/display: Disallow enabling CRTC without primary plane with FB

[Michel Dänzer]

[ Dropping stable@ (fixes with Cc: stable are picked up for stable
branches once they land in Linus' tree, there's no point sending them to
stable@ during review), adding dri-devel ]

On 2018-04-18 10:26 PM, Harry Wentland wrote:
> The below commit
> 
> "drm/atomic: Try to preserve the crtc enabled state in 
> drm_atomic_remove_fb, v2"
> 
> introduces a slight behavioral change to rmfb. Instead of disabling a crtc
> when the primary plane is disabled, it now preserves it.
> 
> Since DC is currently not equipped to handle this we need to fail such
> a commit, otherwise we might see a corrupted screen.

How does the caller react to failing such a commit?


> This is based on Shirish's previous approach but avoids adding all
> planes to the new atomic state which leads to a full update in DC for
> any commit, and is not what we intend.
> 
> Theoretically DM should be able to deal with states with fully populated 
> planes,
> even for simple updates, such as cursor updates. This should still be
> addressed in the future.
> 
> Signed-off-by: Harry Wentland 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 6f92a19bebd6..0bdc6b484bad 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4683,6 +4683,7 @@ static int dm_update_crtcs_state(struct 
> amdgpu_display_manager *dm,
>   struct amdgpu_dm_connector *aconnector = NULL;
>   struct drm_connector_state *new_con_state = NULL;
>   struct dm_connector_state *dm_conn_state = NULL;
> + struct drm_plane_state *new_plane_state = NULL;
>  
>   new_stream = NULL;
>  
> @@ -4690,6 +4691,13 @@ static int dm_update_crtcs_state(struct 
> amdgpu_display_manager *dm,
>   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
>   acrtc = to_amdgpu_crtc(crtc);
>  
> + new_plane_state = drm_atomic_get_new_plane_state(state, 
> new_crtc_state->crtc->primary);
> +
> + if (new_crtc_state->enable && new_plane_state && 
> !new_plane_state->fb) {
> + ret = -EINVAL;
> + goto fail;
> + }
> +
>   aconnector = 
> amdgpu_dm_find_first_crtc_matching_connector(state, crtc);
>  
>   /* TODO This hack should go away */
> @@ -4894,7 +4902,7 @@ static int dm_update_planes_state(struct dc *dc,
>   if (!dm_old_crtc_state->stream)
>   continue;
>  
> - DRM_DEBUG_DRIVER("Disabling DRM plane: %d on DRM crtc 
> %d\n",
> + DRM_DEBUG_ATOMIC("Disabling DRM plane: %d on DRM crtc 
> %d\n",
>   plane->base.id, 
> old_plane_crtc->base.id);
>  
>   if (!dc_remove_plane_from_context(
> 


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

Re: [PATCH] drm: Print unadorned pointers

[Alexey Brodkin]

On Wed, 2018-04-18 at 11:29 +0200, Maarten Lankhorst wrote:
> Op 18-04-18 om 11:24 schreef Alexey Brodkin:
> > After commit ad67b74 ("printk: hash addresses printed with %p")
> > pointers are being hashed when printed. However, this makes
> > debug output completely useless. Switch to %px in order to see the
> > unadorned kernel pointers.
> > 
> > This was done with the following one-liner:
> >  find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i 
> > '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} +
> 
> So first we plug a kernel information leak hole, then we introduce it again? 
> Seems like a terrible idea..

Well security concerns are good but what about us poor kernel developers?
Those debug prints are supposed to help us to deal with stuff we develop or fix.

Frankly I was quite surprised when first saw what was "unique hashed ID" instead
of real pointer value. And what's worse there's no way to get previous behavior 
back.
So now we have to manually patch sources here and there to get meaningful data, 
right?

I wouldn't bother sending this patch if there was Kconfig option reverting %p 
behavior
but that was never implemented.

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

Re: [Freedreno] [DPU PATCH v2 2/2] drm/panel: add backlight control support for truly panel

[Bjorn Andersson]

On Wed 18 Apr 21:23 PDT 2018, abhin...@codeaurora.org wrote:

> Hi Bjorn
> 

Hi Abhinav,

> Thanks very much for the detailed response.
> 

You're welcome.

> Yes, we decided that userspace hardcoding this node name is not a
> strong enough reason to register as another backlight device.
> 
> Had one follow up question though.
> 
> The QC WLED driver, drivers/leds/leds-qpnp-wled.c is not registering itself
> as a backlight device.
> 
> It only registers as a led device.
> 
> In that case, we cannot invoke of_find_backlight_by_node to get a handle on
> it.
> 
> One question we have is , is it required that every WLED driver register
> itself as a backlight device too?
> 
> In this case since it is not doing so, but we need to trigger it for the
> backlight.
> 
> Is there any way we can do this?
> 

It seems I answered this in private, so let me summarize my answer for
the record.

The downstream driver for the Qualcomm WLED registers a LED, but the
WLED driver should register a backlight device. There is a driver
(drivers/video/backlight/pm8941-wled.c) that does that for the WLED
version found in PM8941, so the appropriate solution to this problem is
to extend that to support the PMIC you're looking at.

> OR shall we just abandon the backlight control out of this driver entirely.
> 

The backlight handling in the panel driver serves the purpose of
blanking and unblanking the associated backlight device, given the
status of the panel. And this is still considered valuable.

It does sounds like a reasonable idea to extend this to also cover
brightness management, but as you might guess this becomes a larger and
completely generic issue.

Regards,
Bjorn

> Thanks
> 
> Abhinav
> 
> On 2018-04-18 21:00, Bjorn Andersson wrote:
> > On Tue 17 Apr 17:04 PDT 2018, abhin...@codeaurora.org wrote:
> > 
> > > Hi Bjorn
> > > 
> > > Apologies if the prev reply wasnt clear.
> > > 
> > > Hope this one is.
> > > 
> > 
> > Much better, now we can discuss the actual issues :)
> > 
> > > reply inline.
> > > 
> > > On 2018-04-17 14:29, Bjorn Andersson wrote:
> > > > On Tue 17 Apr 11:21 PDT 2018, abhin...@codeaurora.org wrote:
> > > > > On 2018-04-16 23:13, Bjorn Andersson wrote:
> > > > [..]
> > > > > > If the panel isn't actually a piece of backlight hardware then it 
> > > > > > should
> > > > > > not register a backlight device. Why do you need your own sysfs?
> > > > > >
> > > > > > Regards,
> > > > > > Bjorn
> > > > > [Abhinav] This particular panel isnt a piece of backlight hardware.
> > > > > But, we want to have our own sysfs to give flexibility to our
> > > > > userspace
> > > > > to write and read stuff for its proprietary uses.
> > > >
> > > > Please be more specific in your replies, no one will accept code that
> > > > "does stuff" and expecting a reviewer to spend time guessing or pulling
> > > > the information out of you is a sure way to get your patches ignored.
> > > >
> > > > Exactly what kind of stuff are you talking about here and exactly which
> > > > problem are you solving.
> > > >
> > > > > Thats how our downstream has been working so far and hence to maintain
> > > > > the compatibility would like to have it.
> > > >
> > > > Make your proprietary code work with the upstream kernel and you
> > > > shouldn't ever have to modify it.
> > > >
> > > > Regards,
> > > > Bjorn
> > > 
> > > [Abhinav] We have a few userspace clients today for the backlight
> > > sysfs node
> > > which read/write directly to
> > > "/sys/class/backlight/panel0-backlight/brightness"
> > > When I said "stuff" I was only referring to the brightness value.
> > > This separate sysfs node allows us to validate those userspace
> > > features of ours which directly edit the backlight value on our
> > > reference platform.
> > 
> > That's nice, but you're enforcing that either all panel drivers must
> > implement this backlight wrapper or that your customers must modify
> > their user space to match their backlight implementation.
> > 
> > > Since our reference platform uses this panel,hence having our own
> > > sysfs alias helps.  Otherwise, whenever we try to use this panel with
> > > upstream code we will have to end up changing all those places in our
> > > userspace/framework to change the sysfs path.
> > 
> > The actual problem comes down to "how does user space know the name of
> > the backlight instance associated with the panel" and this is a valid
> > question to pursue.
> > 
> > But given your current design you could just scan for the one and only
> > backlight device available in the system; as your use of the static name
> > "panel0-backlight" doesn't allow multiple backlights anyway.
> > 
> > 
> > If your goal is simply to ship your reference with something that you
> > can show work, then just replace the hard coded panel0-backlight with
> > the name of the wled backlight device. Customers can change panels as
> > they wish, but in the event that they plug in a different backlight
> > controller they would need to modify the 

[PATCH v1 1/4] dt-bindings: gpu: mali-utgard: add mediatek, mt7623-mali compatible

[sean.wang]

From: Sean Wang 

The MediaTek MT7623 SoC contains a Mali-450, so add a compatible for it
and define its own vendor-specific properties.

Signed-off-by: Sean Wang 
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
index c1f65d1..e149995 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
@@ -20,6 +20,7 @@ Required properties:
   + rockchip,rk3228-mali
   + rockchip,rk3328-mali
   + stericsson,db8500-mali
+  + mediatek,mt7623-mali
 
   - reg: Physical base address and length of the GPU registers
 
@@ -86,6 +87,14 @@ to specify one more vendor-specific compatible, among:
   * interrupt-names and interrupts:
 + combined: combined interrupt of all of the above lines
 
+  - mediatek,mt7623-mali
+ Required properties:
+  * resets: phandle to the reset line for the GPU
+  * mediatek,larb: phandle pointed to the local arbiter used to control the
+   access to external memory on the SoC.
+   see 
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+   for details
+
 Example:
 
 mali: gpu@1c4 {
-- 
2.7.4

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

[[RFC]DPU PATCH 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[Sandeep Panda]

Document the bindings used for the sn65dsi86 DSI to eDP bridge.

Signed-off-by: Sandeep Panda 
---
 .../bindings/display/bridge/ti,sn65dsi86.txt   | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 000..9e2612e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,60 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specifications for bridge_en pin
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+
+Optional properties:
+
+- irq-gpios: OF device-tree gpio specification for interrupt pin
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+   compatible = "ti,sn65dsi86";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x2d>;
+
+   enable-gpios = < 33 GPIO_ACTIVE_HIGH>;
+
+   vccio-supply = <_l17>;
+   vcca-supply = <_l6>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   edp_bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   edp_bridge_out: endpoint {
+   remote-endpoint = <_panel_in>;
+   };
+   };
+   };
+}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[[RFC]DPU PATCH 4/4] dt-bindings: Add Innolux TV123WAM panel bindings

[Sandeep Panda]

The Innolux TV123WAM is a 12.3" eDP display panel
with 2160x1440 resolution.

Signed-off-by: Sandeep Panda 
---
 .../bindings/display/panel/innolux,edp-2k-panel.txt | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt
new file mode 100644
index 000..19f271c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt
@@ -0,0 +1,21 @@
+Innolux TV123WAM 12.3 inch eDP display panel
+
+Required properties:
+- power-supply: regulator to provide the supply voltage
+- enable-gpios: GPIO pin to enable or disable the panel
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   edp_panel: edp_panel {
+   compatible = "innolux, edp_2k_panel";
+   reg = <0>;
+
+   enable-gpios = < 32 GPIO_ACTIVE_HIGH>;
+
+   power-supply = <_l8>;
+
+   backlight = <>;
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [[RFC]DPU PATCH 0/4] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel driver

[spanda]

On 2018-04-18 19:42, Sean Paul wrote:

On Wed, Apr 18, 2018 at 05:49:58PM +0530, Sandeep Panda wrote:

Changelog:

v3 -> v4:


I didn't really bother to do a thorough review given that there are 
obvious
mistakes and ignored feedback, it's a waste of time, tbh. Please go 
through

the previous reviews and resend a more polished version.


I have replied to your review comments. Please review the edp driver, so 
that

i can address all the comments together while uploading next patchset.


Sean

Current patchset separates out eDP panel specific resources from 
sn65dsi86

bridge driver and creates a separate driver for the innloux edp panel.

Now bridge driver check if any panel is attached or not to get the 
supported
modes. If any panel is attached then query from panel driver to get 
the modes,

or else probe the provided i2c adapter to read the modes from EDID.

Removed hardcoding of bridge init sequence. With this patchset bridge 
driver now
will program the init sequence based on the current mode set by drm 
framework.


Current patchset is not tested on actual bridge chip/panel.

Sandeep Panda (4):
  drm/bridge: add support for sn65dsi86 bridge driver
  dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
  drm/panel: add Innolux TV123WAM eDP panel driver
  dt-bindings: Add Innolux TV123WAM panel bindings

 .../bindings/display/bridge/ti,sn65dsi86.txt   |  60 ++
 .../display/panel/innolux,edp-2k-panel.txt |  21 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c  | 742 
+

 drivers/gpu/drm/panel/panel-innolux-tv123wam.c | 299 +
 4 files changed, 1122 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,edp-2k-panel.txt

 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
 create mode 100644 drivers/gpu/drm/panel/panel-innolux-tv123wam.c

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project


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

[PATCH v9 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Jacopo Mondi]

Document Thine THC63LVD1024 LVDS decoder device tree bindings.

Signed-off-by: Jacopo Mondi 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Niklas Söderlund 
Reviewed-by: Laurent Pinchart 
Reviewed-by: Rob Herring 
---
 .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

diff --git 
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..37f0c04
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,60 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two LVDS input streams and up to two digital CMOS/TTL outputs.
+
+Single or dual operation mode, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+- vcc-supply: Power supply for TTL output, TTL CLOCKOUT signal, LVDS input,
+  PPL and digital circuitry
+
+Optional properties:
+- powerdown-gpios: Power down GPIO signal, pin name "/PDWN". Active low
+- oe-gpios: Output enable GPIO signal, pin name "OE". Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- port@0: First LVDS input port
+- port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- port@1: Second LVDS input port
+- port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+   thc63lvd1024: lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+
+   vcc-supply = <_lvds_vcc>;
+   powerdown-gpios = < 15 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   lvds_dec_in_0: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2{
+   reg = <2>;
+
+   lvds_dec_out_2: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
2.7.4

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