date:20170119

MHL3 requires that after reading EDID from the sink source should ask
peer for features. To make both protocols happy the patch splits the code
accordingly.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 6ef1a4d..d0e6dc3 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -482,6 +482,13 @@ static void sii8620_sink_detected(struct sii8620 *ctx, int 
ret)
 
dev_info(dev, "detected sink(type: %s): %s\n",
 sink_str[ctx->sink_type], sink_name);
+}
+
+static void sii8620_edid_read(struct sii8620 *ctx, int ret)
+{
+   if (ret < 0)
+   return;
+
sii8620_set_upstream_edid(ctx);
sii8620_enable_hpd(ctx);
 }
@@ -787,12 +794,12 @@ static void sii8620_fetch_edid(struct sii8620 *ctx)
edid = new_edid;
}
}
-
-   if (fetched + FETCH_SIZE == edid_len)
-   sii8620_write(ctx, REG_INTR3, int3);
}
 
-   sii8620_write(ctx, REG_LM_DDC, lm_ddc);
+   sii8620_write_seq(ctx,
+   REG_INTR3_MASK, BIT_DDC_CMD_DONE,
+   REG_LM_DDC, lm_ddc
+   );
 
 end:
kfree(ctx->edid);
@@ -1706,6 +1713,21 @@ static void sii8620_irq_block(struct sii8620 *ctx)
sii8620_write(ctx, REG_EMSCINTR, stat);
 }
 
+static void sii8620_irq_ddc(struct sii8620 *ctx)
+{
+   u8 stat = sii8620_readb(ctx, REG_INTR3);
+
+   if (stat & BIT_DDC_CMD_DONE) {
+   sii8620_write(ctx, REG_INTR3_MASK, 0);
+   if (sii8620_is_mhl3(ctx))
+   sii8620_mt_set_int(ctx, MHL_INT_REG(RCHANGE),
+  MHL_INT_RC_FEAT_REQ);
+   else
+   sii8620_edid_read(ctx, 0);
+   }
+   sii8620_write(ctx, REG_INTR3, stat);
+}
+
 /* endian agnostic, non-volatile version of test_bit */
 static bool sii8620_test_bit(unsigned int nr, const u8 *addr)
 {
@@ -1726,6 +1748,7 @@ static irqreturn_t sii8620_irq_thread(int irq, void *data)
{ BIT_FAST_INTR_STAT_MERR, sii8620_irq_merr },
{ BIT_FAST_INTR_STAT_BLOCK, sii8620_irq_block },
{ BIT_FAST_INTR_STAT_EDID, sii8620_irq_edid },
+   { BIT_FAST_INTR_STAT_DDC, sii8620_irq_ddc },
{ BIT_FAST_INTR_STAT_SCDT, sii8620_irq_scdt },
{ BIT_FAST_INTR_STAT_INFR, sii8620_irq_infr },
};
-- 
2.7.4

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

[PATCH 24/24] drm/bridge/sii8620: enable interlace modes

Bug in DECON(CRTC) driver prevented interlace modes from proper work.
Since DECON is fixed interlace modes can be enabled in MHL.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 57ad0b4..d3c7c21 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2083,9 +2083,6 @@ static bool sii8620_mode_fixup(struct drm_bridge *bridge,
int max_lclk;
bool ret = true;
 
-   if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
-
mutex_lock(>lock);
 
max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
-- 
2.7.4

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

[PATCH 23/24] drm/bridge/sii8620: enable MHL3 mode if possible

Since all sub-protocols of MHL3 are already supported MHL3 mode can be enabled.
With this patch it is possible to use packed pixel modes and clocks up
to 300MHz - 1920x1080@60Hz and 4K modes.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 50bfb3c..57ad0b4 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1372,8 +1372,7 @@ static void sii8620_mhl_init(struct sii8620 *ctx)
);
sii8620_disable_gen2_write_burst(ctx);
 
-   /* currently MHL3 is not supported, so we force version to 0 */
-   sii8620_mt_write_stat(ctx, MHL_DST_REG(VERSION), 0);
+   sii8620_mt_write_stat(ctx, MHL_DST_REG(VERSION), SII8620_MHL_VERSION);
sii8620_mt_write_stat(ctx, MHL_DST_REG(CONNECTED_RDY),
  MHL_DST_CONN_DCAP_RDY | MHL_DST_CONN_XDEVCAPP_SUPP
  | MHL_DST_CONN_POW_STAT);
@@ -1640,14 +1639,16 @@ static void sii8620_irq_g2wb(struct sii8620 *ctx)
sii8620_write(ctx, REG_MDT_INT_0, stat);
 }
 
-static void sii8620_status_changed_dcap(struct sii8620 *ctx)
+static void sii8620_status_dcap_ready(struct sii8620 *ctx)
 {
-   if (ctx->stat[MHL_DST_CONNECTED_RDY] & MHL_DST_CONN_DCAP_RDY) {
-   sii8620_set_mode(ctx, CM_MHL1);
-   sii8620_peer_specific_init(ctx);
-   sii8620_write(ctx, REG_INTR9_MASK, BIT_INTR9_DEVCAP_DONE
-  | BIT_INTR9_EDID_DONE | BIT_INTR9_EDID_ERROR);
-   }
+   enum sii8620_mode mode;
+
+   mode = ctx->stat[MHL_DST_VERSION] >= 0x30 ? CM_MHL3 : CM_MHL1;
+   if (mode > ctx->mode)
+   sii8620_set_mode(ctx, mode);
+   sii8620_peer_specific_init(ctx);
+   sii8620_write(ctx, REG_INTR9_MASK, BIT_INTR9_DEVCAP_DONE
+ | BIT_INTR9_EDID_DONE | BIT_INTR9_EDID_ERROR);
 }
 
 static void sii8620_status_changed_path(struct sii8620 *ctx)
@@ -1675,8 +1676,8 @@ static void sii8620_msc_mr_write_stat(struct sii8620 *ctx)
sii8620_update_array(ctx->stat, st, MHL_DST_SIZE);
sii8620_update_array(ctx->xstat, xst, MHL_XDS_SIZE);
 
-   if (st[MHL_DST_CONNECTED_RDY] & MHL_DST_CONN_DCAP_RDY)
-   sii8620_status_changed_dcap(ctx);
+   if (ctx->stat[MHL_DST_CONNECTED_RDY] & MHL_DST_CONN_DCAP_RDY)
+   sii8620_status_dcap_ready(ctx);
 
if (st[MHL_DST_LINK_MODE] & MHL_DST_LM_PATH_ENABLED)
sii8620_status_changed_path(ctx);
-- 
2.7.4

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

[PATCH 19/24] drm/bridge/sii8620: rewrite hdmi start sequence

MHL3 protocol requires registry adjustments depending on chosen video mode.
Necessary information is gathered in mode_fixup callback. In case of HDMI
video modes driver should also send special AVI and MHL infoframes.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 249 +++
 drivers/gpu/drm/bridge/sil-sii8620.h |  15 ++-
 2 files changed, 231 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 1c76905..2c7b5b9 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -32,6 +32,8 @@
 
 #define SII8620_BURST_BUF_LEN 288
 #define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+#define MHL1_MAX_LCLK 225000
