[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

[bugzilla-daemon]

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

--- Comment #13 from Dieter Nützel  ---
Still there.

But patch works, even with latest DRI3 updates.

-- 
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 99350] libdrm-2.4.74/xf86drmMode.c:904:15: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

[bugzilla-daemon]

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

Thierry Reding  changed:

   What|Removed |Added

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

--- Comment #1 from Thierry Reding  ---
This should be fixed by the following commit that I just pushed to master:

commit ecc2a097294dcc773dbe5e2a989f180bedb89b69
Author: Thierry Reding 
Date:   Mon Apr 13 11:36:59 2015 +0200

xf86drm: Fix type-punned pointer build warning

  CC   libdrm_la-xf86drmMode.lo
../xf86drmMode.c: In function 'drmHandleEvent':
../xf86drmMode.c:854:15: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
   e = (struct drm_event *)([i]);
   ^

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99350
Reviewed-by: Emil Velikov 
Signed-off-by: Thierry Reding 

-- 
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 v11 09/12] drm/mediatek: add dsi transfer function

[CK Hu]

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi read/write commands for transfer function
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 168 
> -
>  1 file changed, 166 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 474861a..b3c7fd8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "mtk_drm_ddp_comp.h"
> @@ -80,8 +81,16 @@
>  #define DSI_HBP_WC   0x54
>  #define DSI_HFP_WC   0x58
>  
> +#define DSI_CMDQ_SIZE0x60
> +#define CMDQ_SIZE0x3f
> +
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RX_DATA0 0x74
> +#define DSI_RX_DATA1 0x78
> +#define DSI_RX_DATA2 0x7c
> +#define DSI_RX_DATA3 0x80
> +
>  #define DSI_RACK 0x84
>  #define RACK BIT(0)
>  
> @@ -117,6 +126,15 @@
>  #define CLK_HS_POST  (0xff << 8)
>  #define CLK_HS_EXIT  (0xff << 16)
>  
> +#define DSI_CMDQ00x180
> +#define CONFIG   (0xff << 0)
> +#define SHORT_PACKET 0
> +#define LONG_PACKET  2
> +#define BTA  BIT(2)
> +#define DATA_ID  (0xff << 8)
> +#define DATA_0   (0xff << 16)
> +#define DATA_1   (0xff << 24)
> +
>  #define T_LPX5
>  #define T_HS_PREP6
>  #define T_HS_TRAIL   8
> @@ -125,6 +143,12 @@
>  
>  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
>  
> +#define MTK_DSI_HOST_IS_READ(type) \
> + ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> + (type == MIPI_DSI_DCS_READ))
> +
>  struct phy;
>  
>  struct mtk_dsi {
> @@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, 
> u32 irq_bit)
>   dsi->irq_data |= irq_bit;
>  }
>  
> -static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
>  {
>   dsi->irq_data &= ~irq_bit;
>  }
>  
> -static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
>unsigned int timeout)
>  {
>   s32 ret = 0;
> @@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   return 0;
>  }
>  
> +static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> +{
> + u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
> +
> + while (timeout_ms--) {
> + if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
> + break;
> +
> + usleep_range(2, 4);
> + }
> +
> + if (timeout_ms == 0) {
> + DRM_WARN("polling dsi wait not busy timeout!\n");
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +}
> +
> +static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
> +{
> + switch (type) {
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
> + return 1;
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
> + return 2;
> + case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
> + case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
> + return read_data[1] + read_data[2] * 16;
> + case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
> + DRM_INFO("type is 0x02, try again\n");
> + break;
> + default:
> + DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
> +{
> + const char *tx_buf = msg->tx_buf;
> + u8 config, cmdq_size, cmdq_off, type = msg->type;
> + u32 reg_val, cmdq_mask, i;
> +
> + if (MTK_DSI_HOST_IS_READ(type))
> + config = BTA;
> + else
> + config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
> +
> + if (msg->tx_len > 2) {
> + cmdq_size = 1 + (msg->tx_len + 3) / 4;
> + cmdq_off = 4;
> + cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
> + reg_val = (msg->tx_len << 16) | (type << 8) | config;
> + } else {
> + cmdq_size = 1;
> + 

Re: [PATCH v11 08/12] drm/mediatek: add dsi interrupt control

[CK Hu]

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi interrupt control
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 92 
> ++
>  1 file changed, 92 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 6f4b3bb..474861a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,16 @@
>  
>  #define DSI_START0x00
>  
> +#define DSI_INTEN0x08
> +
> +#define DSI_INTSTA   0x0c
> +#define LPRX_RD_RDY_INT_FLAG BIT(0)
> +#define CMD_DONE_INT_FLAGBIT(1)
> +#define TE_RDY_INT_FLAG  BIT(2)
> +#define VM_DONE_INT_FLAG BIT(3)
> +#define EXT_TE_RDY_INT_FLAG  BIT(4)
> +#define DSI_BUSY BIT(31)
> +
>  #define DSI_CON_CTRL 0x10
>  #define DSI_RESETBIT(0)
>  #define DSI_EN   BIT(1)
> @@ -71,6 +82,9 @@
>  
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RACK 0x84
> +#define RACK BIT(0)
> +
>  #define DSI_PHY_LCCON0x104
>  #define LC_HS_TX_EN  BIT(0)
>  #define LC_ULPM_EN   BIT(1)
> @@ -137,6 +151,8 @@ struct mtk_dsi {
>   struct videomode vm;
>   int refcount;
>   bool enabled;
> + u32 irq_data;
> + wait_queue_head_t irq_wait_queue;
>  };
>  
>  static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> @@ -469,6 +485,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
>   writel(1, dsi->regs + DSI_START);
>  }
>  
> +static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> +{
> + u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + writel(inten, dsi->regs + DSI_INTEN);
> +}
> +
> +static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
> +{
> + dsi->irq_data |= irq_bit;
> +}
> +
> +static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +{
> + dsi->irq_data &= ~irq_bit;
> +}
> +
> +static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +  unsigned int timeout)
> +{
> + s32 ret = 0;
> + unsigned long jiffies = msecs_to_jiffies(timeout);
> +
> + ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +dsi->irq_data & irq_flag,
> +jiffies);
> + if (ret == 0) {
> + DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +
> + return ret;
> +}
> +
> +static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> +{
> + struct mtk_dsi *dsi = dev_id;
> + u32 status, tmp;
> + u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + status = readl(dsi->regs + DSI_INTSTA) & flag;
> +
> + if (status) {
> + do {
> + mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
> + tmp = readl(dsi->regs + DSI_INTSTA);
> + } while (tmp & DSI_BUSY);
> +
> + mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
> + mtk_dsi_irq_data_set(dsi, status);
> + wake_up_interruptible(>irq_wait_queue);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -517,6 +591,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>  
>   mtk_dsi_ps_control_vact(dsi);
>   mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>  
>   mtk_dsi_set_mode(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -818,6 +893,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct device_node *remote_node, *endpoint;
>   struct resource *regs;
> + int irq_num;
>   int comp_id;
>   int ret;
>  
> @@ -894,6 +970,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> + irq_num = platform_get_irq(pdev, 0);
> + if (irq_num < 0) {
> + dev_err(>dev, "failed to request dsi irq resource\n");
> + return -EPROBE_DEFER;
> + }
> +
> + irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
> + ret = devm_request_irq(>dev, irq_num, mtk_dsi_irq,
> +IRQF_TRIGGER_LOW, dev_name(>dev), dsi);
> + if (ret) {
> + dev_err(>dev, "failed to request mediatek dsi 

Re: [PATCH v11 07/12] drm/mediatek: cleaning up and refine

[CK Hu]

Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> cleaning up unused define and refine function name and variable
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 73 
> --
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c |  8 ++--
>  2 files changed, 39 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 2c42f90..6f4b3bb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -27,9 +27,6 @@
>  
>  #include "mtk_drm_ddp_comp.h"
>  
> -#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
> -#define DSI_HOST_FIFO_DEPTH  64
> -
>  #define DSI_START0x00
>  
>  #define DSI_CON_CTRL 0x10
> @@ -46,7 +43,7 @@
>  #define MIX_MODE BIT(17)
>  
>  #define DSI_TXRX_CTRL0x18
> -#define VC_NUM   (2 << 0)
> +#define VC_NUM   BIT(1)
>  #define LANE_NUM (0xf << 2)
>  #define DIS_EOT  BIT(6)
>  #define NULL_EN  BIT(7)
> @@ -164,7 +161,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
> u32 mask, u32 data)
>   writel((temp & ~mask) | (data & mask), dsi->regs + offset);
>  }
>  
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
>  {
>   u32 timcon0, timcon1, timcon2, timcon3;
>   u32 ui, cycle_time;
> @@ -196,7 +193,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
>  }
>  
> -static void mtk_dsi_reset(struct mtk_dsi *dsi)
> +static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
> @@ -267,8 +264,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_enable(dsi);
> - mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> + mtk_dsi_reset_engine(dsi);
> + mtk_dsi_phy_timconfig(dsi);
>  
>   return 0;
>  
> @@ -281,33 +278,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   return ret;
>  }
>  
> -static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>  }
>  
> -static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
>  }
>  
> -static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
> +static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
>  {
>   u32 tmp_reg1;
>  
> @@ -315,15 +312,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
>   return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
>  }
>  
> -static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
> +static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
>  {
> - if (enter && !dsi_clk_hs_state(dsi))
> + if (enter && !mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
> - else if (!enter && dsi_clk_hs_state(dsi))
> + else if (!enter && mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>  }
>  
> -static void dsi_set_mode(struct mtk_dsi *dsi)
> +static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
>  {
>   u32 vid_mode = CMD_MODE;
>  
> @@ -338,7 +335,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
>   writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
>  }
>  
> -static void dsi_ps_control_vact(struct mtk_dsi *dsi)
> +static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
>  {
>   struct videomode *vm = >vm;
>   u32 dsi_buf_bpp, ps_wc;
> @@ -372,7 +369,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
>   writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
>  }
>  
> -static void dsi_rxtx_control(struct mtk_dsi *dsi)
> 

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

[Ilia Mirkin]

On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater
 wrote:
> HDMI specification 1.4a, table 8-15 is very explicitly a "must
> support at least one of" table, not a "must support all of" table.
> It is not hard to find hardware that does not support some of the
> so-called "mandatory" modes.
>
> More seriously, this code generates invalid display modes for both
> of the 3D-capable panels that I have (a 42-inch LG TV and a Sony
> PlayStation 3D Display).
>
> If we want to be persnickety, one option would be to check the
> final list of modes against the table and give some message if
> none of them are valid, but it's a whole lot easier just to delete
> the code in question.

Damien added this in commit c858cfcae6d some 3 years ago.

Damien, do you remember why you added these "required" modes? Did you
have a monitor that only advertised 3D support without the actual
modes?

>
> Signed-off-by: Alastair Bridgewater 
> ---
>  drivers/gpu/drm/drm_edid.c | 66 
> --
>  1 file changed, 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 336be31..723116a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2926,70 +2926,6 @@ do_cea_modes(struct drm_connector *connector, const u8 
> *db, u8 len)
> return modes;
>  }
>
> -struct stereo_mandatory_mode {
> -   int width, height, vrefresh;
> -   unsigned int flags;
> -};
> -
> -static const struct stereo_mandatory_mode stereo_mandatory_modes[] = {
> -   { 1920, 1080, 24, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
> -   { 1920, 1080, 24, DRM_MODE_FLAG_3D_FRAME_PACKING },
> -   { 1920, 1080, 50,
> - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> -   { 1920, 1080, 60,
> - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> -   { 1280, 720,  50, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
> -   { 1280, 720,  50, DRM_MODE_FLAG_3D_FRAME_PACKING },
> -   { 1280, 720,  60, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
> -   { 1280, 720,  60, DRM_MODE_FLAG_3D_FRAME_PACKING }
> -};
> -
> -static bool
> -stereo_match_mandatory(const struct drm_display_mode *mode,
> -  const struct stereo_mandatory_mode *stereo_mode)
> -{
> -   unsigned int interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
> -
> -   return mode->hdisplay == stereo_mode->width &&
> -  mode->vdisplay == stereo_mode->height &&
> -  interlaced == (stereo_mode->flags & DRM_MODE_FLAG_INTERLACE) &&
> -  drm_mode_vrefresh(mode) == stereo_mode->vrefresh;
> -}
> -
> -static int add_hdmi_mandatory_stereo_modes(struct drm_connector *connector)
> -{
> -   struct drm_device *dev = connector->dev;
> -   const struct drm_display_mode *mode;
> -   struct list_head stereo_modes;
> -   int modes = 0, i;
> -
> -   INIT_LIST_HEAD(_modes);
> -
> -   list_for_each_entry(mode, >probed_modes, head) {
> -   for (i = 0; i < ARRAY_SIZE(stereo_mandatory_modes); i++) {
> -   const struct stereo_mandatory_mode *mandatory;
> -   struct drm_display_mode *new_mode;
> -
> -   if (!stereo_match_mandatory(mode,
> -   
> _mandatory_modes[i]))
> -   continue;
> -
> -   mandatory = _mandatory_modes[i];
> -   new_mode = drm_mode_duplicate(dev, mode);
> -   if (!new_mode)
> -   continue;
> -
> -   new_mode->flags |= mandatory->flags;
> -   list_add_tail(_mode->head, _modes);
> -   modes++;
> -   }
> -   }
> -
> -   list_splice_tail(_modes, >probed_modes);
> -
> -   return modes;
> -}
> -
>  static int add_hdmi_mode(struct drm_connector *connector, u8 vic)
>  {
> struct drm_device *dev = connector->dev;
> @@ -3090,8 +3026,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
> const u8 *db, u8 len,
> /* 3D_Present */
> offset++;
> if (db[8 + offset] & (1 << 7)) {
> -   modes += add_hdmi_mandatory_stereo_modes(connector);
> -
> /* 3D_Multi_present */
> multi_present = (db[8 + offset] & 0x60) >> 5;
> }
> --
> 2.10.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/20] dw-hdmi: Cleanups, fixes and updates for v4.11

[Archit Taneja]

On 01/17/2017 01:58 PM, Laurent Pinchart wrote:

Hello,

This patch series contains the part of my pending dw-hdmi patches that have
been successfully tested on all three supported platforms (i.MX6, RK3288 and
R-Car H3) and have been reviewed without any problem being reported.

All patches here have been previously posted as part of the "[PATCH v2 00/29]
R-Car Gen3 HDMI output support" and "[PATCH 0/3] dw-hdmi: miscellaneous
cleanups and fix" series. This series is a repost with all review tags
collected.


queued to drm-misc-next

Archit



Kieran Bingham (2):
  drm: bridge: dw-hdmi: Remove unused function parameter
  drm: bridge: dw-hdmi: Remove PHY configuration resolution parameter

Laurent Pinchart (18):
  drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and
hdmi_phy_i2c_write
  drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind
functions
  drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi
  drm: bridge: dw-hdmi: Remove encoder field from struct dw_hdmi
  drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before
attach
  drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common
code
  drm: bridge: dw-hdmi: Reorder functions to prepare for next commit
  drm: bridge: dw-hdmi: Create connector in the bridge attach operation
  drm: bridge: dw-hdmi: Implement DRM bridge registration
  drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET
  drm: bridge: dw-hdmi: Reject invalid product IDs
  drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register
  drm: bridge: dw-hdmi: Handle overflow workaround based on device
version
  drm: bridge: dw-hdmi: Detect PHY type at runtime
  drm: bridge: dw-hdmi: Define and use macros for PHY register addresses
  drm: bridge: dw-hdmi: Fix the name of the PHY reset macros
  drm: bridge: dw-hdmi: Assert SVSRET before resetting the PHY
  dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

 .../devicetree/bindings/display/bridge/dw_hdmi.txt |  85 ++--
 .../devicetree/bindings/display/imx/hdmi.txt   |  51 +--
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt |  43 +-
 drivers/gpu/drm/bridge/dw-hdmi.c   | 438 +
 drivers/gpu/drm/bridge/dw-hdmi.h   |  85 +++-
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  14 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c|  14 +-
 include/drm/bridge/dw_hdmi.h   |  19 +-
 8 files changed, 472 insertions(+), 277 deletions(-)



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

[Bug 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted

[bugzilla-daemon]

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

--- Comment #1 from Shmerl  ---
For the reference, to run the game in Wine, you need to set:

[HKEY_CURRENT_USER\Software\Wine\Direct3D] 
"DirectDrawRenderer"="opengl" 
"UseGLSL"="enabled" 
"MaxVersionGL"=dword:00040005

And make sure you are using wine-staging 2.0rc5 or later, since older versions
crash on startup because of the virtual heap limit.

-- 
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 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted

[bugzilla-daemon]

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

Shmerl  changed:

   What|Removed |Added

Summary|[radeonsi] The Witcher 3|[radeonsi] The Witcher 3
   |[Wine] starting menu is |(GOG/1.31) [Wine] starting
   |distorted   |menu is distorted

-- 
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 99444] [radeonsi] The Witcher 3 [Wine] starting menu is distorted

[bugzilla-daemon]

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

Bug ID: 99444
   Summary: [radeonsi] The Witcher 3 [Wine] starting menu is
distorted
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: shtetl...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 129014
  --> https://bugs.freedesktop.org/attachment.cgi?id=129014=edit
Witcher 3 main menu distortion (no CSMT)

I'm testing The Witcher 3 with recent Wine staging 2.0rc5 (CSMT disabled),
using AMD RX 480 and latest Mesa devel:

OpenGL renderer string: Gallium 0.4 on AMD POLARIS10 (DRM 3.3.0 /
4.8.0-2-amd64, LLVM 3.9.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.0.0-devel
(git-aac562f112)

Starting screen has distorted text in the menu (see attached screenshot). For
the reference, the game is still unplayable beyond the starting screen and
intro with broken graphics, but users of Nvidia blob report that they don't
have this issue in the starting menu which appears correct to them, so menu
distortion looks radenosi related.

-- 
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: [01/26] drm/rockchip: dw-mipi-dsi: use mode from display state

[Mark yao]

On 2017年01月17日 18:38, Chris Zhong wrote:
@@ -821,8 +824,6 @@ static void dw_mipi_dsi_encoder_mode_set(struct 
drm_encoder *encoder,

  struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
  int ret;
  -dsi->mode = adjusted_mode;
-
I prefer to keep the original method, although this"dsi->mode" pointer 
is same as ">connector.state->crtc->state->adjusted_mode; "

I still think dsi->mode makes the process easier to read
">connector.state->crtc->state->adjusted_mode;" is too long, and 
dsi->connector.state->crtc can be NULL, seems not good.


agree with Chris, I think dsi->mode is better.

Bug the origin code "dsi->mode = adjusted_mode; " also has a bug, 
adjusted_mode's lift time is unknown, use a pointer from adjusted_mode 
is dangerous.


I think we can use like that, copy a display mode to dsi->mode:
struct dw_mipi_dsi
{
   -struct drm_display_mode *mode;
   +struct drm_display_mode mode;
}
  xxx_encoder_mode_set()
{
   drm_mode_copy(>mode, adjusted_mode);
}

--
Ｍark Yao


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

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

[Inki Dae]

Hi Laurent,

2017년 01월 17일 18:17에 Laurent Pinchart 이(가) 쓴 글:
> Hi Inki,
> 
> Thank you for the patch.
> 
> On Monday 16 Jan 2017 18:13:22 Inki Dae wrote:
>> This patch relpaces specific atomic commit function
>> with atomic helper commit one, which also includes
>> atomic_commit_tail callback for Exynos SoC becasue
>> crtc devices on Exynos SoC uses power domain device
>> so drm_atomic_helper_commit_planes should be called
>> after drm_atomic_helper_commit_modeset_enables.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 110 +---
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c   |  25 ++-
>>  3 files changed, 33 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..47da612 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;
>> +}
> 
> You also need to handle events for exynos_drm_crtc_enable(). I'm not too

Is there any corner case? I think there should be no event which is not handled 
when exynos_drm_crtc_enable() is called.
 
> familiar with the exynos drm driver, is that taken care of by event handling 
> in exynos_crtc_atomic_flush() ?

Yes, exynos_crtc_atomic_flush() handles the event - making crtc->state->event 
to NULL and handing the event.

However, I think no need to handle the event at this funtion so relevant code 
in exynos_crtc_ctomic_flush() is not clear to me excepting setting 
crtc->state->event to NULL - without this code, hw_done function will say 
warning.
This patch would be a first step to clean up atomic interfaces of Exynos DRM 
driver.

> 
> You could also split this change into a separate patch with a clear 
> explanation of why it's needed in the commit message.
> 
>>  }
> 
> [snip]
> 
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 3ec0535..9d0df00 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> 
> [snip]
> 
>> -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() step, this way it will always
>> - * have the relevant clocks enabled to perform the update.
>> - */
> 
> There's a value in this comment, I would copy it to 
> exynos_drm_atomic_commit_tail()

As I already left the comment at other email thread, I will update description 
of this patch instead because atomic kms helper already described why 
atomic_commit_tail callback is required - the driver using runtime PM should 
have different call order.
But.. ok, this is what Gustavo wanted also. Seems better to leave above comment 
because the more explanation, the better. 

> 
>> -drm_atomic_helper_commit_planes(dev, state, 0);
>> -
>> -drm_atomic_helper_wait_for_vblanks(dev, state);
>> -
>> -drm_atomic_helper_cleanup_planes(dev, state);
>> -
>> -drm_atomic_state_put(state);
>> -
>> -spin_lock(>lock);
>> -priv->pending &= ~commit->crtcs;
>> -spin_unlock(>lock);
>> -
>> -wake_up_all(>wait);
>> -
>> -kfree(commit);
>> -}
> 
> [snip]
> 
>> @@ -313,6 +204,7 @@ static void exynos_drm_preclose(struct drm_device *dev,
>>
>>  list_for_each_entry(crtc, >mode_config.crtc_list, head)
>>  exynos_drm_crtc_cancel_page_flip(crtc, file);
>> +
> 
> This isn't needed.
> 
>>  }
>>
>>  static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
>> *file) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 68d4142..1e10b73 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
>> @@ -187,11 +187,33 @@ dma_addr_t exynos_drm_fb_dma_addr(struct
>> drm_framebuffer *fb, int index) return exynos_fb->dma_addr[index];
>>  }
>>

Re: [PATCH 3/4] drm/amd/display: Switch to using atomic_helper for flip.

[Michel Dänzer]

On 17/01/17 07:16 AM, Laurent Pinchart wrote:
> On Monday 16 Jan 2017 10:44:57 Andrey Grodzovsky wrote:
>> Change-Id: Iad3e0b9b3546e4e4dc79be9233daf4fe4dba83e0
>> Signed-off-by: Andrey Grodzovsky 
>> ---
>>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 92 ++
>>  1 file changed, 6 insertions(+), 86 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c index
>> a443b70..d4664bf 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
>> @@ -1060,83 +1060,6 @@ static int dm_crtc_funcs_atomic_set_property(
>>  return 0;
>>  }
>>
>> -
>> -static int amdgpu_atomic_helper_page_flip(struct drm_crtc *crtc,
>> -struct drm_framebuffer *fb,
>> -struct drm_pending_vblank_event *event,
>> -uint32_t flags)
>> -{
>> -struct drm_plane *plane = crtc->primary;
>> -struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
>> -struct drm_atomic_state *state;
>> -struct drm_plane_state *plane_state;
>> -struct drm_crtc_state *crtc_state;
>> -int ret = 0;
>> -
>> -state = drm_atomic_state_alloc(plane->dev);
>> -if (!state)
>> -return -ENOMEM;
>> -
>> -ret = drm_crtc_vblank_get(crtc);
> 
> The DRM core's atomic page flip helper doesn't get/put vblank. Have you 
> double-checked that removing them isn't a problem ?

This patch makes the amdgpu DM code use the page_flip_target hook.
drm_mode_page_flip_ioctl calls drm_crtc_vblank_get before the
page_flip_target hook.

You're right though that the fact that drm_atomic_helper_page_flip
doesn't call drm_crtc_vblank_get is a bit alarming. From the
DRM_IOCTL_MODE_PAGE_FLIP POV, drm_crtc_vblank_get must be called when
userspace calls the ioctl (either by drm_mode_page_flip_ioctl or the
page_flip hook implementation), and drm_crtc_vblank_put must be called
when the flip completes and the event is sent to userspace. How is this
supposed to be handled with atomic?

Andrey, did you check via code audit and/or testing that the vblank
reference count is still balanced after this change?


>> @@ -3143,8 +3064,7 @@ int amdgpu_dm_atomic_check(struct drm_device *dev,
>>   * 1. This commit is not a page flip.
>>   * 2. This commit is a page flip, and targets are 
> created.
>>   */
>> -if (!page_flip_needed(plane_state, old_plane_state,
>> -  true) ||
>> +if (!page_flip_needed(plane_state, old_plane_state, 
> true) ||
> 
> This seems to be an unrelated change.

Yeah, such whitespace-only changes should be dropped.


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

Re: [PATCH 0/3] Fix DECON_UPDATE for TV

[Inki Dae]

Hi Andrzej,

2017년 01월 17일 23:15에 Andrzej Hajda 이(가) 쓴 글:
> Hi Inki,
> 
> This is my final fight with DECON_UPDATE issues (I hope). My two previous 
> patches
> fixed problems on panel path, this patchset fixes also TV path.
> The root cause of all evil was in incorrect DECON_CMU programming.
> 
> Now it works correctly on:
> - panel,
> - TV,
> - both.
> I have not observed (so far) IOMMU faults, or vblank timeouts.

Really thanks for this patch set. Will review and merge it. This patch set will 
go to -fixes.

Thanks.

> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (3):
>   drm/exynos/decon5433: do not disable video after reset
>   drm/exynos/decon5433: fix CMU programming
>   drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
> 
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/7] Host1x IOMMU support + VIC support

[Mikko Perttunen]

On 12/14/2016 04:11 PM, Daniel Vetter wrote:

On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote:

On 14.12.2016 15:05, Daniel Vetter wrote:

On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote:

On 14.12.2016 14:30, Daniel Vetter wrote:

On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote:

This series adds IOMMU support to Host1x and TegraDRM
and adds support for the VIC (Video Image Compositor)
host1x client. The series is available as a git repository at
git://github.com/cyndis/linux.git; branch vic-2.

A userspace test case for VIC can be found at
https://github.com/cyndis/drm/tree/work/tegra.
The testcase is in tests/tegra and is called submit_vic.
The testcase/TRM include full headers and documentation
to program the unit. The unit by itself, however, does not
readily map to existing userspace library interfaces, so
implementations for those are not provided.


Afaik libva has an entire pile of post-processing support. Pretty sure
other video transcode libraries have similar interfaces, so should all be
possible to implement this.


We don't have any actual video transcoding support though, so unless it's
possible to just implement a part of libva and defer the rest to some CPU
implementation, I don't see how this is useful. I suppose I could implement
a GStreamer plugin for colorspace conversion or resizing, since those are
very modular.


Hm, I guess the question then is, how did that get enabled?


What is "that"? I'm not exactly sure.

Our architecture is such that there's the VIC that handles colorspace
conversion, rescaling, blitting and can do some 2d postprocessing effects as
well.

Then there's the separate NVDEC that is a video bitstream decoder. There's
no support for that at the moment. I am working on the IP side of that.

The video processing pipeline is then such that NVDEC is fed the bitstream;
NVDEC outputs a YUV picture in a specific format; VIC takes that YUV picture
and converts/rescales it into the desired format. Or if we are encoding
video, VIC takes your RGB image, converts it into a format that NVENC
understands, and so on.

So with just VIC support, I could implement some simple 2D things. I don't
know if anyone would want to specifically use the VIC for those since
applications already have fast CPU algorithms. For the video pipeline using
VIC is nice since these units can synchronize work without CPU involvement
and when you're already using NVDEC or NVENC it's barely any extra effort to
involve VIC as well. It can also be useful in power usage sensitive
situations, but we aren't really fit for those situations with the upstream
kernel anyway :)


Ah I thought the nvdec was already enabled, since for i915 that's how we
went about things (we have a pretty much exactly matching split in the
various video related engines). But if that's not there yet then no
worries, all fine.

Since you do seem to plan to enable everything anyway, might be worth it
to go directly with something like libva or libvdpau or whatever the cool
thing is. libva is my recommendation since it works on non-X11 too afaik,
but I have 0 clue. And might be worth it to check out whether you can't do
a super-basic libva driver that only does the post processing stuff. With
libva you can import/export images, so it might be possible even ... And
directly doing the full video engine support instead of a one-off in
gstreamer sounds more sensible to me.
-Daniel



It took a while, but I now have a libva backend to go with this kernel 
driver: https://github.com/cyndis/vaapi-tegra-driver.


It is far from complete, but the libva putsurface testcase runs and its 
output looks correct when compared to the intel backend. Would this be 
suitable or should something more be implemented before merging the 
kernel driver?


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

[PATCH] firmware: qcom_scm: Add set remote state API

[Andy Gross]

This patch adds a set remote state SCM API.  This will be used by the
Venus and GPU subsystems to set state on the remote processors.

This work was based on two patch sets by Jordan Crouse and Stanimir
Varbanov.

Signed-off-by: Andy Gross 
---
 drivers/firmware/qcom_scm-32.c | 18 ++
 drivers/firmware/qcom_scm-64.c | 16 
 drivers/firmware/qcom_scm.c|  6 ++
 drivers/firmware/qcom_scm.h|  2 ++
 include/linux/qcom_scm.h   |  4 +++-
 5 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index c6aeedb..8ad226c 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -560,3 +560,21 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool 
reset)
 
return ret ? : le32_to_cpu(out);
 }
+
+int __qcom_scm_set_remote_state(struct device *dev, u32 state, u32 id)
+{
+   struct {
+   __le32 state;
+   __le32 id;
+   } req;
+   __le32 scm_ret = 0;
+   int ret;
+
+   req.state = cpu_to_le32(state);
+   req.id = cpu_to_le32(id);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_SET_REMOTE_STATE,
+   , sizeof(req), _ret, sizeof(scm_ret));
+
+   return ret ? : le32_to_cpu(scm_ret);
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ea..4b220ab 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -358,3 +358,19 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool 
reset)
 
return ret ? : res.a1;
 }
+
+int __qcom_scm_set_remote_state(struct device *dev, u32 state, u32 id)
+{
+   struct qcom_scm_desc desc = {0};
+   struct arm_smccc_res res;
+   int ret;
+
+   desc.args[0] = state;
+   desc.args[1] = id;
+   desc.arginfo = QCOM_SCM_ARGS(2);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_SET_REMOTE_STATE,
+   , );
+
+   return ret ? : res.a1;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 65d0d9d..d987bcc 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -324,6 +324,12 @@ bool qcom_scm_is_available(void)
 }
 EXPORT_SYMBOL(qcom_scm_is_available);
 
+int qcom_scm_set_remote_state(u32 state, u32 id)
+{
+   return __qcom_scm_set_remote_state(__scm->dev, state, id);
+}
+EXPORT_SYMBOL(qcom_scm_set_remote_state);
+
 static int qcom_scm_probe(struct platform_device *pdev)
 {
struct qcom_scm *scm;
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 3584b00..6a0f154 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -15,6 +15,8 @@
 #define QCOM_SCM_SVC_BOOT  0x1
 #define QCOM_SCM_BOOT_ADDR 0x1
 #define QCOM_SCM_BOOT_ADDR_MC  0x11
+#define QCOM_SCM_SET_REMOTE_STATE  0xa
+extern int __qcom_scm_set_remote_state(struct device *dev, u32 state, u32 id);
 
 #define QCOM_SCM_FLAG_HLOS 0x01
 #define QCOM_SCM_FLAG_COLDBOOT_MC  0x02
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 7e004fb..d32f6f1 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -39,6 +39,7 @@ extern int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t 
addr,
 extern int qcom_scm_pas_shutdown(u32 peripheral);
 extern void qcom_scm_cpu_power_down(u32 flags);
 extern u32 qcom_scm_get_version(void);
+extern int qcom_scm_set_remote_state(u32 state, u32 id);
 #else
 static inline
 int qcom_scm_set_cold_boot_addr(void *entry, const cpumask_t *cpus)
@@ -64,6 +65,7 @@ static inline int qcom_scm_pas_mem_setup(u32 peripheral, 
phys_addr_t addr,
 static inline int qcom_scm_pas_shutdown(u32 peripheral) { return -ENODEV; }
 static inline void qcom_scm_cpu_power_down(u32 flags) {}
 static inline u32 qcom_scm_get_version(void) { return 0; }
+static inline u32
+qcom_scm_set_remote_state(u32 state,u32 id) { return -ENODEV; }
 #endif
-
 #endif
-- 
1.9.1

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

Re: [PATCH v2 0/3] Allow ASYNC flip with atomic helpers.

[Edward O'Callaghan]

This series is,
Reviewed-by: Edward O'Callaghan 

On 01/17/2017 04:16 PM, Andrey Grodzovsky wrote:
> This series is a folow-up on
> https://patchwork.kernel.org/patch/9501787/
> 
> The first patch makes changes to atomic helpers to allow for 
> drives with ASYNC flip support to use them.
> Patch 2 is to use this in AMDGPU/DC.
> Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate 
> the helper as we did to support ASYNC flips. 
> 
> v2: 
> Resend drm/atomic: Save flip flags in drm_plane_state since
> the original patch was incomplete.
> Squash 2 AMD changes into one to not break compilation.
> 
> Andrey Grodzovsky (3):
>   drm/atomic: Save flip flags in drm_plane_state
>   drm/amd/display: Switch to using atomic_helper for flip.
>   drm/nouveau/kms/nv50: Switch to using atomic helper for flip.
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |  1 -
>  .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 92 
> ++
>  drivers/gpu/drm/drm_atomic_helper.c| 18 ++---
>  drivers/gpu/drm/nouveau/nv50_display.c | 77 ++
>  include/drm/drm_plane.h|  8 ++
>  5 files changed, 24 insertions(+), 172 deletions(-)
> 



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

Re: Request API: stateless VPU: the buffer mechanism and DPB management

[herman.c...@rock-chips.com]

Hi all,

If we move parser or part of DPB management mechanism into kernel we will face 
a issue as follows:
One customer requires dpb management do a flush when stream occurs in order to 
keep output frame clean.
While another one requires output frame with error to keep output frame smooth.
And when only one field has a error one customer wants to do a simple field 
copy to recover.

These are some operation related to strategy rather then mechanism.
I think it is not a good idea to bring such kind of flexible process to kernel 
driver.

So here is the ultimate challenge that how to reasonably move the parser and 
flexible process
which is encapsuled in firmware to a userspace - kernel stateless driver model.



陈恒明/Herman Chen
算法工程师/Algorithm Engineer
+86-591-83991906-8900
福州瑞芯微电子股份有限公司
 
From: Randy Li
Date: 2017-01-17 11:04
To: linux-me...@vger.kernel.org
CC: dri-devel@lists.freedesktop.org; Hans Verkuil; pawel; ay...@soulik.info; 
nicolas.dufre...@collabora.co.uk; florent.revest; hugues.fruchet; 
herman.c...@rock-chips.com
Subject: Request API: stateless VPU: the buffer mechanism and DPB management
Hello all:
   I have recently finish the learning of the H.264 codec and ready to 
write the driver. Although I have not get deep in syntax of H.264 but I 
think I just need to reuse and extended the VA-API H264 Parser from 
gstreamer. The whole plan in userspace is just injecting a parsing 
operation and set those v4l2 control in kernel before enqueue a buffer 
into OUTPUT, which would keep the most compatible with those stateful 
video IP(those with a firmware).
   But in order to do that, I can't avoid the management of DPB. I 
decided to moving the DPB management job from userspace in kernel. Also 
the video IP(On2 on rk3288 and the transition video IP on those future 
SoC than rk3288, rkv don't have this problem) would a special way to 
manage the DPB, which requests the same reference frame is storing in 
the same reference index in the runtime(actually it is its Motion Vector 
data appended in decoded YUV data would not be moved). I would suggest 
to keep those job in kernel, the userspace just to need update the list0 
and list1 of DPB. DPB is self managed in kernel the userspace don't need 
to even dequeue the buffer from CAPTURE until the re-order is done.
   The kernel driver would also re-order the CAPTURE buffer into display 
order, and blocking the operation on CAPTURE until a buffer is ready to 
place in the very display order. If I don't do that, I have to get the 
buffer once it is decoded, and marking its result with the poc, I could 
only begin the processing of the next frame only after those thing are 
done. Which would effect the performance badly. That is what chromebook 
did(I hear that from the other staff, I didn't get invoke in chromium 
project yet). So I would suggest that doing the re-order job in kernel, 
and inform the the userspace the buffers are ready when the new I 
frame(key frame) is pushed into the video IP.
   Although moving those job into kernel would increase the loading, but 
I think it is worth to do that, but I don't know whether all those 
thought are correct and high performance(It is more important than API 
compatible especially for those 4K video). And I want to know more ideas 
about this topic.
   I would begin the writing the new driver after the coming culture new 
year vacation(I would go to the Europe), I wish we can decide the final 
mechanism before I begin this job.
-- 
Randy Li
The third produce department
 
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Request API: stateless VPU: the buffer mechanism and DPB management

[ayaka]

On 01/17/2017 10:59 PM, Nicolas Dufresne wrote:

Le mardi 17 janvier 2017 à 20:46 +0800, herman.c...@rock-chips.com a
écrit :

If we move parser or part of DPB management mechanism into kernel we
will face a issue as follows:
One customer requires dpb management do a flush when stream occurs in
order to keep output frame clean.
While another one requires output frame with error to keep output
frame smooth.
And when only one field has a error one customer wants to do a simple
field copy to recover.

The driver should send all frames and simply mark the corrupted frames
using V4L2_BUF_FLAG_ERROR. This way, the userspace can then make their
own decision. It is also important to keep track and cleanup the
buffers meta's (which are application specific). If the driver silently
drops frame, it makes that management much harder.

About flushing and draining operation, they are respectively signalled
to the driver using STREAMOFF and CMD_STOP.


These are some operation related to strategy rather then mechanism.
I think it is not a good idea to bring such kind of flexible process
to kernel driver.

So here is the ultimate challenge that how to reasonably move the
parser and flexible process
which is encapsuled in firmware to a userspace - kernel stateless
driver model.

Moving the parsers in the kernel (on the main CPU) is not acceptable.
No, what is not what I said. What I want to do is "The whole plan in 
userspace is just injecting a parsing operation and set those v4l2 
control in kernel before enqueue a buffer into OUTPUT, which would keep 
the most compatible with those stateful video IP(those with a firmware). "

This is too much of a security threat. Userspace should parse the data
into structures, doing any validation required before end.

My main question and that should have an impact decision, is if those
structures can be made generic. PDB handling is not that trivial (my
reference is VAAPI here, maybe they are doing it wrong) and with driver
specific structures, we would have this code copy-pasted over and over.
So with driver specific structures, it's probably better to keep all
the parsing and reordering logic outside (hence together).

The result to keep DPB and re-order inside the kernel is want
to be compatible with the original buffer operation.
Anyway the DPB structure could be common.


That remains, that some driver will deal with reordering on the
firmware side (even the if they don't parse), hence we need to take
this into consideration.

No sure what do you mean, I think all those driver with firmware
would do that.


regards,
Nicolas


Hello all:
  I have recently finish the learning of the H.264 codec and ready to 
write the driver. Although I have not get deep in syntax of H.264 but I 
think I just need to reuse and extended the VA-API H264 Parser from 
gstreamer. The whole plan in userspace is just injecting a parsing 
operation and set those v4l2 control in kernel before enqueue a buffer 
into OUTPUT, which would keep the most compatible with those stateful 
video IP(those with a firmware).
  But in order to do that, I can't avoid the management of DPB. I 
decided to moving the DPB management job from userspace in kernel. Also 
the video IP(On2 on rk3288 and the transition video IP on those future 
SoC than rk3288, rkv don't have this problem) would a special way to 
manage the DPB, which requests the same reference frame is storing in 
the same reference index in the runtime(actually it is its Motion Vector 
data appended in decoded YUV data would not be moved). I would suggest 
to keep those job in kernel, the userspace just to need update the list0 
and list1 of DPB. DPB is self managed in kernel the userspace don't need 
to even dequeue the buffer from CAPTURE until the re-order is done.
  The kernel driver would also re-order the CAPTURE buffer into display 
order, and blocking the operation on CAPTURE until a buffer is ready to 
place in the very display order. If I don't do that, I have to get the 
buffer once it is decoded, and marking its result with the poc, I could 
only begin the processing of the next frame only after those thing are 
done. Which would effect the performance badly. That is what chromebook 
did(I hear that from the other staff, I didn't get invoke in chromium 
project yet). So I would suggest that doing the re-order job in kernel, 
and inform the the userspace the buffers are ready when the new I 
frame(key frame) is pushed into the video IP.
  Although moving those job into kernel would increase the loading, but 
I think it is worth to do that, but I don't know whether all those 
thought are correct and high performance(It is more important than API 
compatible especially for those 4K video). And I want to know more ideas 
about this topic.
  I would begin the writing the new driver after the coming culture new 
year vacation(I would go to the Europe), I wish we can decide the final 
mechanism before I begin this job.

Re: Request API: stateless VPU: the buffer mechanism and DPB management

[Nicolas Dufresne]

Le mardi 17 janvier 2017 à 20:46 +0800, herman.c...@rock-chips.com a
écrit :
> If we move parser or part of DPB management mechanism into kernel we
> will face a issue as follows:
> One customer requires dpb management do a flush when stream occurs in
> order to keep output frame clean.
> While another one requires output frame with error to keep output
> frame smooth.
> And when only one field has a error one customer wants to do a simple
> field copy to recover.

The driver should send all frames and simply mark the corrupted frames
using V4L2_BUF_FLAG_ERROR. This way, the userspace can then make their
own decision. It is also important to keep track and cleanup the
buffers meta's (which are application specific). If the driver silently
drops frame, it makes that management much harder.

About flushing and draining operation, they are respectively signalled
to the driver using STREAMOFF and CMD_STOP.

> 
> These are some operation related to strategy rather then mechanism.
> I think it is not a good idea to bring such kind of flexible process
> to kernel driver.
> 
> So here is the ultimate challenge that how to reasonably move the
> parser and flexible process
> which is encapsuled in firmware to a userspace - kernel stateless
> driver model.

Moving the parsers in the kernel (on the main CPU) is not acceptable.
This is too much of a security threat. Userspace should parse the data
into structures, doing any validation required before end.

My main question and that should have an impact decision, is if those
structures can be made generic. PDB handling is not that trivial (my
reference is VAAPI here, maybe they are doing it wrong) and with driver
specific structures, we would have this code copy-pasted over and over.
So with driver specific structures, it's probably better to keep all
the parsing and reordering logic outside (hence together).

That remains, that some driver will deal with reordering on the
firmware side (even the if they don't parse), hence we need to take
this into consideration.

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

Re: [Freedreno] [PATCH 10/12] firmware: qcom_scm: Add qcom_scm_gpu_zap_resume()

[Andy Gross]

On Tue, Jan 17, 2017 at 10:04:59AM -0700, Jordan Crouse wrote:
> On Sat, Jan 14, 2017 at 11:20:58PM -0600, Andy Gross wrote:
> > + Stanimir
> > 
> > On Sat, Jan 14, 2017 at 09:49:01PM -0600, Andy Gross wrote:
> > > On Fri, Jan 13, 2017 at 04:24:38PM -0700, Jordan Crouse wrote:
> > > > On Fri, Jan 13, 2017 at 11:12:41AM -0600, Andy Gross wrote:
> > > > > On Mon, Nov 28, 2016 at 12:28:35PM -0700, Jordan Crouse wrote:
> > > > > > Add an interface to trigger the remote processor to reinitialize 
> > > > > > the GPU
> > > > > > zap shader on power-up.
> > > > > > 
> > > > > > Signed-off-by: Jordan Crouse 
> > > > > > ---
> > > > > 
> > > > > 
> > > > > 
> > > > > > +int __qcom_scm_gpu_zap_resume(struct device *dev)
> > > > > > +{
> > > > > > +   struct qcom_scm_desc desc = {0};
> > > > > > +   struct arm_smccc_res res;
> > > > > > +   int ret;
> > > > > > +
> > > > > > +   desc.args[0] = 0;
> > > > 
> > > > This is an opcode to force the state to resume.
> > > > 
> > > > QCOM_SCM_BOOT_SET_STATE_RESUME perhaps?  Or something similar but 
> > > > shorter.
> > > > 
> > > > > > +   desc.args[1] = 13;
> > > > 
> > > > This is the same as the SCM id of the GPU but I think that is a 
> > > > coincidence.
> > > > We've always used it to identify the GPU in this call.
> > > > 
> > > > QCOM_SCM_BOOT_SET_STATE_GPU would be fine here - or something similar.
> > > > 
> > > > > Can I get a define here for these two?  Or maybe a comment on what 
> > > > > these values
> > > > > are?
> > > > > 
> > > > > > +   desc.arginfo = QCOM_SCM_ARGS(2);
> > > > > > +
> > > > > > +   ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, 0x0A, , );
> > > > > 
> > > > > Same with the 0xA.  We usually throw a #define in for the command 
> > > > > definitions.
> > > > 
> > > > 0x0A sets the state of the device - for us it is always 0 (resume) and 
> > > > always
> > > > the GPU.
> > > > 
> > > > #define  QCOM_SCM_BOOT_SET_STATE 0x0A
> > > > 
> > > > > Otherwise this all looks fine.  If you can get back to me with either 
> > > > > the values
> > > > > or a new patch I can include this in the next pull.
> > > > 
> > > > I'll make the changes and start the song and dance, but you'll no doubt 
> > > > be
> > > > faster than I.
> > > 
> > > I can just fix up the patch with the above.  Thanks for the additional 
> > > details.
> > 
> > The plot thickens.  So I have a patch from Stanimir concerning another SCM 
> > call
> > that is using the same command and number of arguments.  And it also 
> > concerns
> > setting state.  I think that we need to roll a common API for setting the 
> > state
> > and then both of you can call it.  That way we can kill two birds with one
> > stone.
> 
> I was worried about this, but not this quickly - glad to see that the other
> drivers are coming along too.
> 
> If you look carefully, you'll note that the values are inverted - the video
> state uses 0 to suspend and 1 to resume, and GPU uses 0 to resume and no
> suspend. I asked why and got a bunch of shrugging back. Its not a big deal
> because your API accounts for this but expect GPU to have a RESUME #define
> that is a different value.
> 
> > Something along the lines of a function prototype:
> > int qcom_scm_set_remote_state(u32 state, u32 id)
> > {
> > return __qcom_scm_set_remote_state(__scm->dev, state, id);
> > }
> > EXPORT_SYMBOL(qcom_scm_set_remote_state);
> > 
> > where state is the state you want set, and id is the identifier of the 
> > remote
> > proc.
> >
> > Does this make sense for both of your use cases?
> 
> Yep - this is fine.

If you guys can ack/sob that patch I'd appreciate it.

As for the #defines, you guys can define whatever you like in your drivers.
This API just pushes all that into your client drivers.


Andy

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

Re: [PATCH] drm/vc4: Fix memory leak of the CRTC state.

[Stefan Wahren]

> Hi Eric,
>
> could you please resend this patch [1], because it's still not applied in 
> Linux 4.10-rc2.
>
> Thanks
> Stefan
>
> [1] - https://patchwork.kernel.org/patch/9369793/

ping ...
___
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

[Joonyoung Shim]

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().

You can reproduce overflow of size easily if you use value like
4294967295 or 2147483647 at the req->cmd_buf_nr.

Thanks.
___
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

[Manasi Navare]

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;
+   }
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;
+   }
+   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 test_result;
 }
 
@@ -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 +4228,7 @@ static void intel_dp_handle_test_request(struct intel_dp 
*intel_dp)
   sink_irq_vector);
 
if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
-   DRM_DEBUG_DRIVER("Test request in short pulse not 
handled\n");
+   intel_dp_handle_test_request(intel_dp);
if (sink_irq_vector & (DP_CP_IRQ | 

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

[Manasi Navare]

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 | 58 +
 1 file changed, 58 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 0468135..ff03f8a 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -417,6 +417,64 @@
 #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_SQUARE(0x3)
+
+#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_LO0x22B
+
+#define DP_TEST_VSYNC_HI0x22C
+#define DP_TEST_VSYNC_LO0x22D
+
+#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_MISC_LO 0x232
+# define DP_TEST_SYNC_CLOCK_MASK(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(0x0)
+# define DP_COLOR_FORMAT_YCbCr422   (0x1)
+# define DP_COLOR_FORMAT_YCbCr444   (0x2)
+# define DP_TEST_DYNAMIC_RANGE_MASK (1 << 3)
+# define DP_TEST_DYNAMIC_RANGE_SHIFT3
+# define DP_VESA_RANGE  (0x0)
+# define DP_CEA_RANGE   (0x1)
+# define DP_TEST_BIT_DEPTH_MASK (7 << 5)
+# define DP_TEST_BIT_DEPTH_SHIFT5
+# define DP_TEST_BIT_DEPTH_6(0x0)
+# define DP_TEST_BIT_DEPTH_8(0x1)
+# define DP_TEST_BIT_DEPTH_10   (0x2)
+# define DP_TEST_BIT_DEPTH_12   (0x3)
+# define DP_TEST_BIT_DEPTH_16   (0x4)
+#define DP_TEST_MISC_HI 0x233
+# define DP_TEST_REFRESH_DENOMINATOR_MASK   (1 << 0)
+# define REFRESH_DENOMINATOR_1  (0x0)
+# define REFRESH_DENOMINATOR_1_001  (0x1)
+# define DP_TEST_INTERLACED_MASK(1 << 1)
+# define DP_NON_INTERLACED  (0x0)
+# define DP_INTERLACED  (0x1)
+
+#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 0/4] Add Automation Support for DP Compliance Testing (Rev 4)

[Manasi Navare]

This series is a rebased version of the previous series:
https://patchwork.freedesktop.org/series/16643/

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.

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_dp.c | 117 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c |   7 ++-
 drivers/gpu/drm/i915/intel_drv.h|   5 ++
 include/drm/drm_dp_helper.h |  58 ++
 5 files changed, 193 insertions(+), 8 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

[Manasi Navare]

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.

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.

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_dp.c | 67 +
 drivers/gpu/drm/i915/intel_dp_mst.c |  7 +++-
 drivers/gpu/drm/i915/intel_drv.h|  3 ++
 4 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d493978..a5959c2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3741,6 +3741,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_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 11c902e..09fa8cb 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,12 @@ 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;
+   DRM_DEBUG_KMS("Setting pipe_bpp to %d\n",
+ pipe_config->pipe_bpp);
+   }
return bpp;
 }
 
@@ -3960,6 +3968,65 @@ static uint8_t intel_dp_autotest_link_training(struct 
intel_dp *intel_dp)
 static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
 {
uint8_t test_result = DP_TEST_NAK;
+   uint8_t test_pattern;
+   uint16_t test_misc;
+   __be16 h_width, v_height;
+   int status = 0;
+
+   /* Read the TEST_PATTERN (DP CTS 3.1.5) */
+   status = drm_dp_dpcd_read(_dp->aux, DP_TEST_PATTERN,
+ _pattern, 1);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("Test pattern read failed\n");
+   return 0;
+   }
+   if (test_pattern != DP_COLOR_RAMP)
+   return test_result;
+   intel_dp->compliance.test_data.video_pattern = test_pattern;
+
+   status = drm_dp_dpcd_read(_dp->aux, DP_TEST_H_WIDTH_HI,
+ _width, 2);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("H Width read failed\n");
+   return 0;
+   }
+   intel_dp->compliance.test_data.hdisplay = be16_to_cpu(h_width);
+
+   status = drm_dp_dpcd_read(_dp->aux, DP_TEST_V_HEIGHT_HI,
+ _height, 2);
+   if (status <= 0) {
+   DRM_DEBUG_KMS("V Height read failed\n");
+   return 0;
+   }
+   intel_dp->compliance.test_data.vdisplay = be16_to_cpu(v_height);
+
+   status = drm_dp_dpcd_read(_dp->aux, 

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

[Manasi Navare]

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 01fdbbf..d493978 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3737,7 +3737,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 7a1d3c4..11c902e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3965,7 +3965,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;
 
@@ -4000,7 +4000,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

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

[Eric Anholt]

Mark Brown  writes:

> [ Unknown signature status ]
> On Tue, Jan 03, 2017 at 04:52:50PM +0100, Arnaud Pouliquen wrote:
>> Add helper to allow users to retrieve the speaker allocations without
>> knowledge of the ELD structure.
>
> 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.


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

Re: [PATCH] drm/vc4: Fix memory leak of the CRTC state.

[Eric Anholt]

Stefan Wahren  writes:

>> Hi Eric,
>>
>> could you please resend this patch [1], because it's still not applied in 
>> Linux 4.10-rc2.
>>
>> Thanks
>> Stefan
>>
>> [1] - https://patchwork.kernel.org/patch/9369793/
>
> ping ...

It's in drm-vc4-fixes now.  I just sent out two more fixes, and I should
send the -fixes PR soon.


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

[PATCH 2/2] drm/vc4: Return -EINVAL on the overflow checks failing.

[Eric Anholt]

By failing to set the errno, we'd continue on to trying to set up the
RCL, and then oops on trying to dereference the tile_bo that binning
validation should have set up.

Reported-by: Ingo Molnar 
Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
---
 drivers/gpu/drm/vc4/vc4_gem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index c5fe3554858e..ab3016982466 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -601,6 +601,7 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
  sizeof(struct vc4_shader_state)) ||
temp_size < exec_size) {
DRM_ERROR("overflow in exec arguments\n");
+   ret = -EINVAL;
goto fail;
}
 
-- 
2.11.0

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

[PATCH 1/2] drm/vc4: Fix an integer overflow in temporary allocation layout.

[Eric Anholt]

We copy the unvalidated ioctl arguments from the user into kernel
temporary memory to run the validation from, to avoid a race where the
user updates the unvalidate contents in between validating them and
copying them into the validated BO.

However, in setting up the layout of the kernel side, we failed to
check one of the additions (the roundup() for shader_rec_offset)
against integer overflow, allowing a nearly MAX_UINT value of
bin_cl_size to cause us to under-allocate the temporary space that we
then copy_from_user into.

Reported-by: Murray McAllister 
Signed-off-by: Eric Anholt 
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
---
 drivers/gpu/drm/vc4/vc4_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index db920771bfb5..c5fe3554858e 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -594,7 +594,8 @@ vc4_get_bcl(struct drm_device *dev, struct vc4_exec_info 
*exec)
  args->shader_rec_count);
struct vc4_bo *bo;
 
-   if (uniforms_offset < shader_rec_offset ||
+   if (shader_rec_offset < args->bin_cl_size ||
+   uniforms_offset < shader_rec_offset ||
exec_size < uniforms_offset ||
args->shader_rec_count >= (UINT_MAX /
  sizeof(struct vc4_shader_state)) ||
-- 
2.11.0

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

Re: [PATCH v4 0/3] Generic HDMI codec: Add channel mapping control

[Mark Brown]

On Mon, Jan 16, 2017 at 09:54:31AM +0100, Arnaud Pouliquen wrote:
> Hello,
> 
> Any comments on this patch-set?
> what about the introduction of pcm new callback in DAI ops to use chmap
> helpers?
> Is it something reasonable, or should i come back on V1?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, though there are some other maintainers who like them - if in
doubt look at how patches for the subsystem are normally handled.


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

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

[Mark Brown]

On Tue, Jan 03, 2017 at 04:52:50PM +0100, Arnaud Pouliquen wrote:
> Add helper to allow users to retrieve the speaker allocations without
> knowledge of the ELD structure.

You don't appear to have sent this to any of the DRM maintainers - it
does need review from them.


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

Re: [Intel-gfx] [PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

[Rodrigo Vivi]

On Mon, Jan 16, 2017 at 2:04 AM, Jani Nikula
 wrote:
> On Fri, 13 Jan 2017, Rodrigo Vivi  wrote:
>> This and all the remaining patches on this series (6,7,8 and 9) got
>> merged to dinq.
>
> Given that this patch series was not properly sent as a thread, I don't
> think our CI ran it as a whole, and it should not have been pushed
> before that.

I assumed "[Intel-gfx] ✓ Fi.CI.BAT: success for enable psr2 for
idle_screen on y-cordinate panel"
was enough, giving the patches haven't drastically changed after.

>
> BR,
> Jani.
>
>>
>> Thanks for the patches.
>>
>> On Thu, Jan 12, 2017 at 12:12 PM, Vivi, Rodrigo  
>> wrote:
>>> Reviewed-by: Rodrigo Vivi 
>>>
>>> On Fri, 2017-01-13 at 00:31 +0530, vathsala nagaraju wrote:
 As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
 psr2 enable sequence.
 bit 12 : Program Transcoder EDP VSC DIP header with a valid setting for
 PSR2 and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable
 header packet.
 bit 15 : Set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is supported

 v2: (Rodrigo)
 - move CHICKEN_TRANS_EDP bit set logic right after setup_vsc

 v3:(Rodrigo)
 - initialize chicken_trans to CHICKEN_TRANS_BIT12 instead of 0

 v4:(chris wilson)
 - use BIT(12), remove CHICKEN_TRANS_BIT12
 - remove unnecessary comments
 - update commit message

 v5:
 - rename bit 12 PSR2_VSC_ENABLE_PROG_HEADER
 - rename bit 15 PSR2_ADD_VERTICAL_LINE_COUNT

 v6:(Rodrigo)
 - remove TRANS_EDP=3, use cpu_transcoder

 Cc: Rodrigo Vivi 
 Cc: Jim Bride 
 Signed-off-by: vathsala nagaraju 
 Signed-off-by: Patil Deepti 
 ---
  drivers/gpu/drm/i915/i915_reg.h  | 6 ++
  drivers/gpu/drm/i915/intel_psr.c | 7 +++
  2 files changed, 13 insertions(+)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h 
 b/drivers/gpu/drm/i915/i915_reg.h
 index 7830e6e..c9c1ccd 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -6449,6 +6449,12 @@ enum {
  #define  BDW_DPRS_MASK_VBLANK_SRD(1 << 0)
  #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A, 
 _CHICKEN_PIPESL_1_B)

 +#define CHICKEN_TRANS_A 0x420c0
 +#define CHICKEN_TRANS_B 0x420c4
 +#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
 CHICKEN_TRANS_B)
 +#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
 +#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
 +
  #define DISP_ARB_CTL _MMIO(0x45000)
  #define  DISP_FBC_MEMORY_WAKE(1<<31)
  #define  DISP_TILE_SURFACE_SWIZZLING (1<<13)
 diff --git a/drivers/gpu/drm/i915/intel_psr.c 
 b/drivers/gpu/drm/i915/intel_psr.c
 index 36c4045..935402e 100644
 --- a/drivers/gpu/drm/i915/intel_psr.c
 +++ b/drivers/gpu/drm/i915/intel_psr.c
 @@ -480,6 +480,9 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
   struct drm_device *dev = intel_dig_port->base.base.dev;
   struct drm_i915_private *dev_priv = to_i915(dev);
 + struct intel_crtc *crtc = 
 to_intel_crtc(intel_dig_port->base.base.crtc);
 + enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
 + u32 chicken;

   if (!HAS_PSR(dev_priv)) {
   DRM_DEBUG_KMS("PSR not supported on this platform\n");
 @@ -505,6 +508,10 @@ void intel_psr_enable(struct intel_dp *intel_dp)
   if (HAS_DDI(dev_priv)) {
   if (dev_priv->psr.psr2_support) {
   skl_psr_setup_su_vsc(intel_dp);
 + chicken = PSR2_VSC_ENABLE_PROG_HEADER;
 + if (dev_priv->psr.y_cord_support)
 + chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
 + I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
   } else {
   /* set up vsc header for psr1 */
   hsw_psr_setup_vsc(intel_dp);
>>>
>>> ___
>>> Intel-gfx mailing list
>>> intel-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 10/12] firmware: qcom_scm: Add qcom_scm_gpu_zap_resume()

[Jordan Crouse]

On Sat, Jan 14, 2017 at 11:20:58PM -0600, Andy Gross wrote:
> + Stanimir
> 
> On Sat, Jan 14, 2017 at 09:49:01PM -0600, Andy Gross wrote:
> > On Fri, Jan 13, 2017 at 04:24:38PM -0700, Jordan Crouse wrote:
> > > On Fri, Jan 13, 2017 at 11:12:41AM -0600, Andy Gross wrote:
> > > > On Mon, Nov 28, 2016 at 12:28:35PM -0700, Jordan Crouse wrote:
> > > > > Add an interface to trigger the remote processor to reinitialize the 
> > > > > GPU
> > > > > zap shader on power-up.
> > > > > 
> > > > > Signed-off-by: Jordan Crouse 
> > > > > ---
> > > > 
> > > > 
> > > > 
> > > > > +int __qcom_scm_gpu_zap_resume(struct device *dev)
> > > > > +{
> > > > > + struct qcom_scm_desc desc = {0};
> > > > > + struct arm_smccc_res res;
> > > > > + int ret;
> > > > > +
> > > > > + desc.args[0] = 0;
> > > 
> > > This is an opcode to force the state to resume.
> > > 
> > > QCOM_SCM_BOOT_SET_STATE_RESUME perhaps?  Or something similar but shorter.
> > > 
> > > > > + desc.args[1] = 13;
> > > 
> > > This is the same as the SCM id of the GPU but I think that is a 
> > > coincidence.
> > > We've always used it to identify the GPU in this call.
> > > 
> > > QCOM_SCM_BOOT_SET_STATE_GPU would be fine here - or something similar.
> > > 
> > > > Can I get a define here for these two?  Or maybe a comment on what 
> > > > these values
> > > > are?
> > > > 
> > > > > + desc.arginfo = QCOM_SCM_ARGS(2);
> > > > > +
> > > > > + ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, 0x0A, , );
> > > > 
> > > > Same with the 0xA.  We usually throw a #define in for the command 
> > > > definitions.
> > > 
> > > 0x0A sets the state of the device - for us it is always 0 (resume) and 
> > > always
> > > the GPU.
> > > 
> > > #define  QCOM_SCM_BOOT_SET_STATE 0x0A
> > > 
> > > > Otherwise this all looks fine.  If you can get back to me with either 
> > > > the values
> > > > or a new patch I can include this in the next pull.
> > > 
> > > I'll make the changes and start the song and dance, but you'll no doubt be
> > > faster than I.
> > 
> > I can just fix up the patch with the above.  Thanks for the additional 
> > details.
> 
> The plot thickens.  So I have a patch from Stanimir concerning another SCM 
> call
> that is using the same command and number of arguments.  And it also concerns
> setting state.  I think that we need to roll a common API for setting the 
> state
> and then both of you can call it.  That way we can kill two birds with one
> stone.

I was worried about this, but not this quickly - glad to see that the other
drivers are coming along too.

If you look carefully, you'll note that the values are inverted - the video
state uses 0 to suspend and 1 to resume, and GPU uses 0 to resume and no
suspend. I asked why and got a bunch of shrugging back. Its not a big deal
because your API accounts for this but expect GPU to have a RESUME #define
that is a different value.

> Something along the lines of a function prototype:
> int qcom_scm_set_remote_state(u32 state, u32 id)
> {
>   return __qcom_scm_set_remote_state(__scm->dev, state, id);
> }
> EXPORT_SYMBOL(qcom_scm_set_remote_state);
> 
> where state is the state you want set, and id is the identifier of the remote
> proc.
>
> Does this make sense for both of your use cases?

Yep - this is fine.

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

[PATCH v2] drm: Clean up the 1366x768 fixup codes

[Takashi Iwai]

This is just a cleanup, no functional change.

The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is
basically a copy of the existing code in drm_edid.c.  Make the latter
code public so that it can be called from the former function.

Signed-off-by: Takashi Iwai 
---
v1->v2: Fix the wrong line removal of drm_mode_set_crtcinfo() call

 drivers/gpu/drm/drm_crtc_internal.h | 3 +++
 drivers/gpu/drm/drm_edid.c  | 6 +++---
 drivers/gpu/drm/drm_modes.c | 8 ++--
 3 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index cdf6860c9d22..01bde7103ad6 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -199,3 +199,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 int drm_mode_page_flip_ioctl(struct drm_device *dev,
 void *data, struct drm_file *file_priv);
+
+/* drm_edid.c */
+void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 336be31ff3de..739a19cb27d9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2152,7 +2152,7 @@ drm_dmt_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
 /* fix up 1366x768 mode from 1368x768;
  * GFT/CVT can't express 1366 width which isn't dividable by 8
  */
-static void fixup_mode_1366x768(struct drm_display_mode *mode)
+void drm_mode_fixup_1366x768(struct drm_display_mode *mode)
 {
if (mode->hdisplay == 1368 && mode->vdisplay == 768) {
mode->hdisplay = 1366;
@@ -2176,7 +2176,7 @@ drm_gtf_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
if (!newmode)
return modes;
 
-   fixup_mode_1366x768(newmode);
+   drm_mode_fixup_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing) ||
!valid_inferred_mode(connector, newmode)) {
drm_mode_destroy(dev, newmode);
@@ -2205,7 +2205,7 @@ drm_cvt_modes_for_range(struct drm_connector *connector, 
struct edid *edid,
if (!newmode)
return modes;
 
-   fixup_mode_1366x768(newmode);
+   drm_mode_fixup_1366x768(newmode);
if (!mode_in_range(newmode, edid, timing) ||
!valid_inferred_mode(connector, newmode)) {
drm_mode_destroy(dev, newmode);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e6b19bc9021a..35bb993ebc39 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1461,12 +1461,8 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
 
mode->type |= DRM_MODE_TYPE_USERDEF;
/* fix up 1368x768: GFT/CVT can't express 1366 width due to alignment */
-   if (cmd->xres == 1366 && mode->hdisplay == 1368) {
-   mode->hdisplay = 1366;
-   mode->hsync_start--;
-   mode->hsync_end--;
-   drm_mode_set_name(mode);
-   }
+   if (cmd->xres == 1366)
+   drm_mode_fixup_1366x768(mode);
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
return mode;
 }
-- 
2.11.0

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

[PATCH 3/8] drm: mali-dp: Check more use cases in the plane's ->atomic_check()

[Liviu Dudau]

Mali DP's plane ->atomic_check() only checks for the new state submitting
frame buffers with supported pixel formats and if there is enough
rotation memory for rotated planes. Add a call to
drm_plane_helper_check_state() to add additional checks for plane
state validity and clipping issues.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index d1cc15724dc3..f684fe4a80d2 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -103,8 +104,10 @@ static int malidp_de_plane_check(struct drm_plane *plane,
 {
struct malidp_plane *mp = to_malidp_plane(plane);
struct malidp_plane_state *ms = to_malidp_plane_state(state);
+   struct drm_crtc_state *crtc_state;
struct drm_framebuffer *fb;
-   int i;
+   struct drm_rect clip = { 0 };
+   int i, ret;
u32 src_w, src_h;
 
if (!state->crtc || !state->fb)
@@ -142,6 +145,16 @@ static int malidp_de_plane_check(struct drm_plane *plane,
 fb->format->format == DRM_FORMAT_BGR888))
return -EINVAL;
 
+   crtc_state = drm_atomic_get_existing_crtc_state(state->state, 
state->crtc);
+   clip.x2 = crtc_state->adjusted_mode.hdisplay;
+   clip.y2 = crtc_state->adjusted_mode.vdisplay;
+   ret = drm_plane_helper_check_state(state, ,
+  DRM_PLANE_HELPER_NO_SCALING,
+  DRM_PLANE_HELPER_NO_SCALING,
+  true, true);
+   if (ret)
+   return ret;
+
ms->rotmem_size = 0;
if (state->rotation & MALIDP_ROTATED_MASK) {
int val;
-- 
2.11.0

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

[PATCH 8/8] drm: mali-dp: Rename malidp_input_format to malidp_pixel_format

[Liviu Dudau]

From: Brian Starkey 

We're going to use the same format list for output formats, so rename
everything related to input formats to avoid confusion.

Signed-off-by: Brian Starkey 
[touched commit message to clarify the final struct name]
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_hw.c | 24 
 drivers/gpu/drm/arm/malidp_hw.h |  8 
 drivers/gpu/drm/arm/malidp_planes.c |  8 
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 4bdf531f7844..9ec6d6904f5e 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -21,7 +21,7 @@
 #include "malidp_drv.h"
 #include "malidp_hw.h"
 
-static const struct malidp_input_format malidp500_de_formats[] = {
+static const struct malidp_format_id malidp500_de_formats[] = {
/*fourcc,   layers supporting the format, internal id  */
{ DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2,  0 },
{ DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2,  1 },
@@ -69,7 +69,7 @@ static const struct malidp_input_format 
malidp500_de_formats[] = {
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) },\
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
 
-static const struct malidp_input_format malidp550_de_formats[] = {
+static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
 };
 
@@ -436,8 +436,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP500_DE_IRQ_CONF_VALID,
.vsync_irq = MALIDP500_DE_IRQ_CONF_VALID,
},
-   .input_formats = malidp500_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp500_de_formats),
+   .pixel_formats = malidp500_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp500_de_formats),
.bus_align_bytes = 8,
},
.query_hw = malidp500_query_hw,
@@ -469,8 +469,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
-   .input_formats = malidp550_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .pixel_formats = malidp550_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
.bus_align_bytes = 8,
},
.query_hw = malidp550_query_hw,
@@ -503,8 +503,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
-   .input_formats = malidp550_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .pixel_formats = malidp550_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
@@ -522,10 +522,10 @@ u8 malidp_hw_get_format_id(const struct malidp_hw_regmap 
*map,
 {
unsigned int i;
 
-   for (i = 0; i < map->n_input_formats; i++) {
-   if (((map->input_formats[i].layer & layer_id) == layer_id) &&
-   (map->input_formats[i].format == format))
-   return map->input_formats[i].id;
+   for (i = 0; i < map->n_pixel_formats; i++) {
+   if (((map->pixel_formats[i].layer & layer_id) == layer_id) &&
+   (map->pixel_formats[i].format == format))
+   return map->pixel_formats[i].id;
}
 
return MALIDP_INVALID_FORMAT_ID;
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 087e1202db3d..4f8c884d1960 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -35,7 +35,7 @@ enum {
DE_SMART = BIT(4),
 };
 
-struct malidp_input_format {
+struct malidp_format_id {
u32 format; /* DRM fourcc */
u8 layer;   /* bitmask of layers supporting it */
u8 id;  /* used internally */
@@ -85,9 +85,9 @@ struct malidp_hw_regmap {
const struct malidp_irq_map se_irq_map;
const struct malidp_irq_map dc_irq_map;
 
-   /* list of supported input formats for each layer */
-   const struct malidp_input_format *input_formats;
-   const u8 

[PATCH 1/8] drm/arm/malidp: Fix possible dereference of NULL

[Liviu Dudau]

From: Shailendra Verma 

There is possible deference of NULL pointer on return of
malidp_duplicate_plane_state() if kmalloc fails. Check the
returned kmalloc pointer before continuing.

Signed-off-by: Shailendra Verma 
[cleaned up the code and re-formatted the commit message]
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index eff2fe47e26a..d1cc15724dc3 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -67,13 +67,14 @@ drm_plane_state *malidp_duplicate_plane_state(struct 
drm_plane *plane)
return NULL;
 
state = kmalloc(sizeof(*state), GFP_KERNEL);
-   if (state) {
-   m_state = to_malidp_plane_state(plane->state);
-   __drm_atomic_helper_plane_duplicate_state(plane, >base);
-   state->rotmem_size = m_state->rotmem_size;
-   state->format = m_state->format;
-   state->n_planes = m_state->n_planes;
-   }
+   if (!state)
+   return NULL;
+
+   m_state = to_malidp_plane_state(plane->state);
+   __drm_atomic_helper_plane_duplicate_state(plane, >base);
+   state->rotmem_size = m_state->rotmem_size;
+   state->format = m_state->format;
+   state->n_planes = m_state->n_planes;
 
return >base;
 }
-- 
2.11.0

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

[PATCH 4/8] drm: mali-dp: Don't force source size == crtc size

[Liviu Dudau]

From: Brian Starkey 

Remove the check enforcing that src_w and src_h match crtc_w and crtc_h,
as this prevents rotation from working.

The check was intended to disallow scaling, but
drm_plane_helper_check_state() does that for us, while also taking
rotation into account, so the removed check was redundant in any case.

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index f684fe4a80d2..69eba71253c9 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -135,8 +135,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
if ((state->crtc_w > mp->hwdev->max_line_size) ||
(state->crtc_h > mp->hwdev->max_line_size) ||
(state->crtc_w < mp->hwdev->min_line_size) ||
-   (state->crtc_h < mp->hwdev->min_line_size) ||
-   (state->crtc_w != src_w) || (state->crtc_h != src_h))
+   (state->crtc_h < mp->hwdev->min_line_size))
return -EINVAL;
 
/* packed RGB888 / BGR888 can't be rotated or flipped */
-- 
2.11.0

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

[PATCH 7/8] drm: mali-dp: fix Lx_CONTROL register fields clobber

[Liviu Dudau]

From: Mihail Atanassov 

When updating the rotation fields, one of the assignments zeroes out the
rest of the register fields, which include settings for chroma siting,
inverse gamma, AMBA AXI caching, and alpha blending.

Signed-off-by: Mihail Atanassov 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 629f634872a4..1db8b6977efc 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -219,7 +219,8 @@ static void malidp_de_plane_update(struct drm_plane *plane,
 
/* setup the rotation and axis flip bits */
if (plane->state->rotation & DRM_ROTATE_MASK)
-   val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << 
LAYER_ROT_OFFSET;
+   val |= ilog2(plane->state->rotation & DRM_ROTATE_MASK) <<
+  LAYER_ROT_OFFSET;
if (plane->state->rotation & DRM_REFLECT_X)
val |= LAYER_H_FLIP;
if (plane->state->rotation & DRM_REFLECT_Y)
-- 
2.11.0

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

[PATCH 2/8] drm: malidp: Remove event_list member from struct malidp_drm

[Liviu Dudau]

This struct member managed to outlive the submission process without
being removed. It is useless.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 2 --
 drivers/gpu/drm/arm/malidp_drv.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 32f746e31379..080f7631c672 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -286,7 +285,6 @@ static int malidp_bind(struct device *dev)
memcpy(hwdev, of_device_get_match_data(dev), sizeof(*hwdev));
malidp->dev = hwdev;
 
-   INIT_LIST_HEAD(>event_list);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hwdev->regs = devm_ioremap_resource(dev, res);
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 9fc8a2e405e4..dbc617c6e4ef 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -15,12 +15,12 @@
 
 #include 
 #include 
+#include 
 #include "malidp_hw.h"
 
 struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_fbdev_cma *fbdev;
-   struct list_head event_list;
struct drm_crtc crtc;
wait_queue_head_t wq;
atomic_t config_valid;
-- 
2.11.0

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

[PATCH 6/8] drm: mali-dp: Fix transposed horizontal/vertical flip

[Liviu Dudau]

From: Brian Starkey 

The horizontal and vertical flip flags were the wrong way around,
causing reflect-x to result in reflect-y being applied and vice-versa.
Fix them.

Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 8c5ce36147f3..629f634872a4 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -221,9 +221,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << 
LAYER_ROT_OFFSET;
if (plane->state->rotation & DRM_REFLECT_X)
-   val |= LAYER_V_FLIP;
-   if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;
+   if (plane->state->rotation & DRM_REFLECT_Y)
+   val |= LAYER_V_FLIP;
 
/*
 * always enable pixel alpha blending until we have a way to change
-- 
2.11.0

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

[PATCH 5/8] drm: mali-dp: Fix destination size handling when rotating

[Liviu Dudau]

From: Brian Starkey 

The destination rectangle provided by userspace in the CRTC_X/Y/W/H
properties is already expressed as the dimensions after rotation.
This means we shouldn't swap the width and height ourselves when a
90/270 degree rotation is requested, so remove the code doing the swap.

Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 69eba71253c9..8c5ce36147f3 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -187,13 +187,8 @@ static void malidp_de_plane_update(struct drm_plane *plane,
/* convert src values from Q16 fixed point to integer */
src_w = plane->state->src_w >> 16;
src_h = plane->state->src_h >> 16;
-   if (plane->state->rotation & MALIDP_ROTATED_MASK) {
-   dest_w = plane->state->crtc_h;
-   dest_h = plane->state->crtc_w;
-   } else {
-   dest_w = plane->state->crtc_w;
-   dest_h = plane->state->crtc_h;
-   }
+   dest_w = plane->state->crtc_w;
+   dest_h = plane->state->crtc_h;
 
malidp_hw_write(mp->hwdev, ms->format, mp->layer->base);
 
-- 
2.11.0

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

[PATCH 0/8] drm/mali-dp: Fixes for v4.11

[Liviu Dudau]

Hello,

Here is the collected list of patches that I have accumulated since last
December in my inbox. They are offered for review and comments before
I commit them to the mali-dp tree and they get added to linux-next.

Best regards,
Liviu

Brian Starkey (4):
  drm: mali-dp: Don't force source size == crtc size
  drm: mali-dp: Fix destination size handling when rotating
  drm: mali-dp: Fix transposed horizontal/vertical flip
  drm: mali-dp: Rename malidp_input_format to malidp_pixel_format

Liviu Dudau (2):
  drm: malidp: Remove event_list member from struct malidp_drm
  drm: mali-dp: Check more use cases in the plane's ->atomic_check()

Mihail Atanassov (1):
  drm: mali-dp: fix Lx_CONTROL register fields clobber

Shailendra Verma (1):
  drm/arm/malidp: Fix possible dereference of NULL

 drivers/gpu/drm/arm/malidp_drv.c|  2 --
 drivers/gpu/drm/arm/malidp_drv.h|  2 +-
 drivers/gpu/drm/arm/malidp_hw.c | 24 
 drivers/gpu/drm/arm/malidp_hw.h |  8 +++---
 drivers/gpu/drm/arm/malidp_planes.c | 57 +
 5 files changed, 50 insertions(+), 43 deletions(-)

-- 
2.11.0

___
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

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Tuesday 17 Jan 2017 13:31:32 Neil Armstrong wrote:
> The Synopsys DesignWare HDMI TX Controller support various Transceivers
> (PHY) attached to the controller, but also allows fully custom PHYs to be
> connected.
> 
> Add PHY init, disable functions in plat_data to handle fully custom PHY
> init.
> 
> Some custom PHYs also handles the HPD and RxSense separately and do not use
> the internal signals exported in the Controller's IRQ stat, so a read_hpd
> is provided to switch to HPD status polling.
> To complete the implementation, add a function to mimic the Controllers
> interrupt HPD and RxSense handling from the vendor PHY wrapper code.

I believe this goes in the right direction. PHY handling needs to be decoupled 
from the TX controller. As you've noticed I've taken a first step in that 
direction with "drm: bridge: dw-hdmi: Refactor PHY power handling", but that's 
not enough. Issues were reported with that patch which I plan to rework. If 
that's fine with you, I'll rebase it on top of this patch (that I will likely 
modify) and plan to get the result ready for v4.12.

> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 78 +
>  include/drm/bridge/dw_hdmi.h |  8 +
>  2 files changed, 70 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 13747fe..923e250 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1434,9 +1434,18 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
> drm_display_mode *mode) hdmi_av_composer(hdmi, mode);
> 
>   /* HDMI Initializateion Step B.2 */
> - ret = dw_hdmi_phy_init(hdmi);
> - if (ret)
> - return ret;
> + if (hdmi->plat_data->hdmi_phy_init) {
> + ret = hdmi->plat_data->hdmi_phy_init(hdmi, hdmi->plat_data,
> +  >previous_mode);
> + if (ret)
> + return ret;
> +
> + hdmi->phy_enabled = true;
> + } else {
> + ret = dw_hdmi_phy_init(hdmi);
> + if (ret)
> + return ret;
> + }
> 
>   /* HDMI Initialization Step B.3 */
>   dw_hdmi_enable_video_path(hdmi);
> @@ -1551,7 +1560,11 @@ static void dw_hdmi_poweron(struct dw_hdmi *hdmi)
> 
>  static void dw_hdmi_poweroff(struct dw_hdmi *hdmi)
>  {
> - dw_hdmi_phy_disable(hdmi);
> + if (hdmi->phy_enabled && hdmi->plat_data->hdmi_phy_disable) {
> + hdmi->plat_data->hdmi_phy_disable(hdmi, hdmi->plat_data);
> + hdmi->phy_enabled = false;
> + } else
> + dw_hdmi_phy_disable(hdmi);
>   hdmi->bridge_is_on = false;
>  }
> 
> @@ -1593,6 +1606,9 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi
> *hdmi) {
>   u8 old_mask = hdmi->phy_mask;
> 
> + if (hdmi->plat_data && hdmi->plat_data->hdmi_read_hpd)
> + return;
> +
>   if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
>   hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
>   else
> @@ -1614,6 +1630,11 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi
> *hdmi) dw_hdmi_update_phy_mask(hdmi);
>   mutex_unlock(>mutex);
> 
> + if (hdmi->plat_data && hdmi->plat_data->hdmi_read_hpd)
> + return hdmi->plat_data->hdmi_read_hpd(hdmi, hdmi->plat_data) ?
> + connector_status_connected :
> + connector_status_disconnected;
> +
>   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
>   connector_status_connected : connector_status_disconnected;
>  }
> @@ -1901,6 +1922,26 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> }
>  };
> 
> +void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
> +{
> + struct dw_hdmi *hdmi = dev_get_drvdata(dev);
> +
> + mutex_lock(>mutex);
> +
> + if (!hdmi->disabled && !hdmi->force) {
> + if (!rx_sense)
> + hdmi->rxsense = false;
> +
> + if (hpd)
> + hdmi->rxsense = true;
> +
> + dw_hdmi_update_power(hdmi);
> + dw_hdmi_update_phy_mask(hdmi);
> + }
> + mutex_unlock(>mutex);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
> +
>  static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
>  {
>   unsigned int i;
> @@ -1921,7 +1962,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
>   return -ENODEV;
>   }
> 
> - if (!hdmi->phy->configure && !hdmi->plat_data->configure_phy) {
> + if (!hdmi->phy->configure &&
> + !hdmi->plat_data->configure_phy &&
> + !hdmi->plat_data->hdmi_phy_init) {
>   dev_err(hdmi->dev, "%s requires platform support\n",
>   hdmi->phy->name);
>   return -ENODEV;
> @@ -2101,15 +2144,17 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
> 

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

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Tuesday 17 Jan 2017 13:31:34 Neil Armstrong wrote:
> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
> Controller, this patch takes the pixel format from the plat_data if
> provided.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 7 +--
>  include/drm/bridge/dw_hdmi.h | 9 +
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 8a6a183..fa4147c 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1420,8 +1420,11 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
> drm_display_mode *mode) hdmi->hdmi_data.video_mode.mpixelrepetitionoutput =
> 0;
>   hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
> 
> - /* TODO: Get input format from IPU (via FB driver interface) */
> - hdmi->hdmi_data.enc_in_format = RGB;
> + /* Get input format from plat data or fallback to RGB */
> + if (hdmi->plat_data->input_fmt >= 0)
> + hdmi->hdmi_data.enc_in_format = hdmi->plat_data->input_fmt;
> + else
> + hdmi->hdmi_data.enc_in_format = RGB;

This should ideally be queried dynamically. I believe we need to extend the 
DRM bridge API for this purpose. I might be willing to accept a pdata-based 
solution in the meantime though.

>   hdmi->hdmi_data.enc_out_format = RGB;
> 
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index d6a0ab3..4f426c3 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -21,6 +21,14 @@ enum {
>   DW_HDMI_RES_MAX,
>  };
> 
> +enum {
> + DW_HDMI_INPUT_FMT_RGB = 0,
> + DW_HDMI_INPUT_FMT_YCBCR444,
> + DW_HDMI_INPUT_FMT_YCBCR422_16BITS,
> + DW_HDMI_INPUT_FMT_YCBCR422_8BITS,
> + DW_HDMI_INPUT_FMT_XVYCC444,
> +};

How about giving the enum a name and dropping the

#define RGB 0
#define YCBCR4441
#define YCBCR422_16BITS 2
#define YCBCR422_8BITS  3
#define XVYCC4444

macros from the driver ? Even better, how about using a media bus format code 
from include/uapi/linux/media-bus-format.h ? We would need an additional 
colorspace field to express the difference between the YCBCR and XVYCC 
formats, as both of them are YUV 4:4:4 and map to the same bus format.

>  enum dw_hdmi_phy_type {
>   DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
>   DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
> @@ -68,6 +76,7 @@ struct dw_hdmi_plat_data {
>const struct dw_hdmi_plat_data *data);
>   bool (*hdmi_read_hpd)(struct dw_hdmi *hdmi,
> const struct dw_hdmi_plat_data *data);
> + int input_fmt;
>  };
> 
>  int dw_hdmi_probe(struct platform_device *pdev,

-- 
Regards,

Laurent Pinchart

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

Re: [RFC/RFT PATCH 3/4] drm/bridge: dw-hdmi: Enable CSC even for DVI

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Tuesday 17 Jan 2017 13:31:33 Neil Armstrong wrote:
> If the input pixel format is not RGB, the CSC must be enabled in order to
> provide valid pixel to DVI sinks.
> This patch removes the hdmi only dependency on the CSC enabling.
> 
> Signed-off-by: Neil Armstrong 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index 923e250..8a6a183 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1331,8 +1331,8 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi
> *hdmi) hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
>   }
> 
> - /* Enable color space conversion if needed (for HDMI sinks only). */
> - if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
> + /* Enable color space conversion if needed */
> + if (is_color_space_conversion(hdmi))
>   hdmi_writeb(hdmi, 
HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
>   HDMI_MC_FLOWCTRL);
>   else

-- 
Regards,

Laurent Pinchart

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

Re: [RFC/RFT PATCH 1/4] drm/bridge: dw-hdmi: Switch to regmap for register access

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Tuesday 17 Jan 2017 13:31:31 Neil Armstrong wrote:
> The Synopsys Designware HDMI TX Controller does not enforce register access
> on platforms instanciating it.
> The current driver supports two different types of memory-mapped flat
> register access, but in order to support the Amlogic Meson SoCs integration,
> and provide a more generic way to handle all sorts of register mapping,
> switch the register access to use the regmap infrastructure.
> 
> In the case of the registers are not flat memory-mapped or does not conform

s/does/do/

> at the actual driver implementation, a regmap struct can be given in the

s/at the actual/to the current/ ?

> plat_data and be used at probe or bind.
> 
> Since the AHB audio driver only uses direct memory access, using regmap only
> allows the I2S audio driver to be registered.

This sounds a bit unclear to me, how about "[...], only allow the I2C audio 
driver to be registered if the device is directly memory-mapped." ?

> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.c | 105 +++-
>  include/drm/bridge/dw_hdmi.h |   1 +
>  2 files changed, 57 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c index ca9d0ce..13747fe 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Could you please keep the headers alphabetically sorted ?

>  #include 
>  #include 
> @@ -167,8 +168,7 @@ struct dw_hdmi {
>   unsigned int audio_n;
>   bool audio_enable;
> 
> - void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
> - u8 (*read)(struct dw_hdmi *hdmi, int offset);
> + struct regmap *regm;
>  };
> 
>  #define HDMI_IH_PHY_STAT0_RX_SENSE \
> @@ -179,42 +179,23 @@ struct dw_hdmi {
>   (HDMI_PHY_RX_SENSE0 | HDMI_PHY_RX_SENSE1 | \
>HDMI_PHY_RX_SENSE2 | HDMI_PHY_RX_SENSE3)
> 
> -static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
> -{
> - writel(val, hdmi->regs + (offset << 2));
> -}
> -
> -static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
> -{
> - return readl(hdmi->regs + (offset << 2));
> -}
> -
> -static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
> -{
> - writeb(val, hdmi->regs + offset);
> -}
> -
> -static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
> -{
> - return readb(hdmi->regs + offset);
> -}
> -
>  static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)

Not related to this patch, but the value, offset order of arguments to the 
write function has been making me cringe since the very first time I read the 
code. I wonder if modifying this would be accepted.

>  {
> - hdmi->write(hdmi, val, offset);
> + regmap_write(hdmi->regm, offset, val);
>  }
> 
>  static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
>  {
> - return hdmi->read(hdmi, offset);
> + unsigned int val = 0;
> +
> + regmap_read(hdmi->regm, offset, );
> +
> + return val;
>  }
> 
>  static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
> {
> - u8 val = hdmi_readb(hdmi, reg) & ~mask;
> -
> - val |= data & mask;
> - hdmi_writeb(hdmi, val, reg);
> + regmap_update_bits(hdmi->regm, reg, mask, data);
>  }
> 
>  static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int
> reg, @@ -1949,6 +1930,21 @@ static int dw_hdmi_detect_phy(struct dw_hdmi
> *hdmi) return 0;
>  }
> 
> +static struct regmap_config hdmi_regmap_8bit_config = {
> + .reg_bits   = 32,
> + .val_bits   = 8,
> + .reg_stride = 1,
> + .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR,
> +};
> +
> +static struct regmap_config hdmi_regmap_32bit_config = {
> + .reg_bits   = 8,
> + .pad_bits   = 24,
> + .val_bits   = 32,
> + .reg_stride = 4,
> + .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR,
> +};

I believe you can make these const.

>  static struct dw_hdmi *
>  __dw_hdmi_probe(struct platform_device *pdev,
>   const struct dw_hdmi_plat_data *plat_data)
> @@ -1958,7 +1954,8 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
>   struct platform_device_info pdevinfo;
>   struct device_node *ddc_node;
>   struct dw_hdmi *hdmi;
> - struct resource *iores;
> + struct regmap_config *reg_config = _regmap_8bit_config;

No need to assign a value at declaration time (unless the compiler is not 
smart enough and complains, or is smarter than me and finds a problem where I 
don't).

> + struct resource *iores = NULL;
>   int irq;
>   int ret;
>   u32 val = 1;
> @@ -1982,20 +1979,21 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
>   mutex_init(>audio_mutex);
>   spin_lock_init(>audio_lock);
> 
> - of_property_read_u32(np, "reg-io-width", );
> -
> - 

Re: [PATCH] drm/exynos: g2d: fix overflow of cmdlist size

[Tobias Jakobi]

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

With best wishes,
Tobias


> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index fbd13fa..b31244f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1250,7 +1250,14 @@ int exynos_g2d_set_cmdlist_ioctl(struct drm_device 
> *drm_dev, void *data,
>   cmdlist->data[cmdlist->last++] = G2D_INTEN_ACF;
>   }
>  
> - /* Check size of cmdlist: last 2 is about G2D_BITBLT_START */
> + /* Check size of cmd and cmdlist: last 2 is about G2D_BITBLT_START */
> + size = (G2D_CMDLIST_DATA_NUM - cmdlist->last - 2) / 2;
> + if (req->cmd_nr > size || req->cmd_buf_nr > size) {
> + dev_err(dev, "size of cmd or cmd_buf is too big\n");
> + ret = -EINVAL;
> + goto err_free_event;
> + }
> +
>   size = cmdlist->last + req->cmd_nr * 2 + req->cmd_buf_nr * 2 + 2;
>   if (size > G2D_CMDLIST_DATA_NUM) {
>   dev_err(dev, "cmdlist size is too big\n");
> 

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

[PATCH 0/3] Fix DECON_UPDATE for TV

[Andrzej Hajda]

Hi Inki,

This is my final fight with DECON_UPDATE issues (I hope). My two previous 
patches
fixed problems on panel path, this patchset fixes also TV path.
The root cause of all evil was in incorrect DECON_CMU programming.

Now it works correctly on:
- panel,
- TV,
- both.
I have not observed (so far) IOMMU faults, or vblank timeouts.

Regards
Andrzej


Andrzej Hajda (3):
  drm/exynos/decon5433: do not disable video after reset
  drm/exynos/decon5433: fix CMU programming
  drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

-- 
2.7.4

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

[PATCH 3/3] drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement

[Andrzej Hajda]

DECON_TV requires STANDALONE_UPDATE after output enabling, otherwise it does
not start. This change is neutral for DECON.

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

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 9f4d60d..bcb190f 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -198,6 +198,8 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
 
/* enable output and display signal */
decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
+
+   decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
 }
 
 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
-- 
2.7.4

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

[PATCH 2/3] drm/exynos/decon5433: fix CMU programming

[Andrzej Hajda]

DECON_CMU register has reserved bits which should not be zeroed, otherwise
IP can behave strangely and cause IOMMU faults.

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

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 6fd2b11..9f4d60d 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -158,10 +158,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
m->crtc_vsync_end = m->crtc_vsync_start + 1;
}
 
-   /* enable clock gate */
-   val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
-   writel(val, ctx->addr + DECON_CMU);
-
decon_setup_trigger(ctx);
 
/* lcd on and use command if */
-- 
2.7.4

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

[PATCH 1/3] drm/exynos/decon5433: do not disable video after reset

[Andrzej Hajda]

decon_commit is called just after reset so video is disabled anyway.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 634cfd7..6fd2b11 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -158,8 +158,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
m->crtc_vsync_end = m->crtc_vsync_start + 1;
}
 
-   decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID, 0);
-
/* enable clock gate */
val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
writel(val, ctx->addr + DECON_CMU);
-- 
2.7.4

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

[PATCH v2 1/2] drm: qxl: Open code probing sequence for qxl

[Gabriel Krisman Bertazi]

This avoids using the deprecated drm_get_pci_dev() and load() hook
interfaces in the qxl driver.

The only tricky part is to ensure TTM debugfs initialization happens
after the debugfs root node is created, which is done by moving that
code into the debufs_init() hook.

Tested on qemu with igt and running a WM on top of X.

Changes since v1:
 - Drop verification for primary minor in qxl_debugsfs_init

Signed-off-by: Gabriel Krisman Bertazi 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Gustavo Padovan 
---
 drivers/gpu/drm/qxl/qxl_debugfs.c | 10 +++
 drivers/gpu/drm/qxl/qxl_drv.c | 58 +--
 drivers/gpu/drm/qxl/qxl_drv.h |  7 -
 drivers/gpu/drm/qxl/qxl_kms.c | 40 ++-
 drivers/gpu/drm/qxl/qxl_ttm.c |  8 +-
 5 files changed, 75 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c 
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index 241af9131dc8..057b2b547cac 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -84,8 +84,18 @@ int
 qxl_debugfs_init(struct drm_minor *minor)
 {
 #if defined(CONFIG_DEBUG_FS)
+   int r;
+   struct qxl_device *dev =
+   (struct qxl_device *) minor->dev->dev_private;
+
drm_debugfs_create_files(qxl_debugfs_list, QXL_DEBUGFS_ENTRIES,
 minor->debugfs_root, minor);
+
+   r = qxl_ttm_debugfs_init(dev);
+   if (r) {
+   DRM_ERROR("Failed to init TTM debugfs\n");
+   return r;
+   }
 #endif
return 0;
 }
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 460bbceae297..7cc29027a612 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -62,12 +62,67 @@ static struct pci_driver qxl_pci_driver;
 static int
 qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
+   struct drm_device *drm;
+   struct qxl_device *qdev;
+   int ret;
+
if (pdev->revision < 4) {
DRM_ERROR("qxl too old, doesn't support client_monitors_config,"
  " use xf86-video-qxl in user mode");
return -EINVAL; /* TODO: ENODEV ? */
}
-   return drm_get_pci_dev(pdev, ent, _driver);
+
+   drm = drm_dev_alloc(_driver, >dev);
+   if (IS_ERR(drm))
+   return -ENOMEM;
+
+   qdev = kzalloc(sizeof(struct qxl_device), GFP_KERNEL);
+   if (!qdev) {
+   ret = -ENOMEM;
+   goto free_drm_device;
+   }
+
+   ret = pci_enable_device(pdev);
+   if (ret)
+   goto free_drm_device;
+
+   drm->pdev = pdev;
+   pci_set_drvdata(pdev, drm);
+   drm->dev_private = qdev;
+
+   ret = qxl_device_init(qdev, drm, pdev, ent->driver_data);
+   if (ret)
+   goto disable_pci;
+
+   ret = drm_vblank_init(drm, 1);
+   if (ret)
+   goto unload;
+
+   ret = qxl_modeset_init(qdev);
+   if (ret)
+   goto vblank_cleanup;
+
+   drm_kms_helper_poll_init(qdev->ddev);
+
+   /* Complete initialization. */
+   ret = drm_dev_register(drm, ent->driver_data);
+   if (ret)
+   goto modeset_cleanup;
+
+   return 0;
+
+modeset_cleanup:
+   qxl_modeset_fini(qdev);
+vblank_cleanup:
+   drm_vblank_cleanup(drm);
+unload:
+   qxl_device_fini(qdev);
+disable_pci:
+   pci_disable_device(pdev);
+free_drm_device:
+   kfree(qdev);
+   kfree(drm);
+   return ret;
 }
 
 static void
@@ -230,7 +285,6 @@ static struct pci_driver qxl_pci_driver = {
 static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
-   .load = qxl_driver_load,
.unload = qxl_driver_unload,
.get_vblank_counter = qxl_noop_get_vblank_counter,
.enable_vblank = qxl_noop_enable_vblank,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 883d8639c04e..d0aed9ed12d2 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -336,7 +336,10 @@ __printf(2,3) void qxl_io_log(struct qxl_device *qdev, 
const char *fmt, ...);
 extern const struct drm_ioctl_desc qxl_ioctls[];
 extern int qxl_max_ioctl;
 
-int qxl_driver_load(struct drm_device *dev, unsigned long flags);
+int qxl_device_init(struct qxl_device *qdev, struct drm_device *ddev,
+   struct pci_dev *pdev,  unsigned long flags);
+void qxl_device_fini(struct qxl_device *qdev);
+
 void qxl_driver_unload(struct drm_device *dev);
 
 int qxl_modeset_init(struct qxl_device *qdev);
@@ -345,6 +348,8 @@ void qxl_modeset_fini(struct qxl_device *qdev);
 int qxl_bo_init(struct qxl_device *qdev);
 void qxl_bo_fini(struct qxl_device *qdev);
 
+int qxl_ttm_debugfs_init(struct qxl_device 

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

[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(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 7cc29027a612..6e0f8a2d8ac9 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -129,8 +129,16 @@ static void
 qxl_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
+   struct qxl_device *qdev = dev->dev_private;
+
+   drm_dev_unregister(dev);
+
+   qxl_modeset_fini(qdev);
+   qxl_device_fini(qdev);
 
-   drm_put_dev(dev);
+   dev->dev_private = NULL;
+   kfree(qdev);
+   drm_dev_unref(dev);
 }
 
 static const struct file_operations qxl_fops = {
@@ -285,7 +293,6 @@ static struct pci_driver qxl_pci_driver = {
 static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
-   .unload = qxl_driver_unload,
.get_vblank_counter = qxl_noop_get_vblank_counter,
.enable_vblank = qxl_noop_enable_vblank,
.disable_vblank = qxl_noop_disable_vblank,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index d0aed9ed12d2..458501534313 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -340,8 +340,6 @@ int qxl_device_init(struct qxl_device *qdev, struct 
drm_device *ddev,
struct pci_dev *pdev,  unsigned long flags);
 void qxl_device_fini(struct qxl_device *qdev);
 
-void qxl_driver_unload(struct drm_device *dev);
-
 int qxl_modeset_init(struct qxl_device *qdev);
 void qxl_modeset_fini(struct qxl_device *qdev);
 
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 6848057d0917..d0666f5dccd6 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -284,19 +284,3 @@ void qxl_device_fini(struct qxl_device *qdev)
qdev->mode_info.num_modes = 0;
qxl_debugfs_remove_files(qdev);
 }
-
-void qxl_driver_unload(struct drm_device *dev)
-{
-   struct qxl_device *qdev = dev->dev_private;
-
-   if (qdev == NULL)
-   return;
-
-   drm_vblank_cleanup(dev);
-
-   qxl_modeset_fini(qdev);
-   qxl_device_fini(qdev);
-
-   kfree(qdev);
-   dev->dev_private = NULL;
-}
-- 
2.11.0

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

Re: [PATCH 2/3] drm: qxl: Open code probing sequence for qxl

[Gabriel Krisman Bertazi]

Gustavo Padovan  writes:

> I'm not confortable with exposing minor->type here and making qxl
> the first driver to use it outside of drm core. Don't we have any other
> way. 
>
> I see that inside qxl_debugfs_add_files() we have a check for already
> registered files. Wouldn't that or some modification around work for
> this?

Thanks for your review, Gustavo.

As I mentioned on IRC, I verified the check is not needed at all,
since qxl only implements one minor.  I'll resend without this bit.

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

[Bug 99292] GPU hang in High Fidelity

[bugzilla-daemon]

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

--- Comment #4 from Christoph Haag  ---
Someone said that with mesa with --enable-debug it runs in an assert before the
gpu hang happens, so I tried it to add it to the bug report, but this did not
happen for me. I get no assert and the GPU still hangs with --enable-debug.

Just an idea, since High Fidelity has had the other known application side
rendering bug, it's possible there is a buggy shader that the compiler doesn't
catch.

-- 
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 1/3] drm: qxl: Let DRM core handle connector registering

[Gustavo Padovan]

Hi Gabriel,

2017-01-12 Gabriel Krisman Bertazi :

> Registering the connector explicitly right after creation is not
> necessary for modesetting drivers, because drm_dev_register already takes
> care of this on the core side, by calling drm_modeset_register_all.
> 
> In addition, performing the initialization too early will get in the way
> of the load() hook removal, because the connector interface cannot be
> published prior to registering the minors.
> 
> Signed-off-by: Gabriel Krisman Bertazi 
> CC: Dave Airlie 
> CC: Daniel Vetter 
> CC: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 1 -
>  1 file changed, 1 deletion(-)

Applied to drm-misc-next. Thanks for the patch.

Gustavo

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

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

[Neil Armstrong]

The Synopsys DesignWare HDMI TX Controller support various Transceivers (PHY)
attached to the controller, but also allows fully custom PHYs to be connected.

Add PHY init, disable functions in plat_data to handle fully custom PHY init.

Some custom PHYs also handles the HPD and RxSense separately and do not use
the internal signals exported in the Controller's IRQ stat, so a read_hpd
is provided to switch to HPD status polling.
To complete the implementation, add a function to mimic the Controllers
interrupt HPD and RxSense handling from the vendor PHY wrapper code.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 78 +++-
 include/drm/bridge/dw_hdmi.h |  8 +
 2 files changed, 70 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 13747fe..923e250 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1434,9 +1434,18 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
hdmi_av_composer(hdmi, mode);
 
/* HDMI Initializateion Step B.2 */
-   ret = dw_hdmi_phy_init(hdmi);
-   if (ret)
-   return ret;
+   if (hdmi->plat_data->hdmi_phy_init) {
+   ret = hdmi->plat_data->hdmi_phy_init(hdmi, hdmi->plat_data,
+>previous_mode);
+   if (ret)
+   return ret;
+
+   hdmi->phy_enabled = true;
+   } else {
+   ret = dw_hdmi_phy_init(hdmi);
+   if (ret)
+   return ret;
+   }
 
/* HDMI Initialization Step B.3 */
dw_hdmi_enable_video_path(hdmi);
@@ -1551,7 +1560,11 @@ static void dw_hdmi_poweron(struct dw_hdmi *hdmi)
 
 static void dw_hdmi_poweroff(struct dw_hdmi *hdmi)
 {
-   dw_hdmi_phy_disable(hdmi);
+   if (hdmi->phy_enabled && hdmi->plat_data->hdmi_phy_disable) {
+   hdmi->plat_data->hdmi_phy_disable(hdmi, hdmi->plat_data);
+   hdmi->phy_enabled = false;
+   } else
+   dw_hdmi_phy_disable(hdmi);
hdmi->bridge_is_on = false;
 }
 
@@ -1593,6 +1606,9 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
 {
u8 old_mask = hdmi->phy_mask;
 
+   if (hdmi->plat_data && hdmi->plat_data->hdmi_read_hpd)
+   return;
+
if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
else
@@ -1614,6 +1630,11 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
dw_hdmi_update_phy_mask(hdmi);
mutex_unlock(>mutex);
 
+   if (hdmi->plat_data && hdmi->plat_data->hdmi_read_hpd)
+   return hdmi->plat_data->hdmi_read_hpd(hdmi, hdmi->plat_data) ?
+   connector_status_connected :
+   connector_status_disconnected;
+
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
 }
@@ -1901,6 +1922,26 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
}
 };
 
+void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
+{
+   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
+
+   mutex_lock(>mutex);
+
+   if (!hdmi->disabled && !hdmi->force) {
+   if (!rx_sense)
+   hdmi->rxsense = false;
+
+   if (hpd)
+   hdmi->rxsense = true;
+
+   dw_hdmi_update_power(hdmi);
+   dw_hdmi_update_phy_mask(hdmi);
+   }
+   mutex_unlock(>mutex);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
+
 static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
 {
unsigned int i;
@@ -1921,7 +1962,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
return -ENODEV;
}
 
-   if (!hdmi->phy->configure && !hdmi->plat_data->configure_phy) {
+   if (!hdmi->phy->configure &&
+   !hdmi->plat_data->configure_phy &&
+   !hdmi->plat_data->hdmi_phy_init) {
dev_err(hdmi->dev, "%s requires platform support\n",
hdmi->phy->name);
return -ENODEV;
@@ -2101,15 +2144,17 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
hdmi->ddc = NULL;
}
 
-   /*
-* Configure registers related to HDMI interrupt
-* generation before registering IRQ.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+   if (!hdmi->plat_data || !hdmi->plat_data->hdmi_read_hpd) {
+   /*
+* Configure registers related to HDMI interrupt
+* generation before registering IRQ.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, 
HDMI_PHY_POL0);
 
-   /* Clear Hotplug interrupts */
-   

[RFC/RFT PATCH 3/4] drm/bridge: dw-hdmi: Enable CSC even for DVI

[Neil Armstrong]

If the input pixel format is not RGB, the CSC must be enabled in order to
provide valid pixel to DVI sinks.
This patch removes the hdmi only dependency on the CSC enabling.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 923e250..8a6a183 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1331,8 +1331,8 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi 
*hdmi)
hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
}
 
-   /* Enable color space conversion if needed (for HDMI sinks only). */
-   if (hdmi->sink_is_hdmi && is_color_space_conversion(hdmi))
+   /* Enable color space conversion if needed */
+   if (is_color_space_conversion(hdmi))
hdmi_writeb(hdmi, HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_IN_PATH,
HDMI_MC_FLOWCTRL);
else
-- 
1.9.1

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

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

[Neil Armstrong]

Some display pipelines can only provide non-RBG input pixels to the HDMI TX
Controller, this patch takes the pixel format from the plat_data if provided.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 7 +--
 include/drm/bridge/dw_hdmi.h | 9 +
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 8a6a183..fa4147c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1420,8 +1420,11 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0;
hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
 
-   /* TODO: Get input format from IPU (via FB driver interface) */
-   hdmi->hdmi_data.enc_in_format = RGB;
+   /* Get input format from plat data or fallback to RGB */
+   if (hdmi->plat_data->input_fmt >= 0)
+   hdmi->hdmi_data.enc_in_format = hdmi->plat_data->input_fmt;
+   else
+   hdmi->hdmi_data.enc_in_format = RGB;
 
hdmi->hdmi_data.enc_out_format = RGB;
 
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index d6a0ab3..4f426c3 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -21,6 +21,14 @@ enum {
DW_HDMI_RES_MAX,
 };
 
+enum {
+   DW_HDMI_INPUT_FMT_RGB = 0,
+   DW_HDMI_INPUT_FMT_YCBCR444,
+   DW_HDMI_INPUT_FMT_YCBCR422_16BITS,
+   DW_HDMI_INPUT_FMT_YCBCR422_8BITS,
+   DW_HDMI_INPUT_FMT_XVYCC444,
+};
+
 enum dw_hdmi_phy_type {
DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
@@ -68,6 +76,7 @@ struct dw_hdmi_plat_data {
 const struct dw_hdmi_plat_data *data);
bool (*hdmi_read_hpd)(struct dw_hdmi *hdmi,
  const struct dw_hdmi_plat_data *data);
+   int input_fmt;
 };
 
 int dw_hdmi_probe(struct platform_device *pdev,
-- 
1.9.1

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

[RFC/RFT PATCH 0/4] drm/bridge: dw-hdmi: Add support for Custom PHYs

[Neil Armstrong]

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
in combination with a very custom PHY.

Thanks to Laurent Pinchart's changes, the HW report the following :
 Detected HDMI TX controller v2.01a with HDCP (Vendor PHY)

The following differs from common PHY integration as managed in the current
driver :
 - Amlogic PHY is not configured through the internal I2C link
 - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the 
controller
 - Amlogic PHY do not export HPD ands RxSense signals to the controller

And finally, concerning the controller integration :
 - the Controller registers are not flat memory-mapped, and uses an
addr+read/write register pair to write all registers.
 - Inputs only YUV444 pixel data

This is why the following patchset implements :
 - Conversion to regmap for register access
 - Add more callbacks ops to handle Custom PHYs
 - Configure the Input format from the plat_data
 - Fixes a bug that considers the input to be always RBG and sends bad pixel
   format to a DVI sink by disabling CSC

This patchset makes the Amlogix GX SoCs HDMI output successfully work, but I
do not have access to Renesas, i.MX or RockChip SoCs to test against
potentiel regressions, like the regmap conversion.

This patchset is based on the latest Laurent Pinchart dw-hdmi serie at [1].

[1] 
http://lkml.kernel.org/r/20170117082910.27023-1-laurent.pinchart+rene...@ideasonboard.com

Neil Armstrong (4):
  drm/bridge: dw-hdmi: Switch to regmap for register access
  drm/bridge: dw-hdmi: Add support for custom PHY handling
  drm/bridge: dw-hdmi: Enable CSC even for DVI
  drm/bridge: dw-hdmi: Take input format from plat_data

 drivers/gpu/drm/bridge/dw-hdmi.c | 194 +--
 include/drm/bridge/dw_hdmi.h |  18 
 2 files changed, 143 insertions(+), 69 deletions(-)

-- 
1.9.1

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

[RFC/RFT PATCH 1/4] drm/bridge: dw-hdmi: Switch to regmap for register access

[Neil Armstrong]

The Synopsys Designware HDMI TX Controller does not enforce register access
on platforms instanciating it.
The current driver supports two different types of memory-mapped flat
register access, but in order to support the Amlogic Meson SoCs integration,
and provide a more generic way to handle all sorts of register mapping,
switch the register access to use the regmap infrastructure.

In the case of the registers are not flat memory-mapped or does not conform
at the actual driver implementation, a regmap struct can be given in the
plat_data and be used at probe or bind.

Since the AHB audio driver only uses direct memory access, using regmap only
allows the I2S audio driver to be registered.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 105 +--
 include/drm/bridge/dw_hdmi.h |   1 +
 2 files changed, 57 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ca9d0ce..13747fe 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -167,8 +168,7 @@ struct dw_hdmi {
unsigned int audio_n;
bool audio_enable;
 
-   void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
-   u8 (*read)(struct dw_hdmi *hdmi, int offset);
+   struct regmap *regm;
 };
 
 #define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -179,42 +179,23 @@ struct dw_hdmi {
(HDMI_PHY_RX_SENSE0 | HDMI_PHY_RX_SENSE1 | \
 HDMI_PHY_RX_SENSE2 | HDMI_PHY_RX_SENSE3)
 
-static void dw_hdmi_writel(struct dw_hdmi *hdmi, u8 val, int offset)
-{
-   writel(val, hdmi->regs + (offset << 2));
-}
-
-static u8 dw_hdmi_readl(struct dw_hdmi *hdmi, int offset)
-{
-   return readl(hdmi->regs + (offset << 2));
-}
-
-static void dw_hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
-{
-   writeb(val, hdmi->regs + offset);
-}
-
-static u8 dw_hdmi_readb(struct dw_hdmi *hdmi, int offset)
-{
-   return readb(hdmi->regs + offset);
-}
-
 static inline void hdmi_writeb(struct dw_hdmi *hdmi, u8 val, int offset)
 {
-   hdmi->write(hdmi, val, offset);
+   regmap_write(hdmi->regm, offset, val);
 }
 
 static inline u8 hdmi_readb(struct dw_hdmi *hdmi, int offset)
 {
-   return hdmi->read(hdmi, offset);
+   unsigned int val = 0;
+
+   regmap_read(hdmi->regm, offset, );
+
+   return val;
 }
 
 static void hdmi_modb(struct dw_hdmi *hdmi, u8 data, u8 mask, unsigned reg)
 {
-   u8 val = hdmi_readb(hdmi, reg) & ~mask;
-
-   val |= data & mask;
-   hdmi_writeb(hdmi, val, reg);
+   regmap_update_bits(hdmi->regm, reg, mask, data);
 }
 
 static void hdmi_mask_writeb(struct dw_hdmi *hdmi, u8 data, unsigned int reg,
@@ -1949,6 +1930,21 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
return 0;
 }
 
+static struct regmap_config hdmi_regmap_8bit_config = {
+   .reg_bits   = 32,
+   .val_bits   = 8,
+   .reg_stride = 1,
+   .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR,
+};
+
+static struct regmap_config hdmi_regmap_32bit_config = {
+   .reg_bits   = 8,
+   .pad_bits   = 24,
+   .val_bits   = 32,
+   .reg_stride = 4,
+   .max_register   = HDMI_I2CM_FS_SCL_LCNT_0_ADDR,
+};
+
 static struct dw_hdmi *
 __dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
@@ -1958,7 +1954,8 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
struct dw_hdmi *hdmi;
-   struct resource *iores;
+   struct regmap_config *reg_config = _regmap_8bit_config;
+   struct resource *iores = NULL;
int irq;
int ret;
u32 val = 1;
@@ -1982,20 +1979,21 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
mutex_init(>audio_mutex);
spin_lock_init(>audio_lock);
 
-   of_property_read_u32(np, "reg-io-width", );
-
-   switch (val) {
-   case 4:
-   hdmi->write = dw_hdmi_writel;
-   hdmi->read = dw_hdmi_readl;
-   break;
-   case 1:
-   hdmi->write = dw_hdmi_writeb;
-   hdmi->read = dw_hdmi_readb;
-   break;
-   default:
-   dev_err(dev, "reg-io-width must be 1 or 4\n");
-   return ERR_PTR(-EINVAL);
+   if (plat_data->regm)
+   hdmi->regm = plat_data->regm;
+   else {
+   of_property_read_u32(np, "reg-io-width", );
+   switch (val) {
+   case 4:
+   reg_config = _regmap_32bit_config;
+   break;
+   case 1:
+   reg_config = _regmap_8bit_config;
+   break;
+   default:
+   dev_err(dev, "reg-io-width must be 1 or 4\n");
+ 

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

[bugzilla-daemon]

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

--- Comment #147 from John Boero  ---
Would love to see this get pushed through.  Frustrating having to manually
build kernels each release.  It looks like history of the Fedora kernels has
this being disabled and re-enabled by default a few times.  Much easier to
blacklist a module than have to build a whole new kernel every time.  My $0.02

-- 
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 11/11] drm/rockchip/dsi: fix insufficient bandwidth of some panel

[John Keeping]

On Tue, 17 Jan 2017 17:31:53 +0800, Chris Zhong wrote:

> On 01/16/2017 08:44 PM, John Keeping wrote:
> > On Mon, 16 Jan 2017 18:08:31 +0800, Chris Zhong wrote:
> >  
> >> Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
> >> for some panel, it will cause the screen display is not normal, so
> >> increases the badnwidth to 1 / 0.8.
> >>
> >> Signed-off-by: Chris Zhong 
> >>
> >> ---
> >>
> >>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> >> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> index 9dfa73d..5a973fe 100644
> >> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> @@ -501,8 +501,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> >> *dsi)
> >>   
> >>mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);
> >>if (mpclk) {
> >> -  /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> >> -  tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
> >> +  /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> >> +  tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;  
> > This and patch 9 are just hacking around the underlying problem in order
> > to make particular panels work.  I'm pretty sure the actual issue is the
> > use of hardcoded values when configuring the PHY, since the PHY
> > parameters are specified in clock cycles but the MIPI spec requires
> > absolute time durations.
> >
> > I posted a series addressing this a while ago, although I screwed up
> > sending it so some patches were included twice and since no one
> > expressed any interest I didn't post a cleaned up version.
> >
> > The relevant patch is here:
> >
> > https://patchwork.kernel.org/patch/9340193/  
> 
> Thanks very much, your patches are very useful for me. It looks your 
> method is correct.
> And I am very confused why Mark Yao and me did not receive your patches 
> before,
> although we have subscribed the .
> 
> In addition, could you tell me which device ware you testing with these 
> mipi patches.
> I going to test them these day.

I'm using RK3288 and I tested my patches with three different MIPI
displays, two of which require commands to be sent in order to set up
the panel.

Thanks for testing the patches.


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

Re: [01/26] drm/rockchip: dw-mipi-dsi: use mode from display state

[Chris Zhong]

On 09/20/2016 01:17 AM, John Keeping wrote:

There is no need to keep a pointer to the mode around since we know it
will be present in the connector state.

Signed-off-by: John Keeping 
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index ca22e5ee89ca..a87037556f5c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -286,7 +286,6 @@ struct dw_mipi_dsi {
u32 format;
u16 input_div;
u16 feedback_div;
-   struct drm_display_mode *mode;
  
  	const struct dw_mipi_dsi_plat_data *pdata;

  };
@@ -332,9 +331,10 @@ static int max_mbps_to_testdin(unsigned int max_mbps)
   */
  static void dw_mipi_dsi_wait_for_two_frames(struct dw_mipi_dsi *dsi)
  {
+   struct drm_display_mode *mode = 
>connector.state->crtc->state->adjusted_mode;
int refresh, two_frames;
  
-	refresh = drm_mode_vrefresh(dsi->mode);

+   refresh = drm_mode_vrefresh(mode);
two_frames = DIV_ROUND_UP(MSEC_PER_SEC, refresh) * 2;
msleep(two_frames);
  }
@@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
  
  static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)

  {
+   struct drm_display_mode *mode = 
>connector.state->crtc->state->adjusted_mode;
unsigned int i, pre;
unsigned long mpclk, pllref, tmp;
unsigned int m = 1, n = 1, target_mbps = 1000;
@@ -474,7 +475,7 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
return bpp;
}
  
-	mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);

+   mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
if (mpclk) {
/* take 1 / 0.9, since mbps must big than bandwidth of RGB */
tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
@@ -689,9 +690,9 @@ static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS);
  }
  
-static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi,

-  struct drm_display_mode *mode)
+static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi)
  {
+   struct drm_display_mode *mode = 
>connector.state->crtc->state->adjusted_mode;
u32 val = 0, color = 0;
  
  	switch (dsi->format) {

@@ -726,9 +727,10 @@ static void dw_mipi_dsi_packet_handler_config(struct 
dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PCKHDL_CFG, EN_CRC_RX | EN_ECC_RX | EN_BTA);
  }
  
-static void dw_mipi_dsi_video_packet_config(struct dw_mipi_dsi *dsi,

-   struct drm_display_mode *mode)
+static void dw_mipi_dsi_video_packet_config(struct dw_mipi_dsi *dsi)
  {
+   struct drm_display_mode *mode = 
>connector.state->crtc->state->adjusted_mode;
+
dsi_write(dsi, DSI_VID_PKT_SIZE, VID_PKT_SIZE(mode->hdisplay));
  }
  
@@ -744,12 +746,13 @@ static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)

  static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
   u32 hcomponent)
  {
+   struct drm_display_mode *mode = 
>connector.state->crtc->state->adjusted_mode;
u32 frac, lbcc;
  
  	lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
  
-	frac = lbcc % dsi->mode->clock;

-   lbcc = lbcc / dsi->mode->clock;
+   frac = lbcc % mode->clock;
+   lbcc = lbcc / mode->clock;
if (frac)
lbcc++;
  
@@ -759,7 +762,7 @@ static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,

  static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
  {
u32 htotal, hsa, hbp, lbcc;
-   struct drm_display_mode *mode = dsi->mode;
+   struct drm_display_mode *mode = 
>connector.state->crtc->state->adjusted_mode;
  
  	htotal = mode->htotal;

hsa = mode->hsync_end - mode->hsync_start;
@@ -778,7 +781,7 @@ static void dw_mipi_dsi_line_timer_config(struct 
dw_mipi_dsi *dsi)
  static void dw_mipi_dsi_vertical_timing_config(struct dw_mipi_dsi *dsi)
  {
u32 vactive, vsa, vfp, vbp;
-   struct drm_display_mode *mode = dsi->mode;
+   struct drm_display_mode *mode = 
>connector.state->crtc->state->adjusted_mode;
  
  	vactive = mode->vdisplay;

vsa = mode->vsync_end - mode->vsync_start;
@@ -821,8 +824,6 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder 
*encoder,
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int ret;
  
-	dsi->mode = adjusted_mode;

-
I prefer to keep the original method, although this"dsi->mode" pointer 
is same as ">connector.state->crtc->state->adjusted_mode; "

I still think dsi->mode makes the process easier to read



ret = dw_mipi_dsi_get_lane_bps(dsi);
if (ret < 0)
return;
@@ -833,10 +834,10 @@ static void 

Re: [patch] drm/vc4: fix a bounds check

[Eric Anholt]

Dan Carpenter  writes:

> We accidentally return success even if vc4_full_res_bounds_check() fails.
>
> Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
> Signed-off-by: Dan Carpenter 

Thanks.  Reviewed, added Eric's review, and pushed to -fixes.


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

Re: [05/26] drm/rockchip: dw-mipi-dsi: fix command header writes

[Chris Zhong]

same as https://patchwork.kernel.org/patch/9518417/

Tested-by: Chris Zhong 
Reviewed-by: Chris Zhong 

On 09/20/2016 01:17 AM, John Keeping wrote:

In a couple of places here we use "val" for the value that is about to
be written to a register but then reuse the same variable for the value
of a status register before we get around to writing it.  Rename the
value to be written to so that we write the value we intend to and not
what we have just read from the status register.

Signed-off-by: John Keeping 
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index fac2429b9d6d..03915bf9c97d 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -543,9 +543,10 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host 
*host,
return 0;
  }
  
-static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 val)

+static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
  {
int ret;
+   u32 val;
  
  	ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,

 val, !(val & GEN_CMD_FULL), 1000,
@@ -555,7 +556,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi 
*dsi, u32 val)
return ret;
}
  
-	dsi_write(dsi, DSI_GEN_HDR, val);

+   dsi_write(dsi, DSI_GEN_HDR, hdr_val);
  
  	ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,

 val, val & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
@@ -588,8 +589,9 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi 
*dsi,
  {
const u32 *tx_buf = msg->tx_buf;
int len = msg->tx_len, pld_data_bytes = sizeof(*tx_buf), ret;
-   u32 val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
+   u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
u32 remainder = 0;
+   u32 val;
  
  	if (msg->tx_len < 3) {

dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
@@ -618,7 +620,7 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi 
*dsi,
}
}
  
-	return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);

+   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
  }
  
  static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,



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

Re: [PATCH v2 11/11] drm/rockchip/dsi: fix insufficient bandwidth of some panel

[Chris Zhong]

Hi John

On 01/16/2017 08:44 PM, John Keeping wrote:

On Mon, 16 Jan 2017 18:08:31 +0800, Chris Zhong wrote:


Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
for some panel, it will cause the screen display is not normal, so
increases the badnwidth to 1 / 0.8.

Signed-off-by: Chris Zhong 

---

  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9dfa73d..5a973fe 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -501,8 +501,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
  
  	mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);

if (mpclk) {
-   /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
-   tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
+   /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
+   tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;

This and patch 9 are just hacking around the underlying problem in order
to make particular panels work.  I'm pretty sure the actual issue is the
use of hardcoded values when configuring the PHY, since the PHY
parameters are specified in clock cycles but the MIPI spec requires
absolute time durations.

I posted a series addressing this a while ago, although I screwed up
sending it so some patches were included twice and since no one
expressed any interest I didn't post a cleaned up version.

The relevant patch is here:

https://patchwork.kernel.org/patch/9340193/
Thanks very much, your patches are very useful for me. It looks your 
method is correct.
And I am very confused why Mark Yao and me did not receive your patches 
before,

although we have subscribed the .

In addition, could you tell me which device ware you testing with these 
mipi patches.

I going to test them these day.

Chris Zhong

if (tmp < max_mbps)
target_mbps = tmp;
else






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

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

[Laurent Pinchart]

Hi Inki,

Thank you for the patch.

On Monday 16 Jan 2017 18:13:22 Inki Dae wrote:
> This patch relpaces specific atomic commit function
> with atomic helper commit one, which also includes
> atomic_commit_tail callback for Exynos SoC becasue
> crtc devices on Exynos SoC uses power domain device
> so drm_atomic_helper_commit_planes should be called
> after drm_atomic_helper_commit_modeset_enables.
> 
> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   9 ++-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 110 +---
>  drivers/gpu/drm/exynos/exynos_drm_fb.c   |  25 ++-
>  3 files changed, 33 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..47da612 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;
> + }