+#define MHL3_MAX_LCLK 60
 
 enum sii8620_mode {
CM_DISCONNECTED,
@@ -62,6 +64,9 @@ struct sii8620 {
struct regulator_bulk_data supplies[2];
struct mutex lock; /* context lock, protects fields below */
int error;
+   int pixel_clock;
+   unsigned int use_packed_pixel:1;
+   int video_code;
enum sii8620_mode mode;
enum sii8620_sink_type sink_type;
u8 cbus_status;
@@ -69,7 +74,7 @@ struct sii8620 {
u8 xstat[MHL_XDS_SIZE];
u8 devcap[MHL_DCAP_SIZE];
u8 xdevcap[MHL_XDC_SIZE];
-   u8 avif[19];
+   u8 avif[HDMI_INFOFRAME_SIZE(AVI)];
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
@@ -685,6 +690,40 @@ static void sii8620_burst_tx_rbuf_info(struct sii8620 
*ctx, int size)
d->size = cpu_to_le16(size);
 }
 
+static u8 sii8620_checksum(void *ptr, int size)
+{
+   u8 *d = ptr, sum = 0;
+
+   while (size--)
+   sum += *d++;
+
+   return sum;
+}
+
+static void sii8620_mhl_burst_hdr_set(struct mhl3_burst_header *h,
+   enum mhl_burst_id id)
+{
+   h->id = cpu_to_be16(id);
+   h->total_entries = 1;
+   h->sequence_index = 1;
+}
+
+static void sii8620_burst_tx_bits_per_pixel_fmt(struct sii8620 *ctx, u8 fmt)
+{
+   struct mhl_burst_bits_per_pixel_fmt *d;
+   const int size = sizeof(*d) + sizeof(d->desc[0]);
+
+   d = sii8620_burst_get_tx_buf(ctx, size);
+   if (!d)
+   return;
+
+   sii8620_mhl_burst_hdr_set(>hdr, MHL_BURST_ID_BITS_PER_PIXEL_FMT);
+   d->num_entries = 1;
+   d->desc[0].stream_id = 0;
+   d->desc[0].pixel_format = fmt;
+   d->hdr.checksum -= sii8620_checksum(d, size);
+}
+
 static void sii8620_burst_rx_all(struct sii8620 *ctx)
 {
u8 *d = ctx->burst.rx_buf;
@@ -949,32 +988,162 @@ static void sii8620_stop_video(struct sii8620 *ctx)
sii8620_write(ctx, REG_TPI_SC, val);
 }
 
+static void sii8620_set_format(struct sii8620 *ctx)
+{
+   u8 out_fmt;
+
+   if (sii8620_is_mhl3(ctx)) {
+   sii8620_setbits(ctx, REG_M3_P0CTRL,
+   BIT_M3_P0CTRL_MHL3_P0_PIXEL_MODE_PACKED,
+   ctx->use_packed_pixel ? ~0 : 0);
+   } else {
+   if (ctx->use_packed_pixel)
+   sii8620_write_seq_static(ctx,
+   REG_VID_MODE, BIT_VID_MODE_M1080P,
+   REG_MHL_TOP_CTL, BIT_MHL_TOP_CTL_MHL_PP_SEL | 1,
+   REG_MHLTX_CTL6, 0x60
+   );
+   else
+   sii8620_write_seq_static(ctx,
+   REG_VID_MODE, 0,
+   REG_MHL_TOP_CTL, 1,
+   REG_MHLTX_CTL6, 0xa0
+   );
+   }
+
+   if (ctx->use_packed_pixel)
+   out_fmt = VAL_TPI_FORMAT(YCBCR422, FULL) |
+   BIT_TPI_OUTPUT_CSCMODE709;
+   else
+   out_fmt = VAL_TPI_FORMAT(RGB, FULL);
+
+   sii8620_write_seq(ctx,
+   REG_TPI_INPUT, VAL_TPI_FORMAT(RGB, FULL),
+   REG_TPI_OUTPUT, out_fmt,
+   );
+}
+
+#define MHL3_VSIF_TYPE 0x81
+#define MHL3_VSIF_VERSION  0x03
+#define MHL3_VSIF_LENGTH   0x0f
+#define IEEE_OUI_MHL3  0x7CA61D
+
+static void sii8620_mhl_infoframe_init(void *ptr, int size)
+{
+   u8 *buf = ptr;
+
+   memset(buf, 0, size);
+   buf[0] = MHL3_VSIF_TYPE;
+   buf[1] = MHL3_VSIF_VERSION;
+   buf[2] = MHL3_VSIF_LENGTH;
+   buf[4] = IEEE_OUI_MHL3 & 0xff;
+   buf[5] = (IEEE_OUI_MHL3 >> 8) & 0xff;
+   buf[6] = (IEEE_OUI_MHL3 >> 16) & 0xff;
+   buf[3] -= sii8620_checksum(buf, MHL3_VSIF_LENGTH);
+}
+
+static void sii8620_set_infoframes(struct sii8620 *ctx)
+{
+   union hdmi_infoframe frm;
+   u8 buf[31];
+   int ret;
+
+   if (!sii8620_is_mhl3(ctx) || !ctx->use_packed_pixel) {
+   sii8620_write(ctx, REG_TPI_SC,
+   BIT_TPI_SC_TPI_OUTPUT_MODE_0_HDMI);
+   sii8620_write_buf(ctx, REG_TPI_AVI_CHSUM,

[PATCH 18/24] drm/bridge/sii8620: fix disconnect sequence

The patch allows to avoid rare cases when discovery fails.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index d0e6dc3..1c76905 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1286,10 +1286,12 @@ static void sii8620_disconnect(struct sii8620 *ctx)
 {
sii8620_disable_gen2_write_burst(ctx);
sii8620_stop_video(ctx);
-   msleep(50);
+   msleep(100);
sii8620_cbus_reset(ctx);
sii8620_set_mode(ctx, CM_DISCONNECTED);
sii8620_write_seq_static(ctx,
+   REG_TX_ZONE_CTL1, 0,
+   REG_MHL_PLL_CTL0, 0x07,
REG_COC_CTL0, 0x40,
REG_CBUS3_CNVT, 0x84,
REG_COC_CTL14, 0x00,
-- 
2.7.4

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

[PATCH 22/24] drm/bridge/sii8620: add HSIC initialization code

In case of MHL3 HSIC should be initialized.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 38 
 drivers/gpu/drm/bridge/sil-sii8620.h | 10 ++
 2 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 77c9fb2..50bfb3c 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -489,12 +489,50 @@ static void sii8620_sink_detected(struct sii8620 *ctx, 
int ret)
 sink_str[ctx->sink_type], sink_name);
 }
 
+static void sii8620_hsic_init(struct sii8620 *ctx)
+{
+   if (!sii8620_is_mhl3(ctx))
+   return;
+
+   sii8620_write(ctx, REG_FCGC,
+   BIT_FCGC_HSIC_HOSTMODE | BIT_FCGC_HSIC_ENABLE);
+   sii8620_setbits(ctx, REG_HRXCTRL3,
+   BIT_HRXCTRL3_HRX_STAY_RESET | BIT_HRXCTRL3_STATUS_EN, ~0);
+   sii8620_setbits(ctx, REG_TTXNUMB, MSK_TTXNUMB_TTX_NUMBPS, 4);
+   sii8620_setbits(ctx, REG_TRXCTRL, BIT_TRXCTRL_TRX_FROM_SE_COC, ~0);
+   sii8620_setbits(ctx, REG_HTXCTRL, BIT_HTXCTRL_HTX_DRVCONN1, 0);
+   sii8620_setbits(ctx, REG_KEEPER, MSK_KEEPER_MODE, VAL_KEEPER_MODE_HOST);
+   sii8620_write_seq_static(ctx,
+   REG_TDMLLCTL, 0,
+   REG_UTSRST, BIT_UTSRST_HRX_SRST | BIT_UTSRST_HTX_SRST |
+   BIT_UTSRST_KEEPER_SRST | BIT_UTSRST_FC_SRST,
+   REG_UTSRST, BIT_UTSRST_HRX_SRST | BIT_UTSRST_HTX_SRST,
+   REG_HRXINTL, 0xff,
+   REG_HRXINTH, 0xff,
+   REG_TTXINTL, 0xff,
+   REG_TTXINTH, 0xff,
+   REG_TRXINTL, 0xff,
+   REG_TRXINTH, 0xff,
+   REG_HTXINTL, 0xff,
+   REG_HTXINTH, 0xff,
+   REG_FCINTR0, 0xff,
+   REG_FCINTR1, 0xff,
+   REG_FCINTR2, 0xff,
+   REG_FCINTR3, 0xff,
+   REG_FCINTR4, 0xff,
+   REG_FCINTR5, 0xff,
+   REG_FCINTR6, 0xff,
+   REG_FCINTR7, 0xff
+   );
+}
+
 static void sii8620_edid_read(struct sii8620 *ctx, int ret)
 {
if (ret < 0)
return;
 
sii8620_set_upstream_edid(ctx);
+   sii8620_hsic_init(ctx);
sii8620_enable_hpd(ctx);
 }
 
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.h 
b/drivers/gpu/drm/bridge/sil-sii8620.h
index e42c1c3..30cc992 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.h
+++ b/drivers/gpu/drm/bridge/sil-sii8620.h
@@ -353,7 +353,7 @@
 #define REG_TTXNUMB0x0116
 #define MSK_TTXNUMB_TTX_AFFCTRL_3_00xf0
 #define BIT_TTXNUMB_TTX_COM1_AT_SYNC_WAIT  BIT(3)
-#define MSK_TTXNUMB_TTX_NUMBPS_2_0 0x07
+#define MSK_TTXNUMB_TTX_NUMBPS 0x07
 
 /* TDM TX NUMSPISYM, default value: 0x04 */
 #define REG_TTXSPINUMS 0x0117
@@ -433,12 +433,14 @@
 
 /* HSIC Keeper, default value: 0x00 */
 #define REG_KEEPER 0x0181
-#define MSK_KEEPER_KEEPER_MODE_1_0 0x03
+#define MSK_KEEPER_MODE0x03
+#define VAL_KEEPER_MODE_HOST   0
+#define VAL_KEEPER_MODE_DEVICE 2
 
 /* HSIC Flow Control General, default value: 0x02 */
 #define REG_FCGC   0x0183
-#define BIT_FCGC_HSIC_FC_HOSTMODE  BIT(1)
-#define BIT_FCGC_HSIC_FC_ENABLEBIT(0)
+#define BIT_FCGC_HSIC_HOSTMODE BIT(1)
+#define BIT_FCGC_HSIC_ENABLE   BIT(0)
 
 /* HSIC Flow Control CTR13, default value: 0xfc */
 #define REG_FCCTR130x0191
-- 
2.7.4

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

[PATCH 20/24] drm/bridge/sii8620: send EMSC features on request

Device should report to the peer which features are really supported.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 27 +++
 drivers/gpu/drm/bridge/sil-sii8620.h | 16 
 2 files changed, 31 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2c7b5b9..2cc197d 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1644,6 +1644,25 @@ static void sii8620_got_ecbus_speed(struct sii8620 *ctx, 
int ret)
sii8620_mt_set_cont(ctx, sii8620_ecbus_up);
 }
 
+static void sii8620_mhl_burst_emsc_support_set(struct mhl_burst_emsc_support 
*d,
+   enum mhl_burst_id id)
+{
+   sii8620_mhl_burst_hdr_set(>hdr, MHL_BURST_ID_EMSC_SUPPORT);
+   d->num_entries = 1;
+   d->burst_id[0] = cpu_to_be16(id);
+}
+
+static void sii8620_send_features(struct sii8620 *ctx)
+{
+   u8 buf[16];
+
+   sii8620_write(ctx, REG_MDT_XMIT_CTRL, BIT_MDT_XMIT_CTRL_EN
+   | BIT_MDT_XMIT_CTRL_FIXED_BURST_LEN);
+   sii8620_mhl_burst_emsc_support_set((void *)buf,
+   MHL_BURST_ID_HID_PAYLOAD);
+   sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
+}
+
 static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
 {
u8 ints[MHL_INT_SIZE];
@@ -1664,10 +1683,10 @@ static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
break;
}
}
-   if (ints[MHL_INT_RCHANGE] & MHL_INT_RC_FEAT_REQ) {
-   sii8620_mt_set_int(ctx, MHL_INT_REG(RCHANGE),
-  MHL_INT_RC_FEAT_COMPLETE);
-   }
+   if (ints[MHL_INT_RCHANGE] & MHL_INT_RC_FEAT_REQ)
+   sii8620_send_features(ctx);
+   if (ints[MHL_INT_RCHANGE] & MHL_INT_RC_FEAT_COMPLETE)
+   sii8620_edid_read(ctx, 0);
 }
 
 static struct sii8620_mt_msg *sii8620_msc_msg_first(struct sii8620 *ctx)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.h 
b/drivers/gpu/drm/bridge/sil-sii8620.h
index aefae67..e42c1c3 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.h
+++ b/drivers/gpu/drm/bridge/sil-sii8620.h
@@ -1298,14 +1298,14 @@
 
 /* MDT Transmit Control, default value: 0x70 */
 #define REG_MDT_XMIT_CTRL  0x0588
-#define BIT_MDT_XMIT_CTRL_MDT_XMIT_EN  BIT(7)
-#define BIT_MDT_XMIT_CTRL_MDT_XMIT_CMD_MERGE_ENBIT(6)
-#define BIT_MDT_XMIT_CTRL_MDT_XMIT_FIXED_BURST_LEN BIT(5)
-#define BIT_MDT_XMIT_CTRL_MDT_XMIT_FIXED_AID   BIT(4)
-#define BIT_MDT_XMIT_CTRL_MDT_XMIT_SINGLE_RUN_EN BIT(3)
-#define BIT_MDT_XMIT_CTRL_MDT_CLR_ABORT_WAIT   BIT(2)
-#define BIT_MDT_XMIT_CTRL_MDT_XFIFO_CLR_ALLBIT(1)
-#define BIT_MDT_XMIT_CTRL_MDT_XFIFO_CLR_CURBIT(0)
+#define BIT_MDT_XMIT_CTRL_EN   BIT(7)
+#define BIT_MDT_XMIT_CTRL_CMD_MERGE_EN BIT(6)
+#define BIT_MDT_XMIT_CTRL_FIXED_BURST_LEN  BIT(5)
+#define BIT_MDT_XMIT_CTRL_FIXED_AIDBIT(4)
+#define BIT_MDT_XMIT_CTRL_SINGLE_RUN_ENBIT(3)
+#define BIT_MDT_XMIT_CTRL_CLR_ABORT_WAIT   BIT(2)
+#define BIT_MDT_XMIT_CTRL_XFIFO_CLR_ALLBIT(1)
+#define BIT_MDT_XMIT_CTRL_XFIFO_CLR_CURBIT(0)
 
 /* MDT Receive WRITE Port, default value: 0x00 */
 #define REG_MDT_XMIT_WRITE_PORT0x0589
-- 
2.7.4

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

[PATCH 16/24] drm/bridge/sii8620: add delay during cbus reset

Without delay CBUS sometimes was not reset properly.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index e84cda0..6ef1a4d 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -891,11 +891,10 @@ static void sii8620_hw_reset(struct sii8620 *ctx)
 
 static void sii8620_cbus_reset(struct sii8620 *ctx)
 {
-   sii8620_write_seq_static(ctx,
-   REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST
-   | BIT_PWD_SRST_CBUS_RST_SW_EN,
-   REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST_SW_EN
-   );
+   sii8620_write(ctx, REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST
+ | BIT_PWD_SRST_CBUS_RST_SW_EN);
+   usleep_range(1, 2);
+   sii8620_write(ctx, REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST_SW_EN);
 }
 
 static void sii8620_set_auto_zone(struct sii8620 *ctx)
-- 
2.7.4

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

[PATCH 05/24] drm/bridge/sii8620: initial support for eCBUS-S mode

The Single-ended eCBUS Mode (eCBUS-S) mode provides 60 Mb/s full-duplex
bidirectional traffic for three channels:
 - CBUS data (CBUS1 channel),
 - High-bandwidth MHL data (eMSC channel),
 - tunneling data (T-CBUS channel).
It is required to fully support MHL3 dongles.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 104 ++-
 drivers/gpu/drm/bridge/sil-sii8620.h |   5 ++
 2 files changed, 107 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index cde0074..9f9fd99 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -104,6 +104,7 @@ static void sii8620_fetch_edid(struct sii8620 *ctx);
 static void sii8620_set_upstream_edid(struct sii8620 *ctx);
 static void sii8620_enable_hpd(struct sii8620 *ctx);
 static void sii8620_mhl_disconnected(struct sii8620 *ctx);
+static void sii8620_disconnect(struct sii8620 *ctx);
 
 static int sii8620_clear_error(struct sii8620 *ctx)
 {
@@ -1016,13 +1017,44 @@ static void sii8620_mhl_init(struct sii8620 *ctx)
sii8620_mt_set_int(ctx, MHL_INT_REG(RCHANGE), MHL_INT_RC_DCAP_CHG);
 }
 
+static void sii8620_emsc_enable(struct sii8620 *ctx)
+{
+   u8 reg;
+
+   sii8620_setbits(ctx, REG_GENCTL, BIT_GENCTL_EMSC_EN
+| BIT_GENCTL_CLR_EMSC_RFIFO
+| BIT_GENCTL_CLR_EMSC_XFIFO, ~0);
+   sii8620_setbits(ctx, REG_GENCTL, BIT_GENCTL_CLR_EMSC_RFIFO
+| BIT_GENCTL_CLR_EMSC_XFIFO, 0);
+   sii8620_setbits(ctx, REG_COMMECNT, BIT_COMMECNT_I2C_TO_EMSC_EN, ~0);
+   reg = sii8620_readb(ctx, REG_EMSCINTR);
+   sii8620_write(ctx, REG_EMSCINTR, reg);
+   sii8620_write(ctx, REG_EMSCINTRMASK, BIT_EMSCINTR_SPI_DVLD);
+}
+
+static int sii8620_wait_for_fsm_state(struct sii8620 *ctx, u8 state)
+{
+   int i;
+
+   for (i = 0; i < 10; ++i) {
+   u8 s = sii8620_readb(ctx, REG_COC_STAT_0);
+
+   if ((s & MSK_COC_STAT_0_FSM_STATE) == state)
+   return 0;
+   if (s & BIT_COC_STAT_0_PLL_LOCKED)
+   return -EBUSY;
+   usleep_range(4000, 6000);
+   }
+   return -ETIMEDOUT;
+}
+
 static void sii8620_set_mode(struct sii8620 *ctx, enum sii8620_mode mode)
 {
+   int ret;
+
if (ctx->mode == mode)
return;
 
-   ctx->mode = mode;
-
switch (mode) {
case CM_MHL1:
sii8620_write_seq_static(ctx,
@@ -1032,11 +1064,46 @@ static void sii8620_set_mode(struct sii8620 *ctx, enum 
sii8620_mode mode)
| BIT_DPD_OSC_EN,
REG_COC_INTR_MASK, 0
);
+   ctx->mode = mode;
break;
case CM_MHL3:
sii8620_write(ctx, REG_M3_CTRL, VAL_M3_CTRL_MHL3_VALUE);
+   ctx->mode = mode;
+   return;
+   case CM_ECBUS_S:
+   sii8620_emsc_enable(ctx);
+   sii8620_write_seq_static(ctx,
+   REG_TTXSPINUMS, 4,
+   REG_TRXSPINUMS, 4,
+   REG_TTXHSICNUMS, 0x14,
+   REG_TRXHSICNUMS, 0x14,
+   REG_TTXTOTNUMS, 0x18,
+   REG_TRXTOTNUMS, 0x18,
+   REG_PWD_SRST, BIT_PWD_SRST_COC_DOC_RST
+ | BIT_PWD_SRST_CBUS_RST_SW_EN,
+   REG_MHL_COC_CTL1, 0xbd,
+   REG_PWD_SRST, BIT_PWD_SRST_CBUS_RST_SW_EN,
+   REG_COC_CTLB, 0x01,
+   REG_COC_CTL0, 0x5c,
+   REG_COC_CTL14, 0x03,
+   REG_COC_CTL15, 0x80,
+   REG_MHL_DP_CTL6, BIT_MHL_DP_CTL6_DP_TAP1_SGN
+| BIT_MHL_DP_CTL6_DP_TAP1_EN
+| BIT_MHL_DP_CTL6_DT_PREDRV_FEEDCAP_EN,
+   REG_MHL_DP_CTL8, 0x03
+   );
+   ret = sii8620_wait_for_fsm_state(ctx, 0x03);
+   sii8620_write_seq_static(ctx,
+   REG_COC_CTL14, 0x00,
+   REG_COC_CTL15, 0x80
+   );
+   if (!ret)
+   sii8620_write(ctx, REG_CBUS3_CNVT, 0x85);
+   else
+   sii8620_disconnect(ctx);
return;
case CM_DISCONNECTED:
+   ctx->mode = mode;
break;
default:
dev_err(ctx->dev, "%s mode %d not supported\n", __func__, mode);
@@ -1229,12 +1296,45 @@ static void sii8620_msc_mr_write_stat(struct sii8620 
*ctx)
sii8620_status_changed_path(ctx);
 }
 
+static void sii8620_ecbus_up(struct sii8620 *ctx, int ret)
+{
+   if (ret < 0)
+   return;
+
+

[PATCH 07/24] drm/bridge/sii8620: add support for burst eMSC transmissions

Burst transmissions are used in MHL3 mode negotiation.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 196 ++-
 drivers/gpu/drm/bridge/sil-sii8620.h |   4 +
 2 files changed, 198 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9f9fd99..744e685 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -9,6 +9,8 @@
  * published by the Free Software Foundation.
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -28,7 +30,8 @@
 
 #include "sil-sii8620.h"
 
-#define VAL_RX_HDMI_CTRL2_DEFVAL   VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+#define SII8620_BURST_BUF_LEN 288
+#define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
 
 enum sii8620_mode {
CM_DISCONNECTED,
@@ -71,6 +74,15 @@ struct sii8620 {
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
struct list_head mt_queue;
+   struct {
+   int r_size;
+   int r_count;
+   int rx_ack;
+   int rx_count;
+   u8 rx_buf[32];
+   int tx_count;
+   u8 tx_buf[32];
+   } burst;
 };
 
 struct sii8620_mt_msg;
@@ -511,6 +523,134 @@ static inline void sii8620_mt_read_xdevcap_reg(struct 
sii8620 *ctx, u8 reg)
sii8620_mt_read_devcap_reg(ctx, reg | 0x80);
 }
 
+static void *sii8620_burst_get_tx_buf(struct sii8620 *ctx, int len)
+{
+   u8 *buf = >burst.tx_buf[ctx->burst.tx_count];
+   int size = len + 2;
+
+   if (ctx->burst.tx_count + size > ARRAY_SIZE(ctx->burst.tx_buf)) {
+   dev_err(ctx->dev, "TX-BLK buffer exhausted\n");
+   ctx->error = -EINVAL;
+   return NULL;
+   }
+
+   ctx->burst.tx_count += size;
+   buf[1] = len;
+
+   return buf + 2;
+}
+
+static u8 *sii8620_burst_get_rx_buf(struct sii8620 *ctx, int len)
+{
+   u8 *buf = >burst.rx_buf[ctx->burst.rx_count];
+   int size = len + 1;
+
+   if (ctx->burst.tx_count + size > ARRAY_SIZE(ctx->burst.tx_buf)) {
+   dev_err(ctx->dev, "RX-BLK buffer exhausted\n");
+   ctx->error = -EINVAL;
+   return NULL;
+   }
+
+   ctx->burst.rx_count += size;
+   buf[0] = len;
+
+   return buf + 1;
+}
+
+static void sii8620_burst_send(struct sii8620 *ctx)
+{
+   int tx_left = ctx->burst.tx_count;
+   u8 *d = ctx->burst.tx_buf;
+
+   while (tx_left > 0) {
+   int len = d[1] + 2;
+
+   if (ctx->burst.r_count + len > ctx->burst.r_size)
+   break;
+   d[0] = min(ctx->burst.rx_ack, 255);
+   ctx->burst.rx_ack -= d[0];
+   sii8620_write_buf(ctx, REG_EMSC_XMIT_WRITE_PORT, d, len);
+   ctx->burst.r_count += len;
+   tx_left -= len;
+   d += len;
+   }
+
+   ctx->burst.tx_count = tx_left;
+
+   while (ctx->burst.rx_ack > 0) {
+   u8 b[2] = { min(ctx->burst.rx_ack, 255), 0 };
+
+   if (ctx->burst.r_count + 2 > ctx->burst.r_size)
+   break;
+   ctx->burst.rx_ack -= b[0];
+   sii8620_write_buf(ctx, REG_EMSC_XMIT_WRITE_PORT, b, 2);
+   ctx->burst.r_count += 2;
+   }
+}
+
+static void sii8620_burst_receive(struct sii8620 *ctx)
+{
+   u8 buf[3], *d;
+   int count;
+
+   sii8620_read_buf(ctx, REG_EMSCRFIFOBCNTL, buf, 2);
+   count = get_unaligned_le16(buf);
+   while (count > 0) {
+   int len = min(count, 3);
+
+   sii8620_read_buf(ctx, REG_EMSC_RCV_READ_PORT, buf, len);
+   count -= len;
+   ctx->burst.rx_ack += len - 1;
+   ctx->burst.r_count -= buf[1];
+   if (ctx->burst.r_count < 0)
+   ctx->burst.r_count = 0;
+
+   if (len < 3 || !buf[2])
+   continue;
+
+   len = buf[2];
+   d = sii8620_burst_get_rx_buf(ctx, len);
+   if (!d)
+   continue;
+   sii8620_read_buf(ctx, REG_EMSC_RCV_READ_PORT, d, len);
+   count -= len;
+   ctx->burst.rx_ack += len;
+   }
+}
+
+static void sii8620_burst_tx_rbuf_info(struct sii8620 *ctx, int size)
+{
+   struct mhl_burst_blk_rcv_buffer_info *d =
+   sii8620_burst_get_tx_buf(ctx, sizeof(*d));
+   if (!d)
+   return;
+
+   d->id = cpu_to_be16(MHL_BURST_ID_BLK_RCV_BUFFER_INFO);
+   d->size = cpu_to_le16(size);
+}
+
+static void sii8620_burst_rx_all(struct sii8620 *ctx)
+{
+   u8 *d = ctx->burst.rx_buf;
+   int count = ctx->burst.rx_count;
+
+   while (count-- > 0) {
+   int len = *d++;
+   int id = get_unaligned_be16([0]);
+
+   switch (id) {
+   case MHL_BURST_ID_BLK_RCV_BUFFER_INFO:
+

[PATCH 21/24] drm/bridge/sii8620: improve gen2 write burst IRQ routine

The patch adds code to report back feature complete IRQ, and code
to read and drop burst writes from peer.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 2cc197d..77c9fb2 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1573,12 +1573,31 @@ static void sii8620_irq_disc(struct sii8620 *ctx)
sii8620_write(ctx, REG_CBUS_DISC_INTR0, stat);
 }
 
+static void sii8620_read_burst(struct sii8620 *ctx)
+{
+   u8 buf[17];
+
+   sii8620_read_buf(ctx, REG_MDT_RCV_READ_PORT, buf, ARRAY_SIZE(buf));
+   sii8620_write(ctx, REG_MDT_RCV_CTRL, BIT_MDT_RCV_CTRL_MDT_RCV_EN |
+ BIT_MDT_RCV_CTRL_MDT_DELAY_RCV_EN |
+ BIT_MDT_RCV_CTRL_MDT_RFIFO_CLR_CUR);
+   sii8620_readb(ctx, REG_MDT_RFIFO_STAT);
+}
+
 static void sii8620_irq_g2wb(struct sii8620 *ctx)
 {
u8 stat = sii8620_readb(ctx, REG_MDT_INT_0);
 
if (stat & BIT_MDT_IDLE_AFTER_HAWB_DISABLE)
-   dev_dbg(ctx->dev, "HAWB idle\n");
+   if (sii8620_is_mhl3(ctx))
+   sii8620_mt_set_int(ctx, MHL_INT_REG(RCHANGE),
+   MHL_INT_RC_FEAT_COMPLETE);
+
+   if (stat & BIT_MDT_RFIFO_DATA_RDY)
+   sii8620_read_burst(ctx);
+
+   if (stat & BIT_MDT_XFIFO_EMPTY)
+   sii8620_write(ctx, REG_MDT_XMIT_CTRL, 0);
 
sii8620_write(ctx, REG_MDT_INT_0, stat);
 }
-- 
2.7.4

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

[PATCH 14/24] drm/bridge/sii8620: set gen2 write burst before sending MSC command

Write burst should be enabled for MHL_INT_RC_FEAT_REQ and disabled for
other commands. The patch moves functions up and adds delay setting
for MHL3 burst mode.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 88 
 1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 5b879ff..653187c 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -289,9 +289,59 @@ static void sii8620_mt_work(struct sii8620 *ctx)
msg->send(ctx, msg);
 }
 
+static void sii8620_enable_gen2_write_burst(struct sii8620 *ctx)
+{
+   u8 ctrl = BIT_MDT_RCV_CTRL_MDT_RCV_EN;
+
+   if (ctx->gen2_write_burst)
+   return;
+
+   if (ctx->mode >= CM_MHL1)
+   ctrl |= BIT_MDT_RCV_CTRL_MDT_DELAY_RCV_EN;
+
+   sii8620_write_seq(ctx,
+   REG_MDT_RCV_TIMEOUT, 100,
+   REG_MDT_RCV_CTRL, ctrl
+   );
+   ctx->gen2_write_burst = 1;
+}
+
+static void sii8620_disable_gen2_write_burst(struct sii8620 *ctx)
+{
+   if (!ctx->gen2_write_burst)
+   return;
+
+   sii8620_write_seq_static(ctx,
+   REG_MDT_XMIT_CTRL, 0,
+   REG_MDT_RCV_CTRL, 0
+   );
+   ctx->gen2_write_burst = 0;
+}
+
+static void sii8620_start_gen2_write_burst(struct sii8620 *ctx)
+{
+   sii8620_write_seq_static(ctx,
+   REG_MDT_INT_1_MASK, BIT_MDT_RCV_TIMEOUT
+   | BIT_MDT_RCV_SM_ABORT_PKT_RCVD | BIT_MDT_RCV_SM_ERROR
+   | BIT_MDT_XMIT_TIMEOUT | BIT_MDT_XMIT_SM_ABORT_PKT_RCVD
+   | BIT_MDT_XMIT_SM_ERROR,
+   REG_MDT_INT_0_MASK, BIT_MDT_XFIFO_EMPTY
+   | BIT_MDT_IDLE_AFTER_HAWB_DISABLE
+   | BIT_MDT_RFIFO_DATA_RDY
+   );
+   sii8620_enable_gen2_write_burst(ctx);
+}
+
 static void sii8620_mt_msc_cmd_send(struct sii8620 *ctx,
struct sii8620_mt_msg *msg)
 {
+   if (msg->reg[0] == MHL_SET_INT &&
+   msg->reg[1] == MHL_INT_REG(RCHANGE) &&
+   msg->reg[2] == MHL_INT_RC_FEAT_REQ)
+   sii8620_enable_gen2_write_burst(ctx);
+   else
+   sii8620_disable_gen2_write_burst(ctx);
+
switch (msg->reg[0]) {
case MHL_WRITE_STAT:
case MHL_SET_INT:
@@ -956,44 +1006,6 @@ static void sii8620_enable_hpd(struct sii8620 *ctx)
);
 }
 
-static void sii8620_enable_gen2_write_burst(struct sii8620 *ctx)
-{
-   if (ctx->gen2_write_burst)
-   return;
-
-   sii8620_write_seq_static(ctx,
-   REG_MDT_RCV_TIMEOUT, 100,
-   REG_MDT_RCV_CTRL, BIT_MDT_RCV_CTRL_MDT_RCV_EN
-   );
-   ctx->gen2_write_burst = 1;
-}
-
-static void sii8620_disable_gen2_write_burst(struct sii8620 *ctx)
-{
-   if (!ctx->gen2_write_burst)
-   return;
-
-   sii8620_write_seq_static(ctx,
-   REG_MDT_XMIT_CTRL, 0,
-   REG_MDT_RCV_CTRL, 0
-   );
-   ctx->gen2_write_burst = 0;
-}
-
-static void sii8620_start_gen2_write_burst(struct sii8620 *ctx)
-{
-   sii8620_write_seq_static(ctx,
-   REG_MDT_INT_1_MASK, BIT_MDT_RCV_TIMEOUT
-   | BIT_MDT_RCV_SM_ABORT_PKT_RCVD | BIT_MDT_RCV_SM_ERROR
-   | BIT_MDT_XMIT_TIMEOUT | BIT_MDT_XMIT_SM_ABORT_PKT_RCVD
-   | BIT_MDT_XMIT_SM_ERROR,
-   REG_MDT_INT_0_MASK, BIT_MDT_XFIFO_EMPTY
-   | BIT_MDT_IDLE_AFTER_HAWB_DISABLE
-   | BIT_MDT_RFIFO_DATA_RDY
-   );
-   sii8620_enable_gen2_write_burst(ctx);
-}
-
 static void sii8620_mhl_discover(struct sii8620 *ctx)
 {
sii8620_write_seq_static(ctx,
-- 
2.7.4

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

[PATCH 15/24] drm/bridge/sii8620: do not stop MHL output when TMDS input is stopped

Stopping output causes full re-detection of the sink and slows down the process.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 653187c..e84cda0 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1614,17 +1614,6 @@ static void sii8620_scdt_high(struct sii8620 *ctx)
);
 }
 
-static void sii8620_scdt_low(struct sii8620 *ctx)
-{
-   sii8620_write(ctx, REG_TMDS_CSTAT_P3,
- BIT_TMDS_CSTAT_P3_SCDT_CLR_AVI_DIS |
- BIT_TMDS_CSTAT_P3_CLR_AVI);
-
-   sii8620_stop_video(ctx);
-
-   sii8620_write(ctx, REG_INTR8_MASK, 0);
-}
-
 static void sii8620_irq_scdt(struct sii8620 *ctx)
 {
u8 stat = sii8620_readb(ctx, REG_INTR5);
@@ -1634,8 +1623,6 @@ static void sii8620_irq_scdt(struct sii8620 *ctx)
 
if (cstat & BIT_TMDS_CSTAT_P3_SCDT)
sii8620_scdt_high(ctx);
-   else
-   sii8620_scdt_low(ctx);
}
 
sii8620_write(ctx, REG_INTR5, stat);
-- 
2.7.4

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

[PATCH 09/24] drm/bridge/sii8620: fix peer device capabilities read code

Peer capabilities should be read differently depending on protocol version.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 3842226..be953f3 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1412,7 +1412,8 @@ static void sii8620_status_changed_path(struct sii8620 
*ctx)
sii8620_mt_write_stat(ctx, MHL_DST_REG(LINK_MODE),
  MHL_DST_LM_CLK_MODE_NORMAL
  | MHL_DST_LM_PATH_ENABLED);
-   sii8620_mt_read_devcap(ctx, false);
+   if (!sii8620_is_mhl3(ctx))
+   sii8620_mt_read_devcap(ctx, false);
} else {
sii8620_mt_write_stat(ctx, MHL_DST_REG(LINK_MODE),
  MHL_DST_LM_CLK_MODE_NORMAL);
@@ -1664,6 +1665,14 @@ static void sii8620_irq_infr(struct sii8620 *ctx)
sii8620_start_video(ctx);
 }
 
+static void sii8620_got_xdevcap(struct sii8620 *ctx, int ret)
+{
+   if (ret < 0)
+   return;
+
+   sii8620_mt_read_devcap(ctx, false);
+}
+
 static void sii8620_irq_tdm(struct sii8620 *ctx)
 {
u8 stat = sii8620_readb(ctx, REG_TRXINTH);
@@ -1675,6 +1684,7 @@ static void sii8620_irq_tdm(struct sii8620 *ctx)
ctx->burst.r_size = SII8620_BURST_BUF_LEN;
sii8620_burst_tx_rbuf_info(ctx, SII8620_BURST_BUF_LEN);
sii8620_mt_read_devcap(ctx, true);
+   sii8620_mt_set_cont(ctx, sii8620_got_xdevcap);
} else {
sii8620_write_seq_static(ctx,
REG_MHL_PLL_CTL2, 0,
-- 
2.7.4

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

[PATCH 10/24] drm/bridge/sii8620: remove spare CBUS bring-up sequence

In case of MHL3 CBUS is bring-up already in sii8620_got_ecbus_speed.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index be953f3..fb69353 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -453,10 +453,6 @@ static void sii8620_mr_xdevcap(struct sii8620 *ctx)
 {
sii8620_read_buf(ctx, REG_EDID_FIFO_RD_DATA, ctx->xdevcap,
 MHL_XDC_SIZE);
-
-   sii8620_mt_write_stat(ctx, MHL_XDS_REG(CURR_ECBUS_MODE),
- MHL_XDS_ECBUS_S | MHL_XDS_SLOT_MODE_8BIT);
-   sii8620_mt_rap(ctx, MHL_RAP_CBUS_MODE_UP);
 }
 
 static void sii8620_mt_read_devcap_recv(struct sii8620 *ctx,
-- 
2.7.4

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

[PATCH 13/24] drm/bridge/sii8620: abstract out sink detection code

MHL1 and MHL3 have different initialization paths. To make both protocols
happy sink detection is put into continuation after link mode enablement.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 7d28690..5b879ff 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -402,7 +402,7 @@ static void sii8620_update_array(u8 *dst, u8 *src, int 
count)
}
 }
 
-static void sii8620_mr_devcap(struct sii8620 *ctx)
+static void sii8620_sink_detected(struct sii8620 *ctx, int ret)
 {
static const char * const sink_str[] = {
[SINK_NONE] = "NONE",
@@ -410,23 +410,10 @@ static void sii8620_mr_devcap(struct sii8620 *ctx)
[SINK_DVI] = "DVI"
};
 
-   u8 dcap[MHL_DCAP_SIZE];
char sink_name[20];
struct device *dev = ctx->dev;
 
-   sii8620_read_buf(ctx, REG_EDID_FIFO_RD_DATA, dcap, MHL_DCAP_SIZE);
-   if (ctx->error < 0)
-   return;
-
-   dev_info(dev, "dcap: %*ph\n", MHL_DCAP_SIZE, dcap);
-   dev_info(dev, "detected dongle MHL %d.%d, ChipID %02x%02x:%02x%02x\n",
-dcap[MHL_DCAP_MHL_VERSION] / 16,
-dcap[MHL_DCAP_MHL_VERSION] % 16, dcap[MHL_DCAP_ADOPTER_ID_H],
-dcap[MHL_DCAP_ADOPTER_ID_L], dcap[MHL_DCAP_DEVICE_ID_H],
-dcap[MHL_DCAP_DEVICE_ID_L]);
-   sii8620_update_array(ctx->devcap, dcap, MHL_DCAP_SIZE);
-
-   if (!(dcap[MHL_DCAP_CAT] & MHL_DCAP_CAT_SINK))
+   if (ret < 0)
return;
 
sii8620_fetch_edid(ctx);
@@ -449,6 +436,22 @@ static void sii8620_mr_devcap(struct sii8620 *ctx)
sii8620_enable_hpd(ctx);
 }
 
+static void sii8620_mr_devcap(struct sii8620 *ctx)
+{
+   u8 dcap[MHL_DCAP_SIZE];
+   struct device *dev = ctx->dev;
+
+   sii8620_read_buf(ctx, REG_EDID_FIFO_RD_DATA, dcap, MHL_DCAP_SIZE);
+   if (ctx->error < 0)
+   return;
+
+   dev_info(dev, "detected dongle MHL %d.%d, ChipID %02x%02x:%02x%02x\n",
+   dcap[MHL_DCAP_MHL_VERSION] / 16, dcap[MHL_DCAP_MHL_VERSION] % 
16,
+   dcap[MHL_DCAP_ADOPTER_ID_H], dcap[MHL_DCAP_ADOPTER_ID_L],
+   dcap[MHL_DCAP_DEVICE_ID_H], dcap[MHL_DCAP_DEVICE_ID_L]);
+   sii8620_update_array(ctx->devcap, dcap, MHL_DCAP_SIZE);
+}
+
 static void sii8620_mr_xdevcap(struct sii8620 *ctx)
 {
sii8620_read_buf(ctx, REG_EDID_FIFO_RD_DATA, ctx->xdevcap,
@@ -1409,6 +1412,7 @@ static void sii8620_status_changed_path(struct sii8620 
*ctx)
  | MHL_DST_LM_PATH_ENABLED);
if (!sii8620_is_mhl3(ctx))
sii8620_mt_read_devcap(ctx, false);
+   sii8620_mt_set_cont(ctx, sii8620_sink_detected);
} else {
sii8620_mt_write_stat(ctx, MHL_DST_REG(LINK_MODE),
  MHL_DST_LM_CLK_MODE_NORMAL);
-- 
2.7.4

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

[PATCH 12/24] drm/bridge/sii8620: fix initialization sequence for MHL2 receivers

MHL2 receiver require disabling transmitter on initialization.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index a50ade6..7d28690 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -880,12 +880,11 @@ static void sii8620_stop_video(struct sii8620 *ctx)
| BIT_TPI_SC_TPI_AV_MUTE;
break;
case SINK_HDMI:
+   default:
val = BIT_TPI_SC_REG_TMDS_OE_POWER_DOWN
| BIT_TPI_SC_TPI_AV_MUTE
| BIT_TPI_SC_TPI_OUTPUT_MODE_0_HDMI;
break;
-   default:
-   return;
}
 
sii8620_write(ctx, REG_TPI_SC, val);
-- 
2.7.4

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

[PATCH 01/24] drm/bridge/sii8620: simplify MHL3 mode setting

It is not necessary to set REG_COC_CTL0, REG_MHL_COC_CTL1 registers.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b2c267d..68cdf63 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -974,12 +974,8 @@ static void sii8620_set_mode(struct sii8620 *ctx, enum 
sii8620_mode mode)
);
break;
case CM_MHL3:
-   sii8620_write_seq_static(ctx,
-   REG_M3_CTRL, VAL_M3_CTRL_MHL3_VALUE,
-   REG_COC_CTL0, 0x40,
-   REG_MHL_COC_CTL1, 0x07
-   );
-   break;
+   sii8620_write(ctx, REG_M3_CTRL, VAL_M3_CTRL_MHL3_VALUE);
+   return;
case CM_DISCONNECTED:
break;
default:
-- 
2.7.4

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

[PATCH 00/24] drm/bridge/sii8620: add Ultra HD modes support

Hi Archit,

This quite big patchset adds support for 4K Ultra HD modes in SiI8620 MHL 
bridge.
To support it full MHL3 protocol and its sub-protocols should be implemented.
Patchset contains also various fixes for bugs discovered during development.

Regards
Andrzej


Andrzej Hajda (24):
  drm/bridge/sii8620: simplify MHL3 mode setting
  drm/bridge/sii8620: add MHL3 mode check helper
  drm/bridge/sii8620: add reading device capability registers
  drm/bridge/sii8620: add continuations to messages
  drm/bridge/sii8620: initial support for eCBUS-S mode
  drm/bridge/mhl: add write burst related definitions
  drm/bridge/sii8620: add support for burst eMSC transmissions
  drm/bridge/sii8620: respond to feature requests
  drm/bridge/sii8620: fix peer device capabilities read code
  drm/bridge/sii8620: remove spare CBUS bring-up sequence
  drm/bridge/sii8620: fix MSC message removal
  drm/bridge/sii8620: fix initialization sequence for MHL2 receivers
  drm/bridge/sii8620: abstract out sink detection code
  drm/bridge/sii8620: set gen2 write burst before sending MSC command
  drm/bridge/sii8620: do not stop MHL output when TMDS input is stopped
  drm/bridge/sii8620: add delay during cbus reset
  drm/bridge/sii8620: split EDID read and write code
  drm/bridge/sii8620: fix disconnect sequence
  drm/bridge/sii8620: rewrite hdmi start sequence
  drm/bridge/sii8620: send EMSC features on request
  drm/bridge/sii8620: improve gen2 write burst IRQ routine
  drm/bridge/sii8620: add HSIC initialization code
  drm/bridge/sii8620: enable MHL3 mode if possible
  drm/bridge/sii8620: enable interlace modes

 drivers/gpu/drm/bridge/sil-sii8620.c | 917 ++-
 drivers/gpu/drm/bridge/sil-sii8620.h |  50 +-
 include/drm/bridge/mhl.h |  51 ++
 3 files changed, 868 insertions(+), 150 deletions(-)

-- 
2.7.4

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

[PATCH 11/24] drm/bridge/sii8620: fix MSC message removal

Messages queue can be cleaned up by message callbacks, to avoid repeated
removal of current message it should be removed from the queue before calling
these callbacks.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index fb69353..a50ade6 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -272,11 +272,11 @@ static void sii8620_mt_work(struct sii8620 *ctx)
ctx->mt_state = MT_STATE_READY;
msg = list_first_entry(>mt_queue, struct sii8620_mt_msg,
   node);
+   list_del(>node);
if (msg->recv)
msg->recv(ctx, msg);
if (msg->continuation)
msg->continuation(ctx, msg->ret);
-   list_del(>node);
kfree(msg);
}
 
-- 
2.7.4

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

[PATCH 03/24] drm/bridge/sii8620: add reading device capability registers

This functionality is necessary to implement MHL3 modes.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 50af78f..75867c0 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -286,6 +286,12 @@ static void sii8620_mt_msc_cmd_send(struct sii8620 *ctx,
sii8620_write(ctx, REG_MSC_COMMAND_START,
  BIT_MSC_COMMAND_START_MSC_MSG);
break;
+   case MHL_READ_DEVCAP_REG:
+   case MHL_READ_XDEVCAP_REG:
+   sii8620_write(ctx, REG_MSC_CMD_OR_OFFSET, msg->reg[1]);
+   sii8620_write(ctx, REG_MSC_COMMAND_START,
+ BIT_MSC_COMMAND_START_READ_DEVCAP);
+   break;
default:
dev_err(ctx->dev, "%s: command %#x not supported\n", __func__,
msg->reg[0]);
@@ -455,6 +461,35 @@ static void sii8620_mt_read_devcap(struct sii8620 *ctx, 
bool xdevcap)
msg->recv = sii8620_mt_read_devcap_recv;
 }
 
+static void sii8620_mt_read_devcap_reg_recv(struct sii8620 *ctx,
+   struct sii8620_mt_msg *msg)
+{
+   u8 reg = msg->reg[0] & 0x7f;
+
+   if (msg->reg[0] & 0x80)
+   ctx->xdevcap[reg] = msg->ret;
+   else
+   ctx->devcap[reg] = msg->ret;
+}
+
+static void sii8620_mt_read_devcap_reg(struct sii8620 *ctx, u8 reg)
+{
+   struct sii8620_mt_msg *msg = sii8620_mt_msg_new(ctx);
+
+   if (!msg)
+   return;
+
+   msg->reg[0] = (reg & 0x80) ? MHL_READ_XDEVCAP_REG : MHL_READ_DEVCAP_REG;
+   msg->reg[1] = reg;
+   msg->send = sii8620_mt_msc_cmd_send;
+   msg->recv = sii8620_mt_read_devcap_reg_recv;
+}
+
+static inline void sii8620_mt_read_xdevcap_reg(struct sii8620 *ctx, u8 reg)
+{
+   sii8620_mt_read_devcap_reg(ctx, reg | 0x80);
+}
+
 static void sii8620_fetch_edid(struct sii8620 *ctx)
 {
u8 lm_ddc, ddc_cmd, int3, cbus;
-- 
2.7.4

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

[PATCH 08/24] drm/bridge/sii8620: respond to feature requests

MHL3 protocol requires device to respond to feature request from peer.
This minimal answer fulfills the requirement and allows to continue
negotiation.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 744e685..3842226 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1475,6 +1475,10 @@ static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
break;
}
}
+   if (ints[MHL_INT_RCHANGE] & MHL_INT_RC_FEAT_REQ) {
+   sii8620_mt_set_int(ctx, MHL_INT_REG(RCHANGE),
+  MHL_INT_RC_FEAT_COMPLETE);
+   }
 }
 
 static struct sii8620_mt_msg *sii8620_msc_msg_first(struct sii8620 *ctx)
-- 
2.7.4

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

[PATCH 06/24] drm/bridge/mhl: add write burst related definitions

Burst transmissions are required in MHL3 modes.

Signed-off-by: Andrzej Hajda 
---
 include/drm/bridge/mhl.h | 51 
 1 file changed, 51 insertions(+)

diff --git a/include/drm/bridge/mhl.h b/include/drm/bridge/mhl.h
index 3629b27..71d922f 100644
--- a/include/drm/bridge/mhl.h
+++ b/include/drm/bridge/mhl.h
@@ -288,4 +288,55 @@ enum {
 /* Unsupported/unrecognized key code */
 #define MHL_UCPE_STATUS_INEFFECTIVE_KEY_CODE   0x01
 
+enum mhl_burst_id {
+   MHL_BURST_ID_3D_VIC = 0x10,
+   MHL_BURST_ID_3D_DTD = 0x11,
+   MHL_BURST_ID_HEV_VIC = 0x20,
+   MHL_BURST_ID_HEV_DTDA = 0x21,
+   MHL_BURST_ID_HEV_DTDB = 0x22,
+   MHL_BURST_ID_VC_ASSIGN = 0x38,
+   MHL_BURST_ID_VC_CONFIRM = 0x39,
+   MHL_BURST_ID_AUD_DELAY = 0x40,
+   MHL_BURST_ID_ADT_BURSTID = 0x41,
+   MHL_BURST_ID_BIST_SETUP = 0x51,
+   MHL_BURST_ID_BIST_RETURN_STAT = 0x52,
+   MHL_BURST_ID_EMSC_SUPPORT = 0x61,
+   MHL_BURST_ID_HID_PAYLOAD = 0x62,
+   MHL_BURST_ID_BLK_RCV_BUFFER_INFO = 0x63,
+   MHL_BURST_ID_BITS_PER_PIXEL_FMT = 0x64,
+};
+
+struct mhl_burst_blk_rcv_buffer_info {
+   __be16 id;
+   __le16 size;
+} __packed;
+
+struct mhl3_burst_header {
+   __be16 id;
+   u8 checksum;
+   u8 total_entries;
+   u8 sequence_index;
+} __packed;
+
+struct mhl_burst_bits_per_pixel_fmt {
+   struct mhl3_burst_header hdr;
+   u8 num_entries;
+   struct {
+   u8 stream_id;
+   u8 pixel_format;
+   } __packed desc[0];
+} __packed;
+
+struct mhl_burst_emsc_support {
+   struct mhl3_burst_header hdr;
+   u8 num_entries;
+   __be16 burst_id[0];
+} __packed;
+
+struct mhl_burst_audio_descr {
+   struct mhl3_burst_header hdr;
+   u8 flags;
+   u8 short_desc[9];
+} __packed;
+
 #endif /* __MHL_H__ */
-- 
2.7.4

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

[PATCH 02/24] drm/bridge/sii8620: add MHL3 mode check helper

MHL3 modes differs significantly from MHL1 mode, this helper will be used
frequently to clearly distinguish them.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 68cdf63..50af78f 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -227,6 +227,11 @@ static void sii8620_setbits(struct sii8620 *ctx, u16 addr, 
u8 mask, u8 val)
sii8620_write(ctx, addr, val);
 }
 
+static inline bool sii8620_is_mhl3(struct sii8620 *ctx)
+{
+   return ctx->mode >= CM_MHL3;
+}
+
 static void sii8620_mt_cleanup(struct sii8620 *ctx)
 {
struct sii8620_mt_msg *msg, *n;
@@ -724,7 +729,7 @@ static void sii8620_start_hdmi(struct sii8620 *ctx)
 
 static void sii8620_start_video(struct sii8620 *ctx)
 {
-   if (ctx->mode < CM_MHL3)
+   if (!sii8620_is_mhl3(ctx))
sii8620_stop_video(ctx);
 
switch (ctx->sink_type) {
@@ -838,7 +843,7 @@ static void sii8620_mhl_discover(struct sii8620 *ctx)
 
 static void sii8620_peer_specific_init(struct sii8620 *ctx)
 {
-   if (ctx->mode == CM_MHL3)
+   if (sii8620_is_mhl3(ctx))
sii8620_write_seq_static(ctx,
REG_SYS_CTRL1, BIT_SYS_CTRL1_BLOCK_DDC_BY_HPD,
REG_EMSCINTRMASK1,
-- 
2.7.4

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

[PATCH 04/24] drm/bridge/sii8620: add continuations to messages

Due to asynchronous nature of MHL flow of execution is dispersed. Logical
continuation of some actions happens after response of peer, i.e in interrupt
handler. To simplify coding continuation mechanism has been added - it is now
possible to provide continuation callback, which will be called after peer
responds to given action.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 75867c0..cde0074 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -78,12 +78,15 @@ struct sii8620_mt_msg;
 typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
  struct sii8620_mt_msg *msg);
 
+typedef void (*sii8620_cb)(struct sii8620 *ctx, int ret);
+
 struct sii8620_mt_msg {
struct list_head node;
u8 reg[4];
u8 ret;
sii8620_mt_msg_cb send;
sii8620_mt_msg_cb recv;
+   sii8620_cb continuation;
 };
 
 static const u8 sii8620_i2c_page[] = {
@@ -258,6 +261,8 @@ static void sii8620_mt_work(struct sii8620 *ctx)
   node);
if (msg->recv)
msg->recv(ctx, msg);
+   if (msg->continuation)
+   msg->continuation(ctx, msg->ret);
list_del(>node);
kfree(msg);
}
@@ -310,6 +315,21 @@ static struct sii8620_mt_msg *sii8620_mt_msg_new(struct 
sii8620 *ctx)
return msg;
 }
 
+static void sii8620_mt_set_cont(struct sii8620 *ctx, sii8620_cb cont)
+{
+   struct sii8620_mt_msg *msg;
+
+   if (ctx->error)
+   return;
+
+   if (list_empty(>mt_queue)) {
+   ctx->error = -EINVAL;
+   return;
+   }
+   msg = list_last_entry(>mt_queue, struct sii8620_mt_msg, node);
+   msg->continuation = cont;
+}
+
 static void sii8620_mt_msc_cmd(struct sii8620 *ctx, u8 cmd, u8 arg1, u8 arg2)
 {
struct sii8620_mt_msg *msg = sii8620_mt_msg_new(ctx);
-- 
2.7.4

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

[Bug 98619] amdgpu 0000:01:00.0: GPU fault detected: 146 0x09d88404

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

--- Comment #5 from Brandon Egbert  ---
Changing shadows from 'All shadows' to 'Directional Only' seems to correct the
issue in XCOM2 at least.  Be nice to be able to have shadows working though.

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

[PATCH 5/7] drm/exynos/decon5433: add support for interlace modes

Some registers should be programmed differently in interlace mode.
Additionally IP does not signal stop state properly in interlaced
mode, so warning has been removed.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 45 +++
 include/video/exynos5433_decon.h  |  1 +
 2 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 042d6ef..46434ba9 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -146,6 +146,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *m = >base.mode;
+   bool interlaced = false;
u32 val;
 
if (test_bit(BIT_SUSPENDED, >flags))
@@ -156,12 +157,16 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
m->crtc_hsync_end = m->crtc_htotal - 92;
m->crtc_vsync_start = m->crtc_vdisplay + 1;
m->crtc_vsync_end = m->crtc_vsync_start + 1;
+   if (m->flags & DRM_MODE_FLAG_INTERLACE)
+   interlaced = true;
}
 
decon_setup_trigger(ctx);
 
/* lcd on and use command if */
val = VIDOUT_LCD_ON;
+   if (interlaced)
+   val |= VIDOUT_INTERLACE_EN_F;
if (ctx->out_type & IFTYPE_I80) {
val |= VIDOUT_COMMAND_IF;
} else {
@@ -170,15 +175,21 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
 
writel(val, ctx->addr + DECON_VIDOUTCON0);
 
-   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
-   VIDTCON2_HOZVAL(m->hdisplay - 1);
+   if (interlaced)
+   val = VIDTCON2_LINEVAL(m->vdisplay / 2 - 1) |
+   VIDTCON2_HOZVAL(m->hdisplay - 1);
+   else
+   val = VIDTCON2_LINEVAL(m->vdisplay - 1) |
+   VIDTCON2_HOZVAL(m->hdisplay - 1);
writel(val, ctx->addr + DECON_VIDTCON2);
 
if (!(ctx->out_type & IFTYPE_I80)) {
-   val = VIDTCON00_VBPD_F(
-   m->crtc_vtotal - m->crtc_vsync_end - 1) |
-   VIDTCON00_VFPD_F(
-   m->crtc_vsync_start - m->crtc_vdisplay - 1);
+   int vbp = m->crtc_vtotal - m->crtc_vsync_end;
+   int vfp = m->crtc_vsync_start - m->crtc_vdisplay;
+
+   if (interlaced)
+   vbp = vbp / 2 - 1;
+   val = VIDTCON00_VBPD_F(vbp - 1) | VIDTCON00_VFPD_F(vfp - 1);
writel(val, ctx->addr + DECON_VIDTCON00);
 
val = VIDTCON01_VSPW_F(
@@ -293,12 +304,22 @@ static void decon_update_plane(struct exynos_drm_crtc 
*crtc,
if (test_bit(BIT_SUSPENDED, >flags))
return;
 
-   val = COORDINATE_X(state->crtc.x) | COORDINATE_Y(state->crtc.y);
-   writel(val, ctx->addr + DECON_VIDOSDxA(win));
+   if (crtc->base.mode.flags & DRM_MODE_FLAG_INTERLACE) {
+   val = COORDINATE_X(state->crtc.x) |
+   COORDINATE_Y(state->crtc.y / 2);
+   writel(val, ctx->addr + DECON_VIDOSDxA(win));
+
+   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
+   COORDINATE_Y((state->crtc.y + state->crtc.h) / 2 - 1);
+   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   } else {
+   val = COORDINATE_X(state->crtc.x) | COORDINATE_Y(state->crtc.y);
+   writel(val, ctx->addr + DECON_VIDOSDxA(win));
 
-   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
-   COORDINATE_Y(state->crtc.y + state->crtc.h - 1);
-   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   val = COORDINATE_X(state->crtc.x + state->crtc.w - 1) |
+   COORDINATE_Y(state->crtc.y + state->crtc.h - 1);
+   writel(val, ctx->addr + DECON_VIDOSDxB(win));
+   }
 
val = VIDOSD_Wx_ALPHA_R_F(0x0) | VIDOSD_Wx_ALPHA_G_F(0x0) |
VIDOSD_Wx_ALPHA_B_F(0x0);
@@ -370,8 +391,6 @@ static void decon_swreset(struct decon_context *ctx)
udelay(10);
}
 
-   WARN(tries == 0, "failed to disable DECON\n");
-
writel(VIDCON0_SWRESET, ctx->addr + DECON_VIDCON0);
for (tries = 2000; tries; --tries) {
if (~readl(ctx->addr + DECON_VIDCON0) & VIDCON0_SWRESET)
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index 0098a52..b26511a 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -89,6 +89,7 @@
 #define VIDCON0_ENVID_F(1 << 0)
 
 /* VIDOUTCON0 */
+#define VIDOUT_INTERLACE_EN_F  (1 << 28)
 #define VIDOUT_LCD_ON  (1 << 24)
 #define VIDOUT_IF_F_MASK   (0x3 << 20)
 #define

[PATCH 0/7] drm/exynos: add Ultra HD and interlace modes support to Exynos5433

Hi Inki,

This patchset adds support for UltraHD and intrelace modes on DECON and HDMI
drivers of Exynos5433 chipset. To fully support it on TM2(e) platforms MHL
patches are alse required which will be posted in separate patchset.

Krzysztof, DTS patch do not depend on the previous patches, so there is
no need to synchronize branches.

Regards
Andrzej


Andrzej Hajda (7):
  drm/exynos/hdmi: add 297MHz pixel clock support
  drm/exynos/hdmi: fix VSI infoframe registers
  drm/exynos/hdmi: fix PLL for 27MHz settings
  drm/exynos/hdmi: add bridge support
  drm/exynos/decon5433: add support for interlace modes
  drm/exynos/decon5433: signal vblank only on odd fields
  arm64: dts: exynos: configure TV path clocks for Ultra HD modes

 arch/arm64/boot/dts/exynos/exynos5433.dtsi|  3 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 52 -
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 80 +--
 include/video/exynos5433_decon.h  |  2 +
 4 files changed, 107 insertions(+), 30 deletions(-)

-- 
2.7.4

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

[PATCH 3/7] drm/exynos/hdmi: fix PLL for 27MHz settings

Current settings for 27MHz and 27.027MHz do not work. Use the settings from
vendor code instead.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 223b872..a73b192 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -509,9 +509,9 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] = 
{
{
.pixel_clock = 2700,
.conf = {
-   0x01, 0x51, 0x22, 0x51, 0x08, 0xfc, 0x88, 0x46,
-   0x72, 0x50, 0x24, 0x0c, 0x24, 0x0f, 0x7c, 0xa5,
-   0xd4, 0x2b, 0x87, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x01, 0x51, 0x2d, 0x75, 0x01, 0x00, 0x88, 0x02,
+   0x72, 0x50, 0x44, 0x8c, 0x27, 0x00, 0x7c, 0xac,
+   0xd6, 0x2b, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
},
},
@@ -519,9 +519,9 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] = 
{
.pixel_clock = 27027000,
.conf = {
0x01, 0x51, 0x2d, 0x72, 0x64, 0x09, 0x88, 0xc3,
-   0x71, 0x50, 0x24, 0x14, 0x24, 0x0f, 0x7c, 0xa5,
-   0xd4, 0x2b, 0x87, 0x00, 0x00, 0x04, 0x00, 0x30,
-   0x28, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
+   0x71, 0x50, 0x44, 0x8c, 0x27, 0x00, 0x7c, 0xac,
+   0xd6, 0x2b, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
},
},
{
-- 
2.7.4

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

[PATCH 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes

Ultra HD modes requires clock ticking at increased rate.

Signed-off-by: Andrzej Hajda 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index f120d99..314d928 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -764,6 +764,9 @@
clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
  "aclk_xiu_decon0x", "pclk_smmu_decon0x",
  "sclk_decon_vclk", "sclk_decon_eclk";
+   assigned-clocks = <_mif 
CLK_MOUT_SCLK_DECON_TV_ECLK_A>, <_mif CLK_DIV_SCLK_DECON_TV_ECLK>, 
<_disp CLK_MOUT_SCLK_DECON_TV_ECLK_USER>, <_disp 
CLK_MOUT_SCLK_DECON_TV_ECLK>;
+   assigned-clock-parents = <_mif 
CLK_MOUT_BUS_PLL_DIV2>, <0>, <_mif CLK_SCLK_DECON_TV_ECLK_DISP>, <_disp 
CLK_MOUT_SCLK_DECON_TV_ECLK_USER>;
+   assigned-clock-rates = <0>, <4>;
samsung,disp-sysreg = <_disp>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = ,
-- 
2.7.4

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

[PATCH 4/7] drm/exynos/hdmi: add bridge support

In some platforms there is attached another device to the end of HDMI.
The patch adds support for it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 56 +---
 1 file changed, 46 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a73b192..41fb894 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -133,6 +134,7 @@ struct hdmi_context {
struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
struct regulator*reg_hdmi_en;
struct exynos_drm_clk   phy_clk;
+   struct drm_bridge   *bridge;
 };
 
 static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
@@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder 
*encoder)
drm_connector_register(connector);
drm_mode_connector_attach_encoder(connector, encoder);
 
-   return 0;
+   if (hdata->bridge) {
+   encoder->bridge = hdata->bridge;
+   hdata->bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, hdata->bridge);
+   if (ret)
+   DRM_ERROR("Failed to attach bridge\n");
+   }
+
+   return ret;
 }
 
 static bool hdmi_mode_fixup(struct drm_encoder *encoder,
@@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk 
*clk, bool enable)
hdmiphy_disable(hdata);
 }
 
+static int hdmi_bridge_init(struct hdmi_context *hdata)
+{
+   struct device *dev = hdata->dev;
+   struct device_node *ep, *np;
+
+   ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
+   if (!ep)
+   return 0;
+
+   np = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
+   if (!np) {
+   DRM_ERROR("failed to get remote port parent");
+   return -EINVAL;
+   }
+
+   hdata->bridge = of_drm_find_bridge(np);
+   of_node_put(np);
+
+   if (!hdata->bridge)
+   return -EPROBE_DEFER;
+
+   return 0;
+}
+
 static int hdmi_resources_init(struct hdmi_context *hdata)
 {
struct device *dev = hdata->dev;
@@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
 
hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
 
-   if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
-   return 0;
+   if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
+   if (IS_ERR(hdata->reg_hdmi_en))
+   return PTR_ERR(hdata->reg_hdmi_en);
 
-   if (IS_ERR(hdata->reg_hdmi_en))
-   return PTR_ERR(hdata->reg_hdmi_en);
-
-   ret = regulator_enable(hdata->reg_hdmi_en);
-   if (ret)
-   DRM_ERROR("failed to enable hdmi-en regulator\n");
+   ret = regulator_enable(hdata->reg_hdmi_en);
+   if (ret) {
+   DRM_ERROR("failed to enable hdmi-en regulator\n");
+   return ret;
+   }
+   }
 
-   return ret;
+   return hdmi_bridge_init(hdata);
 }
 
 static struct of_device_id hdmi_match_types[] = {
-- 
2.7.4

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

[PATCH 2/7] drm/exynos/hdmi: fix VSI infoframe registers

VSI infoframe registers address space is non-contiguous, so infoframe write
should be split into two chunks.

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

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bef8965..223b872 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -797,7 +797,8 @@ static void hdmi_reg_infoframes(struct hdmi_context *hdata)
sizeof(buf));
if (ret > 0) {
hdmi_reg_writeb(hdata, HDMI_VSI_CON, HDMI_VSI_CON_EVERY_VSYNC);
-   hdmi_reg_write_buf(hdata, HDMI_VSI_HEADER0, buf, ret);
+   hdmi_reg_write_buf(hdata, HDMI_VSI_HEADER0, buf, 3);
+   hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
}
 
ret = hdmi_audio_infoframe_init();
-- 
2.7.4

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

[PATCH 6/7] drm/exynos/decon5433: signal vblank only on odd fields

In case of interlace mode irq is generated for odd and even fields, but
vblank should be signaled only for the last emitted field.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++
 include/video/exynos5433_decon.h  | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 46434ba9..ad8b93a 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -591,6 +591,13 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)
 
if (val) {
writel(val, ctx->addr + DECON_VIDINTCON1);
+   if (ctx->out_type & IFTYPE_HDMI) {
+   val = readl(ctx->addr + DECON_VIDOUTCON0);
+   val &= VIDOUT_INTERLACE_EN_F | VIDOUT_INTERLACE_FIELD_F;
+   if (val ==
+   (VIDOUT_INTERLACE_EN_F | VIDOUT_INTERLACE_FIELD_F))
+   return IRQ_HANDLED;
+   }
drm_crtc_handle_vblank(>crtc->base);
}
 
diff --git a/include/video/exynos5433_decon.h b/include/video/exynos5433_decon.h
index b26511a..ef8e2a8 100644
--- a/include/video/exynos5433_decon.h
+++ b/include/video/exynos5433_decon.h
@@ -89,6 +89,7 @@
 #define VIDCON0_ENVID_F(1 << 0)
 
 /* VIDOUTCON0 */
+#define VIDOUT_INTERLACE_FIELD_F   (1 << 29)
 #define VIDOUT_INTERLACE_EN_F  (1 << 28)
 #define VIDOUT_LCD_ON  (1 << 24)
 #define VIDOUT_IF_F_MASK   (0x3 << 20)
-- 
2.7.4

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

[PATCH 1/7] drm/exynos/hdmi: add 297MHz pixel clock support

297MHz is used by Ultra HD modes.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1e..bef8965 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -587,6 +587,15 @@ static const struct hdmiphy_config hdmiphy_5433_configs[] 
= {
0x08, 0x10, 0x01, 0x01, 0x48, 0x4a, 0x00, 0x40,
},
},
+   {
+   .pixel_clock = 29700,
+   .conf = {
+   0x01, 0x51, 0x3E, 0x05, 0x40, 0xF0, 0x88, 0xC2,
+   0x52, 0x53, 0x44, 0x8C, 0x27, 0x00, 0x7C, 0xAC,
+   0xD6, 0x2B, 0x67, 0x00, 0x00, 0x04, 0x00, 0x30,
+   0x08, 0x10, 0x01, 0x01, 0x48, 0x40, 0x00, 0x40,
+   },
+   },
 };
 
 static const char * const hdmi_clk_gates4[] = {
-- 
2.7.4

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

[PATCH 3/4] drm: Add definitions for DP compliance Video pattern tests

v3:
* Fix the conventions in bit definitions (Jani Nikula)
v2:
* Add all the other DP Complianec TEST register defs (Jani Nikula)
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 include/drm/drm_dp_helper.h | 64 +
 1 file changed, 64 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 0468135..7ab4153 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -417,6 +417,70 @@
 #define DP_TEST_LANE_COUNT 0x220
 
 #define DP_TEST_PATTERN0x221
+# define DP_NO_TEST_PATTERN 0x0
+# define DP_COLOR_RAMP  0x1
+# define DP_BLACK_AND_WHITE_VERTICAL_LINES  0x2
+# define DP_COLOR_SQUARE0x3
+
+#define DP_TEST_H_TOTAL_HI  0x222
+#define DP_TEST_H_TOTAl_LO  0x223
+
+#define DP_TEST_V_TOTAL_HI  0x224
+#define DP_TEST_V_TOTAl_LO  0x225
+
+#define DP_TEST_H_START_HI  0x226
+#define DP_TEST_H_START_LO  0x227
+
+#define DP_TEST_V_START_HI  0x228
+#define DP_TEST_V_START_LO  0x229
+
+#define DP_TEST_HSYNC_HI0x22A
+# define DP_TEST_HSYNC_POLARITY (1 << 7)
+# define DP_TEST_HSYNC_WIDTH_HI_MASK(127 << 0)
+#define DP_TEST_HSYNC_WIDTH_LO  0x22B
+
+#define DP_TEST_VSYNC_HI0x22C
+# define DP_TEST_VSYNC_POLARITY (1 << 7)
+# define DP_TEST_VSYNC_WIDTH_HI_MASK(127 << 0)
+#define DP_TEST_VSYNC_WIDTH_LO  0x22D
+
+#define DP_TEST_H_WIDTH_HI  0x22E
+#define DP_TEST_H_WIDTH_LO  0x22F
+
+#define DP_TEST_V_HEIGHT_HI 0x230
+#define DP_TEST_V_HEIGHT_LO 0x231
+
+#define DP_TEST_MISC0   0x232
+# define DP_TEST_SYNC_CLOCK (1 << 0)
+# define DP_CLOCK_ASYNC 0x0
+# define DP_CLOCK_SYNC  0x1
+# define DP_TEST_COLOR_FORMAT_MASK  (3 << 1)
+# define DP_TEST_COLOR_FORMAT_SHIFT 1
+# define DP_COLOR_FORMAT_RGB(0 << 1)
+# define DP_COLOR_FORMAT_YCbCr422   (1 << 1)
+# define DP_COLOR_FORMAT_YCbCr444   (2 << 1)
+# define DP_TEST_DYNAMIC_RANGE  (1 << 3)
+# define DP_VESA_RANGE  (0 << 3)
+# define DP_CEA_RANGE   (1 << 3)
+# define DP_TEST_YCBCR_COEFFICIENTS (1 << 4)
+# define DP_YCBCR_COEFFICIENTS_ITU601   (0 << 4)
+# define DP_YCBCR_COEFFICIENTS_ITU709   (1 << 4)
+# define DP_TEST_BIT_DEPTH_MASK (7 << 5)
+# define DP_TEST_BIT_DEPTH_SHIFT5
+# define DP_TEST_BIT_DEPTH_6(0 << 5)
+# define DP_TEST_BIT_DEPTH_8(1 << 5)
+# define DP_TEST_BIT_DEPTH_10   (2 << 5)
+# define DP_TEST_BIT_DEPTH_12   (3 << 5)
+# define DP_TEST_BIT_DEPTH_16   (4 << 5)
+#define DP_TEST_MISC1   0x233
+# define DP_TEST_REFRESH_DENOMINATOR(1 << 0)
+# define REFRESH_DENOMINATOR_1  0x0
+# define REFRESH_DENOMINATOR_1_001  0x1
+# define DP_TEST_INTERLACED (1 << 1)
+# define DP_NON_INTERLACED  (0 << 1)
+# define DP_INTERLACED  (1 << 1)
+
+#define DP_TEST_REFRESH_RATE_NUMERATOR  0x234
 
 #define DP_TEST_CRC_R_CR   0x240
 #define DP_TEST_CRC_G_Y0x242
-- 
1.9.1

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

[PATCH 2/4] drm/i915: Fixes to support DP Compliance EDID tests

This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte

Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.

v2:
* Added read debugfs data from test_data.edid if its EDID test (Jani NIkula)
Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 5 -
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index fa69d72..8ec7edf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3772,7 +3772,10 @@ static int i915_displayport_test_data_show(struct 
seq_file *m, void *data)
if (connector->status == connector_status_connected &&
connector->encoder != NULL) {
intel_dp = enc_to_intel_dp(connector->encoder);
-   seq_printf(m, "%lx", 
intel_dp->compliance.test_data.edid);
+   if (intel_dp->compliance.test_type ==
+   DP_TEST_LINK_EDID_READ)
+   seq_printf(m, "%lx",
+  intel_dp->compliance.test_data.edid);
} else
seq_puts(m, "0");
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3e76b63..7ca45e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3977,7 +3977,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct 
intel_dp *intel_dp)
 
 static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
 {
-   uint8_t test_result = DP_TEST_NAK;
+   uint8_t test_result = DP_TEST_ACK;
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
 
@@ -4012,7 +4012,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("Failed to write EDID checksum\n");
 
test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
-   intel_dp->compliance.test_data.edid = 
INTEL_DP_RESOLUTION_STANDARD;
+   intel_dp->compliance.test_data.edid = 
INTEL_DP_RESOLUTION_PREFERRED;
}
 