You also need to handle events for exynos_drm_crtc_enable(). I'm not too 
familiar with the exynos drm driver, is that taken care of by event handling 
in exynos_crtc_atomic_flush() ?

You could also split this change into a separate patch with a clear 
explanation of why it's needed in the commit message.

>  }

[snip]

> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 3ec0535..9d0df00 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c

[snip]

> -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() step, this way it will always
> -  * have the relevant clocks enabled to perform the update.
> -  */

There's a value in this comment, I would copy it to 
exynos_drm_atomic_commit_tail()

> - drm_atomic_helper_commit_planes(dev, state, 0);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, state);
> -
> - drm_atomic_helper_cleanup_planes(dev, state);
> -
> - drm_atomic_state_put(state);
> -
> - spin_lock(>lock);
> - priv->pending &= ~commit->crtcs;
> - spin_unlock(>lock);
> -
> - wake_up_all(>wait);
> -
> - kfree(commit);
> -}

[snip]

> @@ -313,6 +204,7 @@ static void exynos_drm_preclose(struct drm_device *dev,
> 
>   list_for_each_entry(crtc, >mode_config.crtc_list, head)
>   exynos_drm_crtc_cancel_page_flip(crtc, file);
> +

This isn't needed.

>  }
> 
>  static void exynos_drm_postclose(struct drm_device *dev, struct drm_file
> *file) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c index 68d4142..1e10b73 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -187,11 +187,33 @@ dma_addr_t exynos_drm_fb_dma_addr(struct
> drm_framebuffer *fb, int index) return exynos_fb->dma_addr[index];
>  }
> 
> +static void exynos_drm_atomic_commit_tail(struct drm_atomic_state *state)
> +{
> + struct drm_device *dev = state->dev;
> +
> + drm_atomic_helper_commit_modeset_disables(dev, state);
> +
> + drm_atomic_helper_commit_modeset_enables(dev, state);
> +
> + drm_atomic_helper_commit_planes(dev, state,
> + DRM_PLANE_COMMIT_ACTIVE_ONLY);

The DRM_PLANE_COMMIT_ACTIVE_ONLY flag wasn't set before, I think this change 
should go in a separate patch (or at least be documented in the commit 
message).

> + drm_atomic_helper_commit_hw_done(state);
> +
> + drm_atomic_helper_wait_for_vblanks(dev, state);
> +
> + drm_atomic_helper_cleanup_planes(dev, state);
> +}