/* Set test active flag here so userspace doesn't interrupt things */
-- 
1.9.1

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

[PATCH 1/4] drm/i915: Add support for DP link training compliance

This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is sent in order
to trigger another modeset during which the pipe is configured
and link is retrained and enabled for link parameters requested
by the test.

v3:
* Validate the test link rate and lane count as soon as
the erquest comes (Jani Nikula)
v2:
* Validate the test lane count before using it in
intel_dp_compute_config (Jani Nikula)
Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/i915/intel_dp.c  | 60 
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 2 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e80d620..3e76b63 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1613,6 +1613,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
/* Conveniently, the link BW constants become indices with a shift...*/
int min_clock = 0;
int max_clock;
+   int link_rate_index;
int bpp, mode_rate;
int link_avail, link_clock;
int common_rates[DP_MAX_SUPPORTED_RATES] = {};
@@ -1654,6 +1655,15 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;
 
+   /* Use values requested by Compliance Test Request */
+   if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  
drm_dp_bw_code_to_link_rate(intel_dp->compliance.test_link_rate));
+   if (link_rate_index >= 0)
+   min_clock = max_clock = link_rate_index;
+   min_lane_count = max_lane_count = 
intel_dp->compliance.test_lane_count;
+   }
DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %d pixel clock %iKHz\n",
  max_lane_count, common_rates[max_clock],
@@ -3920,7 +3930,42 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
 
 static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
 {
-   uint8_t test_result = DP_TEST_ACK;
+   uint8_t test_result = DP_TEST_NAK;
+   int status = 0;
+   int min_lane_count = 1;
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+   int link_rate_index;
+   /* (DP CTS 1.2)
+* 4.3.1.11
+*/
+   /* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
+   status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LANE_COUNT,
+ _dp->compliance.test_lane_count);
+
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Lane count read failed\n");
+   return 0;
+   }
+   intel_dp->compliance.test_lane_count &= DP_MAX_LANE_COUNT_MASK;
+   /* Validate the requested lane count */
+   if (intel_dp->compliance.test_lane_count < min_lane_count ||
+   intel_dp->compliance.test_lane_count > 
intel_dp->max_sink_lane_count)
+   return test_result;
+
+   status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LINK_RATE,
+  _dp->compliance.test_link_rate);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Link Rate read failed\n");
+   return 0;
+   }
+   /* Validate the requested link rate */
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  
drm_dp_bw_code_to_link_rate(intel_dp->compliance.test_link_rate));
+   if (link_rate_index < 0)
+   return test_result;
+
+   test_result = DP_TEST_ACK;
return test_result;
 }
 
@@ -4135,9 +4180,8 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
if (!intel_dp->lane_count)
return;
 
-   /* if link training is requested we should perform it always */
-   if ((intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) ||
-   (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
+   /* Retrain if Channel EQ or CR not ok */
+   if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
  intel_encoder->base.name);
 
@@ -4162,6 +4206,7 @@ static void intel_dp_handle_test_request(struct intel_dp

[PATCH 0/4] Add Automation Support for DP Compliance (Rev 5)

This series addresses review comments from the previous series:
https://patchwork.freedesktop.org/series/18150/

Apart from addressing review comments, it also adds a fix for
CRC mismatch errors in Compliance tests 4.4.1.1 - 4.4.1.3

DP 1.2 compliance testing can be acheived using DPR-120's CTS suite.
This compliance unit sends a short pulse to initiate link training
and video pattern generation compliance tests and sends a long pulse
to initate EDID compliance tests. It also sets the AUTOMATED TEST REQUEST
bit in Device IRQ to 1. These patches add support in the kernel to respond
to these test requests sent by DPR-120. The test handler has been added for
Link training/EDID and Video pattern compliance tests that gets invoked on
short/long pulse sent by DPR-120. The test handler for each of the tests
reads the corresponding DPCD registers to read the test parameters.

These tests need to be run with the IGT DP compliance automation tool.
Link Training Tests (4.3.1.1 - 4.3.2.3):
It reads the DPCD registers to get the link rate and lane count requested by
test and sends a hotplug uevent for the userspace to redo a modeset in order
to train the link at the requested test parameters.

EDID Tests (4.2.2.3 - 4.2.2.6):
It reads the EDID set by the DPR-120, if EDID read succeeds, it sets the
video mode to PREFERRED and sets the test_active flag. This flag wakes up
the IGT compliance tool that then fills the framebuffers and triggers a
modeset.

Video Pattern Tests (4.3.3.1):
It reads the DPCD registers to set the requested video pattern parameters.
It then sets the test active flag that wakes up the IGT tool, userspace
reads the video pattern values from corresponding debugfs files and fills the
framebuffers and triggers a modeset.
If the requested video pattern is 18bpp, then we force the dither to be off
so that CRC for the RGB pixels of the rendered video pattern matches the 
expected
CRC.

Manasi Navare (4):
  drm/i915: Add support for DP link training compliance
  drm/i915: Fixes to support DP Compliance EDID tests
  drm: Add definitions for DP compliance Video pattern tests
  drm/i915: Add support for DP Video pattern compliance tests

 drivers/gpu/drm/i915/i915_debugfs.c  |  14 +++-
 drivers/gpu/drm/i915/intel_display.c |   8 ++-
 drivers/gpu/drm/i915/intel_dp.c  | 130 +--
 drivers/gpu/drm/i915/intel_dp_mst.c  |   7 +-
 drivers/gpu/drm/i915/intel_drv.h |  13 
 include/drm/drm_dp_helper.h  |  64 +
 6 files changed, 225 insertions(+), 11 deletions(-)

-- 
1.9.1

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

[PATCH 4/4] drm/i915: Add support for DP Video pattern compliance tests

The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color value. The results of this analysis
are handed off to userspace so that the userspace app can set the
video pattern mode appropriately for the test result/response.
When the  test is requested with specific BPC value, we read the BPC
value from the DPCD register. If this BPC value in intel_dp structure
has a non-zero value and we're on a display port connector, then we use
the value to calculate the bpp for the pipe. Also in this case if its
a 18bpp video pattern request, then we force the dithering on pipe to be
disabled since it causes CRC mismatches.

The compliance_test_active flag is set at the end of the individual
test handling functions. This is so that the kernel-side operations
can be completed without the risk of interruption from the userspace
app that is polling on that flag.

v3:
* Use the updated properly shifted bit definitions (Jani Nikula)
* Force dithering to be disabled on 18bpp compliance
test request (Manasi Navare)
v2:
* Updated the DPCD Register reads based on proper defines in header (Jani 
Nikula)
* Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani 
Nikula)
Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  9 +
 drivers/gpu/drm/i915/intel_display.c |  8 +++--
 drivers/gpu/drm/i915/intel_dp.c  | 66 
 drivers/gpu/drm/i915/intel_dp_mst.c  |  7 +++-
 drivers/gpu/drm/i915/intel_drv.h | 11 ++
 5 files changed, 98 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8ec7edf..2eb8e50 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3776,6 +3776,15 @@ static int i915_displayport_test_data_show(struct 
seq_file *m, void *data)
DP_TEST_LINK_EDID_READ)
seq_printf(m, "%lx",
   intel_dp->compliance.test_data.edid);
+   else if (intel_dp->compliance.test_type ==
+DP_TEST_LINK_VIDEO_PATTERN) {
+   seq_printf(m, "hdisplay: %d\n",
+  
intel_dp->compliance.test_data.hdisplay);
+   seq_printf(m, "vdisplay: %d\n",
+  
intel_dp->compliance.test_data.vdisplay);
+   seq_printf(m, "bpc: %u\n",
+  intel_dp->compliance.test_data.bpc);
+   }
} else
seq_puts(m, "0");
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0f4272f..c593789 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13052,8 +13052,12 @@ static bool check_digital_port_conflicts(struct 
drm_atomic_state *state)
}
 
/* Dithering seems to not pass-through bits correctly when it should, so
-* only enable it on 6bpc panels. */
-   pipe_config->dither = pipe_config->pipe_bpp == 6*3;
+* only enable it on 6bpc panels and when its not a compliance
+* test requesting 6bpc video pattern.
+*/
+   pipe_config->dither = (pipe_config->pipe_bpp == 6*3) &&
+   !pipe_config->dither_force_disable;
+
DRM_DEBUG_KMS("hw max bpp: %i, pipe bpp: %i, dithering: %i\n",
  base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7ca45e0..044e36a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -28,8 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1593,6 +1595,13 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
if (bpc > 0)
bpp = min(bpp, 3*bpc);
 
+   /* For DP Compliance we override the computed bpp for the pipe */
+   if (intel_dp->compliance.test_data.bpc != 0) {
+   pipe_config->pipe_bpp = 3*intel_dp->compliance.test_data.bpc;
+   pipe_config->dither_force_disable = pipe_config->pipe_bpp == 
6*3;
+   DRM_DEBUG_KMS("Setting pipe_bpp to %d\n",
+ pipe_config->pipe_bpp);
+   }
return bpp;
 }
 