[snip]

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/4] drm/atomic: Save flip flags in drm_plane_state

[Laurent Pinchart]

Hi Andrey,

On Tuesday 17 Jan 2017 04:03:11 Grodzovsky, Andrey wrote:
> On Monday, January 16, 2017 5:18 PM Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 10:44:55 Andrey Grodzovsky wrote:
> > > Allows using atomic flip helpers for drivers using ASYNC flip.
> > > Remove ASYNC_FLIP restriction in helpers and caches the page flip
> > > flags in drm_plane_state to be used in the low level drivers.
> > > 
> >> Signed-off-by: Andrey Grodzovsky 
> >> ---
> >> 
> >>  drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
> >>  include/drm/drm_plane.h |  8 
> >>  2 files changed, 11 insertions(+), 7 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c index a4e5477..f83dc43 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -2737,7 +2737,8 @@ static int page_flip_common(
> >>struct drm_atomic_state *state,
> >>struct drm_crtc *crtc,
> >>struct drm_framebuffer *fb,
> >> -  struct drm_pending_vblank_event *event)
> >> +  struct drm_pending_vblank_event *event,
> >> +  uint32_t flags)
> >>  {
> >>struct drm_plane *plane = crtc->primary;
> >>struct drm_plane_state *plane_state;
> >> @@ -2754,6 +2755,7 @@ static int page_flip_common(
> >>if (IS_ERR(plane_state))
> >>return PTR_ERR(plane_state);
> >> 
> >> +  plane_state->pflip_flags = flags;
> >> 
> >>ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> >>if (ret != 0)
> >> @@ -2800,9 +2802,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc
> >> *crtc,
> >>struct drm_atomic_state *state;
> >>int ret = 0;
> >> 
> >> -  if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> >> -  return -EINVAL;
> >> -
> > 
> > With this change all drivers using the helper will not reject that async
> > flag, even if they don't implement support for async page flip. You need
> > to either patch them all to reject the flag, or implement async page flip
> > support for all of them (preferable in the helpers, and then remove the
> 
> Please check drm_mode_page_flip_ioctl, one of the checks in the beginning is
> 
> if ((page_flip->flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
> !dev->mode_config.async_page_flip) return -EINVAL;

I think you're right. Sorry for the noise.

> We in DC explicitly set dev->mode_config.async_page_flip = true, any driver
> which is Not supporting ASYNC flip will fail the IOCTL at this point.
> Same in drm_mode_atomic_ioctl
> 
> >  * Note that for now so called async page flips (i.e. updates which are
> >  not
> >  * synchronized to vblank) are not supported, since the atomic interfaces
> > have
> >  * no provisions for this yet.
> > 
> > comment).
> 
> Thanks, that a good catch, will remove.

-- 
Regards,

Laurent Pinchart

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

[PATCH v3 16/20] drm: bridge: dw-hdmi: Detect PHY type at runtime

[Laurent Pinchart]

Detect the PHY type and use it to handle the PHY type-specific SVSRET
signal.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 68 ++--
 include/drm/bridge/dw_hdmi.h | 10 ++
 2 files changed, 75 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index f4faa14213e5..ef4f2f96ed2c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -113,6 +113,12 @@ struct dw_hdmi_i2c {
boolis_regaddr;
 };
 
+struct dw_hdmi_phy_data {
+   enum dw_hdmi_phy_type type;
+   const char *name;
+   bool has_svsret;
+};
+
 struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
@@ -134,7 +140,9 @@ struct dw_hdmi {
u8 edid[HDMI_EDID_LEN];
bool cable_plugin;
 
+   const struct dw_hdmi_phy_data *phy;
bool phy_enabled;
+
struct drm_display_mode previous_mode;
 
struct i2c_adapter *ddc;
@@ -1015,7 +1023,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   if (hdmi->dev_type == RK3288_HDMI)
+   /* The DWC MHL and HDMI 2.0 PHYs need the SVSRET signal to be set. */
+   if (hdmi->phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
 
/*Wait for PHY PLL lock */
@@ -1840,6 +1849,54 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
+   {
+   .type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
+   .name = "DWC HDMI TX PHY",
+   }, {
+   .type = DW_HDMI_PHY_DWC_MHL_PHY_HEAC,
+   .name = "DWC MHL PHY + HEAC PHY",
+   .has_svsret = true,
+   }, {
+   .type = DW_HDMI_PHY_DWC_MHL_PHY,
+   .name = "DWC MHL PHY",
+   .has_svsret = true,
+   }, {
+   .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC,
+   .name = "DWC HDMI 3D TX PHY + HEAC PHY",
+   }, {
+   .type = DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY,
+   .name = "DWC HDMI 3D TX PHY",
+   }, {
+   .type = DW_HDMI_PHY_DWC_HDMI20_TX_PHY,
+   .name = "DWC HDMI 2.0 TX PHY",
+   .has_svsret = true,
+   }
+};
+
+static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
+{
+   unsigned int i;
+   u8 phy_type;
+
+   phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
+
+   for (i = 0; i < ARRAY_SIZE(dw_hdmi_phys); ++i) {
+   if (dw_hdmi_phys[i].type == phy_type) {
+   hdmi->phy = _hdmi_phys[i];
+   return 0;
+   }
+   }
+
+   if (phy_type == DW_HDMI_PHY_VENDOR_PHY)
+   dev_err(hdmi->dev, "Unsupported vendor HDMI PHY\n");
+   else
+   dev_err(hdmi->dev, "Unsupported HDMI PHY type (%02x)\n",
+   phy_type);
+
+   return -ENODEV;
+}
+
 static struct dw_hdmi *
 __dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
@@ -1950,9 +2007,14 @@ __dw_hdmi_probe(struct platform_device *pdev,
goto err_iahb;
}
 
-   dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
+   ret = dw_hdmi_detect_phy(hdmi);
+   if (ret < 0)
+   goto err_iahb;
+
+   dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP (%s)\n",
 hdmi->version >> 12, hdmi->version & 0xfff,
-prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
+prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without",
+hdmi->phy->name);
 
initialize_hdmi_ih_mutes(hdmi);
 
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 3bb22a849830..b080a171a23f 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -27,6 +27,16 @@ enum dw_hdmi_devtype {
RK3288_HDMI,
 };
 
+enum dw_hdmi_phy_type {
+   DW_HDMI_PHY_DWC_HDMI_TX_PHY = 0x00,
+   DW_HDMI_PHY_DWC_MHL_PHY_HEAC = 0xb2,
+   DW_HDMI_PHY_DWC_MHL_PHY = 0xc2,
+   DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY_HEAC = 0xe2,
+   DW_HDMI_PHY_DWC_HDMI_3D_TX_PHY = 0xf2,
+   DW_HDMI_PHY_DWC_HDMI20_TX_PHY = 0xf3,
+   DW_HDMI_PHY_VENDOR_PHY = 0xfe,
+};
+
 struct dw_hdmi_mpll_config {
unsigned long mpixelclock;
struct {
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 10/20] drm: bridge: dw-hdmi: Implement DRM bridge registration

[Laurent Pinchart]

As an option for drivers not based on the component framework, register
the bridge with the DRM core with the DRM bridge API. Existing drivers
based on dw_hdmi_bind() and dw_hdmi_unbind() are not affected as those
functions are preserved with their current behaviour.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 112 ---
 include/drm/bridge/dw_hdmi.h |   3 ++
 2 files changed, 83 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 88cd40adb977..107fea49c4c6 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1836,24 +1836,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static int dw_hdmi_register(struct drm_encoder *encoder, struct dw_hdmi *hdmi)
-{
-   struct drm_bridge *bridge = >bridge;
-   int ret;
-
-   bridge->driver_private = hdmi;
-   bridge->funcs = _hdmi_bridge_funcs;
-   ret = drm_bridge_attach(encoder, bridge, NULL);
-   if (ret) {
-   DRM_ERROR("Failed to initialize bridge with drm\n");
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+static struct dw_hdmi *
+__dw_hdmi_probe(struct platform_device *pdev,
+   const struct dw_hdmi_plat_data *plat_data)
 {
struct device *dev = >dev;
struct device_node *np = dev->of_node;
@@ -1869,7 +1854,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
 
hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
 
hdmi->plat_data = plat_data;
hdmi->dev = dev;
@@ -1896,7 +1881,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
break;
default:
dev_err(dev, "reg-io-width must be 1 or 4\n");
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
 
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
@@ -1905,7 +1890,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
of_node_put(ddc_node);
if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
-   return -EPROBE_DEFER;
+   return ERR_PTR(-EPROBE_DEFER);
}
 
} else {
@@ -1956,8 +1941,10 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
initialize_hdmi_ih_mutes(hdmi);
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
+   if (irq < 0) {
+   ret = irq;
goto err_iahb;
+   }
 
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
dw_hdmi_irq, IRQF_SHARED,
@@ -1988,11 +1975,11 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
HDMI_IH_PHY_STAT0);
 
-   ret = dw_hdmi_fb_registered(hdmi);
-   if (ret)
-   goto err_iahb;
+   hdmi->bridge.driver_private = hdmi;
+   hdmi->bridge.funcs = _hdmi_bridge_funcs;
+   hdmi->bridge.of_node = pdev->dev.of_node;
 
-   ret = dw_hdmi_register(encoder, hdmi);
+   ret = dw_hdmi_fb_registered(hdmi);
if (ret)
goto err_iahb;
 
@@ -2041,7 +2028,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
 
platform_set_drvdata(pdev, hdmi);
 
-   return 0;
+   return hdmi;
 
 err_iahb:
if (hdmi->i2c) {
@@ -2055,14 +2042,11 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
 err_res:
i2c_put_adapter(hdmi->ddc);
 
-   return ret;
+   return ERR_PTR(ret);
 }
-EXPORT_SYMBOL_GPL(dw_hdmi_bind);
 
-void dw_hdmi_unbind(struct device *dev)
+static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
 {
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
if (hdmi->audio && !IS_ERR(hdmi->audio))
platform_device_unregister(hdmi->audio);
 
@@ -2077,6 +2061,70 @@ void dw_hdmi_unbind(struct device *dev)
else
i2c_put_adapter(hdmi->ddc);
 }
+
+/* 
-
+ * Probe/remove API, used from platforms based on the DRM bridge API.
+ */
+int dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
+{
+   struct dw_hdmi *hdmi;
+   int ret;
+
+   hdmi = __dw_hdmi_probe(pdev, plat_data);
+   if (IS_ERR(hdmi))
+  

[PATCH v3 17/20] drm: bridge: dw-hdmi: Define and use macros for PHY register addresses

[Laurent Pinchart]

Replace the hardcoded register address numerical values with macros to
clarify the code.

This change has been tested by comparing the assembly code before and
after the change.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 35 -
 drivers/gpu/drm/bridge/dw-hdmi.h | 66 
 2 files changed, 86 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ef4f2f96ed2c..6e605fd910ef 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -997,21 +997,26 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
HDMI_PHY_I2CM_SLAVE_ADDR);
hdmi_phy_test_clear(hdmi, 0);
 
-   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);
-   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
-
-   /* CURRCTRL */
-   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
-
-   hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
-   hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
-
-   hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19);  /* TXTERM */
-   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL */
-   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
-
-   /* REMOVE CLK TERM */
-   hdmi_phy_i2c_write(hdmi, 0x8000, 0x05);  /* CKCALCTRL */
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
+  HDMI_3D_TX_PHY_CPCE_CTRL);
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
+  HDMI_3D_TX_PHY_GMPCTRL);
+   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
+  HDMI_3D_TX_PHY_CURRCTRL);
+
+   hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
+   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_MSM_CTRL_CKO_SEL_FB_CLK,
+  HDMI_3D_TX_PHY_MSM_CTRL);
+
+   hdmi_phy_i2c_write(hdmi, phy_config->term, HDMI_3D_TX_PHY_TXTERM);
+   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr,
+  HDMI_3D_TX_PHY_CKSYMTXCTRL);
+   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr,
+  HDMI_3D_TX_PHY_VLEVCTRL);
+
+   /* Override and disable clock termination. */
+   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
+  HDMI_3D_TX_PHY_CKCALCTRL);
 
dw_hdmi_phy_enable_powerdown(hdmi, false);
 
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index a4fd64a203c9..f3c149c88d71 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -1085,4 +1085,70 @@ enum {
HDMI_I2CM_CTLINT_ARB_MASK = 0x4,
 };
 
+/*
+ * HDMI 3D TX PHY registers
+ */
+#define HDMI_3D_TX_PHY_PWRCTRL 0x00
+#define HDMI_3D_TX_PHY_SERDIVCTRL  0x01
+#define HDMI_3D_TX_PHY_SERCKCTRL   0x02
+#define HDMI_3D_TX_PHY_SERCKKILLCTRL   0x03
+#define HDMI_3D_TX_PHY_TXRESCTRL   0x04
+#define HDMI_3D_TX_PHY_CKCALCTRL   0x05
+#define HDMI_3D_TX_PHY_CPCE_CTRL   0x06
+#define HDMI_3D_TX_PHY_TXCLKMEASCTRL   0x07
+#define HDMI_3D_TX_PHY_TXMEASCTRL  0x08
+#define HDMI_3D_TX_PHY_CKSYMTXCTRL 0x09
+#define HDMI_3D_TX_PHY_CMPSEQCTRL  0x0a
+#define HDMI_3D_TX_PHY_CMPPWRCTRL  0x0b
+#define HDMI_3D_TX_PHY_CMPMODECTRL 0x0c
+#define HDMI_3D_TX_PHY_MEASCTRL0x0d
+#define HDMI_3D_TX_PHY_VLEVCTRL0x0e
+#define HDMI_3D_TX_PHY_D2ACTRL 0x0f
+#define HDMI_3D_TX_PHY_CURRCTRL0x10
+#define HDMI_3D_TX_PHY_DRVANACTRL  0x11
+#define HDMI_3D_TX_PHY_PLLMEASCTRL 0x12
+#define HDMI_3D_TX_PHY_PLLPHBYCTRL 0x13
+#define HDMI_3D_TX_PHY_GRP_CTRL0x14
+#define HDMI_3D_TX_PHY_GMPCTRL 0x15
+#define HDMI_3D_TX_PHY_MPLLMEASCTRL0x16
+#define HDMI_3D_TX_PHY_MSM_CTRL0x17
+#define HDMI_3D_TX_PHY_SCRPB_STATUS0x18
+#define HDMI_3D_TX_PHY_TXTERM  0x19
+#define HDMI_3D_TX_PHY_PTRPT_ENBL  0x1a
+#define HDMI_3D_TX_PHY_PATTERNGEN  0x1b
+#define HDMI_3D_TX_PHY_SDCAP_MODE  0x1c
+#define HDMI_3D_TX_PHY_SCOPEMODE   0x1d
+#define HDMI_3D_TX_PHY_DIGTXMODE   0x1e
+#define HDMI_3D_TX_PHY_STR_STATUS  0x1f
+#define HDMI_3D_TX_PHY_SCOPECNT0   0x20
+#define HDMI_3D_TX_PHY_SCOPECNT1   0x21
+#define HDMI_3D_TX_PHY_SCOPECNT2   0x22
+#define HDMI_3D_TX_PHY_SCOPECNTCLK 0x23
+#define HDMI_3D_TX_PHY_SCOPESAMPLE 0x24
+#define HDMI_3D_TX_PHY_SCOPECNTMSB01   0x25
+#define HDMI_3D_TX_PHY_SCOPECNTMSB2CK  