@@ -3972,6 +3981,63 @@ static uint8_t intel_dp_autotest_link_training(struct 
intel_dp

Re: [PATCH v2] drm/exynos: use atomic helper commit

2017-01-19 Thread Inki Dae

Hi Tobias,

2017년 01월 19일 21:49에 Tobias Jakobi 이(가) 쓴 글:
> What about Laurent's comment stating that drm_atomic_helper_commit() is
> broken at the moment? Shouldn't there be some kind of warning in the
> commit message that this patch is only safe to apply once the fixes for
> drm_atomic_helper_commit() have landed? I'm already seeing this getting
> merged by accident, without Maarten's series even being reviewed.

What patches you mean?

According to Laurent's comment, async commit support of 
drm_atomic_helper_commit is subect to a race condition.
So I'm checking whether there is any case to use async commit in Exynos DRM 
driver.

As of now, I don't see any case. even without Maarten's patch set, it works 
well - actually, I had a test with atomic test app more than 10 hours..

And important thing is that this posting is just for review not merge. So if 
there is any critical problem with this patch, I will stop to merge it. This 
would be my role, maintainer. 

Thanks.

> 
> The commit message looks much better now. Still some spelling issues remain:
> implemention -> implementation
> 
> 
> With best wishes,
> Tobias
> 
> 
> Inki Dae wrote:
>> This patch replaces specific atomic commit function
>> with atomic helper commit one.
>>
>> For this, it removes existing atomic commit function
>> and relevant code specific to Exynos DRM and makes
>> atomic helper commit to be used instead.
>>
>> Below are changes for the use of atomic helper commit:
>> - add atomic_commit_tail callback specific to Exynos DRM
>>   . default implemention of atomic helper doesn't mesh well
>> with runtime PM so the device driver which supports runtime
>> PM should call drm_atomic_helper_commit_modeset_enables function
>> prior to drm_atomic_helper_commit_planes function call.
>> atomic_commit_tail callback implements this call ordering.
>> - allow plane commit only in case that CRTC device is enabled.
>>   . for this, it calls atomic_helper_commit_planes function
>> with DRM_PLANE_COMMIT_ACTIVE_ONLY flag in atomic_commit_tail callback.
>>
>> Changelog v1:
>> - fix comment
>> - fix trivial things
>> - revive existing comment which explains why plane commit should be
>>   called after crtc and encoder device are enabled.
>>
>> Signed-off-by: Inki Dae 
>> Reviewed-by: Gustavo Padovan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  10 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 109 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c   |  32 -
>>  3 files changed, 40 insertions(+), 111 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 2530bf5..8f13bce 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -39,6 +39,14 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
>>  
>>  if (exynos_crtc->ops->disable)
>>  exynos_crtc->ops->disable(exynos_crtc);
>> +
>> +if (crtc->state->event && !crtc->state->active) {
>> +spin_lock_irq(>dev->event_lock);
>> +drm_crtc_send_vblank_event(crtc, crtc->state->event);
>> +spin_unlock_irq(>dev->event_lock);
>> +
>> +crtc->state->event = NULL;
>> +}
>>  }
>>  
>>  static void
>> @@ -94,9 +102,9 @@ static void exynos_crtc_atomic_flush(struct drm_crtc 
>> *crtc,
>>  drm_crtc_send_vblank_event(crtc, event);
>>  spin_unlock_irqrestore(>dev->event_lock, flags);
>>  }
>> -
>>  }
>>  
>> +
>>  static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
>>  .enable = exynos_drm_crtc_enable,
>>  .disable= exynos_drm_crtc_disable,
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 3ec0535..c8f3eeb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> @@ -38,56 +38,6 @@
>>  #define DRIVER_MAJOR1
>>  #define DRIVER_MINOR0
>>  
>> -struct exynos_atomic_commit {
>> -struct work_struct  work;
>> -struct drm_device   *dev;
>> -struct drm_atomic_state *state;
>> -u32 crtcs;
>> -};
>> -
>> -static void exynos_atomic_commit_complete(struct exynos_atomic_commit 
>> *commit)
>> -{
>> -struct drm_device *dev = commit->dev;
>> -struct exynos_drm_private *priv = dev->dev_private;
>> -struct drm_atomic_state *state = commit->state;
>> -
>> -drm_atomic_helper_commit_modeset_disables(dev, state);
>> -
>> -drm_atomic_helper_commit_modeset_enables(dev, state);
>> -
>> -/*
>> - * Exynos can't update planes with CRTCs and encoders disabled,
>> - * its updates routines, specially for FIMD, requires the clocks
>> - * to be enabled. So it is necessary to handle the modeset operations
>> - * *before* the commit_planes()

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

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

--- Comment #17 from Michel Dänzer  ---
(In reply to lei.pero from comment #14)
> It does happen on modesetting driver regardless of DRI version, strange.

The modesetting driver doesn't allow disabling DRI3 on the server side. You can
always disable it on the client side though with the environment variable
LIBGL_DRI3_DISABLE=1 .

The fps graph shows the same framerate in both videos, so the problem seems
rather about animation timing. It might be related to the fact that DRI3 allows
triple buffering, and might be at least partially an application issue. It
would be interesting though if it also happens with a non-AMD GPU.

BTW, is there any particular reason why you're disabling sync-to-vblank? It is
the intended mechanism for smooth animation...

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

[Bug 192921] Low frame rates and unrecognized monitor after kernel upgrade

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

--- Comment #6 from Michel Dänzer  ---
dmesg shows that the amdgpu driver fails to initialize due to missing
microcode:

 amdgpu :01:00.0: Direct firmware load for amdgpu/tonga_k_smc.bin failed
with error -2

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

[Bug 192921] Low frame rates and unrecognized monitor after kernel upgrade

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

--- Comment #5 from stevengrusp...@gmail.com ---
Created attachment 252501
  --> https://bugzilla.kernel.org/attachment.cgi?id=252501=edit
Glxinfo

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

[Bug 192921] Low frame rates and unrecognized monitor after kernel upgrade

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

--- Comment #4 from stevengrusp...@gmail.com ---
xrandr
[CODE]
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 2560 x 1440, current 2560 x 1440, maximum 2560 x 1440
default connected primary 2560x1440+0+0 0mm x 0mm
   2560x1440  0.00* 
[/CODE]


Glxgears
[CODE]
2799 frames in 5.0 seconds = 559.599 FPS
3023 frames in 5.0 seconds = 604.556 FPS
2909 frames in 5.0 seconds = 581.332 FPS
2969 frames in 5.0 seconds = 593.634 FPS
2996 frames in 5.0 seconds = 598.985 FPS
[/CODE]

I am using wayland, so what is the equivalent of the xorg log file?

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

[Bug 192921] Low frame rates and unrecognized monitor after kernel upgrade

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

--- Comment #3 from stevengrusp...@gmail.com ---
Created attachment 252491
  --> https://bugzilla.kernel.org/attachment.cgi?id=252491=edit
Dmesg Output

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

[Bug 192921] Low frame rates and unrecognized monitor after kernel upgrade

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

--- Comment #2 from Michel Dänzer  ---
Please attach the Xorg log file and output of glxinfo as well.

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

[Bug 192921] Low frame rates and unrecognized monitor after kernel upgrade

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

--- Comment #1 from Michel Dänzer  ---
Please attach the dmesg output.

Can you bisect?

What does xrandr say about the mode, and what framerate does e.g. glxgears
report?

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

Re: amdgpu: Corrupted video on 32 bit systems (possible fix)

2017-01-19 Thread Michel Dänzer

On 20/01/17 04:35 AM, Nils Holland wrote:
> Hi folks,
> 
> there seems to be an issue on 32 bit kernels which makes graphics
> output look all messed up under X when using the amdgpu drm kernel
> driver.
> 
> In fact, the same issue was present at some time in 2015 using the
> radeon driver too, but it has been fixed a long time ago, as can be
> seen here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=84627#c35
> 
> Now, I reported the same issue in conjunction with the amdgpu driver
> back when I first noticed it back then. Nothing has happened since
> then, but my bug report can still be found here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=91831
> 
> Personally, I had been using the (working) radeon driver again, and
> only today I decided to check if the issue in amdgpu still exists. And
> yes, it seems so: I still get garbled output when using a current
> kernel with a current version of the amdgpu driver.
> 
> Now, I've tried to just "port"  the fix that had been done to the radeon
> driver in 2015 (see the first link above) to the amdgpu driver and created
> myself the following little patch:
> 
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  2016-12-11 
> 20:17:54.0 +0100
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c  2017-01-19 
> 15:38:56.972034489 +0100
> @@ -372,6 +372,10 @@
>   if (!drm_arch_can_wc_memory())
>   bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
>  
> + #ifdef CONFIG_X86_32
> + bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
> + #endif
> +
>   amdgpu_fill_placement_to_bo(bo, placement);
>   /* Kernel allocation are uninterruptible */
>   r = ttm_bo_init(>mman.bdev, >tbo, size, type,

The corresponding code in the radeon driver has changed quite a bit
since this original fix. It would be better to bring the amdgpu code in
line with the current radeon code.


> With this patch, the amdgpu driver works fine for me on my 32 bit
> kernel: All graphics output looks the way it's supposed to, even with
> full acceleration enabled - great!
> 
> I'd suggest that it might be a good idea to put to apply the above
> patch or something similar to the official sources.

Indeed. Do you want to create a proper patch and submit it to the
amd-gfx mailing list for review? See Documentation/SubmittingPatches for
more information.


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

[Bug 192921] Low frame rates and unrecognized monitor after kernel upgrade

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

stevengrusp...@gmail.com changed:

   What|Removed |Added

 Regression|No  |Yes

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

[Bug 192921] New: Low frame rates and unrecognized monitor after kernel upgrade

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

Bug ID: 192921
   Summary: Low frame rates and unrecognized monitor after kernel
upgrade
   Product: Drivers
   Version: 2.5
Kernel Version: 4.10.0
  Hardware: x86-64
OS: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: stevengrusp...@gmail.com
Regression: No

Before upgrading my kernel (4.8.16), there was always a problem where at boot
the refresh rate was too high, so my screen would flicker. I could only set the
refresh rate to 120Hz max without any flickering. This was due to a bug or
feature that had yet to be added to the kernel (was fixed in the DAL patched
unofficial kernel). 

After upgrading the kernel to 4.9.3 I noticed that on boot there was no
flickering at 144Hz anymore, but when trying to play games and videos there are
issues with low frame rates. I then went to the display menu to check settings
and noticed that the monitor now says "unknown". I installed 4.10.0 rc 3 from
the rawhide repo with the same results.

Distro: Fedora 25
GPU: ASUS Strix AMD R9 380 4GB
Monitor: MG278Q (2560 x 1440 @ 144Hz)

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

[Bug 99459] Performace drop on AMD TONGA(380x) on kernels 4.9 and 4.10RC3

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

--- Comment #1 from Michel Dänzer  ---
Can you bisect?

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

[Bug 99456] Firefox crashing when opening about:support with WebGL2 enabled

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

--- Comment #7 from Clément Guérin  ---
Hi Marek,

No, the mesa build I was using when hitting the bug already included this
commit.

I also tried with e0674e740bf8 (current master~1) and I get a crash too.

-- 
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/exynos: g2d: fix overflow of cmdlist size

2017-01-19 Thread Joonyoung Shim

Hi Tobias,

On 01/19/2017 10:16 PM, Tobias Jakobi wrote:
> Hello Joonyoung,
> 
> Joonyoung Shim wrote:
>> Hi Tobias,
>>
>> On 01/17/2017 11:24 PM, Tobias Jakobi wrote:
>>> Joonyoung Shim wrote:
 The size of cmdlist is integer type, so it can be overflowed by cmd and
 cmd_buf that has too big size. This patch will fix overflow issue as
 checking maximum size of cmd and cmd_buf.
>>> I don't understand/see the issue here. Could you point out for which
>>> input of the set_cmdlist ioctl you see this particular overflow?
>>>
>>> In particular it is not clear to me which size field you're talking
>>> about. struct g2d_cmdlist does not have any field named 'size'.
>>>
>>
>> I mean size of cmdlist is
>> size = cmdlist->last + req->cmd_nr * 2 + req->cmd_buf_nr * 2 + 2;
>> in exynos_g2d_set_cmdlist_ioctl().
> ok, that makes things more clear. But then you need to fix the commit
> message. The current message implies that this 'size' you're talking
> about is some property of the cmdlist.
> 
> Also the new comment is wrong.
> /* Check size of cmd and cmdlist: last 2 is about G2D_BITBLT_START */
> 
> What is cmd and cmdlist? You're mixing two different things here. We are
> still checking the size of 'cmdlist' (which is a struct g2d_cmdlist) here.
> 
> What you add is a check for the fields of 'req' (which is a struct
> drm_exynos_g2d_set_cmdlist).
> 
> With all that said, I don't like the changes. I see the issue, but the
> current solution should be cleaner.
> 
> I propose this. We just check req->cmd_buf_nr and req->cmd_nr against
> G2D_CMDLIST_DATA_NUM. This leaves us enough headrom so that the later
> computation (i.e. what is ending up in the local variable 'size') can
> never overflow.
> 

Agree, it's more clear to check req->cmd_buf_nr and req->cmd_nr against
G2D_CMDLIST_DATA_NUM.

> For a comment for the check I propose this:
> "To avoid an integer overflow for the later size computations, we
> enforce a maximum number of submitted commands here. This limit is
> sufficient for all conceivable usage cases of the G2D."
> 

Could you post your patch to ML about this if you want?

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

[Bug 99456] Firefox crashing when opening about:support with WebGL2 enabled

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

--- Comment #6 from Marek Olšák  ---
Does this commit fix it?
https://cgit.freedesktop.org/mesa/mesa/commit/?id=35cd7551a443477147293e562d8c1adfbe00dea9

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

Re: [PATCH v2] drm/exynos: use atomic helper commit

2017-01-19 Thread Inki Dae



2017년 01월 19일 20:53에 Gustavo Padovan 이(가) 쓴 글:
> Hi Inki,
> 
> 2017-01-19 Inki Dae :
> 
>> This patch replaces specific atomic commit function
>> with atomic helper commit one.
>>
>> For this, it removes existing atomic commit function
>> and relevant code specific to Exynos DRM and makes
>> atomic helper commit to be used instead.
>>
>> Below are changes for the use of atomic helper commit:
>> - add atomic_commit_tail callback specific to Exynos DRM
>>   . default implemention of atomic helper doesn't mesh well
>> with runtime PM so the device driver which supports runtime
>> PM should call drm_atomic_helper_commit_modeset_enables function
>> prior to drm_atomic_helper_commit_planes function call.
>> atomic_commit_tail callback implements this call ordering.
>> - allow plane commit only in case that CRTC device is enabled.
>>   . for this, it calls atomic_helper_commit_planes function
>> with DRM_PLANE_COMMIT_ACTIVE_ONLY flag in atomic_commit_tail callback.
>>
>> Changelog v1:
>> - fix comment
>> - fix trivial things
>> - revive existing comment which explains why plane commit should be
>>   called after crtc and encoder device are enabled.
>>
>> Signed-off-by: Inki Dae 
>> Reviewed-by: Gustavo Padovan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  10 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 109 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c   |  32 -
>>  3 files changed, 40 insertions(+), 111 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> index 2530bf5..8f13bce 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>> @@ -39,6 +39,14 @@ static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
>>  
>>  if (exynos_crtc->ops->disable)
>>  exynos_crtc->ops->disable(exynos_crtc);
>> +
>> +if (crtc->state->event && !crtc->state->active) {
>> +spin_lock_irq(>dev->event_lock);
>> +drm_crtc_send_vblank_event(crtc, crtc->state->event);
>> +spin_unlock_irq(>dev->event_lock);
>> +
>> +crtc->state->event = NULL;
>> +}
>>  }
>>  
>>  static void
>> @@ -94,9 +102,9 @@ static void exynos_crtc_atomic_flush(struct drm_crtc 
>> *crtc,
>>  drm_crtc_send_vblank_event(crtc, event);
>>  spin_unlock_irqrestore(>dev->event_lock, flags);
>>  }
>> -
>>  }
>>  
>> +
> 
> Please refrain from removing/adding random blank lines when working on your

Oops, sorry. I didn't check it. :(

> features, they polute the code review and git history. Actually your line
> addition here breaks the kernel coding styles rules. Please update the
> patch.
> 
> Gustavo
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Time to update GSoC/EVoC ideas page

2017-01-19 Thread Rob Clark

Just a friendly reminder that now would be a good time to update the
wiki page for GSoC/EVoC ideas:

  https://www.x.org/wiki/SummerOfCodeIdeas/

There are currently still some stale ideas there (and probably plenty
of missing good ideas).

Also, I've added a "Potential Mentors" section.  Please add yourself
if you are willing to be a mentor (and what sorts of projects you
would be willing to mentor)

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

Re: [PATCH] drm: Provide a driver hook for drm_dev_release()

Hi Chris,

On Thursday 19 Jan 2017 11:20:37 Chris Wilson wrote:
> On Wed, Dec 14, 2016 at 12:04:38AM +0200, Laurent Pinchart wrote:
> > On Thursday 08 Dec 2016 08:18:40 Chris Wilson wrote:
> >> Some state is coupled into the device lifetime outside of the
> >> load/unload timeframe and requires teardown during final unreference
> >> from drm_dev_release(). For example, dmabufs hold both a device and
> >> module reference and may live longer than expected (i.e. the current
> >> pattern of the driver tearing down its state and then releasing a
> >> reference to the drm device) and yet touch driver private state when
> >> destroyed.
> >> 
> >> Signed-off-by: Chris Wilson 
> >> ---
> >> 
> >>  drivers/gpu/drm/drm_drv.c | 3 +++
> >>  include/drm/drm_drv.h | 8 
> >>  2 files changed, 11 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >> index f74b7d06ec01..f945bbcc8eb3 100644
> >> --- a/drivers/gpu/drm/drm_drv.c
> >> +++ b/drivers/gpu/drm/drm_drv.c
> >> @@ -595,6 +595,9 @@ static void drm_dev_release(struct kref *ref)
> >>  {
> >>struct drm_device *dev = container_of(ref, struct drm_device, ref);
> >> 
> >> +  if (dev->driver->release)
> >> +  dev->driver->release(dev);
> >> +
> >>if (drm_core_check_feature(dev, DRIVER_GEM))
> >>drm_gem_destroy(dev);
> > 
> > For drivers embedding the drm_device structure, you should only call
> > .release() at the very end of this function, as the callback will free
> > memory, including the embedded struct drm_device.
> 
> Not quite. The layering is wrong as the driver needs to release its
> state prior to e.g. drm_gem_destroy. It is not for freeing the memory.

drm_dev_release() is the drm_device kref's release function. It is the last 
function called on a drm_device when the last reference goes away. It's 
responsible for performing the last cleanups, and turning the lights off.

Turning the lights off involves freeing the drm_device memory. This is 
currently done by drm_dev_release() unconditionally. When drivers allocate the 
drm_device structure dynamically with drm_dev_alloc() the existing code is 
fine. However, when drivers embed the drm_device structure in a driver-
specific structure, the kfree() at the end of drm_dev_release() only does the 
right thing if the driver-specific structure embeds the drm_device as the very 
first field. This is a hack, and should eventually be fixed, by propagating 
the release call to the driver and having the driver free the memory it has 
allocated. This can only be done as the very last operation in 
drm_dev_release().

When drm_dev_release() is called all GEM objects should have been destroyed 
already. The ones exported through dmabuf should hold a reference to the 
drm_device instance, which is dropped when the dmabufs are destroyed. It 
should thus be safe to call drm_gem_destroy() before the driver's release() 
callback.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 10/10] drm/msm/dsi: Add PHY/PLL for 8x96

2017-01-19 Thread Stephen Boyd

On 01/07, Archit Taneja wrote:
> +
> +static struct clk *pll_14nm_postdiv_register(struct dsi_pll_14nm *pll_14nm,
> +  const char *name,
> +  const char *parent_name,
> +  unsigned long flags,
> +  u8 shift)
> +{
> + struct dsi_pll_14nm_postdiv *pll_postdiv;
> + struct device *dev = _14nm->pdev->dev;
> + struct clk_init_data postdiv_init = {
> + .parent_names = (const char *[]) { parent_name },
> + .num_parents = 1,
> + .name = name,
> + .flags = flags,
> + .ops = _ops_dsi_pll_14nm_postdiv,
> + };
> +
> + pll_postdiv = devm_kzalloc(dev, sizeof(*pll_postdiv), GFP_KERNEL);
> + if (!pll_postdiv)
> + return ERR_PTR(-ENOMEM);
> +
> + pll_postdiv->pll = pll_14nm;
> + pll_postdiv->shift = shift;
> + /* both N1 and N2 postdividers are 4 bits wide */
> + pll_postdiv->width = 4;
> + /* range of each divider is from 1 to 15 */
> + pll_postdiv->flags = CLK_DIVIDER_ONE_BASED;
> + pll_postdiv->hw.init = _init;
> +
> + return clk_register(dev, _postdiv->hw);

Can you use clk_hw_register() and the variants instead? Same for
the clk_provider calls in this patch.

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

amdgpu: Corrupted video on 32 bit systems (possible fix)

2017-01-19 Thread Nils Holland

Hi folks,

there seems to be an issue on 32 bit kernels which makes graphics
output look all messed up under X when using the amdgpu drm kernel
driver.

In fact, the same issue was present at some time in 2015 using the
radeon driver too, but it has been fixed a long time ago, as can be
seen here:

https://bugs.freedesktop.org/show_bug.cgi?id=84627#c35

Now, I reported the same issue in conjunction with the amdgpu driver
back when I first noticed it back then. Nothing has happened since
then, but my bug report can still be found here:

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

Personally, I had been using the (working) radeon driver again, and
only today I decided to check if the issue in amdgpu still exists. And
yes, it seems so: I still get garbled output when using a current
kernel with a current version of the amdgpu driver.

Now, I've tried to just "port"  the fix that had been done to the radeon
driver in 2015 (see the first link above) to the amdgpu driver and created
myself the following little patch:

--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2016-12-11 
20:17:54.0 +0100
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2017-01-19 
15:38:56.972034489 +0100
@@ -372,6 +372,10 @@
if (!drm_arch_can_wc_memory())
bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
 
+   #ifdef CONFIG_X86_32
+   bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
+   #endif
+
amdgpu_fill_placement_to_bo(bo, placement);
/* Kernel allocation are uninterruptible */
r = ttm_bo_init(>mman.bdev, >tbo, size, type,

With this patch, the amdgpu driver works fine for me on my 32 bit
kernel: All graphics output looks the way it's supposed to, even with
full acceleration enabled - great!

I'd suggest that it might be a good idea to put to apply the above
patch or something similar to the official sources.

Note that I've only experienced the issue and successfully tried the
patch on one GPU, namely my...:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Kabini [Radeon HD 8210]

...and cannot say anything about how things look with 32 bit and other
cards supported by amdgpu, except for the fact that another user has
reported the same issue with a Tonga GPU (see the comments in the
second link above), and I'm pretty sure that this change would help in
his and similar cases, too.

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

[Bug 99456] Firefox crashing when opening about:support with WebGL2 enabled

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

--- Comment #5 from Clément Guérin  ---
bf75ef3f9201e11bb08a4d03dab20d5ff86f1ebc is the first bad commit
commit bf75ef3f9201e11bb08a4d03dab20d5ff86f1ebc
Author: Marek Olšák 
Date:   Tue Nov 15 21:15:55 2016 +0100

radeonsi: remove all varyings for depth-only rendering or rasterization off

Tested-by: Edmondo Tommasina 
Reviewed-by: Nicolai Hähnle 

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

[Bug 99456] Firefox crashing when opening about:support with WebGL2 enabled

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

--- Comment #4 from Clément Guérin  ---
I did some bisecting yesterday, didn't have to finish but I'm really close.
I'll update later today.

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

Re: [PATCH v3 2/2] drm: qxl: Open code teardown function for qxl

2017-01-19 Thread Gustavo Padovan

Hi Gabriel,

2017-01-19 Gabriel Krisman Bertazi :

> This avoids using the deprecated drm_put_dev() and unload() hook
> interfaces in the qxl driver.
> 
> Signed-off-by: Gabriel Krisman Bertazi 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Cc: Gustavo Padovan 
> ---
>  drivers/gpu/drm/qxl/qxl_drv.c | 11 +--
>  drivers/gpu/drm/qxl/qxl_drv.h |  2 --
>  drivers/gpu/drm/qxl/qxl_kms.c | 16 
>  3 files changed, 9 insertions(+), 20 deletions(-)

Both patches applied to drm-misc-next. Thanks.

Gustavo

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

[Bug 99450] [amdgpu] Payday 2 visual glitches on some models

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

--- Comment #2 from hugo.pos...@protonmail.com ---
(In reply to Samuel Pitoiset from comment #1)
> Should be fixed by e490b7812cae778c61004971d86dc8299b6cd240.

Thank's for this patch. Can't test it but I hope so ;)

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

[Bug 99450] [amdgpu] Payday 2 visual glitches on some models

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #1 from Samuel Pitoiset  ---
Should be fixed by e490b7812cae778c61004971d86dc8299b6cd240.

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

[Bug 98975] Wasteland 2 Directors Cut: Hangs. GPU fault

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #1 from Samuel Pitoiset  ---
Should be fixed by e490b7812cae778c61004971d86dc8299b6cd240.

-- 
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 4/5] dt: add bindings for ZTE tvenc device

2017-01-19 Thread Lucas Stach

Am Freitag, den 20.01.2017, 00:24 +0800 schrieb Shawn Guo:
> From: Shawn Guo 
> 
> It adds bindings doc for ZTE VOU TV Encoder device.
> 
> Signed-off-by: Shawn Guo 
> ---
>  Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt 
> b/Documentation/devicetree/bindings/display/zte,vou.txt
> index 740e5bd2e4f7..9c356284232b 100644
> --- a/Documentation/devicetree/bindings/display/zte,vou.txt
> +++ b/Documentation/devicetree/bindings/display/zte,vou.txt
> @@ -49,6 +49,15 @@ Required properties:
>   "osc_clk"
>   "xclk"
>  
> +* TV Encoder output device
> +
> +Required properties:
> + - compatible: should be "zte,zx296718-tvenc"
> + - reg: Physical base address and length of the TVENC device IO region
> + - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two
> +   integer cells.  The first cell is the offset of SYSCTRL register used
> +   to control TV Encoder DAC power, and the second cell is the bit mask.

I don't know much about this platform, but shouldn't this be handled
with a proper power domain driver, rather than bashing bits directly?

Regards,
Lucas

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

Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

Hi Peter,

On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> >>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
>  On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >> On 03 January, 2017 23:51 CET, Rob Herring  wrote:
> >>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin 
wrote:
>  Devicetree bindings documentation for the GE B850v3 LVDS/DP++
>  display bridge.
>  
>  Cc: Martyn Welch 
>  Cc: Martin Donnelly 
>  Cc: Javier Martinez Canillas 
>  Cc: Enric Balletbo i Serra 
>  Cc: Philipp Zabel 
>  Cc: Rob Herring 
>  Cc: Fabio Estevam 
>  Signed-off-by: Peter Senna Tschudin 
>  ---
>  There was an Acked-by from Rob Herring  for V6,
>  but I changed the bindings to use i2c_new_secondary_device() so I
>  removed it from the commit message.
> 
> [...]
> 
>   .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 39 +
> >>> 
> >>> Isn't '-lvds-dp' redundant? The part# should be enough.
> >> 
> >> b850v3 is the name of the product, this is why the proposed name.
> >> What about, b850v3-dp2 dp2 indicating the second DP output?
> > 
> > Humm, b850v3 is the board name? This node should be the name of the
> > bridge chip.
>  
>  From the cover letter:
>  
>  -- // --
>  There are two physical bridges on the video signal pipeline: a
>  STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
>  firmware made it complicated for this binding to comprise two device
>  tree nodes, as the design goal is to configure both bridges based on
>  the LVDS signal, which leave the driver powerless to control the
>  video processing pipeline. The two bridges behaves as a single bridge,
>  and the driver is only needed for telling the host about EDID / HPD,
>  and for giving the host powers to ack interrupts. The video signal
>  pipeline
>  
>  is as follows:
>    Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
>    output
>  
>  -- // --
> >>> 
> >>> You forgot to prefix your patch series with [HACK] ;-)
> >>> 
> >>> How about fixing the issues that make the two DT nodes solution
> >>> difficult ? What are they ?
> >> 
> >> The Firmware and the hardware design. Both bridges, with stock firmware,
> >> are fully capable of providig EDID information and handling interrupts.
> >> But on this specific design, with this specific firmware, I need to read
> >> EDID from one bridge, and handle interrupts on the other.
> > 
> > Which firmware are you talking about ? Firmware running on the bridges, or
> > somewhere else ?
> 
> Each bridge has it's own external flash containing a binary firmware.
> The goal of the firmware is to configure the output end based on the
> input end. This is part of what makes handling EDID and HPD challenging.
> 
> >> Back when I was starting the development I could not come up with a
> >> proper way to split EDID and interrupts between two bridges in a way
> >> that would result in a fully functional connector. Did I miss something?
> > 
> > You didn't, we did :-) I've been telling for quite some time now that we
> > must decouple bridges from connectors, and this is another example of why
> > we have such a need. Bridges should expose additional functions needed to
> > implement connector operations, and the connector should be instantiated
> > by the display driver with the help of bridge operations. You could then
> > create a connector that relies on one bridge to read the EDID and on the
> > other bridge to handle HPD.
> 
> Ah thanks. So for now the single DT node approach is acceptable, right?
> The problem is that even if the driver is getting better on each
> iteration, the single DT node for two chips issue comes back often and I
> believe is _the_ issue preventing the driver from getting upstream. V1
> was sent ~ 8 months ago...
> 
> Can I have some blessing on the single DT node approach for now?

With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are 
acceptable on the driver side, but you need two nodes in DT.

> I'm one of the 3 proposed maintainers for the driver, and I'm willing to
> maintain the driver on the long run, as is the same with the other two
> proposed maintainers. So when the time to split the node in two comes,
> we will be around, and willing to do it

Re: [PATCH v4 1/3] DRM: add help to get ELD speaker allocation

2017-01-19 Thread Arnaud Pouliquen



On 01/19/2017 11:29 AM, Mark Brown wrote:
> On Wed, Jan 18, 2017 at 07:38:53AM +1100, Eric Anholt wrote:
>> Mark Brown  writes:
> 
>>> You don't appear to have sent this to any of the DRM
>>> maintainers - it does need review from them.
> 
>> It was sent to dri-devel.  That's us.  And the patch already has
>> a r-b From DRM on it.
> 
> I see.  For most subsystems you need to actually copy a human to
> make sure that things are seen - just the list isn't enough.  In
> terms of it being reviewed one of the problems with DRM not listing
> the reviwers in the MAINTAINERS file or anything is that it's very
> hard for anyone to tell if something is considered a good enough
> review or if it's just a review from someone who happens to
> contribute to DRM sometimes.
> 
I limited diffusion to ASoC, as Daniel Vetter and Takashi Iwai
discussed the topic here:
http://www.spinics.net/lists/alsa-devel/msg58114.html
Seems that is was not a good strategy as it leads to discussions..
Sorry for this.

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

Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

2017-01-19 Thread Peter Senna Tschudin

On Thu, Jan 19, 2017 at 10:17:45AM +0200, Laurent Pinchart wrote:
> Hi Peter,
> 
> On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> > On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> > > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> > >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > >>> On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> >  On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> > >> On 03 January, 2017 23:51 CET, Rob Herring  wrote:
> > >>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin 
> wrote:
> >  Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >  display bridge.
> >  
> >  Cc: Martyn Welch 
> >  Cc: Martin Donnelly 
> >  Cc: Javier Martinez Canillas 
> >  Cc: Enric Balletbo i Serra 
> >  Cc: Philipp Zabel 
> >  Cc: Rob Herring 
> >  Cc: Fabio Estevam 
> >  Signed-off-by: Peter Senna Tschudin 
> >  ---
> >  There was an Acked-by from Rob Herring  for V6,
> >  but I changed the bindings to use i2c_new_secondary_device() so I
> >  removed it from the commit message.
> > 
> > [...]
> > 
> >   .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 39 +
> > >>> 
> > >>> Isn't '-lvds-dp' redundant? The part# should be enough.
> > >> 
> > >> b850v3 is the name of the product, this is why the proposed name.
> > >> What about, b850v3-dp2 dp2 indicating the second DP output?
> > > 
> > > Humm, b850v3 is the board name? This node should be the name of the
> > > bridge chip.
> >  
> >  From the cover letter:
> >  
> >  -- // --
> >  There are two physical bridges on the video signal pipeline: a
> >  STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> >  firmware made it complicated for this binding to comprise two device
> >  tree nodes, as the design goal is to configure both bridges based on
> >  the LVDS signal, which leave the driver powerless to control the
> >  video processing pipeline. The two bridges behaves as a single bridge,
> >  and the driver is only needed for telling the host about EDID / HPD,
> >  and for giving the host powers to ack interrupts. The video signal
> >  pipeline
> >  
> >  is as follows:
> >    Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> >    output
> >  
> >  -- // --
> > >>> 
> > >>> You forgot to prefix your patch series with [HACK] ;-)
> > >>> 
> > >>> How about fixing the issues that make the two DT nodes solution
> > >>> difficult ? What are they ?
> > >> 
> > >> The Firmware and the hardware design. Both bridges, with stock firmware,
> > >> are fully capable of providig EDID information and handling interrupts.
> > >> But on this specific design, with this specific firmware, I need to read
> > >> EDID from one bridge, and handle interrupts on the other.
> > > 
> > > Which firmware are you talking about ? Firmware running on the bridges, or
> > > somewhere else ?
> > 
> > Each bridge has it's own external flash containing a binary firmware.
> > The goal of the firmware is to configure the output end based on the
> > input end. This is part of what makes handling EDID and HPD challenging.
> > 
> > >> Back when I was starting the development I could not come up with a
> > >> proper way to split EDID and interrupts between two bridges in a way
> > >> that would result in a fully functional connector. Did I miss something?
> > > 
> > > You didn't, we did :-) I've been telling for quite some time now that we
> > > must decouple bridges from connectors, and this is another example of why
> > > we have such a need. Bridges should expose additional functions needed to
> > > implement connector operations, and the connector should be instantiated
> > > by the display driver with the help of bridge operations. You could then
> > > create a connector that relies on one bridge to read the EDID and on the
> > > other bridge to handle HPD.
> > 
> > Ah thanks. So for now the single DT node approach is acceptable, right?
> > The problem is that even if the driver is getting better on each
> > iteration, the single DT node for two chips issue comes back often and I
> > believe is _the_ issue preventing the driver from getting upstream. V1
> > was sent ~ 8 months ago...
> > 
> > Can I have some blessing on the single DT node approach for now?
> 
> With the "DT as an ABI" approach, I'm afraid not. Temporary hacks are 
> acceptable on the driver side, but you need two nodes in DT.

So

Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

2017-01-19 Thread Peter Senna Tschudin

On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> Hi Peter,
> 
> On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> > On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> > >> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > >>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >  On 03 January, 2017 23:51 CET, Rob Herring  wrote:
> > > On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> > >> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > >> display bridge.
> > >> 
> > >> Cc: Martyn Welch 
> > >> Cc: Martin Donnelly 
> > >> Cc: Javier Martinez Canillas 
> > >> Cc: Enric Balletbo i Serra 
> > >> Cc: Philipp Zabel 
> > >> Cc: Rob Herring 
> > >> Cc: Fabio Estevam 
> > >> Signed-off-by: Peter Senna Tschudin 
> > >> ---
> > >> There was an Acked-by from Rob Herring  for V6,
> > >> but I changed the bindings to use i2c_new_secondary_device() so I
> > >> removed it from the commit message.
> > >> 

[...]

> > >>  .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 39 +++
> > > 
> > > Isn't '-lvds-dp' redundant? The part# should be enough.
> >  
> >  b850v3 is the name of the product, this is why the proposed name.
> >  What about, b850v3-dp2 dp2 indicating the second DP output?
> > >>> 
> > >>> Humm, b850v3 is the board name? This node should be the name of the
> > >>> bridge chip.
> > >> 
> > >> From the cover letter:
> > >> 
> > >> -- // --
> > >> There are two physical bridges on the video signal pipeline: a
> > >> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> > >> firmware made it complicated for this binding to comprise two device
> > >> tree nodes, as the design goal is to configure both bridges based on
> > >> the LVDS signal, which leave the driver powerless to control the video
> > >> processing pipeline. The two bridges behaves as a single bridge, and
> > >> the driver is only needed for telling the host about EDID / HPD, and
> > >> for giving the host powers to ack interrupts. The video signal pipeline
> > >> is as follows:
> > >>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> > >>   output
> > >> -- // --
> > > 
> > > You forgot to prefix your patch series with [HACK] ;-)
> > > 
> > > How about fixing the issues that make the two DT nodes solution difficult
> > > ? What are they ?
> > 
> > The Firmware and the hardware design. Both bridges, with stock firmware,
> > are fully capable of providig EDID information and handling interrupts.
> > But on this specific design, with this specific firmware, I need to read
> > EDID from one bridge, and handle interrupts on the other.
> 
> Which firmware are you talking about ? Firmware running on the bridges, or 
> somewhere else ?

Each bridge has it's own external flash containing a binary firmware.
The goal of the firmware is to configure the output end based on the
input end. This is part of what makes handling EDID and HPD challenging.

> 
> > Back when I was starting the development I could not come up with a proper
> > way to split EDID and interrupts between two bridges in a way that would
> > result in a fully functional connector. Did I miss something?
> 
> You didn't, we did :-) I've been telling for quite some time now that we must 
> decouple bridges from connectors, and this is another example of why we have 
> such a need. Bridges should expose additional functions needed to implement 
> connector operations, and the connector should be instantiated by the display 
> driver with the help of bridge operations. You could then create a connector 
> that relies on one bridge to read the EDID and on the other bridge to handle 
> HPD.

Ah thanks. So for now the single DT node approach is acceptable, right?
The problem is that even if the driver is getting better on each
iteration, the single DT node for two chips issue comes back often and I
believe is _the_ issue preventing the driver from getting upstream. V1
was sent ~ 8 months ago...

Can I have some blessing on the single DT node approach for now? I'm one
of the 3 proposed maintainers for the driver, and I'm willing to
maintain the driver on the long run, as is the same with the other two
proposed maintainers. So when the time to split the node in two comes,
we will be around, and willing to do it ourselves.

Thank you!

Peter
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC/RFT PATCH 2/4] drm/bridge: dw-hdmi: Add support for custom PHY handling

2017-01-19 Thread Jose Abreu

Hi Neil,


On 18-01-2017 11:20, Neil Armstrong wrote:
>
> It's the idea we discussed with Laurent.
> Keeping the Synopsys PHY code inside the dw-hdmi driver would be simpler.
>
> But don't you think adding a proper "ops" structure apart from the plat_data
> should be necessary ?
>
> Neil
>

An "ops" structure seems fine by me :) We could have one for the
generic phy's (the ones that dw-hdmi already supports) and let
the developer specify other one if needed.

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

Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data

2017-01-19 Thread Jose Abreu

Hi Laurent,

On 18-01-2017 20:49, Laurent Pinchart wrote:
>
> Ideally the bridge mode set operation should be extended to take format and 
> colorspace information (or another bridge operation should be created for 
> that 
> purpose, I'm still undecided). As that's quite a big change, I'm fine if you 
> start by passing a fixed format and colorspace through platform data. I would 
> however like the format to use the media bus format codes defined in 
> include/uapi/linux/media-bus-format.h.
>
> As far as I'm aware we have no colorspace definitions in DRM, so we would 
> need 
> to fix that. V4L2 handles colorspaces, and the API went through several 
> iterations before we got it working, with stupid mistakes that we don't want 
> to repeat here.
>
> Jose pointed to 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9495153_=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=BkyajeUCra1JNwll2fmexnvnkIDglOZPocC1ibkiNCQ=V21eO0BUlcWrbddiKml5I6ylkiX2ALOHPHmble7kxwI=
>   as a starting 
> point, and I would like to point out the format and colorspace are two 
> different things. A colorspace is a combination of an encoding and  
> quantization and transfer functions. Hans Verkuil has researched this topic 
> for V4L2 (see 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gstreamer.freedesktop.org_data_events_gstreamer-2Dconference_2015_Hans=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=BkyajeUCra1JNwll2fmexnvnkIDglOZPocC1ibkiNCQ=z9IMQn5gPepKFfsLUwUXiG8MA2s1SBB1jyQDE0JIKdk=
>   Verkuil - Colorspaces and HDMI.pdf and 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__linuxtv.org_downloads_v4l-2Ddvb-2Dapis_uapi_v4l_colorspaces.html=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=BkyajeUCra1JNwll2fmexnvnkIDglOZPocC1ibkiNCQ=QReIV1CxgeALvbP5QObIvfwIh7hjEL8J4fxiATaMVYc=
>  ), we 
> *really* want to involve him in this discussion.
>
> I believe colorspace information should be shared between V4L2 and DRM the 
> same way we share the media bus formats (We should have done so for 4CCs as 
> well but it's unfortunately too late for that).
>
>

Hmm, I am always confusing this :/ So, what I was refering as
"color space" is in reality the encoding (pixel encoding). In
HDMI the pixel encoding can be RGB 4:4:4, YCbCr 4:4:4, YCbCr
4:2:2 and YCbCr 4:2:0. We also have color depth which can be from
8-bit to 16-bit. Besides this there is also colorimetry.

I've used media-bus-format.h to successfully pass information
across a V4L2 driver but I've used it in BGR24 only, which is RGB
4:4:4 8 bit, which in media-bust-format.h would correspond to
MEDIA_BUS_FMT_BGR888_1X24. So, I don't know exactly what is the
support for other encodings and what if there's support for color
depth. If there is then great, but if not then support for this
should also be added.

DRM already parses successfully the supported encodings from EDID
and stores them in a structure. Note that this is the output
encoding, not the input one. We can still have RGB as input and
then output at YCbCr using CSC. The missing point is the
selection of encoding (either from userspace or from some sort of
automatic mechanism by the kernel).

Best regards,
Jose Miguel Abreu

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

Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

Hi Peter,

On Thursday 19 Jan 2017 10:25:32 Peter Senna Tschudin wrote:
> On Thu, Jan 19, 2017 at 10:17:45AM +0200, Laurent Pinchart wrote:
> > On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> >> On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> >>> On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
>  On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> >> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> >>> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
>  On 03 January, 2017 23:51 CET, Rob Herring  wrote:
> > On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin 
> > wrote:
> >> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >> display bridge.
> >> 
> >> Cc: Martyn Welch 
> >> Cc: Martin Donnelly 
> >> Cc: Javier Martinez Canillas 
> >> Cc: Enric Balletbo i Serra 
> >> Cc: Philipp Zabel 
> >> Cc: Rob Herring 
> >> Cc: Fabio Estevam 
> >> Signed-off-by: Peter Senna Tschudin 
> > ---
> >> There was an Acked-by from Rob Herring  for
> >> V6, but I changed the bindings to use i2c_new_secondary_device()
> >> so I removed it from the commit message.
> >> 
> >> [...]
> >> 
> >> .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 39 +
> > 
> > Isn't '-lvds-dp' redundant? The part# should be enough.
>  
>  b850v3 is the name of the product, this is why the proposed name.
>  What about, b850v3-dp2 dp2 indicating the second DP output?
> >>> 
> >> Humm, b850v3 is the board name? This node should be the name of
> >>> the bridge chip.
> >> 
> >> From the cover letter:
> >> 
> >> -- // --
> >> There are two physical bridges on the video signal pipeline: a
> >> STDP4028(LVDS to DP) and a STDP2690(DP to DP++).  The hardware and
> >> firmware made it complicated for this binding to comprise two
> >> device tree nodes, as the design goal is to configure both bridges
> >> based on the LVDS signal, which leave the driver powerless to control
> >> the video processing pipeline. The two bridges behaves as a single
> >> bridge, and the driver is only needed for telling the host about EDID
> >> / HPD, and for giving the host powers to ack interrupts. The video
> >> signal pipeline
> >> 
> >> is as follows:
> >>   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video
> >>   output
> >> 
> >> -- // --
> > 
> > You forgot to prefix your patch series with [HACK] ;-)
> > 
> > How about fixing the issues that make the two DT nodes solution
> > difficult ? What are they ?
>  
>  The Firmware and the hardware design. Both bridges, with stock
>  firmware, are fully capable of providig EDID information and handling
>  interrupts. But on this specific design, with this specific firmware, I
>  need to read EDID from one bridge, and handle interrupts on the other.
> >>> 
> >>> Which firmware are you talking about ? Firmware running on the
> >>> bridges, or somewhere else ?
> >> 
> >> Each bridge has it's own external flash containing a binary firmware.
> >> The goal of the firmware is to configure the output end based on the
> >> input end. This is part of what makes handling EDID and HPD challenging.
> >> 
>  Back when I was starting the development I could not come up with a
>  proper way to split EDID and interrupts between two bridges in a way
>  that would result in a fully functional connector. Did I miss
>  something?
> >>> 
> >>> You didn't, we did :-) I've been telling for quite some time now that
> >>> we must decouple bridges from connectors, and this is another example of
> >>> why we have such a need. Bridges should expose additional functions
> >>> needed to implement connector operations, and the connector should be
> >>> instantiated by the display driver with the help of bridge operations.
> >>> You could then create a connector that relies on one bridge to read the
> >>> EDID and on the other bridge to handle HPD.
> >> 
> >> Ah thanks. So for now the single DT node approach is acceptable, right?
> >> The problem is that even if the driver is getting better on each
> >> iteration, the single DT node for two chips issue comes back often and I
> >> believe is _the_ issue preventing the driver from getting upstream. V1
> >> was sent ~ 8 months ago...
> >> 
> >> Can I have some blessing on the single DT node approach for now?
> > 
> > With the "DT as an ABI" approach, I'm afraid not.

Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data

Hi Hans and Jose,

On Thursday 19 Jan 2017 16:30:57 Hans Verkuil wrote:
> On 01/19/17 16:21, Jose Abreu wrote:
> > On 18-01-2017 20:49, Laurent Pinchart wrote:
> >> Ideally the bridge mode set operation should be extended to take format
> >> and colorspace information (or another bridge operation should be created
> >> for that purpose, I'm still undecided). As that's quite a big change, I'm
> >> fine if you start by passing a fixed format and colorspace through
> >> platform data. I would however like the format to use the media bus
> >> format codes defined in include/uapi/linux/media-bus-format.h.
> >> 
> >> As far as I'm aware we have no colorspace definitions in DRM, so we would
> >> need to fix that. V4L2 handles colorspaces, and the API went through
> >> several iterations before we got it working, with stupid mistakes that
> >> we don't want to repeat here.
> >> 
> >> Jose pointed to
> >> https://patchwork.kernel.org/patch/9495153/ as a starting point, and I
> >> would like to point out the format and colorspace are two different
> >> things. A colorspace is a combination of an encoding and quantization
> >> and transfer functions. Hans Verkuil has researched this topic for V4L2
> >> (see https://gstreamer.freedesktop.org/data/events/gstreamer-> >> 
> >> conference/2015/Hans Verkuil - Colorspaces and HDMI.pdf and
> >> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/colorspaces.html), we
> >> *really* want to involve him in this discussion.
> >> 
> >> I believe colorspace information should be shared between V4L2 and DRM
> >> the same way we share the media bus formats (We should have done so for
> >> 4CCs as well but it's unfortunately too late for that).
> > 
> > Hmm, I am always confusing this :/ So, what I was refering as
> > "color space" is in reality the encoding (pixel encoding). In
> > HDMI the pixel encoding can be RGB 4:4:4, YCbCr 4:4:4, YCbCr
> > 4:2:2 and YCbCr 4:2:0. We also have color depth which can be from
> > 8-bit to 16-bit. Besides this there is also colorimetry.

There's two separate concepts here, the color encoding and the pixel format. 
The color encoding defines how non-linear R'G'B' is transformed to non-linear 
Y'CbCr (or whether to stick to R'G'B' of course). It's a mathematical formula, 
and along with the quantization defines how the numerical Y'CbCr values are 
obtained. The pixel format then defines the number of bits per sample, as well 
as the subsampling factors.

The media bus codes thus roughly correspond to pixel formats (although they 
also define whether the color encoding uses RGB or YCbCr, but don't define the 
color encoding itself or the quantization method).

> > I've used media-bus-format.h to successfully pass information
> > across a V4L2 driver but I've used it in BGR24 only, which is RGB
> > 4:4:4 8 bit, which in media-bust-format.h would correspond to
> > MEDIA_BUS_FMT_BGR888_1X24. So, I don't know exactly what is the
> > support for other encodings and what if there's support for color
> > depth. If there is then great, but if not then support for this
> > should also be added.

We have a bunch of YUV media bus formats defined in the kernel (see 
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/subdev-formats.html#v4l2-mbus-pixelcode).
 We're missing some that would be needed here (namely YUV 
4:4:4 in 12bpp and I believe the 4:2:0 formats), but it's just a matter of 
adding new definitions with the related documentation.

> > DRM already parses successfully the supported encodings from EDID
> > and stores them in a structure. Note that this is the output
> > encoding, not the input one. We can still have RGB as input and
> > then output at YCbCr using CSC. The missing point is the
> > selection of encoding (either from userspace or from some sort of
> > automatic mechanism by the kernel).

We need to select both the input and output formats and encodings, and, yes, I 
believe that at least the output format and encoding should come from 
userspace.

> The list of supported encodings for video capture depends on the HW
> capabilities. So the driver will list the supported formats (ENUMFMT)
> and userspace then selects a format (S_FMT) from that list.

Please note that this is about HDMI encoders and the DRM/KMS subsystem :-)

> Most HDMI receivers can convert the input to various RGB/YCbCr formats.
> 
> Deep color support for HDMI has not been added (surprisingly nobody needed
> it apparently), but it is pretty easy: new V4L2_PIX_FMT defines should be
> added for those.

New media bus formats in this case.

> When talking about RGB/YCbCr I prefer the term 'color encoding', since
> this has nothing to do with colorspaces (sRGB. AdobeRGB, BT.2020, etc.)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v1 3/7] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

On Mon, Jan 16, 2017 at 02:29:00PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre 
> ---
>  .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>  
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> new file mode 100644
> index 000..f59e3c4
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
> @@ -0,0 +1,7 @@
> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "ampire,am-480272h3tmqw-t01h"

No GPIOs or power supply?

> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver

On Thu, Jan 19, 2017 at 04:16:01PM +, Yannick FERTRE wrote:
> On 01/16/2017 09:30 PM, Laurent Pinchart wrote:
> > Hi Yannick,
> >
> > Thank you for the patch.
> >
> > On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
> >> Signed-off-by: Yannick Fertre 
> >> ---
> >>  .../devicetree/bindings/display/st,ltdc.txt| 57 ++
> >>  1 file changed, 57 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt
> >> b/Documentation/devicetree/bindings/display/st,ltdc.txt new file mode
> >> 100644
> >> index 000..20e89da
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> >> @@ -0,0 +1,57 @@
> >> +* STMicroelectronics STM32 lcd-tft display controller
> >> +
> >> +- st-display-subsystem: Master device for DRM sub-components
> >> +  This device must be the parent of all the sub-components and is
> >> responsible
> >> +  of bind them.
> >
> > Why do you need this ? At a quick glance the ltdc node should be enough.
> Hi Laurent,
> To prepare next device upstream of dsi, we need a master node 
> "st-display-subsystem" and a sub node "st,ltdc". It's the same kind of 
> node than st,stih4xx.

No, you don't. That's what OF graph is for. The DRM driver binds to the 
LCD controller node and walks the graph to find the DSI node and then 
the panel.

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

Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver

On Mon, Jan 16, 2017 at 02:28:58PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre 

Changelog?

> ---
>  .../devicetree/bindings/display/st,ltdc.txt| 57 
> ++
>  1 file changed, 57 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt 
> b/Documentation/devicetree/bindings/display/st,ltdc.txt
> new file mode 100644
> index 000..20e89da
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
> @@ -0,0 +1,57 @@
> +* STMicroelectronics STM32 lcd-tft display controller
> +
> +- st-display-subsystem: Master device for DRM sub-components
> +  This device must be the parent of all the sub-components and is responsible
> +  of bind them.
> +  Required properties:
> +  - compatible: "st,display-subsystem"
> +  - ranges: to allow probing of subdevices

You have a single sub device. There is no need for this node.


> +- ltdc_host: lcd-tft display controller host
> +  must be a sub-node of st-display-subsystem
> +  Required properties:
> +  - compatible: "st,ltdc"

Too generic. Needs to be SoC specific.

> +  - reg: Physical base address of the IP registers and length of memory 
> mapped region.
> +  - clocks: from common clock binding: handle hardware IP needed clocks, the
> +number of clocks may depend of the SoC type.

No. You must be explicit on how many clocks and their order.

> +See ../clocks/clock-bindings.txt for details.
> +  - clock-names: names of the clocks listed in clocks property in the same
> +order.
> +  - resets: resets to be used by the device

ditto.

> +See ../reset/reset.txt for details.
> +  - reset-names: names of the resets listed in resets property in the same
> +order.

You are missing this in the example. However, for a single entry, -names 
is pointless.