[PATCH v3 19/20] drm: bridge: dw-hdmi: Assert SVSRET before resetting the PHY

[Laurent Pinchart]

According to the PHY IP core vendor, the SVSRET signal must be asserted
before resetting the PHY. Tests on RK3288 and R-Car Gen3 showed no
regression, the change should thus be safe.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 93e8816f1f78..4fda0717e789 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -986,6 +986,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
/* gen2 pddq */
dw_hdmi_phy_gen2_pddq(hdmi, 1);
 
+   /* Leave low power consumption mode by asserting SVSRET. */
+   if (hdmi->phy->has_svsret)
+   dw_hdmi_phy_enable_svsret(hdmi, 1);
+
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
@@ -1028,11 +1032,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   /* The DWC MHL and HDMI 2.0 PHYs need the SVSRET signal to be set. */
-   if (hdmi->phy->has_svsret)
-   dw_hdmi_phy_enable_svsret(hdmi, 1);
-
-   /*Wait for PHY PLL lock */
+   /* Wait for PHY PLL lock */
msec = 5;
do {
val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 20/20] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

[Laurent Pinchart]

Make it clear that the core bridge/dw_hdmi.txt document isn't a device
tree binding by itself but is meant to be referenced by platform device
tree bindings, and update the Rockchip and Freescale DWC HDMI TX
bindings to reference it.

Signed-off-by: Laurent Pinchart 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 +-
 .../devicetree/bindings/display/imx/hdmi.txt   | 51 +++--
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++
 3 files changed, 91 insertions(+), 88 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
index 5e9a84d6e5f1..33bf981fbe33 100644
--- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
@@ -1,52 +1,33 @@
-DesignWare HDMI bridge bindings
-
-Required properties:
-- compatible: platform specific such as:
-   * "snps,dw-hdmi-tx"
-   * "fsl,imx6q-hdmi"
-   * "fsl,imx6dl-hdmi"
-   * "rockchip,rk3288-dw-hdmi"
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The HDMI interrupt number
-- clocks, clock-names : must have the phandles to the HDMI iahb and isfr 
clocks,
-  as described in Documentation/devicetree/bindings/clock/clock-bindings.txt,
-  the clocks are soc specific, the clock-names should be "iahb", "isfr"
--port@[X]: SoC specific port nodes with endpoint definitions as defined
-   in Documentation/devicetree/bindings/media/video-interfaces.txt,
-   please refer to the SoC specific binding document:
-* Documentation/devicetree/bindings/display/imx/hdmi.txt
-* Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
-
-Optional properties
-- reg-io-width: the width of the reg:1,4, default set to 1 if not present
-- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing,
-  if the property is omitted, a functionally reduced I2C bus
-  controller on DW HDMI is probed
-- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
-
-Example:
-   hdmi: hdmi@012 {
-   compatible = "fsl,imx6q-hdmi";
-   reg = <0x0012 0x9000>;
-   interrupts = <0 115 0x04>;
-   gpr = <>;
-   clocks = < 123>, < 124>;
-   clock-names = "iahb", "isfr";
-   ddc-i2c-bus = <>;
-
-   port@0 {
-   reg = <0>;
-
-   hdmi_mux_0: endpoint {
-   remote-endpoint = <_di0_hdmi>;
-   };
-   };
-
-   port@1 {
-   reg = <1>;
-
-   hdmi_mux_1: endpoint {
-   remote-endpoint = <_di1_hdmi>;
-   };
-   };
-   };
+Synopsys DesignWare HDMI TX Encoder
+===
+
+This document defines device tree properties for the Synopsys DesignWare HDMI
+TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding
+specification by itself but is meant to be referenced by platform-specific
+device tree bindings.
+
+When referenced from platform device tree bindings the properties defined in
+this document are defined as follows. The platform device tree bindings are
+responsible for defining whether each property is required or optional.
+
+- reg: Memory mapped base address and length of the DWC HDMI TX registers.
+
+- reg-io-width: Width of the registers specified by the reg property. The
+  value is expressed in bytes and must be equal to 1 or 4 if specified. The
+  register width defaults to 1 if the property is not present.
+
+- interrupts: Reference to the DWC HDMI TX interrupt.
+
+- clocks: References to all the clocks specified in the clock-names property
+  as specified in Documentation/devicetree/bindings/clock/clock-bindings.txt.
+
+- clock-names: The DWC HDMI TX uses the following clocks.
+
+  - "iahb" is the bus clock for either AHB and APB (mandatory).
+  - "isfr" is the internal register configuration clock (mandatory).
+  - "cec" is the HDMI CEC controller main clock (optional).
+
+- ports: The connectivity of the DWC HDMI TX with the rest of the system is
+  expressed in using ports as specified in the device graph bindings defined
+  in Documentation/devicetree/bindings/graph.txt. The numbering of the ports
+  is platform-specific.
diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt 
b/Documentation/devicetree/bindings/display/imx/hdmi.txt
index 1b756cf9afb0..66a8f86e5d12 100644
--- a/Documentation/devicetree/bindings/display/imx/hdmi.txt
+++ b/Documentation/devicetree/bindings/display/imx/hdmi.txt
@@ -1,29 +1,36 @@
-Device-Tree bindings for HDMI Transmitter
+Freescale i.MX6 DWC HDMI TX Encoder
+===
 
-HDMI Transmitter

[PATCH v3 18/20] drm: bridge: dw-hdmi: Fix the name of the PHY reset macros

[Laurent Pinchart]

The PHY reset signal is controlled by bit PHYRSTZ in the MC_PHYRSTZ
register. The signal is active low on Gen1 PHYs and active high on Gen2
PHYs. The driver toggles the signal high then low, which is correct for
all currently supported platforms, but the register values macros are
incorrectly named. Replace them with a single macro named after the bit,
and add a comment to the source code to explain the behaviour.

The driver's behaviour isn't changed by this rename, the code will still
need to be fixed to support Gen1 PHYs.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++---
 drivers/gpu/drm/bridge/dw-hdmi.h | 3 +--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 6e605fd910ef..93e8816f1f78 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -986,9 +986,9 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
/* gen2 pddq */
dw_hdmi_phy_gen2_pddq(hdmi, 1);
 
-   /* PHY reset */
-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_DEASSERT, HDMI_MC_PHYRSTZ);
-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_ASSERT, HDMI_MC_PHYRSTZ);
+   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
 
hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
 
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index f3c149c88d71..325b0b8ae639 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -989,8 +989,7 @@ enum {
HDMI_MC_FLOWCTRL_FEED_THROUGH_OFF_CSC_BYPASS = 0x0,
 
 /* MC_PHYRSTZ field values */
-   HDMI_MC_PHYRSTZ_ASSERT = 0x0,
-   HDMI_MC_PHYRSTZ_DEASSERT = 0x1,
+   HDMI_MC_PHYRSTZ_PHYRSTZ = 0x01,
 
 /* MC_HEACPHY_RST field values */
HDMI_MC_HEACPHY_RST_ASSERT = 0x1,
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 13/20] drm: bridge: dw-hdmi: Reject invalid product IDs

[Laurent Pinchart]

The DWC HDMI TX can be recognized by the two product identification
registers. If the registers don't read as expect the IP will be very
different than what the driver has been designed for, or will be
misconfigured in a way that makes it non-operational (invalid memory
address, incorrect clocks, ...). We should reject this situation with an
error.

While this isn't critical for proper operation with supported IPs at the
moment, the driver will soon gain automatic device-specific handling
based on runtime device identification. This change makes it easier to
implement that without having to default to a random guess in case the
device can't be identified.

While at it print a readable version number in the device identification
message instead of raw register values.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 25 +++--
 drivers/gpu/drm/bridge/dw-hdmi.h |  8 
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 06c252f560ad..1809247745b8 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1832,6 +1832,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
int irq;
int ret;
u32 val = 1;
+   u16 version;
+   u8 prod_id0;
+   u8 prod_id1;
u8 config0;
u8 config1;
 
@@ -1914,12 +1917,22 @@ __dw_hdmi_probe(struct platform_device *pdev,
}
 
/* Product and revision IDs */
-   dev_info(dev,
-"Detected HDMI controller 0x%x:0x%x:0x%x:0x%x\n",
-hdmi_readb(hdmi, HDMI_DESIGN_ID),
-hdmi_readb(hdmi, HDMI_REVISION_ID),
-hdmi_readb(hdmi, HDMI_PRODUCT_ID0),
-hdmi_readb(hdmi, HDMI_PRODUCT_ID1));
+   version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
+   | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
+   prod_id0 = hdmi_readb(hdmi, HDMI_PRODUCT_ID0);
+   prod_id1 = hdmi_readb(hdmi, HDMI_PRODUCT_ID1);
+
+   if (prod_id0 != HDMI_PRODUCT_ID0_HDMI_TX ||
+   (prod_id1 & ~HDMI_PRODUCT_ID1_HDCP) != HDMI_PRODUCT_ID1_HDMI_TX) {
+   dev_err(dev, "Unsupported HDMI controller (%04x:%02x:%02x)\n",
+   version, prod_id0, prod_id1);
+   ret = -ENODEV;
+   goto err_iahb;
+   }
+
+   dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
+version >> 12, version & 0xfff,
+prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
 
initialize_hdmi_ih_mutes(hdmi);
 
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index 08235aef2fa3..91d7fabbd6e5 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -545,6 +545,14 @@
 #define HDMI_I2CM_FS_SCL_LCNT_0_ADDR0x7E12
 
 enum {
+/* PRODUCT_ID0 field values */
+   HDMI_PRODUCT_ID0_HDMI_TX = 0xa0,
+
+/* PRODUCT_ID1 field values */
+   HDMI_PRODUCT_ID1_HDCP = 0xc0,
+   HDMI_PRODUCT_ID1_HDMI_RX = 0x02,
+   HDMI_PRODUCT_ID1_HDMI_TX = 0x01,
+
 /* CONFIG0_ID field values */
HDMI_CONFIG0_I2S = 0x10,
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 15/20] drm: bridge: dw-hdmi: Handle overflow workaround based on device version

[Laurent Pinchart]

Use the device version queried at runtime instead of the device type
provided through platform data to handle the overflow workaround. This
will make support of other SoCs integrating the same HDMI TX controller
version easier.

Among the supported platforms only i.MX6DL and i.MX6Q have been
identified as needing the workaround. Disabling it on Rockchip RK3288
(which integrates a v2.00a controller) didn't produce any error or
artifact.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 46 
 1 file changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 730a7558d4d4..f4faa14213e5 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -117,8 +117,10 @@ struct dw_hdmi {
struct drm_connector connector;
struct drm_bridge bridge;
 
-   struct platform_device *audio;
enum dw_hdmi_devtype dev_type;
+   unsigned int version;
+
+   struct platform_device *audio;
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
@@ -1323,19 +1325,38 @@ static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
 /* Workaround to clear the overflow condition */
 static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 {
-   int count;
+   unsigned int count;
+   unsigned int i;
u8 val;
 
-   /* TMDS software reset */
-   hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
+   /*
+* Under some circumstances the Frame Composer arithmetic unit can miss
+* an FC register write due to being busy processing the previous one.
+* The issue can be worked around by issuing a TMDS software reset and
+* then write one of the FC registers several times.
+*
+* The number of iterations matters and depends on the HDMI TX revision
+* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
+* i.MX6DL (v1.31a) have been identified as needing the workaround, with
+* 4 and 1 iterations respectively.
+*/
 
-   val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
-   if (hdmi->dev_type == IMX6DL_HDMI) {
-   hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
+   switch (hdmi->version) {
+   case 0x130a:
+   count = 4;
+   break;
+   case 0x131a:
+   count = 1;
+   break;
+   default:
return;
}
 
-   for (count = 0; count < 4; count++)
+   /* TMDS software reset */
+   hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, HDMI_MC_SWRSTZ);
+
+   val = hdmi_readb(hdmi, HDMI_FC_INVIDCONF);
+   for (i = 0; i < count; i++)
hdmi_writeb(hdmi, val, HDMI_FC_INVIDCONF);
 }
 
@@ -1832,7 +1853,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
int irq;
int ret;
u32 val = 1;
-   u16 version;
u8 prod_id0;
u8 prod_id1;
u8 config0;
@@ -1917,21 +1937,21 @@ __dw_hdmi_probe(struct platform_device *pdev,
}
 
/* Product and revision IDs */
-   version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
-   | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
+   hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
+ | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
prod_id0 = hdmi_readb(hdmi, HDMI_PRODUCT_ID0);
prod_id1 = hdmi_readb(hdmi, HDMI_PRODUCT_ID1);
 
if (prod_id0 != HDMI_PRODUCT_ID0_HDMI_TX ||
(prod_id1 & ~HDMI_PRODUCT_ID1_HDCP) != HDMI_PRODUCT_ID1_HDMI_TX) {
dev_err(dev, "Unsupported HDMI controller (%04x:%02x:%02x)\n",
-   version, prod_id0, prod_id1);
+   hdmi->version, prod_id0, prod_id1);
ret = -ENODEV;
goto err_iahb;
}
 
dev_info(dev, "Detected HDMI TX controller v%x.%03x %s HDCP\n",
-version >> 12, version & 0xfff,
+hdmi->version >> 12, hdmi->version & 0xfff,
 prod_id1 & HDMI_PRODUCT_ID1_HDCP ? "with" : "without");
 
initialize_hdmi_ih_mutes(hdmi);
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 12/20] drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET

[Laurent Pinchart]

The bit is documented in a Rockchip BSP as

 #define m_SVSRET_SIG   (1 << 5) /* depend on PHY_MHL_COMB0=1 */

This is confirmed by a Renesas platform, which uses a 2.0 DWC HDMI TX as
the RK3288. Rename the bit accordingly.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 8 
 drivers/gpu/drm/bridge/dw-hdmi.h | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b4fb0bd78910..06c252f560ad 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -895,11 +895,11 @@ static void dw_hdmi_phy_enable_tmds(struct dw_hdmi *hdmi, 
u8 enable)
 HDMI_PHY_CONF0_ENTMDS_MASK);
 }
 
-static void dw_hdmi_phy_enable_spare(struct dw_hdmi *hdmi, u8 enable)
+static void dw_hdmi_phy_enable_svsret(struct dw_hdmi *hdmi, u8 enable)
 {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
-HDMI_PHY_CONF0_SPARECTRL_OFFSET,
-HDMI_PHY_CONF0_SPARECTRL_MASK);
+HDMI_PHY_CONF0_SVSRET_OFFSET,
+HDMI_PHY_CONF0_SVSRET_MASK);
 }
 
 static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
@@ -1014,7 +1014,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
if (hdmi->dev_type == RK3288_HDMI)
-   dw_hdmi_phy_enable_spare(hdmi, 1);
+   dw_hdmi_phy_enable_svsret(hdmi, 1);
 
/*Wait for PHY PLL lock */
msec = 5;
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index 55135bbd0c16..08235aef2fa3 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -847,8 +847,8 @@ enum {
HDMI_PHY_CONF0_PDZ_OFFSET = 7,
HDMI_PHY_CONF0_ENTMDS_MASK = 0x40,
HDMI_PHY_CONF0_ENTMDS_OFFSET = 6,
-   HDMI_PHY_CONF0_SPARECTRL_MASK = 0x20,
-   HDMI_PHY_CONF0_SPARECTRL_OFFSET = 5,
+   HDMI_PHY_CONF0_SVSRET_MASK = 0x20,
+   HDMI_PHY_CONF0_SVSRET_OFFSET = 5,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK = 0x10,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET = 4,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK = 0x8,
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 14/20] drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register

[Laurent Pinchart]

Bit 0 in CONFIG1_ID tells whether the IP core uses an AHB slave
interface for control. The correct way to identify AHB audio DMA support
is through bit 1 in CONFIG3_ID.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 6 +++---
 drivers/gpu/drm/bridge/dw-hdmi.h | 4 
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 1809247745b8..730a7558d4d4 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1836,7 +1836,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
u8 prod_id0;
u8 prod_id1;
u8 config0;
-   u8 config1;
+   u8 config3;
 
hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
if (!hdmi)
@@ -1988,9 +1988,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
pdevinfo.id = PLATFORM_DEVID_AUTO;
 
config0 = hdmi_readb(hdmi, HDMI_CONFIG0_ID);
-   config1 = hdmi_readb(hdmi, HDMI_CONFIG1_ID);
+   config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID);
 
-   if (config1 & HDMI_CONFIG1_AHB) {
+   if (config3 & HDMI_CONFIG3_AHBAUDDMA) {
struct dw_hdmi_audio_data audio;
 
audio.phys = iores->start;
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index 91d7fabbd6e5..a4fd64a203c9 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -559,6 +559,10 @@ enum {
 /* CONFIG1_ID field values */
HDMI_CONFIG1_AHB = 0x01,
 
+/* CONFIG3_ID field values */
+   HDMI_CONFIG3_AHBAUDDMA = 0x02,
+   HDMI_CONFIG3_GPAUD = 0x01,
+
 /* IH_FC_INT2 field values */
HDMI_IH_FC_INT2_OVERFLOW_MASK = 0x03,
HDMI_IH_FC_INT2_LOW_PRIORITY_OVERFLOW = 0x02,
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 06/20] drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before attach

[Laurent Pinchart]

Hotplug events should only be forwarded to the DRM core by the interrupt
handler when the bridge has been attached, otherwise the DRM device
pointer will be NULL, resulting in a crash.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ef10bb866b2f..488dc1a9204f 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1805,7 +1805,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
dev_dbg(hdmi->dev, "EVENT=%s\n",
phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
-   drm_helper_hpd_irq_event(hdmi->bridge.dev);
+   if (hdmi->bridge.dev)
+   drm_helper_hpd_irq_event(hdmi->bridge.dev);
}
 
hdmi_writeb(hdmi, intr_stat, HDMI_IH_PHY_STAT0);
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 02/20] drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind functions

[Laurent Pinchart]

The master argument isn't used. The data argument, a void pointer, is
used by the bind function only where it's cast to a drm_device pointer,
which can easily be obtained from the encoder argument instead. Remove
them.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c| 8 +++-
 drivers/gpu/drm/imx/dw_hdmi-imx.c   | 4 ++--
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 4 ++--
 include/drm/bridge/dw_hdmi.h| 5 ++---
 4 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index a6685502571e..f86894622070 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1854,12 +1854,10 @@ static int dw_hdmi_register(struct drm_device *drm, 
struct dw_hdmi *hdmi)
return 0;
 }
 
-int dw_hdmi_bind(struct device *dev, struct device *master,
-void *data, struct drm_encoder *encoder,
+int dw_hdmi_bind(struct device *dev, struct drm_encoder *encoder,
 struct resource *iores, int irq,
 const struct dw_hdmi_plat_data *plat_data)
 {
-   struct drm_device *drm = data;
struct device_node *np = dev->of_node;
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
@@ -1992,7 +1990,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
if (ret)
goto err_iahb;
 
-   ret = dw_hdmi_register(drm, hdmi);
+   ret = dw_hdmi_register(encoder->dev, hdmi);
if (ret)
goto err_iahb;
 
@@ -2059,7 +2057,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_bind);
 
-void dw_hdmi_unbind(struct device *dev, struct device *master, void *data)
+void dw_hdmi_unbind(struct device *dev)
 {
struct dw_hdmi *hdmi = dev_get_drvdata(dev);
 
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 359cd2765552..f79665801543 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -249,7 +249,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
 
-   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+   ret = dw_hdmi_bind(dev, encoder, iores, irq, plat_data);
 
/*
 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
@@ -264,7 +264,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
 static void dw_hdmi_imx_unbind(struct device *dev, struct device *master,
   void *data)
 {
-   return dw_hdmi_unbind(dev, master, data);
+   return dw_hdmi_unbind(dev);
 }
 
 static const struct component_ops dw_hdmi_imx_ops = {
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 0665fb915579..e8fb5c56b224 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -301,7 +301,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
drm_encoder_init(drm, encoder, _hdmi_rockchip_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
 
-   ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data);
+   ret = dw_hdmi_bind(dev, encoder, iores, irq, plat_data);
 
/*
 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
@@ -316,7 +316,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
 static void dw_hdmi_rockchip_unbind(struct device *dev, struct device *master,
void *data)
 {
-   return dw_hdmi_unbind(dev, master, data);
+   return dw_hdmi_unbind(dev);
 }
 
 static const struct component_ops dw_hdmi_rockchip_ops = {
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index bae79f3c4d28..11edda631a9d 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -56,9 +56,8 @@ struct dw_hdmi_plat_data {
   struct drm_display_mode *mode);
 };
 
-void dw_hdmi_unbind(struct device *dev, struct device *master, void *data);
-int dw_hdmi_bind(struct device *dev, struct device *master,
-void *data, struct drm_encoder *encoder,
+void dw_hdmi_unbind(struct device *dev);
+int dw_hdmi_bind(struct device *dev, struct drm_encoder *encoder,
 struct resource *iores, int irq,
 const struct dw_hdmi_plat_data *plat_data);
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 00/20] dw-hdmi: Cleanups, fixes and updates for v4.11

[Laurent Pinchart]

Hello,

This patch series contains the part of my pending dw-hdmi patches that have
been successfully tested on all three supported platforms (i.MX6, RK3288 and
R-Car H3) and have been reviewed without any problem being reported.

All patches here have been previously posted as part of the "[PATCH v2 00/29]
R-Car Gen3 HDMI output support" and "[PATCH 0/3] dw-hdmi: miscellaneous
cleanups and fix" series. This series is a repost with all review tags
collected.

Kieran Bingham (2):
  drm: bridge: dw-hdmi: Remove unused function parameter
  drm: bridge: dw-hdmi: Remove PHY configuration resolution parameter

Laurent Pinchart (18):
  drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and
hdmi_phy_i2c_write
  drm: bridge: dw-hdmi: Remove unneeded arguments to bind/unbind
functions
  drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi
  drm: bridge: dw-hdmi: Remove encoder field from struct dw_hdmi
  drm: bridge: dw-hdmi: Don't forward HPD events to DRM core before
attach
  drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common
code
  drm: bridge: dw-hdmi: Reorder functions to prepare for next commit
  drm: bridge: dw-hdmi: Create connector in the bridge attach operation
  drm: bridge: dw-hdmi: Implement DRM bridge registration
  drm: bridge: dw-hdmi: Rename CONF0 SPARECTRL bit to SVSRET
  drm: bridge: dw-hdmi: Reject invalid product IDs
  drm: bridge: dw-hdmi: Detect AHB audio DMA using correct register
  drm: bridge: dw-hdmi: Handle overflow workaround based on device
version
  drm: bridge: dw-hdmi: Detect PHY type at runtime
  drm: bridge: dw-hdmi: Define and use macros for PHY register addresses
  drm: bridge: dw-hdmi: Fix the name of the PHY reset macros
  drm: bridge: dw-hdmi: Assert SVSRET before resetting the PHY
  dt-bindings: display: dw-hdmi: Clean up DT bindings documentation

 .../devicetree/bindings/display/bridge/dw_hdmi.txt |  85 ++--
 .../devicetree/bindings/display/imx/hdmi.txt   |  51 +--
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt |  43 +-
 drivers/gpu/drm/bridge/dw-hdmi.c   | 438 +
 drivers/gpu/drm/bridge/dw-hdmi.h   |  85 +++-
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  14 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c|  14 +-
 include/drm/bridge/dw_hdmi.h   |  19 +-
 8 files changed, 472 insertions(+), 277 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH v3 07/20] drm: bridge: dw-hdmi: Move IRQ and IO resource allocation to common code

[Laurent Pinchart]

There's no need to duplicate identical code in multiple drivers (two at
the moment, one more to come soon). Move it to the dw-hdmi core where it
can be shared. If resource allocation ever becomes device-specific later
we'll always have the option of splitting it out again.

While it at pass the platform device to the bind function to avoid
having to cast struct device to struct platform_device.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c| 13 ++---
 drivers/gpu/drm/imx/dw_hdmi-imx.c   | 12 +---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 12 +---
 include/drm/bridge/dw_hdmi.h|  3 +--
 4 files changed, 13 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 488dc1a9204f..563cbec47da6 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1843,14 +1843,16 @@ static int dw_hdmi_register(struct drm_encoder 
*encoder, struct dw_hdmi *hdmi)
return 0;
 }
 
-int dw_hdmi_bind(struct device *dev, struct drm_encoder *encoder,
-struct resource *iores, int irq,
+int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
 const struct dw_hdmi_plat_data *plat_data)
 {
+   struct device *dev = >dev;
struct device_node *np = dev->of_node;
struct platform_device_info pdevinfo;
struct device_node *ddc_node;
struct dw_hdmi *hdmi;
+   struct resource *iores;
+   int irq;
int ret;
u32 val = 1;
u8 config0;
@@ -1903,6 +1905,7 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder 
*encoder,
dev_dbg(hdmi->dev, "no ddc property found\n");
}
 
+   iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hdmi->regs = devm_ioremap_resource(dev, iores);
if (IS_ERR(hdmi->regs)) {
ret = PTR_ERR(hdmi->regs);
@@ -1945,6 +1948,10 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder 
*encoder,
 
initialize_hdmi_ih_mutes(hdmi);
 
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   goto err_iahb;
+
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
dw_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
@@ -2025,7 +2032,7 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder 
*encoder,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
 
-   dev_set_drvdata(dev, hdmi);
+   platform_set_drvdata(pdev, hdmi);
 
return 0;
 
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index f79665801543..f645275e6e63 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -207,8 +207,6 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
struct drm_device *drm = data;
struct drm_encoder *encoder;
struct imx_hdmi *hdmi;
-   struct resource *iores;
-   int irq;
int ret;
 
if (!pdev->dev.of_node)
@@ -223,14 +221,6 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
hdmi->dev = >dev;
encoder = >encoder;
 
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
-   return irq;
-
-   iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!iores)
-   return -ENXIO;
-
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
/*
 * If we failed to find the CRTC(s) which this encoder is
@@ -249,7 +239,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
 
-   ret = dw_hdmi_bind(dev, encoder, iores, irq, plat_data);
+   ret = dw_hdmi_bind(pdev, encoder, plat_data);
 
/*
 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index e8fb5c56b224..a6d4a0236e8f 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -257,8 +257,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
struct drm_device *drm = data;
struct drm_encoder *encoder;
struct rockchip_hdmi *hdmi;
-   struct resource *iores;
-   int irq;
int ret;
 
if (!pdev->dev.of_node)
@@ -273,14 +271,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
hdmi->dev = >dev;
encoder = >encoder;
 
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
-   return irq;
-
-   iores = 

[PATCH v3 08/20] drm: bridge: dw-hdmi: Reorder functions to prepare for next commit

[Laurent Pinchart]

The next commit will reference structures and functions in a way that
currently requires forward declarations. Reorder the functions to avoid
that. No functional change to the code is performed.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 72 
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 563cbec47da6..92ce9e532603 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1575,42 +1575,6 @@ static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
 }
 
-static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
-   struct drm_display_mode *orig_mode,
-   struct drm_display_mode *mode)
-{
-   struct dw_hdmi *hdmi = bridge->driver_private;
-
-   mutex_lock(>mutex);
-
-   /* Store the display mode for plugin/DKMS poweron events */
-   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
-
-   mutex_unlock(>mutex);
-}
-
-static void dw_hdmi_bridge_disable(struct drm_bridge *bridge)
-{
-   struct dw_hdmi *hdmi = bridge->driver_private;
-
-   mutex_lock(>mutex);
-   hdmi->disabled = true;
-   dw_hdmi_update_power(hdmi);
-   dw_hdmi_update_phy_mask(hdmi);
-   mutex_unlock(>mutex);
-}
-
-static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
-{
-   struct dw_hdmi *hdmi = bridge->driver_private;
-
-   mutex_lock(>mutex);
-   hdmi->disabled = false;
-   dw_hdmi_update_power(hdmi);
-   dw_hdmi_update_phy_mask(hdmi);
-   mutex_unlock(>mutex);
-}
-
 static enum drm_connector_status
 dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
 {
@@ -1703,6 +1667,42 @@ static const struct drm_connector_helper_funcs 
dw_hdmi_connector_helper_funcs =
.best_encoder = drm_atomic_helper_best_encoder,
 };
 
+static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   mutex_lock(>mutex);
+
+   /* Store the display mode for plugin/DKMS poweron events */
+   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
+
+   mutex_unlock(>mutex);
+}
+
+static void dw_hdmi_bridge_disable(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   mutex_lock(>mutex);
+   hdmi->disabled = true;
+   dw_hdmi_update_power(hdmi);
+   dw_hdmi_update_phy_mask(hdmi);
+   mutex_unlock(>mutex);
+}
+
+static void dw_hdmi_bridge_enable(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+
+   mutex_lock(>mutex);
+   hdmi->disabled = false;
+   dw_hdmi_update_power(hdmi);
+   dw_hdmi_update_phy_mask(hdmi);
+   mutex_unlock(>mutex);
+}
+
 static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 01/20] drm: bridge: dw-hdmi: Merge __hdmi_phy_i2c_write and hdmi_phy_i2c_write