> +  Required nodes:
> +- Video port for RGB output.
> +
> +Example:
> +
> +/ {
> + ...
> + soc {
> + ...
> + st-display-subsystem {
> + compatible = "st,display-subsystem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + dma-ranges;
> +
> + ltdc_host: stm32-ltdc@40016800 {
> + compatible = "st,ltdc";
> + reg = <0x40016800 0x200>;
> + interrupts = <88>, <89>;
> + resets = < 314>;
> + clocks = < 1 8>;
> + clock-names = "clk-lcd";

The 'clk-' part is redundant.

> + status = "disabled";
> +
> + port {
> + ltdc_out_rgb: endpoint {
> + };
> + };
> + };
> + };
> + ...
> + };
> +};
> -- 
> 1.9.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] dt: add bindings for ZTE tvenc device

From: Shawn Guo 

It adds bindings doc for ZTE VOU TV Encoder device.

Signed-off-by: Shawn Guo 
---
 Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt 
b/Documentation/devicetree/bindings/display/zte,vou.txt
index 740e5bd2e4f7..9c356284232b 100644
--- a/Documentation/devicetree/bindings/display/zte,vou.txt
+++ b/Documentation/devicetree/bindings/display/zte,vou.txt
@@ -49,6 +49,15 @@ Required properties:
"osc_clk"
"xclk"
 
+* TV Encoder output device
+
+Required properties:
+ - compatible: should be "zte,zx296718-tvenc"
+ - reg: Physical base address and length of the TVENC device IO region
+ - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two
+   integer cells.  The first cell is the offset of SYSCTRL register used
+   to control TV Encoder DAC power, and the second cell is the bit mask.
+
 Example:
 
 vou: vou@144 {
@@ -81,4 +90,10 @@ vou: vou@144 {
 < HDMI_XCLK>;
clock-names = "osc_cec", "osc_clk", "xclk";
};
+
+   tvenc: tvenc@2000 {
+   compatible = "zte,zx296718-tvenc";
+   reg = <0x2000 0x1000>;
+   zte,tvenc-power-control = < 0x170 0x10>;
+   };
 };
-- 
1.9.1

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

[PATCH 5/5] drm: zte: add tvenc driver support

From: Shawn Guo 

It adds the TV Encoder driver to support video output in PAL and NTSC
format.  The driver uses syscon/regmap interface to configure register
bit sitting in SYSCTRL module for DAC power control.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/Makefile|   1 +
 drivers/gpu/drm/zte/zx_drm_drv.c|   1 +
 drivers/gpu/drm/zte/zx_drm_drv.h|   1 +
 drivers/gpu/drm/zte/zx_tvenc.c  | 416 
 drivers/gpu/drm/zte/zx_tvenc_regs.h |  31 +++
 drivers/gpu/drm/zte/zx_vou.c|   5 +
 6 files changed, 455 insertions(+)
 create mode 100644 drivers/gpu/drm/zte/zx_tvenc.c
 create mode 100644 drivers/gpu/drm/zte/zx_tvenc_regs.h

diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
index 699180bfd57c..01352b56c418 100644
--- a/drivers/gpu/drm/zte/Makefile
+++ b/drivers/gpu/drm/zte/Makefile
@@ -2,6 +2,7 @@ zxdrm-y := \
zx_drm_drv.o \
zx_hdmi.o \
zx_plane.o \
+   zx_tvenc.o \
zx_vou.o
 
 obj-$(CONFIG_DRM_ZTE) += zxdrm.o
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 3e76f72c92ff..13081fed902d 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -247,6 +247,7 @@ static int zx_drm_remove(struct platform_device *pdev)
 static struct platform_driver *drivers[] = {
_crtc_driver,
_hdmi_driver,
+   _tvenc_driver,
_drm_platform_driver,
 };
 
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.h b/drivers/gpu/drm/zte/zx_drm_drv.h
index e65cd18a6cba..5ca035b079c7 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.h
+++ b/drivers/gpu/drm/zte/zx_drm_drv.h
@@ -13,6 +13,7 @@
 
 extern struct platform_driver zx_crtc_driver;
 extern struct platform_driver zx_hdmi_driver;
+extern struct platform_driver zx_tvenc_driver;
 
 static inline u32 zx_readl(void __iomem *reg)
 {
diff --git a/drivers/gpu/drm/zte/zx_tvenc.c b/drivers/gpu/drm/zte/zx_tvenc.c
new file mode 100644
index ..5a6cff1ff8a8
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_tvenc.c
@@ -0,0 +1,416 @@
+/*
+ * Copyright 2017 Linaro Ltd.
+ * Copyright 2017 ZTE Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "zx_drm_drv.h"
+#include "zx_tvenc_regs.h"
+#include "zx_vou.h"
+
+struct zx_tvenc_pwrctrl {
+   struct regmap *regmap;
+   u32 reg;
+   u32 mask;
+};
+
+struct zx_tvenc {
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+   struct device *dev;
+   void __iomem *mmio;
+   const struct vou_inf *inf;
+   struct zx_tvenc_pwrctrl pwrctrl;
+};
+
+#define to_zx_tvenc(x) container_of(x, struct zx_tvenc, x)
+
+struct zx_tvenc_mode {
+   char *name;
+   u32 hdisplay;
+   u32 vdisplay;
+   u32 hfp;
+   u32 hbp;
+   u32 hsw;
+   u32 vfp;
+   u32 vbp;
+   u32 vsw;
+   u32 video_info;
+   u32 video_res;
+   u32 field1_param;
+   u32 field2_param;
+   u32 burst_line_odd1;
+   u32 burst_line_even1;
+   u32 burst_line_odd2;
+   u32 burst_line_even2;
+   u32 line_timing_param;
+   u32 weight_value;
+   u32 blank_black_level;
+   u32 burst_level;
+   u32 control_param;
+   u32 sub_carrier_phase1;
+   u32 phase_line_incr_cvbs;
+};
+
+static const struct zx_tvenc_mode tvenc_modes[] = {
+   {
+   .name = "PAL",
+   .hdisplay = 720,
+   .vdisplay = 576,
+   .hfp = 12,
+   .hbp = 130,
+   .hsw = 2,
+   .vfp = 2,
+   .vbp = 20,
+   .vsw = 2,
+   .video_info = 0x00040040,
+   .video_res = 0x05a9c760,
+   .field1_param = 0x0004d416,
+   .field2_param = 0x0009b94f,
+   .burst_line_odd1 = 0x0004d406,
+   .burst_line_even1 = 0x0009b53e,
+   .burst_line_odd2 = 0x0004d805,
+   .burst_line_even2 = 0x0009b93f,
+   .line_timing_param = 0x06a96fdf,
+   .weight_value = 0x00c188a0,
+   .blank_black_level = 0xfcfc,
+   .burst_level = 0x1595,
+   .control_param = 0x0001,
+   .sub_carrier_phase1 = 0x1504c566,
+   .phase_line_incr_cvbs = 0xc068db8c,
+   }, {
+   .name = "NTSC",
+   .hdisplay = 720,
+   .vdisplay = 480,
+   .hfp = 16,
+   .hbp = 120,
+   .hsw = 2,
+   .vfp = 3,
+   .vbp = 17,
+   .vsw = 2,
+   .video_info = 0x00040080,
+   .video_res = 0x05a8375a,
+   .field1_param = 0x00041817,
+

[PATCH 2/5] drm: zte: move struct vou_inf into zx_vou driver

From: Shawn Guo 

Although data in struct vou_inf is defined per output device, it doesn't
belong to the device itself but VOU control module.  All these data can
just be defined in VOU driver, and output device driver only needs to
invoke VOU driver function with device ID to enable/disable specific
output device.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_hdmi.c | 12 ++--
 drivers/gpu/drm/zte/zx_vou.c  | 31 ---
 drivers/gpu/drm/zte/zx_vou.h  | 11 ++-
 3 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index 6bf6c364811e..2f1e278ab50e 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -53,13 +53,6 @@ struct zx_hdmi {
 
 #define to_zx_hdmi(x) container_of(x, struct zx_hdmi, x)
 
-static const struct vou_inf vou_inf_hdmi = {
-   .id = VOU_HDMI,
-   .data_sel = VOU_YUV444,
-   .clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
-   .clocks_sel_bits = BIT(13) | BIT(2),
-};
-
 static inline u8 hdmi_readb(struct zx_hdmi *hdmi, u16 offset)
 {
return readl_relaxed(hdmi->mmio + offset * 4);
@@ -238,14 +231,14 @@ static void zx_hdmi_encoder_enable(struct drm_encoder 
*encoder)
 
zx_hdmi_hw_enable(hdmi);
 
-   vou_inf_enable(hdmi->inf, encoder->crtc);
+   vou_inf_enable(VOU_HDMI, encoder->crtc);
 }
 
 static void zx_hdmi_encoder_disable(struct drm_encoder *encoder)
 {
struct zx_hdmi *hdmi = to_zx_hdmi(encoder);
 
-   vou_inf_disable(hdmi->inf, encoder->crtc);
+   vou_inf_disable(VOU_HDMI, encoder->crtc);
 
zx_hdmi_hw_disable(hdmi);
 
@@ -523,7 +516,6 @@ static int zx_hdmi_bind(struct device *dev, struct device 
*master, void *data)
 
hdmi->dev = dev;
hdmi->drm = drm;
-   hdmi->inf = _inf_hdmi;
 
dev_set_drvdata(dev, hdmi);
 
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 8c4f0e2885f3..c48704b4425a 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -158,6 +158,21 @@ struct zx_vou_hw {
struct zx_crtc *aux_crtc;
 };
 
+struct vou_inf {
+   enum vou_inf_id id;
+   enum vou_inf_data_sel data_sel;
+   u32 clocks_en_bits;
+   u32 clocks_sel_bits;
+};
+
+static struct vou_inf vou_infs[] = {
+   [VOU_HDMI] = {
+   .data_sel = VOU_YUV444,
+   .clocks_en_bits = BIT(24) | BIT(18) | BIT(6),
+   .clocks_sel_bits = BIT(13) | BIT(2),
+   },
+};
+
 static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
 {
struct zx_crtc *zcrtc = to_zx_crtc(crtc);
@@ -165,20 +180,21 @@ static inline struct zx_vou_hw *crtc_to_vou(struct 
drm_crtc *crtc)
return zcrtc->vou;
 }
 
-void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc)
+void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc)
 {
struct zx_crtc *zcrtc = to_zx_crtc(crtc);
struct zx_vou_hw *vou = zcrtc->vou;
+   struct vou_inf *inf = _infs[id];
bool is_main = zcrtc->chn_type == VOU_CHN_MAIN;
-   u32 data_sel_shift = inf->id << 1;
+   u32 data_sel_shift = id << 1;
 
/* Select data format */
zx_writel_mask(vou->vouctl + VOU_INF_DATA_SEL, 0x3 << data_sel_shift,
   inf->data_sel << data_sel_shift);
 
/* Select channel */
-   zx_writel_mask(vou->vouctl + VOU_INF_CH_SEL, 0x1 << inf->id,
-  zcrtc->chn_type << inf->id);
+   zx_writel_mask(vou->vouctl + VOU_INF_CH_SEL, 0x1 << id,
+  zcrtc->chn_type << id);
 
/* Select interface clocks */
zx_writel_mask(vou->vouctl + VOU_CLK_SEL, inf->clocks_sel_bits,
@@ -189,15 +205,16 @@ void vou_inf_enable(const struct vou_inf *inf, struct 
drm_crtc *crtc)
   inf->clocks_en_bits);
 
/* Enable the device */
-   zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << inf->id, 1 << inf->id);
+   zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << id, 1 << id);
 }
 
-void vou_inf_disable(const struct vou_inf *inf, struct drm_crtc *crtc)
+void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc)
 {
struct zx_vou_hw *vou = crtc_to_vou(crtc);
+   struct vou_inf *inf = _infs[id];
 
/* Disable the device */
-   zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << inf->id, 0);
+   zx_writel_mask(vou->vouctl + VOU_INF_EN, 1 << id, 0);
 
/* Disable interface clocks */
zx_writel_mask(vou->vouctl + VOU_CLK_EN, inf->clocks_en_bits, 0);
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index 4b4339be641b..a41a0ad49857 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -30,15 +30,8 @@ enum vou_inf_data_sel {
VOU_RGB_666 = 3,
 };
 
-struct vou_inf {
-   enum vou_inf_id id;
-   enum vou_inf_data_sel data_sel;
-   u32 clocks_en_bits;
-

[PATCH 1/5] drm: zte: add interlace mode support

From: Shawn Guo 

It adds interlace mode support in VOU TIMING_CTRL and channel control
block, so that VOU driver gets ready to support output device in
interlace mode like TV Encoder.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_vou.c  | 53 +--
 drivers/gpu/drm/zte/zx_vou_regs.h | 15 +++
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 3056b41df518..8c4f0e2885f3 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -40,6 +40,7 @@ struct zx_crtc_regs {
u32 fir_active;
u32 fir_htiming;
u32 fir_vtiming;
+   u32 sec_vtiming;
u32 timing_shift;
u32 timing_pi_shift;
 };
@@ -48,6 +49,7 @@ struct zx_crtc_regs {
.fir_active = FIR_MAIN_ACTIVE,
.fir_htiming = FIR_MAIN_H_TIMING,
.fir_vtiming = FIR_MAIN_V_TIMING,
+   .sec_vtiming = SEC_MAIN_V_TIMING,
.timing_shift = TIMING_MAIN_SHIFT,
.timing_pi_shift = TIMING_MAIN_PI_SHIFT,
 };
@@ -56,6 +58,7 @@ struct zx_crtc_regs {
.fir_active = FIR_AUX_ACTIVE,
.fir_htiming = FIR_AUX_H_TIMING,
.fir_vtiming = FIR_AUX_V_TIMING,
+   .sec_vtiming = SEC_AUX_V_TIMING,
.timing_shift = TIMING_AUX_SHIFT,
.timing_pi_shift = TIMING_AUX_PI_SHIFT,
 };
@@ -65,6 +68,10 @@ struct zx_crtc_bits {
u32 polarity_shift;
u32 int_frame_mask;
u32 tc_enable;
+   u32 sec_vactive_shift;
+   u32 sec_vactive_mask;
+   u32 interlace_select;
+   u32 pi_enable;
 };
 
 static const struct zx_crtc_bits main_crtc_bits = {
@@ -72,6 +79,10 @@ struct zx_crtc_bits {
.polarity_shift = MAIN_POL_SHIFT,
.int_frame_mask = TIMING_INT_MAIN_FRAME,
.tc_enable = MAIN_TC_EN,
+   .sec_vactive_shift = SEC_VACT_MAIN_SHIFT,
+   .sec_vactive_mask = SEC_VACT_MAIN_MASK,
+   .interlace_select = MAIN_INTERLACE_SEL,
+   .pi_enable = MAIN_PI_EN,
 };
 
 static const struct zx_crtc_bits aux_crtc_bits = {
@@ -79,6 +90,10 @@ struct zx_crtc_bits {
.polarity_shift = AUX_POL_SHIFT,
.int_frame_mask = TIMING_INT_AUX_FRAME,
.tc_enable = AUX_TC_EN,
+   .sec_vactive_shift = SEC_VACT_AUX_SHIFT,
+   .sec_vactive_mask = SEC_VACT_AUX_MASK,
+   .interlace_select = AUX_INTERLACE_SEL,
+   .pi_enable = AUX_PI_EN,
 };
 
 struct zx_crtc {
@@ -196,19 +211,26 @@ static inline void vou_chn_set_update(struct zx_crtc 
*zcrtc)
 static void zx_crtc_enable(struct drm_crtc *crtc)
 {
struct drm_display_mode *mode = >state->adjusted_mode;
+   bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
struct zx_crtc *zcrtc = to_zx_crtc(crtc);
struct zx_vou_hw *vou = zcrtc->vou;
const struct zx_crtc_regs *regs = zcrtc->regs;
const struct zx_crtc_bits *bits = zcrtc->bits;
struct videomode vm;
+   u32 vactive;
u32 pol = 0;
u32 val;
+   u32 mask;
int ret;
 
drm_display_mode_to_videomode(mode, );
 
/* Set up timing parameters */
-   val = V_ACTIVE(vm.vactive - 1);
+   vactive = vm.vactive;
+   if (interlaced)
+   vactive /= 2;
+
+   val = V_ACTIVE(vactive - 1);
val |= H_ACTIVE(vm.hactive - 1);
zx_writel(vou->timing + regs->fir_active, val);
 
@@ -222,6 +244,22 @@ static void zx_crtc_enable(struct drm_crtc *crtc)
val |= FRONT_PORCH(vm.vfront_porch - 1);
zx_writel(vou->timing + regs->fir_vtiming, val);
 
+   if (interlaced) {
+   u32 shift = bits->sec_vactive_shift;
+   u32 mask = bits->sec_vactive_mask;
+
+   val = zx_readl(vou->timing + SEC_V_ACTIVE);
+   val &= ~mask;
+   val |= ((vactive - 1) << shift) & mask;
+   zx_writel(vou->timing + SEC_V_ACTIVE, val);
+
+   val = SYNC_WIDE(vm.vsync_len - 1);
+   /* sec_vbp = fir_vbp + 1 */
+   val |= BACK_PORCH(vm.vback_porch);
+   val |= FRONT_PORCH(vm.vfront_porch - 1);
+   zx_writel(vou->timing + regs->sec_vtiming, val);
+   }
+
/* Set up polarities */
if (vm.flags & DISPLAY_FLAGS_VSYNC_LOW)
pol |= 1 << POL_VSYNC_SHIFT;
@@ -232,9 +270,16 @@ static void zx_crtc_enable(struct drm_crtc *crtc)
   pol << bits->polarity_shift);
 
/* Setup SHIFT register by following what ZTE BSP does */
-   zx_writel(vou->timing + regs->timing_shift, H_SHIFT_VAL);
+   val = H_SHIFT_VAL;
+   if (interlaced)
+   val |= V_SHIFT_VAL << 16;
+   zx_writel(vou->timing + regs->timing_shift, val);
zx_writel(vou->timing + regs->timing_pi_shift, H_PI_SHIFT_VAL);
 
+   /* Progressive or interlace scan select */
+   mask = bits->interlace_select | bits->pi_enable;
+   zx_writel_mask(vou->timing + SCAN_CTRL, mask,

[PATCH 0/5] Add TV Encoder support for ZTE DRM driver

From: Shawn Guo 

The series updates zx_vou driver a bit as the preparation of adding
TVENC output device, and then adds the device driver.

Shawn Guo (5):
  drm: zte: add interlace mode support
  drm: zte: move struct vou_inf into zx_vou driver
  drm: zte: add function to configure vou_ctrl dividers
  dt: add bindings for ZTE tvenc device
  drm: zte: add tvenc driver support

 .../devicetree/bindings/display/zte,vou.txt|  15 +
 drivers/gpu/drm/zte/Makefile   |   1 +
 drivers/gpu/drm/zte/zx_drm_drv.c   |   1 +
 drivers/gpu/drm/zte/zx_drm_drv.h   |   1 +
 drivers/gpu/drm/zte/zx_hdmi.c  |  12 +-
 drivers/gpu/drm/zte/zx_tvenc.c | 416 +
 drivers/gpu/drm/zte/zx_tvenc_regs.h|  31 ++
 drivers/gpu/drm/zte/zx_vou.c   | 168 -
 drivers/gpu/drm/zte/zx_vou.h   |  32 +-
 drivers/gpu/drm/zte/zx_vou_regs.h  |  31 ++
 10 files changed, 682 insertions(+), 26 deletions(-)
 create mode 100644 drivers/gpu/drm/zte/zx_tvenc.c
 create mode 100644 drivers/gpu/drm/zte/zx_tvenc_regs.h

-- 
1.9.1

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

[PATCH 3/5] drm: zte: add function to configure vou_ctrl dividers

From: Shawn Guo 

The clock control module (CRM) cannot always provide desired frequency
for all VOU output devices.  That's why VOU integrates a few dividers
to further divide the clocks from CRM.  Let's add an interface for
configuring these dividers.

Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/zte/zx_vou.c  | 79 +++
 drivers/gpu/drm/zte/zx_vou.h  | 25 +
 drivers/gpu/drm/zte/zx_vou_regs.h | 16 
 3 files changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index c48704b4425a..98f0f51f9748 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -72,6 +72,13 @@ struct zx_crtc_bits {
u32 sec_vactive_mask;
u32 interlace_select;
u32 pi_enable;
+   u32 div_vga_shift;
+   u32 div_pic_shift;
+   u32 div_tvenc_shift;
+   u32 div_hdmi_pnx_shift;
+   u32 div_hdmi_shift;
+   u32 div_inf_shift;
+   u32 div_layer_shift;
 };
 
 static const struct zx_crtc_bits main_crtc_bits = {
@@ -83,6 +90,13 @@ struct zx_crtc_bits {
.sec_vactive_mask = SEC_VACT_MAIN_MASK,
.interlace_select = MAIN_INTERLACE_SEL,
.pi_enable = MAIN_PI_EN,
+   .div_vga_shift = VGA_MAIN_DIV_SHIFT,
+   .div_pic_shift = PIC_MAIN_DIV_SHIFT,
+   .div_tvenc_shift = TVENC_MAIN_DIV_SHIFT,
+   .div_hdmi_pnx_shift = HDMI_MAIN_PNX_DIV_SHIFT,
+   .div_hdmi_shift = HDMI_MAIN_DIV_SHIFT,
+   .div_inf_shift = INF_MAIN_DIV_SHIFT,
+   .div_layer_shift = LAYER_MAIN_DIV_SHIFT,
 };
 
 static const struct zx_crtc_bits aux_crtc_bits = {
@@ -94,6 +108,13 @@ struct zx_crtc_bits {
.sec_vactive_mask = SEC_VACT_AUX_MASK,
.interlace_select = AUX_INTERLACE_SEL,
.pi_enable = AUX_PI_EN,
+   .div_vga_shift = VGA_AUX_DIV_SHIFT,
+   .div_pic_shift = PIC_AUX_DIV_SHIFT,
+   .div_tvenc_shift = TVENC_AUX_DIV_SHIFT,
+   .div_hdmi_pnx_shift = HDMI_AUX_PNX_DIV_SHIFT,
+   .div_hdmi_shift = HDMI_AUX_DIV_SHIFT,
+   .div_inf_shift = INF_AUX_DIV_SHIFT,
+   .div_layer_shift = LAYER_AUX_DIV_SHIFT,
 };
 
 struct zx_crtc {
@@ -220,6 +241,64 @@ void vou_inf_disable(enum vou_inf_id id, struct drm_crtc 
*crtc)
zx_writel_mask(vou->vouctl + VOU_CLK_EN, inf->clocks_en_bits, 0);
 }
 
+void zx_vou_config_dividers(struct drm_crtc *crtc,
+   struct vou_div_config *configs, int num)
+{
+   struct zx_crtc *zcrtc = to_zx_crtc(crtc);
+   struct zx_vou_hw *vou = zcrtc->vou;
+   const struct zx_crtc_bits *bits = zcrtc->bits;
+   int i;
+
+   /* Clear update flag bit */
+   zx_writel_mask(vou->vouctl + VOU_DIV_PARA, DIV_PARA_UPDATE, 0);
+
+   for (i = 0; i < num; i++) {
+   struct vou_div_config *cfg = configs + i;
+   u32 reg, shift;
+
+   switch (cfg->id) {
+   case VOU_DIV_VGA:
+   reg = VOU_CLK_SEL;
+   shift = bits->div_vga_shift;
+   break;
+   case VOU_DIV_PIC:
+   reg = VOU_CLK_SEL;
+   shift = bits->div_pic_shift;
+   break;
+   case VOU_DIV_TVENC:
+   reg = VOU_DIV_PARA;
+   shift = bits->div_tvenc_shift;
+   break;
+   case VOU_DIV_HDMI_PNX:
+   reg = VOU_DIV_PARA;
+   shift = bits->div_hdmi_pnx_shift;
+   break;
+   case VOU_DIV_HDMI:
+   reg = VOU_DIV_PARA;
+   shift = bits->div_hdmi_shift;
+   break;
+   case VOU_DIV_INF:
+   reg = VOU_DIV_PARA;
+   shift = bits->div_inf_shift;
+   break;
+   case VOU_DIV_LAYER:
+   reg = VOU_DIV_PARA;
+   shift = bits->div_layer_shift;
+   break;
+   default:
+   continue;
+   }
+
+   /* Each divider occupies 3 bits */
+   zx_writel_mask(vou->vouctl + reg, 0x7 << shift,
+  cfg->val << shift);
+   }
+
+   /* Set update flag bit to get dividers effected */
+   zx_writel_mask(vou->vouctl + VOU_DIV_PARA, DIV_PARA_UPDATE,
+  DIV_PARA_UPDATE);
+}
+
 static inline void vou_chn_set_update(struct zx_crtc *zcrtc)
 {
zx_writel(zcrtc->chnreg + CHN_UPDATE, 1);
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index a41a0ad49857..0dae4faefac4 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -33,6 +33,31 @@ enum vou_inf_data_sel {
 void vou_inf_enable(enum vou_inf_id id, struct drm_crtc *crtc);
 void vou_inf_disable(enum vou_inf_id id, struct drm_crtc *crtc);
 
+enum vou_div_id

Re: [PATCH v1 1/7] dt-bindings: display: add STM32 LTDC driver

2017-01-19 Thread Yannick FERTRE

On 01/16/2017 09:30 PM, Laurent Pinchart wrote:
> Hi Yannick,
>
> Thank you for the patch.
>
> On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
>> Signed-off-by: Yannick Fertre 
>> ---
>>  .../devicetree/bindings/display/st,ltdc.txt| 57 ++
>>  1 file changed, 57 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/st,ltdc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/st,ltdc.txt
>> b/Documentation/devicetree/bindings/display/st,ltdc.txt new file mode
>> 100644
>> index 000..20e89da
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/st,ltdc.txt
>> @@ -0,0 +1,57 @@
>> +* STMicroelectronics STM32 lcd-tft display controller
>> +
>> +- st-display-subsystem: Master device for DRM sub-components
>> +  This device must be the parent of all the sub-components and is
>> responsible
>> +  of bind them.
>
> Why do you need this ? At a quick glance the ltdc node should be enough.
Hi Laurent,
To prepare next device upstream of dsi, we need a master node 
"st-display-subsystem" and a sub node "st,ltdc". It's the same kind of 
node than st,stih4xx.
>
>> +  Required properties:
>> +  - compatible: "st,display-subsystem"
>> +  - ranges: to allow probing of subdevices
>> +
>> +- ltdc_host: lcd-tft display controller host
>> +  must be a sub-node of st-display-subsystem
>> +  Required properties:
>> +  - compatible: "st,ltdc"
>> +  - reg: Physical base address of the IP registers and length of memory
>> mapped region.
>> +  - clocks: from common clock binding: handle hardware IP needed clocks,
>> the
>> +number of clocks may depend of the SoC type.
>> +See ../clocks/clock-bindings.txt for details.
>> +  - clock-names: names of the clocks listed in clocks property in the same
>> +order.
>
> You need to define the required/optional clocks with their names here. If they
> vary depending on the SoC, the DT bindings document need to list them for each
> SoC.
>
Ok, I'll push news bindings with pack V2.
>> +  - resets: resets to be used by the device
>> +See ../reset/reset.txt for details.
>> +  - reset-names: names of the resets listed in resets property in the same
>> +order.
>> +  Required nodes:
>> +- Video port for RGB output.
>> +
>> +Example:
>> +
>> +/ {
>> +...
>> +soc {
>> +...
>> +st-display-subsystem {
>> +compatible = "st,display-subsystem";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +dma-ranges;
>> +
>> +ltdc_host: stm32-ltdc@40016800 {
>> +compatible = "st,ltdc";
>> +reg = <0x40016800 0x200>;
>> +interrupts = <88>, <89>;
>> +resets = < 314>;
>> +clocks = < 1 8>;
>> +clock-names = "clk-lcd";
>> +status = "disabled";
>> +
>> +port {
>> +ltdc_out_rgb: endpoint {
>> +};
>> +};
>> +};
>> +};
>> +...
>> +};
>> +};
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon and amdgpu drm-fixes-4.10

2017-01-19 Thread Alex Deucher

Hi Dave,

A little bigger than usual since it's two weeks worth.  Highlights:
- Add support for new smc firmware on some new hainan variants
- add support for SI chips that require special mc firmware
- remove workarounds for issues fixed by new mc firmware
- fix a regression in cursor handling
- various VCE fixes
- fix for UVD clockgating

The following changes since commit 9afe69d5a9495f8b023017e4c328fa717e00f092:

  Merge tag 'drm-misc-fixes-2017-01-09' of 
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-01-10 08:18:53 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.10

for you to fetch changes up to 17324b6add82d6c0bf119f1d1944baef392a4e39:

  drm/amdgpu: add support for new hainan variants (2017-01-17 15:25:41 -0500)


Alex Deucher (8):
  drm/radeon/si: load special ucode for certain MC configs
  drm/amdgpu/si: load special ucode for certain MC configs
  drm/amdgpu: drop oland quirks
  drm/amdgpu: drop the mclk quirk for hainan
  drm/radeon: drop oland quirks
  drm/radeon: drop the mclk quirk for hainan
  drm/radeon: add support for new hainan variants
  drm/amdgpu: add support for new hainan variants

Flora Cui (1):
  drm/amdgpu: fix vm_fault_stop on gfx6

Michel Dänzer (1):
  Revert "drm/amdgpu: Only update the CUR_SIZE register when necessary"

Rex Zhu (5):
  drm/amd/powerplay: fix vce cg logic error on CZ/St.
  drm/amd/powerplay: refine vce dpm update code on Cz.
  drm/amdgpu: fix bug set incorrect value to vce register
  drm/amdgpu: fix program vce instance logic error.
  drm/amdgpu: change clock gating mode for uvd_v4.

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 22 
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 22 
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 24 +
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 22 
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 34 ++
 drivers/gpu/drm/amd/amdgpu/si_dpm.c| 20 +++
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  | 42 ++
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  | 27 --
 .../drm/amd/powerplay/hwmgr/cz_clockpowergating.c  |  4 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 24 -
 drivers/gpu/drm/radeon/si.c| 25 ++---
 drivers/gpu/drm/radeon/si_dpm.c| 12 ---
 12 files changed, 119 insertions(+), 159 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/i915: Add support for DP link training compliance

2017-01-19 Thread Jani Nikula

On Wed, 18 Jan 2017, Manasi Navare  wrote:
> This patch adds support to handle automated DP compliance
> link training test requests. This patch has been tested with
> Unigraf DPR-120 DP Compliance device for testing Link
> Training Compliance.
> After we get a short pulse Compliance test request, test
> request values are read and hotplug uevent is sent in order
> to trigger another modeset during which the pipe is configured
> and link is retrained and enabled for link parameters requested
> by the test.
>
> v2:
> * Validate the test lane count before using it in
> intel_dp_compute_config (Jani Nikula)
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 46 
> 
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  2 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e80d620..7a1d3c4 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1613,6 +1613,7 @@ static int intel_dp_compute_bpp(struct intel_dp 
> *intel_dp,
>   /* Conveniently, the link BW constants become indices with a shift...*/
>   int min_clock = 0;
>   int max_clock;
> + int link_rate_index;
>   int bpp, mode_rate;
>   int link_avail, link_clock;
>   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> @@ -1654,6 +1655,17 @@ static int intel_dp_compute_bpp(struct intel_dp 
> *intel_dp,
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return false;
>  
> + /* Use values requested by Compliance Test Request */
> + if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
> + link_rate_index = intel_dp_link_rate_index(intel_dp,
> +common_rates,
> +
> drm_dp_bw_code_to_link_rate(intel_dp->compliance.test_link_rate));
> + if (link_rate_index >= 0)
> + min_clock = max_clock = link_rate_index;
> + if (min_lane_count <= intel_dp->compliance.test_lane_count
> + && intel_dp->compliance.test_lane_count >= max_lane_count)
> + min_lane_count = max_lane_count = 
> intel_dp->compliance.test_lane_count;
> + }

Why don't we do these checks and conversions when we get the test
request, so we can NAK the request on errors?

>   DRM_DEBUG_KMS("DP link computation with max lane count %i "
> "max bw %d pixel clock %iKHz\n",
> max_lane_count, common_rates[max_clock],
> @@ -3921,6 +3933,27 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
> *crc)
>  static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
>  {
>   uint8_t test_result = DP_TEST_ACK;
> + int status = 0;
> + /* (DP CTS 1.2)
> +  * 4.3.1.11
> +  */
> + /* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
> + status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LANE_COUNT,
> +   _dp->compliance.test_lane_count);
> +
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Lane count read failed\n");
> + return 0;

return DP_TEST_NAK;

> + }
> + intel_dp->compliance.test_lane_count &= DP_MAX_LANE_COUNT_MASK;
> +
> + status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LINK_RATE,
> +_dp->compliance.test_link_rate);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Link Rate read failed\n");
> + return 0;

return DP_TEST_NAK;

> + }
> +
>   return test_result;

Could replace this with a direct return DP_TEST_ACK without the temp
variable.

>  }
>  
> @@ -4135,9 +4168,8 @@ static void intel_dp_handle_test_request(struct 
> intel_dp *intel_dp)
>   if (!intel_dp->lane_count)
>   return;
>  
> - /* if link training is requested we should perform it always */
> - if ((intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) ||
> - (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> + /* Retrain if Channel EQ or CR not ok */
> + if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
>   DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> intel_encoder->base.name);
>  
> @@ -4162,6 +4194,7 @@ static void intel_dp_handle_test_request(struct 
> intel_dp *intel_dp)
>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> + struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
>   u8 sink_irq_vector = 0;
>   u8 old_sink_count = intel_dp->sink_count;
>   bool ret;
> @@ -4195,7

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

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

--- Comment #16 from lei.p...@gmail.com ---
Created attachment 129049
  --> https://bugs.freedesktop.org/attachment.cgi?id=129049=edit
DRI3_EV1

DRI3 Chromium with EV

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

Re: [PATCH v2 01/11] dt-bindings: add rk3399 support for dw-mipi-rockchip

On Mon, Jan 16, 2017 at 06:08:21PM +0800, Chris Zhong wrote:
> The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has
> additional phy config clock.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
>  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 
> +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

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

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

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

--- Comment #15 from lei.p...@gmail.com ---
Created attachment 129048
  --> https://bugs.freedesktop.org/attachment.cgi?id=129048=edit
DRI2_EV1

DRI2 Chromium with EV

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

Re: [RFC/RFT PATCH 4/4] drm/bridge: dw-hdmi: Take input format from plat_data

2017-01-19 Thread Hans Verkuil

On 01/19/17 16:21, Jose Abreu wrote:

Hi Laurent,

On 18-01-2017 20:49, Laurent Pinchart wrote:

Ideally the bridge mode set operation should be extended to take format and
colorspace information (or another bridge operation should be created for that
purpose, I'm still undecided). As that's quite a big change, I'm fine if you
start by passing a fixed format and colorspace through platform data. I would
however like the format to use the media bus format codes defined in
include/uapi/linux/media-bus-format.h.

As far as I'm aware we have no colorspace definitions in DRM, so we would need
to fix that. V4L2 handles colorspaces, and the API went through several
iterations before we got it working, with stupid mistakes that we don't want
to repeat here.

Jose pointed to
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9495153_=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=BkyajeUCra1JNwll2fmexnvnkIDglOZPocC1ibkiNCQ=V21eO0BUlcWrbddiKml5I6ylkiX2ALOHPHmble7kxwI=
as a starting
point, and I would like to point out the format and colorspace are two
different things. A colorspace is a combination of an encoding and
quantization and transfer functions. Hans Verkuil has researched this topic
for V4L2 (see
https://urldefense.proofpoint.com/v2/url?u=https-3A__gstreamer.freedesktop.org_data_events_gstreamer-2Dconference_2015_Hans=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=BkyajeUCra1JNwll2fmexnvnkIDglOZPocC1ibkiNCQ=z9IMQn5gPepKFfsLUwUXiG8MA2s1SBB1jyQDE0JIKdk=
Verkuil - Colorspaces and HDMI.pdf and
https://urldefense.proofpoint.com/v2/url?u=https-3A__linuxtv.org_downloads_v4l-2Ddvb-2Dapis_uapi_v4l_colorspaces.html=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=BkyajeUCra1JNwll2fmexnvnkIDglOZPocC1ibkiNCQ=QReIV1CxgeALvbP5QObIvfwIh7hjEL8J4fxiATaMVYc=
), we
*really* want to involve him in this discussion.

I believe colorspace information should be shared between V4L2 and DRM the
same way we share the media bus formats (We should have done so for 4CCs as
well but it's unfortunately too late for that).

Hmm, I am always confusing this :/ So, what I was refering as
"color space" is in reality the encoding (pixel encoding). In
HDMI the pixel encoding can be RGB 4:4:4, YCbCr 4:4:4, YCbCr
4:2:2 and YCbCr 4:2:0. We also have color depth which can be from
8-bit to 16-bit. Besides this there is also colorimetry.

I've used media-bus-format.h to successfully pass information
across a V4L2 driver but I've used it in BGR24 only, which is RGB
4:4:4 8 bit, which in media-bust-format.h would correspond to
MEDIA_BUS_FMT_BGR888_1X24. So, I don't know exactly what is the
support for other encodings and what if there's support for color
depth. If there is then great, but if not then support for this
should also be added.

DRM already parses successfully the supported encodings from EDID
and stores them in a structure. Note that this is the output
encoding, not the input one. We can still have RGB as input and
then output at YCbCr using CSC. The missing point is the
selection of encoding (either from userspace or from some sort of
automatic mechanism by the kernel).

The list of supported encodings for video capture depends on the HW
capabilities. So the driver will list the supported formats (ENUMFMT)
and userspace then selects a format (S_FMT) from that list.

Most HDMI receivers can convert the input to various RGB/YCbCr formats.

Deep color support for HDMI has not been added (surprisingly nobody needed
it apparently), but it is pretty easy: new V4L2_PIX_FMT defines should be
added for those.

When talking about RGB/YCbCr I prefer the term 'color encoding', since
this has nothing to do with colorspaces (sRGB. AdobeRGB, BT.2020, etc.)

Regards,

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

[Bug 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

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

--- Comment #14 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #13)
> (In reply to lei.pero from comment #7)
> > Sure, i will, it's like performace loss, I'm not sure if video would do the
> > justice,
> 
> Indeed, I'm afraid I can't see much difference, though the DRI2 videos do
> seem slightly smoother.
> 
> Can you create another comparison video with the environment variable
> GALLIUM_HUD=.dfps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,
> cpu+temperature+GPU-load,.dnum-bytes-moved,.dbuffer-wait-time,.dnum-
> compilations+num-shaders-created set when starting chromium? It should
> overlay some graphs showing the framerate and other performance related
> values.
> 
> 
> > I think this is hardware specific onr adeon driver (only?).
> 
> Does it not happen using the modesetting driver instead of radeon?

Sure, I did it, will upload now. It does happen on modesetting driver
regardless of DRI version, strange. It's most visible on Chrome/ium scrolling,
but I can also notice it in standard GNOME-shell animations (for example, after
logging in startup animation is not smooth as it should be/as it is on radeon
DRI2), hope this information helps a bit. I'm very positive i can notice same
behaviour in games also (I'm not a gamer, so just a few I play).

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

[PULL] drm-intel-fixes

2017-01-19 Thread Jani Nikula


Hi Dave -

Apparently you haven't pulled my fixes from last week [1], so this one
supersedes and includes that one.

More GVT-g stuff than I'd like at this stage, but then again that's
pretty new and isolated so I'm not too worried.

BR,
Jani.

[1] 877f605pim.fsf@intel.com">http://mid.mail-archive.com/877f605pim.fsf@intel.com


The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-01-19

for you to fetch changes up to 3bfdfdcbce2796ce75bf2d85fd8471858d702e5d:

  drm/i915: Ignore bogus plane coordinates on SKL when the plane is not visible 
(2017-01-18 16:31:25 +0200)


Changbin Du (13):
  drm/i915/gvt: fix error handing of tlb_control emulation
  drm/i915/gvt: fix return value in mul_force_wake_write
  drm/i915/gvt: always use readq and writeq
  drm/i915/gvt: fix use after free for workload
  drm/i915/gvt: dec vgpu->running_workload_num after the workload is really 
done
  drm/i915/gvt: introudce intel_vgpu_reset_resource() to reset vgpu 
resource state
  drm/i915/gvt: introuduce intel_vgpu_reset_gtt() to reset gtt
  drm/i915/gvt: move cfg space inititation function to cfg_space.c
  drm/i915/gvt: introduce intel_vgpu_reset_cfg_space to reset configuration 
space
  drm/i915/gvt: move mmio init/clean function to mmio.c
  drm/i915/gvt: introduce intel_vgpu_reset_mmio() to reset mmio space
  drm/i915/gvt: fix vGPU instance reuse issues by vGPU reset function
  drm/i915/gvt: rewrite gt reset handler using new function 
intel_gvt_reset_vgpu_locked

Chris Wilson (2):
  drm/i915: Clear ret before unbinding in i915_gem_evict_something()
  drm/i915: Fix phys pwrite for struct_mutex-less operation

Francisco Jerez (1):
  drm/i915: Remove WaDisableLSQCROPERFforOCL KBL workaround.

Jani Nikula (2):
  Merge tag 'gvt-fixes-2017-01-10' of https://github.com/01org/gvt-linux 
into drm-intel-fixes
  Merge tag 'gvt-fixes-2017-01-16' of https://github.com/01org/gvt-linux 
into drm-intel-fixes

Jike Song (5):
  drm/i915/gvt: init/destroy vgpu_idr properly
  drm/i915/gvt: destroy the allocated idr on vgpu creating failures
  drm/i915/gvt: cleanup opregion memory allocation code
  drm/i915/gvt/kvmgt: return meaningful error for vgpu creating failure
  drm/i915/gvt: cleanup GFP flags

Nicolas Iooss (1):
  drm/i915/gvt: verify functions types in new_mmio_info()

Pei Zhang (1):
  drm/i915/gvt: print correct value for untracked mmio

Ville Syrjälä (1):
  drm/i915: Ignore bogus plane coordinates on SKL when the plane is not 
visible

Zhenyu Wang (2):
  drm/i915/gvt: adjust high memory size for default vGPU type
  drm/i915/gvt: remove duplicated definition

 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  36 +--
 drivers/gpu/drm/i915/gvt/cfg_space.c|  74 +++
 drivers/gpu/drm/i915/gvt/gtt.c  |  81 
 drivers/gpu/drm/i915/gvt/gtt.h  |   1 +
 drivers/gpu/drm/i915/gvt/gvt.c  |   8 +-
 drivers/gpu/drm/i915/gvt/gvt.h  |   8 +-
 drivers/gpu/drm/i915/gvt/handlers.c | 103 +++-
 drivers/gpu/drm/i915/gvt/kvmgt.c|  14 ++-
 drivers/gpu/drm/i915/gvt/mmio.c |  84 ++---
 drivers/gpu/drm/i915/gvt/mmio.h |   4 +
 drivers/gpu/drm/i915/gvt/opregion.c |   8 +-
 drivers/gpu/drm/i915/gvt/reg.h  |   3 +-
 drivers/gpu/drm/i915/gvt/scheduler.c|  14 +--
 drivers/gpu/drm/i915/gvt/vgpu.c | 162 
 drivers/gpu/drm/i915/i915_gem.c |  34 +--
 drivers/gpu/drm/i915/i915_gem_evict.c   |   1 +
 drivers/gpu/drm/i915/intel_display.c|   3 +
 drivers/gpu/drm/i915/intel_lrc.c|  10 --
 drivers/gpu/drm/i915/intel_ringbuffer.c |   8 --
 19 files changed, 379 insertions(+), 277 deletions(-)

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

Re: [PATCH 0/2] amdgpu: HDMI Stereo 3D support

2017-01-19 Thread Alex Deucher

On Wed, Jan 18, 2017 at 10:34 AM, Jeff Smith  wrote:
> Hello all,
>
> This code is very raw at this point, but wanted to get this out there
> for feedback.
>
> This uses codepaths very close to those used for HDMI audio support.
> The driver currently has this disabled, so I needed to re-enable it.
> Turning stereo 3D on without turning audio on would require a bit of
> additional condition handling.
>
> I suspect there are some non-stereo modes that will break with the
> code in its current state, such as modes that require double-scan.
>

Thanks for the patches.  We are in the process of transitioning to new
updated modesetting code (DC), so I would suggest working against that
rather than the existing code.  You can find the latest DC code on the
branch below.  See the display directory in drivers/gpu/drm/amd.
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9

Alex


> Regards,
> Jeff
>
>
> Jeff Smith (2):
>   amdgpu: Stereo 3D support requires enabling audio
>   amdgpu: Add stereo 3D support
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 15 +++--
>  drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 27 
>  drivers/gpu/drm/amd/amdgpu/atombios_encoders.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 86 
> --
>  4 files changed, 106 insertions(+), 24 deletions(-)
>
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: tegra: shut up harmless warning on NOMMU

2017-01-19 Thread Arnd Bergmann

On Thursday, January 19, 2017 12:00:58 PM CET Thierry Reding wrote:
> On Thu, Jan 12, 2017 at 12:13:51PM +0100, Arnd Bergmann wrote:
> > The tegra DRM driver is almost ok without an MMU, but there
> > is one small warning that I get:
> > 
> > drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
> > drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'
> > 
> > This marks the variable as __maybe_unused instead.
> > 
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  drivers/gpu/drm/tegra/gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> > index 7d853e6b5ff0..63f14b7a59a0 100644
> > --- a/drivers/gpu/drm/tegra/gem.c
> > +++ b/drivers/gpu/drm/tegra/gem.c
> > @@ -505,7 +505,7 @@ int tegra_drm_mmap(struct file *file, struct 
> > vm_area_struct *vma)
> >  
> > vma->vm_pgoff = vm_pgoff;
> > } else {
> > -   pgprot_t prot = vm_get_page_prot(vma->vm_flags);
> > +   pgprot_t prot __maybe_unused = vm_get_page_prot(vma->vm_flags);
> 
> This seems to me like a suboptimal solution. The reason why this fails
> is because pgprot_writecombine(prot) for NOMMU translates to __pgprot(0)
> via a macro. This also means that we need to potentially add a
> __maybe_unused annotation to every local variable that stores a value
> that gets passed to pgprot_writecombine().
> 
> There fortunately aren't very many of those cases, but I still think
> that a better solution would be to turn pgprot_writecombine() into a
> static inline function, so that the parameter would get silently
> ignored. Or perhaps if it must remain a macro, then doing the following
> should still avoid the need to modify every call site:
> 
>   #define pgprot_writecombine(prot) ({ (void)prot; __pgprot(0); })
> 
> Thierry
> 

Makes sense. How about this version?

Arnd
---
From 83af6bc74423c90be7f580a827268b89f94b5c6b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann 
Date: Thu, 19 Jan 2017 16:05:29 +0100
Subject: [PATCH] ARM: improve NOMMU definition of pgprot_*()

The tegra DRM driver produces a harmless warning when built for NOMMU:

drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'

This is because pgprot_writecombine() on ARM returns a constant and
ignores its argument. The version in asm-generic doesn't have that
problem, so let's use that one instead. We don't actually care
about the value on NOMMU, and this is consistent with what some
other architectures do.

Signed-off-by: Arnd Bergmann 

diff --git a/arch/arm/include/asm/pgtable-nommu.h 
b/arch/arm/include/asm/pgtable-nommu.h
index add094d09e3e..302240c19a5a 100644
--- a/arch/arm/include/asm/pgtable-nommu.h
+++ b/arch/arm/include/asm/pgtable-nommu.h
@@ -63,9 +63,9 @@ typedef pte_t *pte_addr_t;
 /*
  * Mark the prot value as uncacheable and unbufferable.
  */
-#define pgprot_noncached(prot) __pgprot(0)
-#define pgprot_writecombine(prot) __pgprot(0)
-#define pgprot_dmacoherent(prot) __pgprot(0)
+#define pgprot_noncached(prot) (prot)
+#define pgprot_writecombine(prot) (prot)
+#define pgprot_dmacoherent(prot) (prot)
 
 
 /*

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

[Bug 99051] Pillars of Eternity won't start on AMD Radeon mesa