[Laurent Pinchart]

The latter is just an int wrapper around the former void function that
unconditionally returns 0. As the return value is never checked, merge
the two functions into one.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index f5009ae39b89..a6685502571e 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -868,7 +868,7 @@ static bool hdmi_phy_wait_i2c_done(struct dw_hdmi *hdmi, 
int msec)
return true;
 }
 
-static void __hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
+static void hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
 unsigned char addr)
 {
hdmi_writeb(hdmi, 0xFF, HDMI_IH_I2CMPHY_STAT0);
@@ -882,13 +882,6 @@ static void __hdmi_phy_i2c_write(struct dw_hdmi *hdmi, 
unsigned short data,
hdmi_phy_wait_i2c_done(hdmi, 1000);
 }
 
-static int hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data,
- unsigned char addr)
-{
-   __hdmi_phy_i2c_write(hdmi, data, addr);
-   return 0;
-}
-
 static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable)
 {
hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0,
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 03/20] drm: bridge: dw-hdmi: Remove unused function parameter

[Laurent Pinchart]

From: Kieran Bingham 

The 'prep' parameter passed to hdmi_phy_configure() is useless. It is
hardcoded as 0, and if set, simply prevents the configure function from
executing.

Remove it.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index f86894622070..5f8044a7d602 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -931,7 +931,7 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }
 
-static int hdmi_phy_configure(struct dw_hdmi *hdmi, unsigned char prep,
+static int hdmi_phy_configure(struct dw_hdmi *hdmi,
  unsigned char res, int cscon)
 {
unsigned res_idx;
@@ -941,9 +941,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
 
-   if (prep)
-   return -EINVAL;
-
switch (res) {
case 0: /* color resolution 0 is 8 bit colour depth */
case 8:
@@ -1072,7 +1069,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_powerdown(hdmi, true);
 
/* Enable CSC */
-   ret = hdmi_phy_configure(hdmi, 0, 8, cscon);
+   ret = hdmi_phy_configure(hdmi, 8, cscon);
if (ret)
return ret;
}
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 11/20] drm: bridge: dw-hdmi: Remove PHY configuration resolution parameter

[Laurent Pinchart]

From: Kieran Bingham 

The current code hard codes the call of hdmi_phy_configure() to be 8bpp
and provides extraneous error checking to verify that this hardcoded
value is correct. Simplify the implementation by removing the argument.

Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 27 +--
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 107fea49c4c6..b4fb0bd78910 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -930,31 +930,14 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
 }
 
-static int hdmi_phy_configure(struct dw_hdmi *hdmi,
- unsigned char res, int cscon)
+static int hdmi_phy_configure(struct dw_hdmi *hdmi, int cscon)
 {
-   unsigned res_idx;
u8 val, msec;
const struct dw_hdmi_plat_data *pdata = hdmi->plat_data;
const struct dw_hdmi_mpll_config *mpll_config = pdata->mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = pdata->cur_ctr;
const struct dw_hdmi_phy_config *phy_config = pdata->phy_config;
 
-   switch (res) {
-   case 0: /* color resolution 0 is 8 bit colour depth */
-   case 8:
-   res_idx = DW_HDMI_RES_8;
-   break;
-   case 10:
-   res_idx = DW_HDMI_RES_10;
-   break;
-   case 12:
-   res_idx = DW_HDMI_RES_12;
-   break;
-   default:
-   return -EINVAL;
-   }
-
/* PLL/MPLL Cfg - always match on final entry */
for (; mpll_config->mpixelclock != ~0UL; mpll_config++)
if (hdmi->hdmi_data.video_mode.mpixelclock <=
@@ -1004,11 +987,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
HDMI_PHY_I2CM_SLAVE_ADDR);
hdmi_phy_test_clear(hdmi, 0);
 
-   hdmi_phy_i2c_write(hdmi, mpll_config->res[res_idx].cpce, 0x06);
-   hdmi_phy_i2c_write(hdmi, mpll_config->res[res_idx].gmp, 0x15);
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
 
/* CURRCTRL */
-   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[res_idx], 0x10);
+   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
 
hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
@@ -1068,7 +1051,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_powerdown(hdmi, true);
 
/* Enable CSC */
-   ret = hdmi_phy_configure(hdmi, 8, cscon);
+   ret = hdmi_phy_configure(hdmi, cscon);
if (ret)
return ret;
}
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 04/20] drm: bridge: dw-hdmi: Embed drm_bridge in struct dw_hdmi

[Laurent Pinchart]

The drm_bridge instance is always needed, there's no point in allocating
it separately.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 5f8044a7d602..2c85b6c07a80 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -116,7 +116,7 @@ struct dw_hdmi_i2c {
 struct dw_hdmi {
struct drm_connector connector;
struct drm_encoder *encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge bridge;
 
struct platform_device *audio;
enum dw_hdmi_devtype dev_type;
@@ -1806,7 +1806,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
dev_dbg(hdmi->dev, "EVENT=%s\n",
phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
-   drm_helper_hpd_irq_event(hdmi->bridge->dev);
+   drm_helper_hpd_irq_event(hdmi->bridge.dev);
}
 
hdmi_writeb(hdmi, intr_stat, HDMI_IH_PHY_STAT0);
@@ -1819,16 +1819,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
 static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi)
 {
struct drm_encoder *encoder = hdmi->encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *bridge = >bridge;
int ret;
 
-   bridge = devm_kzalloc(drm->dev, sizeof(*bridge), GFP_KERNEL);
-   if (!bridge) {
-   DRM_ERROR("Failed to allocate drm bridge\n");
-   return -ENOMEM;
-   }
-
-   hdmi->bridge = bridge;
bridge->driver_private = hdmi;
bridge->funcs = _hdmi_bridge_funcs;
ret = drm_bridge_attach(encoder, bridge, NULL);
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 05/20] drm: bridge: dw-hdmi: Remove encoder field from struct dw_hdmi

[Laurent Pinchart]

The field isn't needed, remove it.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 2c85b6c07a80..ef10bb866b2f 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -115,7 +115,6 @@ struct dw_hdmi_i2c {
 
 struct dw_hdmi {
struct drm_connector connector;
-   struct drm_encoder *encoder;
struct drm_bridge bridge;
 
struct platform_device *audio;
@@ -1816,9 +1815,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static int dw_hdmi_register(struct drm_device *drm, struct dw_hdmi *hdmi)
+static int dw_hdmi_register(struct drm_encoder *encoder, struct dw_hdmi *hdmi)
 {
-   struct drm_encoder *encoder = hdmi->encoder;
struct drm_bridge *bridge = >bridge;
int ret;
 
@@ -1835,7 +1833,7 @@ static int dw_hdmi_register(struct drm_device *drm, 
struct dw_hdmi *hdmi)
drm_connector_helper_add(>connector,
 _hdmi_connector_helper_funcs);
 
-   drm_connector_init(drm, >connector,
+   drm_connector_init(encoder->dev, >connector,
   _hdmi_connector_funcs,
   DRM_MODE_CONNECTOR_HDMIA);
 
@@ -1867,7 +1865,6 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder 
*encoder,
hdmi->dev = dev;
hdmi->dev_type = plat_data->dev_type;
hdmi->sample_rate = 48000;
-   hdmi->encoder = encoder;
hdmi->disabled = true;
hdmi->rxsense = true;
hdmi->phy_mask = (u8)~(HDMI_PHY_HPD | HDMI_PHY_RX_SENSE);
@@ -1980,7 +1977,7 @@ int dw_hdmi_bind(struct device *dev, struct drm_encoder 
*encoder,
if (ret)
goto err_iahb;
 
-   ret = dw_hdmi_register(encoder->dev, hdmi);
+   ret = dw_hdmi_register(encoder, hdmi);
if (ret)
goto err_iahb;
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v3 09/20] drm: bridge: dw-hdmi: Create connector in the bridge attach operation

[Laurent Pinchart]

The DRM device is not guaranteed by the bridge API to be available
before the attach callback. The driver performs properly at the moment
as it doesn't use the drm_bridge_add() registration method. As this will
be changed later, move connector creation to attach time to ensure
compatibility with the API.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Jose Abreu 
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 92ce9e532603..88cd40adb977 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1667,6 +1667,25 @@ static const struct drm_connector_helper_funcs 
dw_hdmi_connector_helper_funcs =
.best_encoder = drm_atomic_helper_best_encoder,
 };
 
+static int dw_hdmi_bridge_attach(struct drm_bridge *bridge)
+{
+   struct dw_hdmi *hdmi = bridge->driver_private;
+   struct drm_encoder *encoder = bridge->encoder;
+   struct drm_connector *connector = >connector;
+
+   connector->interlace_allowed = 1;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
+
+   drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
+
+   drm_connector_init(bridge->dev, connector, _hdmi_connector_funcs,
+  DRM_MODE_CONNECTOR_HDMIA);
+
+   drm_mode_connector_attach_encoder(connector, encoder);
+
+   return 0;
+}
+
 static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
struct drm_display_mode *orig_mode,
struct drm_display_mode *mode)
@@ -1704,6 +1723,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge 
*bridge)
 }
 
 static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
+   .attach = dw_hdmi_bridge_attach,
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
@@ -1829,17 +1849,6 @@ static int dw_hdmi_register(struct drm_encoder *encoder, 
struct dw_hdmi *hdmi)
return -EINVAL;
}
 
-   hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
-
-   drm_connector_helper_add(>connector,
-_hdmi_connector_helper_funcs);
-
-   drm_connector_init(encoder->dev, >connector,
-  _hdmi_connector_funcs,
-  DRM_MODE_CONNECTOR_HDMIA);
-
-   drm_mode_connector_attach_encoder(>connector, encoder);
-
return 0;
 }
 
@@ -1862,8 +1871,6 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
if (!hdmi)
return -ENOMEM;
 
-   hdmi->connector.interlace_allowed = 1;
-
hdmi->plat_data = plat_data;
hdmi->dev = dev;
hdmi->dev_type = plat_data->dev_type;
-- 
Regards,

Laurent Pinchart

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

Re: drm: rockchip: CONFIG_DRM_FBDEV_EMULATION will crash the HDMI down sometimes

[Mark yao]

static void vop_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
if (WARN_ON(!vop->is_enabled))
return;

The issues seems vop is not enable. but commit planes is using 
DRM_PLANE_COMMIT_ACTIVE_ONLY...


Hi Randy

Can you add some print for this bug:
1, I think vop_crtc_enable function should be call before 
vop_plane_atomic_update, you can add some print to verified it.

2, also add a trace on vop_crtc_disable.
3, print the status of  crtc->state->active and 
plane_crtc_active(plane->state) when bug happen.


Thanks.
On 2017年01月17日 15:58, Randy Li wrote:

Hello:
  I want to enable the video output at RK3288 Firefly board, but I 
found if I enable CONFIG_DRM_FBDEV_EMULATION, the HDMI would crash 
down sometimes but sometimes it works. After disable that opinion, I 
never meet a problem. I have not verified it with eDP as I meet a big 
problem in there.


[  OK  ] Stopped LSB: Load kernel modules needed to enable cpufreq 
scaling.
[   33.282843] [drm:drm_atomic_helper_commit_cleanup_done 
[drm_kms_helper]] *ERROR* [CRTC:27:crtc-0] flip_done timed out

[   33.361489] [ cut here ]
[   33.366251] WARNING: CPU: 2 PID: 476 at 
/home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm$

vop.c:730 vop_plane_atomic_update+0x1218/0x177c [rockchipdrm]
[   33.383071] Modules linked in: rockchip_vop_reg rockchipdrm 
dw_hdmi_rockchip dw_hdmi drm_kms_helper cfbfillrect mali_kbase sys$
opyarea gpio_ir_recv cfbimgblt sysfillrect rc_core dwc2 sysimgblt 
fb_sys_fops panel_simple cfbcopyarea rk_crypto drm nvmem_rockch$
p_efuse udc_core des_generic phy_rockchip_usb pwm_rockchip pwm_bl 
backlight fb
[   33.412751] CPU: 2 PID: 476 Comm: X Tainted: GW 
4.10.0-rc3-next-20170111+ #148

[   33.421182] Hardware name: Rockchip (Device Tree)
[   33.425905] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   33.433652] [] (show_stack) from [] 
(dump_stack+0x8c/0xa0)
[   33.440881] [] (dump_stack) from [] 
(__warn+0xf8/0x110)
[   33.447839] [] (__warn) from [] 
(warn_slowpath_null+0x30/0x38)
[   33.455431] [] (warn_slowpath_null) from [] 
(vop_plane_atomic_update+0x1218/0x177c [rockchipdrm])
[   33.466126] [] (vop_plane_atomic_update [rockchipdrm]) 
from [] (drm_atomic_helper_commit_planes+0xd4/0x2b8

[drm_kms_helper])
[   33.479160] [] (drm_atomic_helper_commit_planes 
[drm_kms_helper]) from [] (rockchip_atomic_commit_tail+0x4$

/0x68 [rockchipdrm])
[   33.492451] [] (rockchip_atomic_commit_tail 
[rockchipdrm]) from [] (commit_tail+0x50/0xb8 [drm_kms_helper]$
[   33.504061] [] (commit_tail [drm_kms_helper]) from 
[] (drm_atomic_helper_commit+0xd4/0x13c [drm_kms_helper$

)
[   33.515850] [] (drm_atomic_helper_commit 
[drm_kms_helper]) from [] (drm_atomic_commit+0x5c/0x68 [drm])
[   33.527126] [] (drm_atomic_commit [drm]) from 
[] (restore_fbdev_mode+0x160/0x300 [drm_kms_helper])
[   33.537952] [] (restore_fbdev_mode [drm_kms_helper]) from 
[] (drm_fb_helper_restore_fbdev_mode_unlocked+0x$

0/0x84 [drm_kms_helper])
[   33.551590] [] (drm_fb_helper_restore_fbdev_mode_unlocked 
[drm_kms_helper]) from [] (rockchip_drm_lastclos$

+0x1c/0x20 [rockchipdrm])
[   33.565404] [] (rockchip_drm_lastclose [rockchipdrm]) 
from [] (drm_lastclose+0x48/0xd8 [drm])
[   33.575977] [] (drm_lastclose [drm]) from [] 
(drm_release+0x2c4/0x36c [drm])
[   33.584927] [] (drm_release [drm]) from [] 
(__fput+0x9c/0x1e8)
[   33.592501] [] (__fput) from [] 
(fput+0x18/0x1c)
[   33.599206] [] (fput) from [] 
(task_work_run+0xcc/0xf0)
[   33.606519] [] (task_work_run) from [] 
(do_work_pending+0xd0/0xd4)
[   33.614439] [] (do_work_pending) from [] 
(slow_work_pending+0xc/0x20)

[   33.622674] ---[ end trace 95ed2c3f167607d2 ]---
[   33.627327] [ cut here ]
[   33.632013] WARNING: CPU: 2 PID: 476 at 
/home/ayaka/workspace/rk3288/kernel/linux-kernel/drivers/gpu/drm/rockchip/rockchip_drm_

vop.c:1017 vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm]
[   33.648542] Modules linked in: rockchip_vop_reg rockchipdrm 
dw_hdmi_rockchip dw_hdmi drm_kms_helper cfbfillrect mali_kbase sysc
opyarea gpio_ir_recv cfbimgblt sysfillrect rc_core dwc2 sysimgblt 
fb_sys_fops panel_simple cfbcopyarea rk_crypto drm nvmem_rockchi
p_efuse udc_core des_generic phy_rockchip_usb pwm_rockchip pwm_bl 
backlight fb
[   33.678191] CPU: 2 PID: 476 Comm: X Tainted: GW 
4.10.0-rc3-next-20170111+ #148

[   33.686621] Hardware name: Rockchip (Device Tree)
[   33.691339] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[   33.699084] [] (show_stack) from [] 
(dump_stack+0x8c/0xa0)
[   33.706309] [] (dump_stack) from [] 
(__warn+0xf8/0x110)
[   33.713275] [] (__warn) from [] 
(warn_slowpath_null+0x30/0x38)
[   33.720864] [] (warn_slowpath_null) from [] 
(vop_crtc_atomic_flush+0x27c/0x2b8 [rockchipdrm])
[   33.731208] [] (vop_crtc_atomic_flush [rockchipdrm]) from 
[] (drm_atomic_helper_commit_planes+0x1d0/0x2b8 [

drm_kms_helper])
[   

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

[Inki Dae]

2017년 01월 17일 04:08에 Gustavo Padovan 이(가) 쓴 글:
> Hi Inki,
> 
> 2017-01-16 Inki Dae :
> 
>> This patch relpaces specific atomic commit function
>> with atomic helper commit one, which also includes
>> atomic_commit_tail callback for Exynos SoC becasue
>> crtc devices on Exynos SoC uses power domain device
>> so drm_atomic_helper_commit_planes should be called
>> after drm_atomic_helper_commit_modeset_enables.
> 
> Indeed, the commit message needs fixing.

Right, above comment should be fixed. 

I will update the comment like below,
"because 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
before drm_atomic_helper_commit_planes function is called. atomic_commit_tail 
callback implements this call ordering."

> 
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   9 ++-
>>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 110 
>> +--
>>  drivers/gpu/drm/exynos/exynos_drm_fb.c   |  25 ++-
>>  3 files changed, 33 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..47da612 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,7 +102,6 @@ static void exynos_crtc_atomic_flush(struct drm_crtc 
>> *crtc,
>>  drm_crtc_send_vblank_event(crtc, event);
>>  spin_unlock_irqrestore(>dev->event_lock, flags);
>>  }
>> -
> 
> Nitpick: I wouldn't include changes like this in the patch.
> 
>>  }
>>  
>>  static const struct drm_crtc_helper_funcs exynos_crtc_helper_funcs = {
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> index 3ec0535..9d0df00 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() step, this way it will always
>> - * have the relevant clocks enabled to perform the update.
>> - */
> 
> Please move this comment to the commit_tail function instead of deleting
> it.

I'm not sure why we have to keep above comment becuase this is why 
atomic_commit_tail callback is added.
For this, I will leave this as a description of this patch like I already left 
my comment above.

> 
>> -
>> -drm_atomic_helper_commit_planes(dev, state, 0);
>> -
>> -drm_atomic_helper_wait_for_vblanks(dev, state);
>> -
>> -drm_atomic_helper_cleanup_planes(dev, state);
>> -
>> -drm_atomic_state_put(state);
>> -
>> -spin_lock(>lock);
>> -priv->pending &= ~commit->crtcs;
>> -spin_unlock(>lock);
>> -
>> -wake_up_all(>wait);
>> -
>> -kfree(commit);
>> -}
>> -
>> -static void exynos_drm_atomic_work(struct work_struct *work)
>> -{
>> -struct exynos_atomic_commit *commit = container_of(work,
>> -struct exynos_atomic_commit, work);
>> -
>> -exynos_atomic_commit_complete(commit);
>> -}
>> -
>>  static struct device *exynos_drm_get_dma_device(void);
>>  
>>  static int exynos_drm_load(struct drm_device *dev, unsigned long flags)
>> @@ -202,65 +152,6 @@ static void exynos_drm_unload(struct drm_device *dev)
>>  dev->dev_private = NULL;
>>  }
>>  
>> -static int commit_is_pending(struct exynos_drm_private *priv, u32 crtcs)
>> -{
>> -bool pending;
>> -
>> -spin_lock(>lock);
>> -pending = 

Re: [PATCH 1/4] drm/atomic: Save flip flags in drm_plane_state

[Ville Syrjälä]

On Mon, Jan 16, 2017 at 10:44:55AM -0500, Andrey Grodzovsky wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_plane_state
> to be used in the low level drivers.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
>  include/drm/drm_plane.h |  8 
>  2 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a4e5477..f83dc43 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2737,7 +2737,8 @@ static int page_flip_common(
>   struct drm_atomic_state *state,
>   struct drm_crtc *crtc,
>   struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event)
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
>  {
>   struct drm_plane *plane = crtc->primary;
>   struct drm_plane_state *plane_state;
> @@ -2754,6 +2755,7 @@ static int page_flip_common(
>   if (IS_ERR(plane_state))
>   return PTR_ERR(plane_state);
>  
> + plane_state->pflip_flags = flags;

"pflip" looks off. Better just spell it out.

These flags need to be reset in duplicate_state otherwise they leak into
subsequent operations. This is why I don't really like the concept of
"state" containing flags and stuff that are not really part of the
state but rather part of the operation of moving from the old state to
the new state. But maybe we don't have a better place for this sort of
stuff? I have suggested at some point that we might rename drm_atomic_state
to drm_atomic_transaction or something. Stuffing the flags (or just a bool
perhaps?) in there might be less confusing.

>  
>   ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
>   if (ret != 0)
> @@ -2800,9 +2802,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   struct drm_atomic_state *state;
>   int ret = 0;
>  
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
>   state = drm_atomic_state_alloc(plane->dev);
>   if (!state)
>   return -ENOMEM;
> @@ -2865,9 +2864,6 @@ int drm_atomic_helper_page_flip_target(
>   struct drm_crtc_state *crtc_state;
>   int ret = 0;
>  
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
>   state = drm_atomic_state_alloc(plane->dev);
>   if (!state)
>   return -ENOMEM;
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index db3bbde..86d8ffc 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -122,6 +122,14 @@ struct drm_plane_state {
>*/
>   bool visible;
>  
> +
> + /**
> +  * @pflip_flags:
> +  *
> +  * Flip related config options
> +  */
> + u32 pflip_flags;
> +
>   struct drm_atomic_state *state;
>  };
>  
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
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

[bugzilla-daemon]

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

--- Comment #5 from lei.p...@gmail.com ---
(In reply to lei.pero from comment #2)
> Created attachment 128993 [details]
> glxinfo

(In reply to Michel Dänzer from comment #1)
> Please attach the corresponding Xorg log file and output of glxinfo.

Sure, files attached. To be more accurate, it's like "ghosting" when scrolling
with DRI3 on most pages (google search results, phoronix forum etc.), even tho
CRT displays do not ghost.

-- 
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 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

[bugzilla-daemon]

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

--- Comment #4 from lei.p...@gmail.com ---
Created attachment 128995
  --> https://bugs.freedesktop.org/attachment.cgi?id=128995=edit
Xorg.1

DRI2

-- 
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 99418] DRI3 Stuttering while scrolling in Chromium/Chrome with VBLANK off

[bugzilla-daemon]

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

--- Comment #3 from lei.p...@gmail.com ---
Created attachment 128994
  --> https://bugs.freedesktop.org/attachment.cgi?id=128994=edit
Xorg.0

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