Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

[Eric Anholt]

Ville Syrjälä  writes:

> On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote:
>> On Fri, 11 May 2018 20:29:48 +0300
>> Ville Syrjälä  wrote:
>> 
>> > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote:
>> > > On Fri, 11 May 2018 19:54:02 +0300
>> > > Ville Syrjälä  wrote:
>> > >   
>> > > > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote:  
>> > > > > On Fri, 11 May 2018 18:34:50 +0300
>> > > > > Ville Syrjälä  wrote:
>> > > > > 
>> > > > > > On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote:   
>> > > > > >  
>> > > > > > > Applying an underscan setup is just a matter of scaling all 
>> > > > > > > planes
>> > > > > > > appropriately and adjusting the CRTC X/Y offset to account for 
>> > > > > > > the
>> > > > > > > horizontal and vertical border.
>> > > > > > > 
>> > > > > > > Create an vc4_plane_underscan_adj() function doing that and call 
>> > > > > > > it from
>> > > > > > > vc4_plane_setup_clipping_and_scaling() so that we are ready to 
>> > > > > > > attach
>> > > > > > > underscan properties to the HDMI connector.
>> > > > > > > 
>> > > > > > > Signed-off-by: Boris Brezillon 
>> > > > > > > ---
>> > > > > > > Changes in v2:
>> > > > > > > - Take changes on hborder/vborder meaning into account
>> > > > > > > ---
>> > > > > > >  drivers/gpu/drm/vc4/vc4_plane.c | 49 
>> > > > > > > -
>> > > > > > >  1 file changed, 48 insertions(+), 1 deletion(-)
>> > > > > > > 
>> > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_plane.c 
>> > > > > > > b/drivers/gpu/drm/vc4/vc4_plane.c
>> > > > > > > index 71d44c357d35..61ed60841cd6 100644
>> > > > > > > --- a/drivers/gpu/drm/vc4/vc4_plane.c
>> > > > > > > +++ b/drivers/gpu/drm/vc4/vc4_plane.c
>> > > > > > > @@ -258,6 +258,49 @@ static u32 vc4_get_scl_field(struct 
>> > > > > > > drm_plane_state *state, int plane)
>> > > > > > >  }
>> > > > > > >  }
>> > > > > > >  
>> > > > > > > +static int vc4_plane_underscan_adj(struct drm_plane_state 
>> > > > > > > *pstate)
>> > > > > > > +{
>> > > > > > > +struct vc4_plane_state *vc4_pstate = 
>> > > > > > > to_vc4_plane_state(pstate);
>> > > > > > > +struct drm_connector_state *conn_state = NULL;
>> > > > > > > +struct drm_connector *conn;
>> > > > > > > +struct drm_crtc_state *crtc_state;
>> > > > > > > +int i;
>> > > > > > > +
>> > > > > > > +for_each_new_connector_in_state(pstate->state, conn, 
>> > > > > > > conn_state, i) {
>> > > > > > > +if (conn_state->crtc == pstate->crtc)
>> > > > > > > +break;
>> > > > > > > +}
>> > > > > > > +
>> > > > > > > +if (i == pstate->state->num_connector)
>> > > > > > > +return 0;
>> > > > > > > +
>> > > > > > > +if (conn_state->underscan.mode != DRM_UNDERSCAN_ON)
>> > > > > > > +return 0;
>> > > > > > > +
>> > > > > > > +crtc_state = 
>> > > > > > > drm_atomic_get_new_crtc_state(pstate->state,
>> > > > > > > +   
>> > > > > > > pstate->crtc);
>> > > > > > > +
>> > > > > > > +if (conn_state->underscan.hborder >= 
>> > > > > > > crtc_state->mode.hdisplay ||
>> > > > > > > +conn_state->underscan.vborder >= 
>> > > > > > > crtc_state->mode.vdisplay)
>> > > > > > > +return -EINVAL;  
>> > > > > > 
>> > > > > > border * 2 ?
>> > > > > 
>> > > > > Oops, indeed. I'll fix that.
>> > > > > 
>> > > > > > 
>> > > > > > > +
>> > > > > > > +vc4_pstate->crtc_x += conn_state->underscan.hborder;
>> > > > > > > +vc4_pstate->crtc_y += conn_state->underscan.vborder;
>> > > > > > > +vc4_pstate->crtc_w = (vc4_pstate->crtc_w *
>> > > > > > > +  (crtc_state->mode.hdisplay -
>> > > > > > > +   (conn_state->underscan.hborder * 
>> > > > > > > 2))) /
>> > > > > > > + crtc_state->mode.hdisplay;
>> > > > > > > +vc4_pstate->crtc_h = (vc4_pstate->crtc_h *
>> > > > > > > +  (crtc_state->mode.vdisplay -
>> > > > > > > +   (conn_state->underscan.vborder * 
>> > > > > > > 2))) /
>> > > > > > > + crtc_state->mode.vdisplay;  
>> > > > > > 
>> > > > > > So you're now scaling all planes? The code seems to reject scaling 
>> > > > > > for
>> > > > > > the cursor plane, how are you dealing with that? Or just no cursor
>> > > > > > allowed when underscanning?
>> > > > > 
>> > > > > No, I just didn't test with a cursor plane. We should probably avoid
>> > > > > scaling the cursor plane and just adjust its position. Eric any 
>> > > > > opinion
>> > > > > on that?
>> > > > 
>> > > > I don't think you can just not 

Re: [PATCH 1/4] drm/panel: otm8009a: fix backlight updates

[Vincent ABRIOU]

Hi Philippe,

Reviewed-by: Vincent Abriou 

BR
Vincent

On 04/23/2018 04:10 PM, Philippe Cornu wrote:
> Backlight updates was not working anymore since the good
> implementation of the dsi lpm mode in the dsi host driver.
> After a longer analysis, the backlight updates in dsi video
> mode require the dsi hs mode.
> Note: it is important to keep the dsi lpm mode for the rest
> of the driver as init sequence, sleep in/out... dsi commands
> work in lp mode.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 18 --
>   1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> index 90f1ae4af93c..0fd2e0144d2b 100644
> --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> @@ -98,6 +98,20 @@ static void otm8009a_dcs_write_buf(struct otm8009a *ctx, 
> const void *data,
>   DRM_WARN("mipi dsi dcs write buffer failed\n");
>   }
>   
> +static void otm8009a_dcs_write_buf_hs(struct otm8009a *ctx, const void *data,
> +   size_t len)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> + /* data will be sent in dsi hs mode (ie. no lpm) */
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + otm8009a_dcs_write_buf(ctx, data, len);
> +
> + /* restore back the dsi lpm mode */
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +}
> +
>   #define dcs_write_seq(ctx, seq...)  \
>   ({  \
>   static const u8 d[] = { seq };  \
> @@ -387,7 +401,7 @@ static int otm8009a_backlight_update_status(struct 
> backlight_device *bd)
>*/
>   data[0] = MIPI_DCS_SET_DISPLAY_BRIGHTNESS;
>   data[1] = bd->props.brightness;
> - otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data));
> + otm8009a_dcs_write_buf_hs(ctx, data, ARRAY_SIZE(data));
>   
>   /* set Brightness Control & Backlight on */
>   data[1] = 0x24;
> @@ -399,7 +413,7 @@ static int otm8009a_backlight_update_status(struct 
> backlight_device *bd)
>   
>   /* Update Brightness Control & Backlight */
>   data[0] = MIPI_DCS_WRITE_CONTROL_DISPLAY;
> - otm8009a_dcs_write_buf(ctx, data, ARRAY_SIZE(data));
> + otm8009a_dcs_write_buf_hs(ctx, data, ARRAY_SIZE(data));
>   
>   return 0;
>   }
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] drm/panel: otm8009a: no message if probe success

[Vincent ABRIOU]

Hi Philippe,

Reviewed-by: Vincent Abriou 

BR
Vincent

On 04/23/2018 04:10 PM, Philippe Cornu wrote:
> Remove the message in case of probe success. This comes from
> a suggestion followed in the recent integration of the
> raydium rm68200 panel.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 11 ++-
>   1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> index de4a16d5275c..4c638b7b9943 100644
> --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> @@ -14,8 +14,6 @@
>   #include 
>   #include 
>   
> -#define DRV_NAME "orisetech_otm8009a"
> -
>   #define OTM8009A_BACKLIGHT_DEFAULT  240
>   #define OTM8009A_BACKLIGHT_MAX  255
>   
> @@ -461,7 +459,7 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
>   ctx->panel.dev = dev;
>   ctx->panel.funcs = _drm_funcs;
>   
> - ctx->bl_dev = backlight_device_register(DRV_NAME "_backlight", dev, ctx,
> + ctx->bl_dev = backlight_device_register(dev_name(dev), dev, ctx,
>   _backlight_ops, NULL);
>   if (IS_ERR(ctx->bl_dev)) {
>   dev_err(dev, "failed to register backlight device\n");
> @@ -483,11 +481,6 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
>   return ret;
>   }
>   
> - DRM_INFO(DRV_NAME "_panel %ux%u@%u %ubpp dsi %udl - ready\n",
> -  default_mode.hdisplay, default_mode.vdisplay,
> -  default_mode.vrefresh,
> -  mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
> -
>   return 0;
>   }
>   
> @@ -513,7 +506,7 @@ static struct mipi_dsi_driver orisetech_otm8009a_driver = 
> {
>   .probe  = otm8009a_probe,
>   .remove = otm8009a_remove,
>   .driver = {
> - .name = DRV_NAME "_panel",
> + .name = "panel-orisetech-otm8009a",
>   .of_match_table = orisetech_otm8009a_of_match,
>   },
>   };
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] drm/panel: otm8009a: fix glitches by moving backlight enable to otm8009a_enable()

[Vincent ABRIOU]

Hi Philippe,

Reviewed-by: Vincent Abriou 

BR
Vincent

On 04/23/2018 04:10 PM, Philippe Cornu wrote:
> The backlight 1st update was in the otm8009a_prepare() function
> for a bad reason: backlight was not working in video mode and the
> otm8009a_prepare() is in command mode for the init sequence. As the
> backlight is now fixed (no lpm), it is good to put it back in the
> otm8009a_enable() function, avoiding also image glitches visible
> on some "slow" devices.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 17 ++---
>   1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> index 0fd2e0144d2b..de4a16d5275c 100644
> --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> @@ -330,13 +330,6 @@ static int otm8009a_prepare(struct drm_panel *panel)
>   
>   ctx->prepared = true;
>   
> - /*
> -  * Power on the backlight. Note: end-user still controls brightness
> -  * Note: ctx->prepared must be true before updating the backlight.
> -  */
> - ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
> - backlight_update_status(ctx->bl_dev);
> -
>   return 0;
>   }
>   
> @@ -344,6 +337,16 @@ static int otm8009a_enable(struct drm_panel *panel)
>   {
>   struct otm8009a *ctx = panel_to_otm8009a(panel);
>   
> + if (ctx->enabled)
> + return 0;
> +
> + /*
> +  * Power on the backlight. Note: end-user still controls brightness
> +  * Note: ctx->prepared must be true before updating the backlight.
> +  */
> + ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
> + backlight_update_status(ctx->bl_dev);
> +
>   ctx->enabled = true;
>   
>   return 0;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/tegra: Fix order of teardown in IOMMU case

[Thierry Reding]

On Mon, Apr 23, 2018 at 11:35:14AM +0300, Dmitry Osipenko wrote:
> On 23.04.2018 09:57, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > The original code works fine, this is merely a cosmetic change to make
> > the teardown order the reverse of the setup order.
> > 
> > Signed-off-by: Thierry Reding 
> Reviewed-by: Dmitry Osipenko 

Applied, thanks.

Thierry


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

RE: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

May be calling enable/disable sequence separately will be better :)

>
>Implements a sequence of enabling and disabling the HDCP2.2 (auth and
>encryption).
>
>v2:
>  Rebased.
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 75
>+++
> 1 file changed, 75 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 91cac643f083..005627746ca5 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -21,6 +21,9 @@
> #define HDCP2_LC_RETRY_CNT3
> #define TIME_FOR_ENCRYPT_STATUS_CHANGE32
>
>+static int _intel_hdcp2_enable(struct intel_connector *connector);
>+static int _intel_hdcp2_disable(struct intel_connector *connector);
>+
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim)  { @@ -
>1384,3 +1387,75 @@ static int hdcp2_disable_encryption(struct intel_connector
>*connector)
>
>   return ret;
> }
>+
>+static int hdcp2_authenticate_and_encrypt(struct intel_connector
>+*connector) {
>+  int ret, i, tries = 3;
>+
>+  for (i = 0; i < tries; i++) {
>+  ret = hdcp2_authenticate_sink(connector);
>+  if (!ret)
>+  break;
>+
>+  /* Clearing the mei hdcp session */
>+  hdcp2_deauthenticate_port(>hdcp);
>+  DRM_DEBUG_KMS("HDCP2.2 Auth %d of %d Failed.(%d)\n",
>+i + 1, tries, ret);
>+  }
>+
>+  if (i != tries) {
>+
>+  /*
>+   * Ensuring the required 200mSec min time interval between
>+   * Session Key Exchange and encryption.
>+   */
>+  msleep(HDCP_2_2_DELAY_BEFORE_ENCRYPTION_EN);
>+  ret = hdcp2_enable_encryption(connector);
>+  if (ret < 0) {
>+  DRM_DEBUG_KMS("Encryption Enable Failed.(%d)\n",
>ret);
>+  hdcp2_deauthenticate_port(>hdcp);
>+  }
>+  }
>+
>+  return ret;
>+}
>+
>+static int _intel_hdcp2_disable(struct intel_connector *connector) {
>+  int ret;
>+
>+  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
>+connector->base.name, connector->base.base.id);
>+
>+  ret = hdcp2_disable_encryption(connector);

Check for return and print a message.

>+
>+  hdcp2_deauthenticate_port(>hdcp);
>+
>+  return ret;
>+}
>+
>+static int _intel_hdcp2_enable(struct intel_connector *connector) {
>+  struct intel_hdcp *hdcp = >hdcp;
>+  int ret;
>+
>+  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being enabled. Type: %d\n",
>+connector->base.name, connector->base.base.id,
>+hdcp->content_type);
>+
>+  ret = hdcp2_authenticate_and_encrypt(connector);
>+  if (ret) {
>+  DRM_ERROR("HDCP2 Type%d  Enabling Failed. (%d)\n",
>+ hdcp->content_type, ret);
>+  return ret;
>+  }
>+
>+  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is enabled. Type %d\n",
>+connector->base.name, connector->base.base.id,
>+hdcp->content_type);
>+
>+  hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+  schedule_work(>hdcp_prop_work);
>+
>+  return 0;
>+}
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
;>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97025] flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #28 from Michel Dänzer  ---
(In reply to Bernd Steinhauser from comment #27)
> 
> Although I'm not sure if it works as expected, since the display does still
> seem to disconnect when I turn the screen off.

AFAIK that's either a monitor or general DisplayPort issue. The drivers can't
prevent it but have to cope with it.

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

Re: [PATCH 4/4] drm/panel: otm8009a: use new backlight api

[Vincent ABRIOU]

Hi Philippe,

Reviewed-by: Vincent Abriou 

BR
Vincent

On 04/23/2018 04:10 PM, Philippe Cornu wrote:
> Use the new backlight api.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 26 
> 
>   1 file changed, 9 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c 
> b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> index 4c638b7b9943..c2a71bd17e08 100644
> --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> @@ -260,11 +260,7 @@ static int otm8009a_disable(struct drm_panel *panel)
>   if (!ctx->enabled)
>   return 0; /* This is not an issue so we return 0 here */
>   
> - /* Power off the backlight. Note: end-user still controls brightness */
> - ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
> - ret = backlight_update_status(ctx->bl_dev);
> - if (ret)
> - return ret;
> + backlight_disable(ctx->bl_dev);
>   
>   ret = mipi_dsi_dcs_set_display_off(dsi);
>   if (ret)
> @@ -338,12 +334,7 @@ static int otm8009a_enable(struct drm_panel *panel)
>   if (ctx->enabled)
>   return 0;
>   
> - /*
> -  * Power on the backlight. Note: end-user still controls brightness
> -  * Note: ctx->prepared must be true before updating the backlight.
> -  */
> - ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
> - backlight_update_status(ctx->bl_dev);
> + backlight_enable(ctx->bl_dev);
>   
>   ctx->enabled = true;
>   
> @@ -459,11 +450,14 @@ static int otm8009a_probe(struct mipi_dsi_device *dsi)
>   ctx->panel.dev = dev;
>   ctx->panel.funcs = _drm_funcs;
>   
> - ctx->bl_dev = backlight_device_register(dev_name(dev), dev, ctx,
> - _backlight_ops, NULL);
> + ctx->bl_dev = devm_backlight_device_register(dev, dev_name(dev),
> +  dsi->host->dev, ctx,
> +  _backlight_ops,
> +  NULL);
>   if (IS_ERR(ctx->bl_dev)) {
> - dev_err(dev, "failed to register backlight device\n");
> - return PTR_ERR(ctx->bl_dev);
> + ret = PTR_ERR(ctx->bl_dev);
> + dev_err(dev, "failed to register backlight %d\n", ret);
> + return ret;
>   }
>   
>   ctx->bl_dev->props.max_brightness = OTM8009A_BACKLIGHT_MAX;
> @@ -491,8 +485,6 @@ static int otm8009a_remove(struct mipi_dsi_device *dsi)
>   mipi_dsi_detach(dsi);
>   drm_panel_remove(>panel);
>   
> - backlight_device_unregister(ctx->bl_dev);
> -
>   return 0;
>   }
>   
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] gpu: host1x: Fix dma_free_wc() argument in the error path

[Thierry Reding]

On Mon, Apr 23, 2018 at 12:54:56PM +0300, Dmitry Osipenko wrote:
> If IOVA allocation or IOMMU mapping fails, dma_free_wc() is invoked with
> size=0 because of a typo, that triggers "kernel BUG at mm/vmalloc.c:124!".
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/host1x/cdma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Thierry


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

Re: [PATCH 2/2] drm/tegra: Acquire a reference to the IOVA cache

[Thierry Reding]

On Mon, Apr 23, 2018 at 11:43:16AM +0300, Dmitry Osipenko wrote:
> On 23.04.2018 11:41, Dmitry Osipenko wrote:
> > On 23.04.2018 11:34, Dmitry Osipenko wrote:
> >> On 23.04.2018 09:57, Thierry Reding wrote:
> >>> From: Thierry Reding 
> >>>
> >>> The IOVA API uses a memory cache to allocate IOVA nodes from. To make
> >>> sure that this cache is available, obtain a reference to it and release
> >>> the reference when the cache is no longer needed.
> >>>
> >>> On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
> >>> that reference and never releases it. On 32-bit ARM, however, the DMA
> >>> mapping API doesn't do that, so allocation of IOVA nodes fails.
> >>>
> >>> Signed-off-by: Thierry Reding 
> >>> ---
> >>
> >> Reviewed-by: Dmitry Osipenko 
> >> Tested-by: Dmitry Osipenko 
> >>
> >> CONFIG_TEGRA_IOMMU_SMMU is enabled in the default kernel configs and hence 
> >> DRM
> >> should fail to probe on t124 since 4.11. What about to add stable tag for 
> >> v4.11+
> >> here to unbreak stable kernels as well?
> > 
> > IOMMU node for host1x was added to t124 DT in kernel v4.14, so s/4.11/4.14/.
> 
> On the other hand nothing stops to use newer DT with older kernel.

I've applied this and added:

Fixes: ad92601521ea ("drm/tegra: Add Tegra DRM allocation API")

Since that's the commit that introduced the iova API usage. It seems
like we also need a fix in drivers/gpu/host1x to grab a reference to
this IOVA cache because the host1x driver also makes use of that. It
looks as if this patch currently papers over that bug, and there's
very little chance that anyone will use the host1x driver without the
Tegra DRM driver. However, it's probably best to still fix it to avoid
future exposure.

I'll go type that patch up now.

Thierry


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

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

[Gerd Hoffmann]

  Hi,

> > So my expectation that a backmerge happens anyway after -rc1/2 is in
> > line with reality, it is just to be delayed this time.  I'll stay
> > tuned ;)
> 
> Is this patch already merged in drm-misc-next tree ?

Pushed now.

cheers,
  Gerd

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

RE: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication

[Shankar, Uma]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater
>authentication
>
>Implements the HDCP2.2 repeaters authentication steps such as verifying the
>downstream topology and sending stream management information.
>
>v2:
>  Rebased.
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 135
>++
> 1 file changed, 135 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index ee9b7519fe73..d70320da85e4 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -1145,6 +1145,135 @@ static int hdcp2_session_key_exchange(struct
>intel_connector *connector)
>   return 0;
> }
>
>+/*
>+ * Lib endianness functions are aligned for 16/32/64 bits. Since here
>+sequence
>+ * num is 24bits developed a small conversion function.
>+ */
>+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)

This function is already defined and used in mei layer. Define this in some
common header file and use instead of duplicating it here.  May be in below 
file:  


>+{
>+  u32 index;
>+
>+  if (dest != NULL && dst_sz != 0) {
>+  for (index = 0; index < dst_sz && index < sizeof(u32);
>+   index++) {
>+  dest[dst_sz - index - 1] = src[index];
>+  }
>+  }
>+}
>+
>+static
>+int hdcp2_propagate_stream_management_info(struct intel_connector
>+*connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  union {
>+  struct hdcp2_rep_stream_manage stream_manage;
>+  struct hdcp2_rep_stream_ready stream_ready;
>+  } msgs;
>+  const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
>+  int ret;
>+
>+  /* Prepare RepeaterAuth_Stream_Manage msg */
>+  msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
>+  reverse_endianness(msgs.stream_manage.seq_num_m,
>HDCP_2_2_SEQ_NUM_LEN,
>+ (u8 *)>seq_num_m);
>+
>+  /* K no of streams is fixed as 1. Stored as big-endian. */
>+  msgs.stream_manage.k = __swab16(1);
>+
>+  /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
>+  msgs.stream_manage.streams[0].stream_id = 0;
>+  msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
>+
>+  /* Send it to Repeater */
>+  ret = shim->write_2_2_msg(intel_dig_port, _manage,
>+sizeof(msgs.stream_manage));
>+  if (ret < 0)
>+  return ret;
>+
>+  ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_STREAM_READY,
>+   _ready,
>sizeof(msgs.stream_ready));
>+  if (ret < 0)
>+  return ret;
>+
>+  hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
>+  hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
>+
>+  ret = hdcp2_verify_mprime(hdcp, _ready);
>+  if (ret < 0)
>+  return ret;
>+
>+  hdcp->seq_num_m++;
>+
>+  if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
>+  DRM_DEBUG_KMS("seq_num_m roll over.\n");
>+  return -1;
>+  }

Leave a blank line.

>+  return 0;
>+}
>+
>+static
>+int hdcp2_authenticate_repeater_topology(struct intel_connector
>+*connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  union {
>+  struct hdcp2_rep_send_receiverid_list recvid_list;
>+  struct hdcp2_rep_send_ack rep_ack;
>+  } msgs;
>+  const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
>+  uint8_t *rx_info;
>+  uint32_t seq_num_v;
>+  int ret;
>+
>+  ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_SEND_RECVID_LIST,
>+   _list, sizeof(msgs.recvid_list));
>+  if (ret < 0)
>+  return ret;
>+
>+  rx_info = msgs.recvid_list.rx_info;
>+
>+  if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
>+  HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
>+  DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
>+  return -1;
>+  }
>+
>+  /* Converting and Storing the seq_num_v to local variable as DWORD */
>+  reverse_endianness((u8 *)_num_v, HDCP_2_2_SEQ_NUM_LEN,
>+ msgs.recvid_list.seq_num_v);
>+
>+  if (seq_num_v < hdcp->seq_num_v) {
>+  

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

[Liviu Dudau]

On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the erorrs,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA models which have a lot of constrains, so we could easily
> end up in AXI or underrun errors.
> 
> Add a new file called debug that contains an agregate of the
> errors reported by the Mali DP hardware.
> 
> E.g:
> [root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
> [DE] num_errors : 167
> [DE] last_error_status  : 0x0001
> [DE] last_error_vblank : 385
> [SE] num_errors : 3
> [SE] last_error_status  : 0x00e23001
> [SE] last_error_vblank : 201
> 
> This a morphosis of the patch presented here [1], where the errors
> where reported continuously via trace_printk.
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167042.html
> 
> Signed-off-by: Alexandru Gheorghe 

Acked-by: Liviu Dudau 

> ---
>  drivers/gpu/drm/arm/malidp_drv.c  | 61 
> +++
>  drivers/gpu/drm/arm/malidp_drv.h  | 15 ++
>  drivers/gpu/drm/arm/malidp_hw.c   | 46 -
>  drivers/gpu/drm/arm/malidp_hw.h   |  1 +
>  drivers/gpu/drm/arm/malidp_regs.h |  6 
>  5 files changed, 122 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 8d20faa..70ce19a 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -29,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "malidp_drv.h"
>  #include "malidp_regs.h"
> @@ -327,6 +329,62 @@ static int malidp_dumb_create(struct drm_file *file_priv,
>   return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
>  }
>  
> +#ifdef CONFIG_DEBUG_FS
> +
> +static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
> +{
> + atomic_set(_stats->num_errors, 0);
> + atomic_set(_stats->last_error_status, 0);
> + atomic64_set(_stats->last_error_vblank, -1);
> +}
> +
> +void malidp_error(struct malidp_error_stats *error_stats, u32 status,
> +   u64 vblank)
> +{
> + atomic_set(_stats->last_error_status, status);
> + atomic64_set(_stats->last_error_vblank, vblank);
> + atomic_inc(_stats->num_errors);
> +}
> +
> +void malidp_error_stats_dump(const char *prefix,
> +  struct malidp_error_stats *error_stats,
> +  struct seq_file *m)
> +{
> + seq_printf(m, "[%s] num_errors : %d\n", prefix,
> +atomic_read(_stats->num_errors));
> + seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
> +atomic_read(_stats->last_error_status));
> + seq_printf(m, "[%s] last_error_vblank : %ld\n", prefix,
> +atomic64_read(_stats->last_error_vblank));
> +}
> +
> +static int malidp_show_stats(struct seq_file *m, void *arg)
> +{
> + struct drm_info_node *node = (struct drm_info_node *)m->private;
> + struct drm_device *drm = node->minor->dev;
> + struct malidp_drm *malidp = drm->dev_private;
> +
> + malidp_error_stats_dump("DE", >de_errors, m);
> + malidp_error_stats_dump("SE", >se_errors, m);
> + return 0;
> +}
> +
> +static struct drm_info_list malidp_debugfs_list[] = {
> + { "debug", malidp_show_stats, 0 },
> +};
> +
> +static int malidp_debugfs_init(struct drm_minor *minor)
> +{
> + struct malidp_drm *malidp = minor->dev->dev_private;
> +
> + malidp_error_stats_init(>de_errors);
> + malidp_error_stats_init(>se_errors);
> + return drm_debugfs_create_files(malidp_debugfs_list,
> + ARRAY_SIZE(malidp_debugfs_list), minor->debugfs_root, minor);
> +}
> +
> +#endif //CONFIG_DEBUG_FS
> +
>  static struct drm_driver malidp_driver = {
>   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
>  DRIVER_PRIME,
> @@ -343,6 +401,9 @@ static struct drm_driver malidp_driver = {
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
>   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
>   .gem_prime_mmap = drm_gem_cma_prime_mmap,
> +#ifdef CONFIG_DEBUG_FS
> + .debugfs_init = malidp_debugfs_init,
> +#endif
>   .fops = ,
>   .name = "mali-dp",
>   .desc = "ARM Mali Display Processor driver",
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h 
> b/drivers/gpu/drm/arm/malidp_drv.h
> index c70989b..c49056c 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -18,6 +18,12 @@
>  #include 
>  #include "malidp_hw.h"
>  
> +struct malidp_error_stats {
> + atomic_t num_errors;
> + atomic_t last_error_status;
> + atomic64_t last_error_vblank;
> +};
> +
>  struct malidp_drm 

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

[Brian Starkey]

Hi Alex,

On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:

Status register contains a lot of bits for reporting internal errors
inside Mali DP. Currently, we just silently ignore all of the erorrs,


Being picky: s/erorrs/errors/


that doesn't help when we are investigating different bugs, especially
on the FPGA models which have a lot of constrains, so we could easily


s/constrains/constraints/


end up in AXI or underrun errors.

Add a new file called debug that contains an agregate of the


s/agregate/aggregate/


errors reported by the Mali DP hardware.

E.g:
[root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
[DE] num_errors : 167
[DE] last_error_status  : 0x0001
[DE] last_error_vblank : 385
[SE] num_errors : 3
[SE] last_error_status  : 0x00e23001
[SE] last_error_vblank : 201

This a morphosis of the patch presented here [1], where the errors
where reported continuously via trace_printk.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167042.html

Signed-off-by: Alexandru Gheorghe 
---
drivers/gpu/drm/arm/malidp_drv.c  | 61 +++
drivers/gpu/drm/arm/malidp_drv.h  | 15 ++
drivers/gpu/drm/arm/malidp_hw.c   | 46 -
drivers/gpu/drm/arm/malidp_hw.h   |  1 +
drivers/gpu/drm/arm/malidp_regs.h |  6 
5 files changed, 122 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 8d20faa..70ce19a 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -17,6 +17,7 @@
#include 
#include 
#include 
+#include 

#include 
#include 
@@ -29,6 +30,7 @@
#include 
#include 
#include 
+#include 

#include "malidp_drv.h"
#include "malidp_regs.h"
@@ -327,6 +329,62 @@ static int malidp_dumb_create(struct drm_file *file_priv,
return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
}

+#ifdef CONFIG_DEBUG_FS
+
+static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
+{
+   atomic_set(_stats->num_errors, 0);
+   atomic_set(_stats->last_error_status, 0);
+   atomic64_set(_stats->last_error_vblank, -1);
+}
+
+void malidp_error(struct malidp_error_stats *error_stats, u32 status,
+ u64 vblank)
+{
+   atomic_set(_stats->last_error_status, status);
+   atomic64_set(_stats->last_error_vblank, vblank);
+   atomic_inc(_stats->num_errors);
+}
+


Do we already have a lock we could use to make sure the status printed
is consistent? I know this is "only debug", but it could be annoying
if we can't trust that the last_error_status does actually match the
last_error_vblank.


+void malidp_error_stats_dump(const char *prefix,
+struct malidp_error_stats *error_stats,
+struct seq_file *m)
+{
+   seq_printf(m, "[%s] num_errors : %d\n", prefix,
+  atomic_read(_stats->num_errors));
+   seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
+  atomic_read(_stats->last_error_status));
+   seq_printf(m, "[%s] last_error_vblank : %ld\n", prefix,
+  atomic64_read(_stats->last_error_vblank));
+}
+
+static int malidp_show_stats(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *drm = node->minor->dev;
+   struct malidp_drm *malidp = drm->dev_private;
+
+   malidp_error_stats_dump("DE", >de_errors, m);
+   malidp_error_stats_dump("SE", >se_errors, m);
+   return 0;
+}
+
+static struct drm_info_list malidp_debugfs_list[] = {
+   { "debug", malidp_show_stats, 0 },
+};


I think it would be pretty useful to have a way to reset the counters.
Maybe by just writing anything to the file?

Thanks,
-Brian


+
+static int malidp_debugfs_init(struct drm_minor *minor)
+{
+   struct malidp_drm *malidp = minor->dev->dev_private;
+
+   malidp_error_stats_init(>de_errors);
+   malidp_error_stats_init(>se_errors);
+   return drm_debugfs_create_files(malidp_debugfs_list,
+   ARRAY_SIZE(malidp_debugfs_list), minor->debugfs_root, minor);
+}
+
+#endif //CONFIG_DEBUG_FS
+
static struct drm_driver malidp_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
   DRIVER_PRIME,
@@ -343,6 +401,9 @@ static struct drm_driver malidp_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
+#ifdef CONFIG_DEBUG_FS
+   .debugfs_init = malidp_debugfs_init,
+#endif
.fops = ,
.name = "mali-dp",
.desc = "ARM Mali Display Processor driver",
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index c70989b..c49056c 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -18,6 +18,12 @@

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

[Philippe CORNU]

Hi Rob & Laurent :)

On 04/26/2018 12:05 AM, Laurent Pinchart wrote:
> Hi Rob,
> 
> On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote:
>> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote:
>>> On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
 On 04/25/2018 11:01 AM, Laurent Pinchart wrote:
> On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
>> Add optional power supplies using the description found in
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> There is a single 1v2 supply voltage named vcc12 from which cvcc12
>> (digital core) and avcc12 (TMDS analog) are derived because according
>> to this data sheet:
>> "cvcc12 and avcc12 can be derived from the same power source"
>
> Shouldn't the power supplies be mandatory, as explained by Mark in
> https://lists.freedesktop.org/archives/dri-devel/2018-April/172400.html
> ?

 Laurent,
 Many thanks Laurent for your comment, I understood the merge of the two
 1v2 power supplies but missed the "mandatory" part... maybe because this
 patch (with optional power supplies) already got the reviewed-by from
 Rob, I thought the discussion thread you pointed out was applicable
 "only" to totally new driver documentation.

 So, on my side, as a "new user" of sii902x IC, no problem to put these
 power supplies as mandatory instead of optional properties but I would
 like to be sure this is applicable to both old and new bindings doc : )
>>>
>>> We obviously need to retain backward compatibility, so on the driver side
>>> you need to treat those power supplies as optional. From a DT bindings
>>> point of view, however, I think they should be mandatory for new DT.
>>
>> We don't really have a way to describe these 3 conditions (required for
>> all, optional for all, and required for new). So generally we make
>> additions optional. The exception sometimes is if we update all the dts
>> files.
> 
> Can't we just make it mandatory in the bindings, as long as we treat it as
> optional in drivers ?
> 

How to progress on this patch? Do you have any suggestions?

Many thanks for your help,
Philippe :-)

 Rob,
 could you please confirm these power supply properties should be
 "mandatory"? if yes, should we then modify other optional properties like
 the reset-gpios too in the future?
>>>
>>> The GPIOs properties are different in my opinion, as there's no
>>> requirement to connect for instance the reset pin to a GPIO controllable
>>> by the SoC. The pin could be hardwired to VCC, or connected to a system
>>> reset that is automatically managed without SoC intervention. The power
>>> supplies, however, are mandatory, in the sense that the chip will not work
>>> if you leave the power supplies unconnected.
>>
>> DT only needs to describe what matters to s/w. If a regulator is
>> fixed and you don't need to know its voltage (or other read-only
>> parameters), then there's not much point in putting it in DT.
>>
>> I'd probably base this more at a platform level and you either use
>> regulator binding or you don't. It's perfectly valid that you want to do
>> things like regulator setup, pin ctrl and muxing setup, etc. all in
>> firmware and the OS doesn't touch any of that.
>>
>> That's all a big can of worms which we shouldn't solve on this 2 line
>> change. I think this change is fine as-is, so:
>>
>> Reviewed-by: Rob Herring 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Philippe CORNU]

Hi Laurent, Archit, Andrzej & Yannick,

Do you have any comments on this v2 driver part?
(more details regarding v1/v2 differences in the cover letter 
https://www.spinics.net/lists/dri-devel/msg174137.html)

Thank you,
Philippe :-)


On 04/25/2018 09:53 AM, Philippe Cornu wrote:
> Add the optional power supplies using the description found in
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> 
> The sii902x input IOs are not "io safe" so it is important to
> enable/disable voltage regulators during probe/remove phases to
> avoid damages.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/bridge/sii902x.c | 38 ++
>   1 file changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 60373d7eb220..c367d7b91ade 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -24,6 +24,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #include 
>   #include 
> @@ -86,6 +87,7 @@ struct sii902x {
>   struct drm_bridge bridge;
>   struct drm_connector connector;
>   struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data supplies[2];
>   };
>   
>   static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
>   return PTR_ERR(sii902x->reset_gpio);
>   }
>   
> + sii902x->supplies[0].supply = "iovcc";
> + sii902x->supplies[1].supply = "vcc12";
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
> +   sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to get power supplies: %d\n", ret);
> + return ret;
> + }
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to enable power supplies: %d\n", ret);
> + return ret;
> + }
> +
> + usleep_range(1, 2);
> +
>   sii902x_reset(sii902x);
>   
>   ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>   if (ret)
> - return ret;
> + goto err_disable_regulator;
>   
>   ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>  , 4);
>   if (ret) {
>   dev_err(dev, "regmap_read failed %d\n", ret);
> - return ret;
> + goto err_disable_regulator;
>   }
>   
>   if (chipid[0] != 0xb0) {
>   dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>   chipid[0]);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto err_disable_regulator;
>   }
>   
>   /* Clear all pending interrupts */
> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
>   IRQF_ONESHOT, dev_name(dev),
>   sii902x);
>   if (ret)
> - return ret;
> + goto err_disable_regulator;
>   }
>   
>   sii902x->bridge.funcs = _bridge_funcs;
> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
>   i2c_set_clientdata(client, sii902x);
>   
>   return 0;
> +
> +err_disable_regulator:
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +
> + return ret;
>   }
>   
>   static int sii902x_remove(struct i2c_client *client)
> @@ -443,6 +470,9 @@ static int sii902x_remove(struct i2c_client *client)
>   
>   drm_bridge_remove(>bridge);
>   
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +
>   return 0;
>   }
>   
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

[Ayan Halder]

On Wed, Apr 25, 2018 at 01:49:35PM +0200, Daniel Vetter wrote:
Hi Daniel,
> On Wed, Apr 25, 2018 at 1:26 PM, Liviu Dudau  wrote:
> > On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote:
> >> > malidp_pm_suspend_late checks if the runtime status is not suspended
> >> > and if so, invokes malidp_runtime_pm_suspend which disables the
> >> > display engine/core interrupts and the clocks. It sets the runtime status
> >> > as suspended.
> >> >
> >> > The difference between suspend() and suspend_late() is as follows:-
> >> > 1. suspend() makes the device quiescent. In our case, we invoke the DRM
> >> > helper which disables the CRTC. This would have invoked runtime pm
> >> > suspend but the system suspend process disables runtime pm.
> >> > 2. suspend_late() It continues the suspend operations of the drm device
> >> > which was started by suspend(). In our case, it performs the same 
> >> > functionality
> >> > as runtime_suspend().
> >> >
> >> > The complimentary functions are resume() and resume_early(). In the case 
> >> > of
> >> > resume_early(), we invoke malidp_runtime_pm_resume() which enables the 
> >> > clocks
> >> > and the interrupts. It sets the runtime status as active. If the device 
> >> > was
> >> > in runtime suspend mode before system suspend was called, 
> >> > pm_runtime_work()
> >> > will put the device back in runtime suspended mode( after the complete 
> >> > system
> >> > has been resumed).
> >> >
> >> > Signed-off-by: Ayan Kumar Halder 
> >> >
> >>
> >> Afaiui we still haven't bottomed out on the discussion on v1. Did you get
> >> hold of Rafael?
> >
> > No, there was no reply from him. Lets try again:
> >
> > Rafael, we are debating on what the proper approach is for handling the
> > suspend/resume callbacks for a DRM driver that is likely to not be
> > runtime suspended when the power-down happens (because we are driving
> > the display output). We are using in this patch the LATE_SYSTEM_SLEEP_PM_OPS
> > in order to do the work that we also do during runtime suspend, which is
> > turning off the output and the clocks driving it. The reason for doing
> > that is because the PM core takes a runtime reference during system
> > suspend for all devices that are not already runtime suspended, so our
> > runtime_pm_suspend() hook is never called.
> >
> > Daniel's argument is that we should not be doing this from LATE hooks,
> > but from the normal suspend hooks, however kernel doc seems to suggest
> > otherwise.
> 
> For more context: I thought the reason behind the recommendation to
> stuff the rpm callbacks into the late/early hooks was to solve
> cross-device ordering issues. That way everyone shuts down the device
> functionality in the normal hooks, but only powers them off in the
> late hook (to allow other drivers to keep using the clock/i2c
> master/whatever). But we now have device_link to solve that since a
> while, so I'm not sure the recommendation to stuff the rpm hooks into
> late/early callbacks is still correct.
> -Daniel
> 
It has been more than two weeks and we have not got any response from
Rafael. Can you ping him personally or suggest any way by which ask
him to respond?
> >
> > Best regards,
> > Liviu
> >
> >
> >
> >> -Daniel
> >>
> >> > ---
> >> > Changes in v3:-
> >> > - Rebased on top of earlier v3 patches,
> >> >
> >> > Changes in v2:-
> >> > - Removed the change id and modified the commit message
> >> > ---
> >> >  drivers/gpu/drm/arm/malidp_drv.c | 17 +
> >> >  1 file changed, 17 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> >> > b/drivers/gpu/drm/arm/malidp_drv.c
> >> > index 82221ea..c53b46a 100644
> >> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> >> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> >> > @@ -768,8 +768,25 @@ static int __maybe_unused malidp_pm_resume(struct 
> >> > device *dev)
> >> > return 0;
> >> >  }
> >> >
> >> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> >> > +{
> >> > +   if (!pm_runtime_status_suspended(dev)) {
> >> > +   malidp_runtime_pm_suspend(dev);
> >> > +   pm_runtime_set_suspended(dev);
> >> > +   }
> >> > +   return 0;
> >> > +}
> >> > +
> >> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> >> > +{
> >> > +   malidp_runtime_pm_resume(dev);
> >> > +   pm_runtime_set_active(dev);
> >> > +   return 0;
> >> > +}
> >> > +
> >> >  static const struct dev_pm_ops malidp_pm_ops = {
> >> > SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
> >> > +   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
> >> > malidp_pm_resume_early) \
> >> > SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, 
> >> > malidp_runtime_pm_resume, NULL)
> >> >  };
> >> >
> >> > --
> >> > 2.7.4
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > 

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

[Alexandru-Cosmin Gheorghe]

On Mon, May 14, 2018 at 10:19:27AM +0100, Brian Starkey wrote:
> Hi Alex,
> 
> On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:
> >Status register contains a lot of bits for reporting internal errors
> >inside Mali DP. Currently, we just silently ignore all of the erorrs,
> 
> Being picky: s/erorrs/errors/
> 
> >that doesn't help when we are investigating different bugs, especially
> >on the FPGA models which have a lot of constrains, so we could easily
> 
> s/constrains/constraints/
> 
> >end up in AXI or underrun errors.
> >
> >Add a new file called debug that contains an agregate of the
> 
> s/agregate/aggregate/
> 
> >errors reported by the Mali DP hardware.
> >
> >E.g:
> >[root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
> >[DE] num_errors : 167
> >[DE] last_error_status  : 0x0001
> >[DE] last_error_vblank : 385
> >[SE] num_errors : 3
> >[SE] last_error_status  : 0x00e23001
> >[SE] last_error_vblank : 201
> >
> >This a morphosis of the patch presented here [1], where the errors
> >where reported continuously via trace_printk.
> >
> >[1] 
> >https://lists.freedesktop.org/archives/dri-devel/2018-February/167042.html
> >
> >Signed-off-by: Alexandru Gheorghe 
> >---
> >drivers/gpu/drm/arm/malidp_drv.c  | 61 
> >+++
> >drivers/gpu/drm/arm/malidp_drv.h  | 15 ++
> >drivers/gpu/drm/arm/malidp_hw.c   | 46 -
> >drivers/gpu/drm/arm/malidp_hw.h   |  1 +
> >drivers/gpu/drm/arm/malidp_regs.h |  6 
> >5 files changed, 122 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> >b/drivers/gpu/drm/arm/malidp_drv.c
> >index 8d20faa..70ce19a 100644
> >--- a/drivers/gpu/drm/arm/malidp_drv.c
> >+++ b/drivers/gpu/drm/arm/malidp_drv.c
> >@@ -17,6 +17,7 @@
> >#include 
> >#include 
> >#include 
> >+#include 
> >
> >#include 
> >#include 
> >@@ -29,6 +30,7 @@
> >#include 
> >#include 
> >#include 
> >+#include 
> >
> >#include "malidp_drv.h"
> >#include "malidp_regs.h"
> >@@ -327,6 +329,62 @@ static int malidp_dumb_create(struct drm_file 
> >*file_priv,
> > return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
> >}
> >
> >+#ifdef CONFIG_DEBUG_FS
> >+
> >+static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
> >+{
> >+atomic_set(_stats->num_errors, 0);
> >+atomic_set(_stats->last_error_status, 0);
> >+atomic64_set(_stats->last_error_vblank, -1);
> >+}
> >+
> >+void malidp_error(struct malidp_error_stats *error_stats, u32 status,
> >+  u64 vblank)
> >+{
> >+atomic_set(_stats->last_error_status, status);
> >+atomic64_set(_stats->last_error_vblank, vblank);
> >+atomic_inc(_stats->num_errors);
> >+}
> >+
> 
> Do we already have a lock we could use to make sure the status printed
> is consistent? I know this is "only debug", but it could be annoying
> if we can't trust that the last_error_status does actually match the
> last_error_vblank.
>

No, we don't have any lock. Yes that would be annoying, I will add
one.
 
> >+void malidp_error_stats_dump(const char *prefix,
> >+ struct malidp_error_stats *error_stats,
> >+ struct seq_file *m)
> >+{
> >+seq_printf(m, "[%s] num_errors : %d\n", prefix,
> >+   atomic_read(_stats->num_errors));
> >+seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
> >+   atomic_read(_stats->last_error_status));
> >+seq_printf(m, "[%s] last_error_vblank : %ld\n", prefix,
> >+   atomic64_read(_stats->last_error_vblank));
> >+}
> >+
> >+static int malidp_show_stats(struct seq_file *m, void *arg)
> >+{
> >+struct drm_info_node *node = (struct drm_info_node *)m->private;
> >+struct drm_device *drm = node->minor->dev;
> >+struct malidp_drm *malidp = drm->dev_private;
> >+
> >+malidp_error_stats_dump("DE", >de_errors, m);
> >+malidp_error_stats_dump("SE", >se_errors, m);
> >+return 0;
> >+}
> >+
> >+static struct drm_info_list malidp_debugfs_list[] = {
> >+{ "debug", malidp_show_stats, 0 },
> >+};
> 
> I think it would be pretty useful to have a way to reset the counters.
> Maybe by just writing anything to the file?
> 

drm_debugfs_fops doesn't allow writing. I see no reason using our own
debugs_fops, but do you think worth the trouble?

> Thanks,
> -Brian
> 
> >+
> >+static int malidp_debugfs_init(struct drm_minor *minor)
> >+{
> >+struct malidp_drm *malidp = minor->dev->dev_private;
> >+
> >+malidp_error_stats_init(>de_errors);
> >+malidp_error_stats_init(>se_errors);
> >+return drm_debugfs_create_files(malidp_debugfs_list,
> >+ARRAY_SIZE(malidp_debugfs_list), minor->debugfs_root, minor);
> >+}
> >+
> >+#endif //CONFIG_DEBUG_FS
> >+
> >static struct drm_driver malidp_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> >DRIVER_PRIME,
> >@@ -343,6 +401,9 @@ static 

[PATCH] gpu: host1x: Acquire a reference to the IOVA cache

[Thierry Reding]

From: Thierry Reding 

The IOVA API uses a memory cache to allocate IOVA nodes from. To make
sure that this cache is available, obtain a reference to it and release
the reference when the cache is no longer needed.

On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
that reference and never releases it. On 32-bit ARM, this is papered
over by the Tegra DRM driver (the sole user of the host1x API requiring
the cache) acquiring a reference to the IOVA cache for its own purposes.
However, there may be additional users of this API in the future, so fix
this upfront to avoid surprises.

Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/dev.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 03db71173f5d..f1d5f76e9c33 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -223,10 +223,14 @@ static int host1x_probe(struct platform_device *pdev)
struct iommu_domain_geometry *geometry;
unsigned long order;
 
+   err = iova_cache_get();
+   if (err < 0)
+   goto put_group;
+
host->domain = iommu_domain_alloc(_bus_type);
if (!host->domain) {
err = -ENOMEM;
-   goto put_group;
+   goto put_cache;
}
 
err = iommu_attach_group(host->domain, host->group);
@@ -234,6 +238,7 @@ static int host1x_probe(struct platform_device *pdev)
if (err == -ENODEV) {
iommu_domain_free(host->domain);
host->domain = NULL;
+   iova_cache_put();
iommu_group_put(host->group);
host->group = NULL;
goto skip_iommu;
@@ -308,6 +313,9 @@ static int host1x_probe(struct platform_device *pdev)
 fail_free_domain:
if (host->domain)
iommu_domain_free(host->domain);
+put_cache:
+   if (host->group)
+   iova_cache_put();
 put_group:
iommu_group_put(host->group);
 
@@ -328,6 +336,7 @@ static int host1x_remove(struct platform_device *pdev)
put_iova_domain(>iova);
iommu_detach_group(host->domain, host->group);
iommu_domain_free(host->domain);
+   iova_cache_put();
iommu_group_put(host->group);
}
 
-- 
2.17.0

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

[PATCH] drm/omap: dss: Use ERR_CAST instead of ERR_PTR(PTR_ERR())

[Hernán Gonzalez]

Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).

drivers/gpu/drm/omapdrm/dss/dss.c:959:9-16: WARNING: ERR_CAST can be used with d
Generated by: scripts/coccinelle/api/err_cast.cocci

Signed-off-by: Hernán Gonzalez 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 0b908e9..be043c8 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -956,7 +956,7 @@ dss_debugfs_create_file(struct dss_device *dss, const char 
*name,
_debug_fops);
if (IS_ERR(d)) {
kfree(entry);
-   return ERR_PTR(PTR_ERR(d));
+   return ERR_CAST(d);
}
 
entry->dentry = d;
-- 
2.7.4

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

Re: drm SPDX updates

[Thomas Gleixner]

Dirk,

On Mon, 7 May 2018, Dirk Hohndel (VMware) wrote:

> License clarifications and SPDX headers for a bunch of files which were
> authored by VMware.
> 
> This should address the comments made on the previous series.
> I added Thomas as Cc (sorry, forgot on the first version) and added a
> couple of SOBs that I had received in the meantime.

Thanks for cleaning that up.

FWIW: Acked-by: Thomas Gleixner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] amdkfd next 4.18

[Oded Gabbay]

Hi Dave,

This is amdkfd pull for 4.18. The major new features are:

- Add support for GFXv9 dGPUs (VEGA)
- Add support for userptr memory mapping

In addition, there are a couple of small fixes and improvements, such as:
- Fix lock handling
- Fix rollback packet in kernel kfd_queue
- Optimize kfd signal handling
- Fix CP hang in APU

Thanks,
Oded

The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:

  Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2018-05-14

for you to fetch changes up to af47b390273f1068bdb1d01263a81948c4e2f97a:

  drm/amdkfd: Remove vla (2018-04-13 14:24:12 -0700)


Ben Goz (1):
  drm/amdkfd: Locking PM mutex while allocating IB buffer

Dan Carpenter (1):
  drm/amdkfd: Integer overflows in ioctl

Felix Kuehling (29):
  drm/amdgpu: Add MMU notifier type for KFD userptr
  drm/amdgpu: Enable amdgpu_ttm_tt_get_user_pages in worker threads
  drm/amdgpu: Avoid reclaim while holding locks taken in MMU notifier
  drm/amdkfd: GFP_NOIO while holding locks taken in MMU notifier
  drm/amdkfd: Add quiesce_mm and resume_mm to kgd2kfd_calls
  drm/amdgpu: Add userptr support for KFD
  drm/amdgpu: Remove unused interface from kfd2kgd interface
  drm/amd: Update GFXv9 SDMA MQD structure
  drm/amdgpu: Add GFXv9 TLB invalidation packet definition
  drm/amdgpu: Add GFXv9 kfd2kgd interface functions
  drm/amdgpu: Add doorbell routing info to kgd2kfd_shared_resources
  drm/amdkfd: Make doorbell size ASIC-dependent
  drm/amdkfd: Implement doorbell allocation for SOC15
  drm/amdkfd: Move packet writer functions into ASIC-specific file
  drm/amdkfd: Add GFXv9 PM4 packet writer functions
  drm/amdkfd: Add GFXv9 MQD manager
  drm/amdkfd: Add GFXv9 device queue manager
  drm/amdkfd: Add SOC15 interrupt processing support
  drm/amdkfd: Fix goto usage
  drm/amdkfd: Fix kernel queue rollback_packet
  drm/amdkfd: Add 64-bit doorbell and wptr support to kernel queue
  drm/amdkfd: Remove limit on number of GPUs (follow-up)
  drm/amdkfd: Support flat memory apertures for GFXv9
  drm/amdkfd: Add GFXv9 CWSR trap handler
  drm/amdkfd: Add Vega10 topology and device info
  drm/amdkfd: Remove redundant include of amd-iommu.h
  drm/amdkfd: Fix signal handling performance again
  drm/amdkfd: Remove initialization of cp_hqd_ib_control on CIK
  drm/amdkfd: Add sanity checks in IRQ handlers

Harish Kasiviswanathan (1):
  drm/amdkfd: Clean up KFD_MMAP_ offset handling

Jay Cornwall (2):
  drm/amdkfd: Reduce priority of context-saving waves before spin-wait
  drm/amdkfd: Use volatile MTYPE in default/alternate apertures

Laura Abbott (1):
  drm/amdkfd: Remove vla

Oak Zeng (1):
  drm/amdkfd: Dump HQD of HIQ

Philip Yang (1):
  drm/amdkfd: use %px to print user space address instead of %p

Shaoyun Liu (1):
  drm/amdkfd: Remove queue node when destroy queue failed

Yong Zhao (2):
  drm/amdkfd: Separate trap handler assembly code and its hex values
  drm/amdkfd: Fix CP soft hang on APUs

welu (1):
  drm/amdkfd: Try to enable atomics for all GPUs

 MAINTAINERS|2 +
 drivers/gpu/drm/amd/amdgpu/Makefile|3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |   26 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h |   13 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c  |   10 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c  |   10 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c  | 1043 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   |  572 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c |  111 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h |   11 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   38 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  |1 +
 drivers/gpu/drm/amd/amdgpu/soc15d.h|5 +
 drivers/gpu/drm/amd/amdkfd/Makefile|   10 +-
 drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c   |   20 +-
 drivers/gpu/drm/amd/amdkfd/cik_regs.h  |3 +-
 drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h |  560 +
 .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm  |  274 +
 .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx9.asm  | 1214 
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |   52 +-
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c  |   11 +
 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  131 ++-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  114 +-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |2 +
 .../drm/amd/amdkfd/kfd_device_queue_manager_v9.c   |   84 ++
 

[PATCH v1 0/7] drm/mediatek: support hdmi output for mt2701 and mt7623

[Bibby Hsieh]

In order to support HDMI on mt2701,
we have to make some modifications.
1) Add the HDMI driver.
2) Add the DPI driver.
3) Add a mechanism that config output component by dts.

Changes since v0:
 - Correct some typos in commit message.
 - Fixup the build warning (tmp variable didn't be initialized)

Bibby Hsieh (3):
  drm/mediatek: implement connection from BLS to DPI0
  drm/mediatek: add a error return value when clock driver has been
prepared
  drm/mediatek: config component output by device node port

chunhui dai (4):
  drm/mediatek: move dpi private data to device
  drm/mediatek: fix to get right bridge for dpi encoder
  drm/mediatek: add dpi driver for mt2701 and mt7623
  drm/mediatek: add hdmi driver for different hardware

 drivers/gpu/drm/mediatek/Makefile  |   4 +-
 drivers/gpu/drm/mediatek/mtk_dpi.c | 125 +++---
 drivers/gpu/drm/mediatek/mtk_dpi_regs.h|   2 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c |  14 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c|   2 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  38 ++-
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |   4 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  88 +--
 drivers/gpu/drm/mediatek/mtk_hdmi.h|  28 +++
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 157 +
 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h   |   1 +
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 307 +
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 129 +--
 13 files changed, 716 insertions(+), 183 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c

-- 
2.12.5

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

[PATCH v1 2/7] drm/mediatek: fix to get right bridge for dpi encoder

[Bibby Hsieh]

From: chunhui dai 

1, dpi is an encoder, there is an bridge in the struct
of decoder, we could use it.
2, using of_graph_get_remote_port_parent to get right
bridge in device tree.

Signed-off-by: chunhui dai 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 0a44ab175422..2b8b34c72697 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -63,7 +63,6 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -643,8 +642,8 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
-
-   ret = drm_bridge_attach(>encoder, dpi->bridge, NULL);
+   dpi->encoder.bridge->encoder = >encoder;
+   ret = drm_bridge_attach(>encoder, dpi->encoder.bridge, NULL);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -709,7 +708,7 @@ static int mtk_dpi_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct mtk_dpi *dpi;
struct resource *mem;
-   struct device_node *bridge_node;
+   struct device_node *ep, *bridge_node;
int comp_id;
const struct of_device_id *match;
int ret;
@@ -759,15 +758,21 @@ static int mtk_dpi_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   bridge_node = of_graph_get_remote_node(dev->of_node, 0, 0);
-   if (!bridge_node)
+   ep = of_graph_get_next_endpoint(dev->of_node, NULL);
+   if (ep) {
+   bridge_node = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
+   }
+   if (!bridge_node) {
+   dev_err(dev, "Failed to find bridge node\n");
return -ENODEV;
+   }
 
dev_info(dev, "Found bridge node: %pOF\n", bridge_node);
 
-   dpi->bridge = of_drm_find_bridge(bridge_node);
+   dpi->encoder.bridge = of_drm_find_bridge(bridge_node);
of_node_put(bridge_node);
-   if (!dpi->bridge)
+   if (!dpi->encoder.bridge)
return -EPROBE_DEFER;
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
-- 
2.12.5

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

[PATCH v1 6/7] drm/mediatek: add a error return value when clock driver has been prepared

[Bibby Hsieh]

DRM driver get the comp->clk by of_clk_get(), we only
assign NULL to comp->clk when error happened, but do
not return the error number.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4672317e3ad1..d38a5303f8fc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -283,7 +283,7 @@ int mtk_ddp_comp_init(struct device *dev, struct 
device_node *node,
comp->irq = of_irq_get(node, 0);
comp->clk = of_clk_get(node, 0);
if (IS_ERR(comp->clk))
-   comp->clk = NULL;
+   return PTR_ERR(comp->clk);
 
/* Only DMA capable components need the LARB property */
comp->larb_dev = NULL;
-- 
2.12.5

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

[Bug 104598] vkmark with kwin compositing: Page flip failed: Cannot allocate memory

[bugzilla-daemon]

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

--- Comment #6 from Christoph Haag  ---
Yes, it's still happening. It's just running vkmark in default mode. It looks
like this: https://youtu.be/MngLl6BgOfg

I'm not sure if previously it happened continuously but now it's only a couple
of flips that fail (there's noticeable stutter visible when it happens).

Not sure how to make sure it doesn't use EGL but I ran it with
KWIN_OPENGL_INTERFACE=glx kwin_x11 --replace, I hope that's enough.

Currently on kwin 5.12.5, xserver 1.19.99.905 g4191b59bd and latest
xf86-video-amdgpu git so it has not been resolved there yet.

It happens with kwin's OpenGL 2 and OpenGL 3 backends and all vsync methods,
including None.
It does not happen with XRender.

-- 
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 09/21] arm64: dts: allwinner: a64: Add HDMI support

[Maxime Ripard]

On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard  
> wrote:
> > Hi,
> >
> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
> >> + hdmi_phy: hdmi-phy@1ef {
> >> + compatible = "allwinner,sun50i-a64-hdmi-phy",
> >> +  "allwinner,sun8i-h3-hdmi-phy";
> >> + reg = <0x01ef 0x1>;
> >> + clocks = < CLK_BUS_HDMI>, < CLK_HDMI_DDC>,
> >> +  < CLK_PLL_VIDEO1>;
> >
> > You were discussing that the PLL0 could also be used to clock the PHY,
> > has that been figured out?
> 
> This is what I understand from Fig: 3-3. Module Clock Diagram, both
> tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
> configuration we need use proper PLL or some logic to get common PLL
> don't know yet. Since this series adding tcon1 I've attached PLL1.

You're not describing the TCON node here though, but the HDMI one, and
the HDMI block is listed in both the PLL video 0 and 1.

Maxime

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


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

RE: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check
>
>Implements the link integrity check once in 500mSec.
>
>Once encryption is enabled, an ongoing Link Integrity Check is performed by the
>HDCP Receiver to check that cipher synchronization is maintained between the
>HDCP Transmitter and the HDCP Receiver.
>
>On the detection of synchronization lost, the HDCP Receiver must assert the
>corresponding bits of the RxStatus register. The Transmitter polls the RxStatus
>register and it may initiate re-authentication.
>
>v2:
>  Rebased.
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 81
>++-
> include/drm/drm_hdcp.h|  8 
> 2 files changed, 88 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 005627746ca5..e2aec73aefe3 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -23,6 +23,8 @@
>
> static int _intel_hdcp2_enable(struct intel_connector *connector);  static int
>_intel_hdcp2_disable(struct intel_connector *connector);
>+static void intel_hdcp2_check_work(struct work_struct *work); static
>+int intel_hdcp2_check_link(struct intel_connector *connector);
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim) @@ -
>1456,6 +1458,83 @@ static int _intel_hdcp2_enable(struct intel_connector
>*connector)
>
>   hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
>   schedule_work(>hdcp_prop_work);
>-
>+  schedule_delayed_work(>hdcp2_check_work,
>+DRM_HDCP2_CHECK_PERIOD_MS);
>   return 0;
> }
>+
>+static int intel_hdcp2_check_link(struct intel_connector *connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  enum port port = connector->encoder->port;
>+  int ret = 0;
>+
>+  if (!hdcp->hdcp_shim)
>+  return -ENOENT;
>+
>+  mutex_lock(>hdcp_mutex);
>+
>+  if (hdcp->hdcp_value ==
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
>+  goto out;
>+
>+  if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
>LINK_ENCRYPTION_STATUS)) {
>+  DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
>+ I915_READ(HDCP2_STATUS_DDI(port)));
>+  ret = -ENXIO;
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+  schedule_work(>hdcp_prop_work);
>+  goto out;
>+  }
>+
>+  ret = hdcp->hdcp_shim->check_2_2_link(intel_dig_port);

Check " hdcp->hdcp_shim->check_2_2_link " for NULL.

>+  if (!ret) {
>+  if (hdcp->hdcp_value !=
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+  schedule_work(>hdcp_prop_work);
>+  }
>+  goto out;
>+  }
>+
>+  DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\n",
>+   connector->base.name, connector->base.base.id);
>+
>+  ret = _intel_hdcp2_disable(connector);
>+  if (ret) {
>+  DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
>+connector->base.name, connector->base.base.id, ret);
>+
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+  schedule_work(>hdcp_prop_work);
>+  goto out;
>+  }
>+
>+  ret = _intel_hdcp2_enable(connector);
>+  if (ret) {
>+  DRM_ERROR("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
>+connector->base.name, connector->base.base.id, ret);
>+
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+  schedule_work(>hdcp_prop_work);
>+  goto out;
>+  }
>+
>+out:
>+  mutex_unlock(>hdcp_mutex);
>+  return ret;
>+}
>+
>+static void intel_hdcp2_check_work(struct work_struct *work) {
>+  struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
>+  struct intel_hdcp,
>+  hdcp2_check_work);
>+  struct intel_connector *connector = container_of(hdcp,
>+  

[PATCH v1 1/7] drm/mediatek: move dpi private data to device

[Bibby Hsieh]

From: chunhui dai 

move clock factor and edge enable setting to private data.

Signed-off-by: chunhui dai 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 82 ++---
 drivers/gpu/drm/mediatek/mtk_dpi_regs.h |  2 +-
 2 files changed, 66 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index e80a603e5fb0..993dc44368bd 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -71,11 +71,13 @@ struct mtk_dpi {
struct clk *tvd_clk;
int irq;
struct drm_display_mode mode;
+   const struct mtk_dpi_conf *conf;
enum mtk_dpi_out_color_format color_format;
enum mtk_dpi_out_yc_map yc_map;
enum mtk_dpi_out_bit_num bit_num;
enum mtk_dpi_out_channel_swap channel_swap;
bool power_sta;
+   int refcount;
u8 power_ctl;
 };
 
@@ -115,6 +117,12 @@ struct mtk_dpi_yc_limit {
u16 c_bottom;
 };
 
+struct mtk_dpi_conf {
+   unsigned int (*cal_factor)(int clock);
+   const u32 reg_h_fre_con;
+   bool edge_sel_en;
+};
+
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
 {
u32 tmp = readl(dpi->regs + offset) & ~mask;
@@ -340,7 +348,13 @@ static void mtk_dpi_config_swap_input(struct mtk_dpi *dpi, 
bool enable)
 
 static void mtk_dpi_config_2n_h_fre(struct mtk_dpi *dpi)
 {
-   mtk_dpi_mask(dpi, DPI_H_FRE_CON, H_FRE_2N, H_FRE_2N);
+   mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, H_FRE_2N, H_FRE_2N);
+}
+
+static void mtk_dpi_config_disable_edge(struct mtk_dpi *dpi)
+{
+   if (dpi->conf->edge_sel_en)
+   mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
 }
 
 static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
@@ -368,6 +382,12 @@ static void mtk_dpi_config_color_format(struct mtk_dpi 
*dpi,
 
 static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
 {
+   if (WARN_ON(dpi->refcount == 0))
+   return;
+
+   if (--dpi->refcount != 0)
+   return;
+
dpi->power_ctl &= ~pctl;
 
if ((dpi->power_ctl & DPI_POWER_START) ||
@@ -385,16 +405,19 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum 
mtk_dpi_power_ctl pctl)
 
 static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
 {
-   int ret;
+   int ret = 0;
+
+   if (++dpi->refcount != 1)
+   return 0;
 
dpi->power_ctl |= pctl;
 
if (!(dpi->power_ctl & DPI_POWER_START) &&
!(dpi->power_ctl & DPI_POWER_ENABLE))
-   return 0;
+   goto err_refcount;
 
if (dpi->power_sta)
-   return 0;
+   goto err_refcount;
 
ret = clk_prepare_enable(dpi->engine_clk);
if (ret) {
@@ -416,6 +439,8 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum 
mtk_dpi_power_ctl pctl)
clk_disable_unprepare(dpi->engine_clk);
 err_eng:
dpi->power_ctl &= ~pctl;
+err_refcount:
+   dpi->refcount--;
return ret;
 }
 
@@ -433,16 +458,13 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
unsigned long pll_rate;
unsigned int factor;
 
+   if (!dpi) {
+   dev_err(dpi->dev, "invalid argument\n");
+   return -EINVAL;
+   }
/* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
pix_rate = 1000UL * mode->clock;
-   if (mode->clock <= 27000)
-   factor = 16 * 3;
-   else if (mode->clock <= 84000)
-   factor = 8 * 3;
-   else if (mode->clock <= 167000)
-   factor = 4 * 3;
-   else
-   factor = 2 * 3;
+   factor = dpi->conf->cal_factor(mode->clock);
pll_rate = pix_rate * factor;
 
dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
@@ -518,6 +540,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
mtk_dpi_config_yc_map(dpi, dpi->yc_map);
mtk_dpi_config_color_format(dpi, dpi->color_format);
mtk_dpi_config_2n_h_fre(dpi);
+   mtk_dpi_config_disable_edge(dpi);
mtk_dpi_sw_reset(dpi, false);
 
return 0;
@@ -656,6 +679,31 @@ static const struct component_ops mtk_dpi_component_ops = {
.unbind = mtk_dpi_unbind,
 };
 
+static unsigned int mt8173_calculate_factor(int clock)
+{
+   if (clock <= 27000)
+   return 16 * 3;
+   else if (clock <= 74250)
+   return 8 * 3;
+   else if (clock <= 167000)
+   return 4 * 3;
+   else
+   return 2 * 3;
+}
+
+static const struct mtk_dpi_conf mt8173_conf = {
+   .cal_factor = mt8173_calculate_factor,
+   .reg_h_fre_con = 0xe0,
+};
+
+static const struct of_device_id mtk_dpi_of_ids[] = {
+   { .compatible = "mediatek,mt8173-dpi",
+ .data = _conf,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, 

[PATCH v1 7/7] drm/mediatek: config component output by device node port

[Bibby Hsieh]

We can select output component by device node port.
Main path default output component is DSI.
External path default output component is DPI.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 37 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  4 ++--
 2 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index f4fb86ab7b8d..05333769d862 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mtk_drm_crtc.h"
 #include "mtk_drm_ddp.h"
@@ -133,7 +135,7 @@ static const struct drm_mode_config_funcs 
mtk_drm_mode_config_funcs = {
.atomic_commit = mtk_atomic_commit,
 };
 
-static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
+static enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_COLOR0,
@@ -141,12 +143,12 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_main[] = 
{
DDP_COMPONENT_DSI0,
 };
 
-static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
+static enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_DPI0,
 };
 
-static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
+static enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_COLOR0,
DDP_COMPONENT_AAL,
@@ -157,7 +159,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
DDP_COMPONENT_PWM0,
 };
 
-static const enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
+static enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] = {
DDP_COMPONENT_OVL1,
DDP_COMPONENT_COLOR1,
DDP_COMPONENT_GAMMA,
@@ -411,6 +413,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
 
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(dev->of_node->parent, node) {
+   struct device_node *port, *ep, *remote;
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -470,6 +473,32 @@ static int mtk_drm_probe(struct platform_device *pdev)
 
private->ddp_comp[comp_id] = comp;
}
+
+   if (comp_type != MTK_DSI && comp_type != MTK_DPI) {
+   port = of_graph_get_port_by_id(node, 0);
+   if (!port)
+   continue;
+   ep = of_get_child_by_name(port, "endpoint");
+   of_node_put(port);
+   if (!ep)
+   continue;
+   remote = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
+   if (!remote)
+   continue;
+   of_id = of_match_node(mtk_ddp_comp_dt_ids, remote);
+   if (!of_id)
+   continue;
+   comp_type = (enum mtk_ddp_comp_type)of_id->data;
+   for (i = 0; i < private->data->main_len - 1; i++)
+   if (private->data->main_path[i] == comp_id)
+   private->data->main_path[i + 1] =
+   mtk_ddp_comp_get_id(node, comp_type);
+   for (i = 0; i < private->data->ext_len - 1; i++)
+   if (private->data->ext_path[i] == comp_id)
+   private->data->ext_path[i + 1] =
+   mtk_ddp_comp_get_id(node, comp_type);
+   }
}
 
if (!private->mutex_node) {
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index c3378c452c0a..2bcba8eb06f4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -29,9 +29,9 @@ struct drm_property;
 struct regmap;
 
 struct mtk_mmsys_driver_data {
-   const enum mtk_ddp_comp_id *main_path;
+   enum mtk_ddp_comp_id *main_path;
unsigned int main_len;
-   const enum mtk_ddp_comp_id *ext_path;
+   enum mtk_ddp_comp_id *ext_path;
unsigned int ext_len;
bool shadow_register;
 };
-- 
2.12.5

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

[PATCH v1 4/7] drm/mediatek: add hdmi driver for different hardware

[Bibby Hsieh]

From: chunhui dai 

This patch adds hdmi driver suppot for both MT2701 and MT7623.
And also support other (existing or future) chips that use
the same binding and driver.

Signed-off-by: Chunhui Dai 
---
 drivers/gpu/drm/mediatek/Makefile  |   4 +-
 drivers/gpu/drm/mediatek/mtk_hdmi.c|  91 +---
 drivers/gpu/drm/mediatek/mtk_hdmi.h|  28 +++
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 157 +
 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h   |   1 +
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 307 +
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 129 +--
 7 files changed, 568 insertions(+), 149 deletions(-)
 create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
 create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c

diff --git a/drivers/gpu/drm/mediatek/Makefile 
b/drivers/gpu/drm/mediatek/Makefile
index ce83c396a742..44464893c1cb 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -18,6 +18,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
 mediatek-drm-hdmi-objs := mtk_cec.o \
  mtk_hdmi.o \
  mtk_hdmi_ddc.o \
- mtk_mt8173_hdmi_phy.o
+ mtk_mt2701_hdmi_phy.o \
+ mtk_mt8173_hdmi_phy.o \
+ mtk_hdmi_phy.o
 
 obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 59a11026dceb..85e280962aad 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -233,6 +233,7 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi, 
bool black)
 static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
 {
struct arm_smccc_res res;
+   struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
 
/*
 * MT8173 HDMI hardware has an output control bit to enable/disable HDMI
@@ -240,8 +241,13 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi 
*hdmi, bool enable)
 * The ARM trusted firmware provides an API for the HDMI driver to set
 * this control bit to enable HDMI output in supervisor mode.
 */
-   arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904, 0x8000,
- 0, 0, 0, 0, 0, );
+   if (hdmi_phy->conf && hdmi_phy->conf->tz_enabled)
+   arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
+ 0x8000, 0, 0, 0, 0, 0, );
+   else
+   regmap_update_bits(hdmi->sys_regmap,
+  hdmi->sys_offset + HDMI_SYS_CFG20,
+  HDMI_PSECUR_EN, enable ? 0 : HDMI_PSECUR_EN);
 
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
   HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
@@ -1437,6 +1443,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
struct platform_device *cec_pdev;
struct regmap *regmap;
struct resource *mem;
+   const char *phy_name;
int ret;
 
ret = mtk_hdmi_get_all_clk(hdmi, np);
@@ -1445,9 +1452,20 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
return ret;
}
 
+   ret = of_property_read_string(np, "phy-names", _name);
+   if (ret < 0) {
+   dev_err(dev, "Failed to read phy-names: %d\n", ret);
+   return ret;
+   }
+   hdmi->phy = devm_phy_get(dev, phy_name);
+   if (IS_ERR(hdmi->phy)) {
+   ret = PTR_ERR(hdmi->phy);
+   dev_err(dev, "Failed to get HDMI PHY: %d\n", ret);
+   return ret;
+   }
+
/* The CEC module handles HDMI hotplug detection */
-   cec_np = of_find_compatible_node(np->parent, NULL,
-"mediatek,mt8173-cec");
+   cec_np = of_parse_phandle(np, "cec", 0);
if (!cec_np) {
dev_err(dev, "Failed to find CEC node\n");
return -EINVAL;
@@ -1486,8 +1504,14 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
return PTR_ERR(hdmi->regs);
 
remote = of_graph_get_remote_node(np, 1, 0);
-   if (!remote)
-   return -EINVAL;
+   if (!remote) {
+   i2c_np = of_parse_phandle(np, "ddc-i2c-bus", 0);
+   if (!i2c_np) {
+   dev_err(dev, "Failed to find ddc-i2c-bus node\n");
+   return -EINVAL;
+   }
+   goto find_ddc_adpt;
+   }
 
if (!of_device_is_compatible(remote, "hdmi-connector")) {
hdmi->next_bridge = of_drm_find_bridge(remote);
@@ -1507,6 +1531,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
}

[PATCH v1 3/7] drm/mediatek: add dpi driver for mt2701 and mt7623

[Bibby Hsieh]

From: chunhui dai 

This patch adds dpi driver suppot for both mt2701 and mt7623.
And also support other (existing or future) chips that use
the same binding and driver.

Signed-off-by: chunhui dai 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 24 ++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  1 +
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 2b8b34c72697..e1af1d0d213d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -640,8 +640,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
}
drm_encoder_helper_add(>encoder, _dpi_encoder_helper_funcs);
 
-   /* Currently DPI0 is fixed to be driven by OVL1 */
-   dpi->encoder.possible_crtcs = BIT(1);
+   dpi->encoder.possible_crtcs = BIT(0) | BIT(1);
dpi->encoder.bridge->encoder = >encoder;
ret = drm_bridge_attach(>encoder, dpi->encoder.bridge, NULL);
if (ret) {
@@ -690,12 +689,33 @@ static unsigned int mt8173_calculate_factor(int clock)
return 2 * 3;
 }
 
+static unsigned int mt2701_calculate_factor(int clock)
+{
+   if (clock <= 64000)
+   return 16;
+   else if (clock <= 128000)
+   return 8;
+   else if (clock <= 256000)
+   return 4;
+   else
+   return 2;
+}
+
 static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
 };
 
+static const struct mtk_dpi_conf mt2701_conf = {
+   .cal_factor = mt2701_calculate_factor,
+   .reg_h_fre_con = 0xb0,
+   .edge_sel_en = true,
+};
+
 static const struct of_device_id mtk_dpi_of_ids[] = {
+   { .compatible = "mediatek,mt2701-dpi",
+ .data = _conf,
+   },
{ .compatible = "mediatek,mt8173-dpi",
  .data = _conf,
},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a2ca90fc403c..f4fb86ab7b8d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -372,6 +372,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ .compatible = "mediatek,mt8173-disp-ufoe",  .data = (void 
*)MTK_DISP_UFOE },
{ .compatible = "mediatek,mt2701-dsi",.data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dsi",.data = (void *)MTK_DSI },
+   { .compatible = "mediatek,mt2701-dpi",.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8173-dpi",.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt2701-disp-mutex", .data = (void 
*)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex", .data = (void 
*)MTK_DISP_MUTEX },
-- 
2.12.5

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

[PATCH v1 5/7] drm/mediatek: implement connection from BLS to DPI0

[Bibby Hsieh]

Modify display driver to support connection from BLS to DPI.

Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..289a68c6731f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -35,6 +35,7 @@
 #define DISP_REG_CONFIG_DISP_OVL_MOUT_EN   0x030
 #define DISP_REG_CONFIG_OUT_SEL0x04c
 #define DISP_REG_CONFIG_DSI_SEL0x050
+#define DISP_REG_CONFIG_DPI_SEL0x064
 
 #define DISP_REG_MUTEX_EN(n)   (0x20 + 0x20 * (n))
 #define DISP_REG_MUTEX(n)  (0x24 + 0x20 * (n))
@@ -84,7 +85,10 @@
 
 #define OVL_MOUT_EN_RDMA   0x1
 #define BLS_TO_DSI_RDMA1_TO_DPI1   0x8
+#define BLS_TO_DPI_RDMA1_TO_DSI0x2
 #define DSI_SEL_IN_BLS 0x0
+#define DPI_SEL_IN_BLS 0x0
+#define DSI_SEL_IN_RDMA0x1
 
 struct mtk_disp_mutex {
int id;
@@ -189,9 +193,17 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
 enum mtk_ddp_comp_id cur,
 enum mtk_ddp_comp_id next)
 {
-   if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
+   if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
   config_regs + DISP_REG_CONFIG_OUT_SEL);
+   } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
+   writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
+  config_regs + DISP_REG_CONFIG_OUT_SEL);
+   writel_relaxed(DSI_SEL_IN_RDMA,
+  config_regs + DISP_REG_CONFIG_DSI_SEL);
+   writel_relaxed(DPI_SEL_IN_BLS,
+  config_regs + DISP_REG_CONFIG_DPI_SEL);
+   }
 }
 
 void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
-- 
2.12.5

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

Re: [PATCH] gpu: host1x: Fix compiler errors

[Thierry Reding]

On Mon, Mar 26, 2018 at 04:44:14PM +0200, Emil Goode wrote:
> The compiler is complaining with the following errors:
> 
> drivers/gpu/host1x/cdma.c:94:48: error:
>   passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
>   [-Werror=incompatible-pointer-types]
> 
> drivers/gpu/host1x/cdma.c:113:48: error:
>   passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
>   [-Werror=incompatible-pointer-types]
> 
> The expected pointer type of the third argument to dma_alloc_wc() is
> dma_addr_t but phys_addr_t is passed. Fix this by adding casts to the
> expected pointer type.
> 
> Signed-off-by: Emil Goode 
> ---
>  drivers/gpu/host1x/cdma.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
> index 28541b280739..5e8b321a751e 100644
> --- a/drivers/gpu/host1x/cdma.c
> +++ b/drivers/gpu/host1x/cdma.c
> @@ -91,8 +91,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
>  
>   size = iova_align(>iova, size);
>  
> - pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
> -   GFP_KERNEL);
> + pb->mapped = dma_alloc_wc(host1x->dev, size,
> +   (dma_addr_t *)>phys, GFP_KERNEL);
>   if (!pb->mapped)
>   return -ENOMEM;
>  
> @@ -110,8 +110,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
>   if (err)
>   goto iommu_free_iova;
>   } else {
> - pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
> -   GFP_KERNEL);
> + pb->mapped = dma_alloc_wc(host1x->dev, size,
> +   (dma_addr_t *)>phys, GFP_KERNEL);
>   if (!pb->mapped)
>   return -ENOMEM;
>  

This doesn't seem right. There's no guarantee that phys_addr_t and
dma_addr_t will be compatible, so the above isn't always correct. Also,
I don't see a need for pb->phys to ever be phys_addr_t. It's allocated
through dma_alloc_wc() exclusively, so it should just be dma_addr_t.

Note that the !pb->phys check in host1x_pushbuffer_destroy() becomes
technically wrong if pb->phys is dma_addr_t (0 is a perfectly valid
value for dma_addr_t), so make sure to flip that to !pb->mapped instead.
pb->mapped and pb->phys are always set in tandem, and checking mapped
for non-NULL is the right check to test whether the pair is valid or
not.

Thierry


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

RE: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
>
>Implements the enable and disable functions for HDCP2.2 encryption of the
>PORT.
>
>v2:
>  intel_wait_for_register is used instead of wait_for. [Chris Wilson]
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 54
>+++
> 1 file changed, 54 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index d70320da85e4..91cac643f083 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -19,6 +19,7 @@
>(enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES5
> #define HDCP2_LC_RETRY_CNT3
>+#define TIME_FOR_ENCRYPT_STATUS_CHANGE32
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim) @@ -
>1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct intel_connector
>*connector)
>
>   return ret;
> }
>+
>+static int hdcp2_enable_encryption(struct intel_connector *connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  enum port port = connector->encoder->port;
>+  int ret;
>+
>+  if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)

Print a message saying "Encryption Already enabled" .

>+  return 0;
>+
>+  if (hdcp->hdcp_shim->toggle_signalling)

Check for "hdcp->hdcp_shim" as well.

>+  hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
>+
>+  if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
>+
>+  /* Link is Authenticated. Now set for Encryption */
>+  I915_WRITE(HDCP2_CTR_DDI(port),
>+ I915_READ(HDCP2_CTR_DDI(port)) |
>+ CTL_LINK_ENCRYPTION_REQ);
>+  }
>+
>+  ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
>+LINK_ENCRYPTION_STATUS,
>+LINK_ENCRYPTION_STATUS,
>+TIME_FOR_ENCRYPT_STATUS_CHANGE);

Print a message in case of timeout.

>+  return ret;
>+}
>+
>+static int hdcp2_disable_encryption(struct intel_connector *connector)
>+{
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  enum port port = connector->encoder->port;
>+  int ret;
>+
>+  if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
>LINK_ENCRYPTION_STATUS))

Put a info message saying "Already Disabled" .

>+  return 0;
>+
>+  I915_WRITE(HDCP2_CTR_DDI(port),
>+ I915_READ(HDCP2_CTR_DDI(port)) &
>~CTL_LINK_ENCRYPTION_REQ);
>+
>+  ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
>+LINK_ENCRYPTION_STATUS, 0x0,
>+TIME_FOR_ENCRYPT_STATUS_CHANGE);

If this times out, do we still need to toggle the signalling ?

>+
>+  if (hdcp->hdcp_shim->toggle_signalling)

Check for validity of " hdcp->hdcp_shim".

>+  hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
>+
>+  return ret;
>+}
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106490] VA-API video deconding broken for Chromium on Mesa 18.0.3

[bugzilla-daemon]

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

--- Comment #1 from Leonid Maksymchuk  ---
It looks like it's Chromium or VA-API bug, but not Mesa.
Chromium VA-API decoding works with Mesa 18.0 if RGB10 visual configs is
disabled.

-- 
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 106496] Hung screen at modprobe amdgpu

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Michel Dänzer  ---
You'll have to disable SME for the time being.

*** This bug has been marked as a duplicate of bug 106245 ***

-- 
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 106245] Raven ridge (2400g) fails to start (swiotlb buffer is full) with IOMMU disabled

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||c...@atamisk.net

--- Comment #3 from Michel Dänzer  ---
*** Bug 106496 has been marked as a duplicate of this bug. ***

-- 
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] gpu: host1x: Acquire a reference to the IOVA cache

[Thierry Reding]

On Mon, May 14, 2018 at 01:34:27PM +0300, Dmitry Osipenko wrote:
> On 14.05.2018 13:13, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > The IOVA API uses a memory cache to allocate IOVA nodes from. To make
> > sure that this cache is available, obtain a reference to it and release
> > the reference when the cache is no longer needed.
> > 
> > On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
> > that reference and never releases it. On 32-bit ARM, this is papered
> > over by the Tegra DRM driver (the sole user of the host1x API requiring
> > the cache) acquiring a reference to the IOVA cache for its own purposes.
> > However, there may be additional users of this API in the future, so fix
> > this upfront to avoid surprises.
> > 
> > Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/host1x/dev.c | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)

Applied, thanks.

Thierry


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

[Bug 106496] Hung screen at modprobe amdgpu

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #139536|text/x-log  |text/plain
  mime type||

-- 
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] gpu: drm: tegra: Adding new typedef vm_fault_t

[Thierry Reding]

On Tue, Apr 17, 2018 at 07:17:55PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
> 
> Reference id -> 1c8f422059ae ("mm: change return type to
> vm_fault_t")
> 
> Previously vm_insert_page() returns err which driver
> mapped into VM_FAULT_* type. The new function 
> vmf_insert_page() will replace this inefficiency by
> returning VM_FAULT_* type.
> 
> Signed-off-by: Souptick Joarder 
> ---
>  drivers/gpu/drm/tegra/gem.c | 18 ++
>  1 file changed, 2 insertions(+), 16 deletions(-)

Applied, thanks.

Thierry


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

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

[Maxime Ripard]

Hi Eric,

On Tue, Apr 24, 2018 at 09:53:28AM -0700, Eric Anholt wrote:
> Maxime Ripard  writes:
> 
> > The vc4 HVS uses an internal RGB888 representation of the frames, and will
> > by default expand formats using a lower depth using zeros.
> >
> > This causes an issue when we try to use other compositing software such as
> > pixman that seems to be filling the missing bits using the format least
> > significant bit value. As such, this prevents us from checking the display
> > output in a reliable way.
> 
> I don't think this is the right expansion function, though?  My
> understanding of proper unorm expansion, and what pixman's
> unorm_to_unorm() does, is that you replicate the value in the missing
> bits until you've filled them all (so SCALER_CTL0_EXPAND_REPEAT)

This was based on experiment, so I might have missed that case and you
are probably right. I'll test with SCALER_CTL0_EXPAND_REPEAT and let
you know :)

Thanks!
Maxime

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


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

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

[Stefan Schake]

On Tue, Apr 24, 2018 at 9:48 AM, Maxime Ripard
 wrote:
> The vc4 HVS uses an internal RGB888 representation of the frames, and will
> by default expand formats using a lower depth using zeros.
>
> This causes an issue when we try to use other compositing software such as
> pixman that seems to be filling the missing bits using the format least
> significant bit value. As such, this prevents us from checking the display
> output in a reliable way.
>
> To prevent this, force the same behaviour so that we can do such things.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_plane.c | 1 +
>  drivers/gpu/drm/vc4/vc4_regs.h  | 8 
>  2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index ce39390be389..8dd33c6e9fd8 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -542,6 +542,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> /* Control word */
> vc4_dlist_write(vc4_state,
> SCALER_CTL0_VALID |
> +   VC4_SET_FIELD(SCALER_CTL0_EXPAND_LSB, 
> SCALER_CTL0_EXPAND) |
> (format->pixel_order << SCALER_CTL0_ORDER_SHIFT) |
> (format->hvs << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
> VC4_SET_FIELD(tiling, SCALER_CTL0_TILING) |
> diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
> index a141496104a6..7c28e6207ec2 100644
> --- a/drivers/gpu/drm/vc4/vc4_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_regs.h
> @@ -806,12 +806,20 @@ enum hvs_pixel_format {
>  #define SCALER_CTL0_ORDER_MASK VC4_MASK(14, 13)
>  #define SCALER_CTL0_ORDER_SHIFT13
>
> +#define SCALER_CTL0_EXPAND_MASKVC4_MASK(12, 11)
> +#define SCALER_CTL0_EXPAND_SHIFT   11
> +
>  #define SCALER_CTL0_SCL1_MASK  VC4_MASK(10, 8)
>  #define SCALER_CTL0_SCL1_SHIFT 8
>
>  #define SCALER_CTL0_SCL0_MASK  VC4_MASK(7, 5)
>  #define SCALER_CTL0_SCL0_SHIFT 5
>
> +#define SCALER_CTL0_EXPAND_ZERO0
> +#define SCALER_CTL0_EXPAND_LSB 1
> +#define SCALER_CTL0_EXPAND_MSB 2
> +#define SCALER_CTL0_EXPAND_REPEAT  3

Just a heads up, those defines have recently landed in drm-misc, with
slightly different naming: SCALER_CTL0_RGBA_EXPAND_*

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

Re: [PATCH 0/3] fbdev/drm: sh_mobile: remove unused MERAM support

[Bartlomiej Zolnierkiewicz]

On Friday, April 27, 2018 02:09:31 PM Daniel Vetter wrote:
> On Fri, Apr 27, 2018 at 1:36 PM, Laurent Pinchart
>  wrote:
> > Hi Bartlomiej,
> >
> > On Friday, 27 April 2018 14:21:42 EEST Bartlomiej Zolnierkiewicz wrote:
> >> Hi,
> >>
> >> This patchset removes unused MERAM support (last user was removed
> >> 3 years ago) from shmobile fbdev & drm drivers and then removes
> >> MERAM driver itself.
> >>
> >> If it is okay to merge this patches I would like patch #1 to go
> >> through fbdev tree and patch #2 to go through drm tree. Once they
> >> are both upstream (v4.18) I will apply patch #3 to fbdev tree.
> >
> > Or you could merge everything through the fbdev tree in one go, the shmobile
> > driver hardly sees any activity these days.
> >
> > For the whole series,
> >
> > Acked-by: Laurent Pinchart 
> 
> Yeah merging all through fbdev is probably simplest, shmobile is not a
> driver that's actively changed a lot. Ack from me too.

Thanks, I've applied all patches to fbdev-for-next.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[ryadav]

On 2018-05-11 20:58, Sean Paul wrote:

On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:

SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.

Currently, in dpu driver, all the power resource
management is part of power_handle which manages
these resources via a custom implementation. And
the resource relationships are not modelled properly
in dt.  Moreover the irq domain handling code is part
of dpu device (which is a child device) due to lack
of a dedicated driver for MDSS top level wrapper
device.

This change adds dpu_mdss top level driver to handle
common clock like - core clock, ahb clock
(for register access), main power supply (i.e. gdsc)
and irq management.
The top level mdss device/driver acts as an interrupt
controller and manage hwirq mapping for its child
devices.

It implements runtime_pm support for resource management.
Child nodes can control these resources via runtime_pm
get/put calls on their corresponding devices due to parent
child relationship defined in dt.

Changes in v2:
- merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
- merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
- fix indentation for irq_find_mapping call (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant param checks from
  dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
- remove redundant param checks from
  dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
	- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)

- remove redundant param check from dpu_mdss_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove extra line before dpu_mdss_init (Sean Paul)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- remove redundant param check from dpu_mdss_irq (Jordan Crouse)
- change mdss address space log message to debug and use %pK for
  kernel pointers (Jordan Crouse)
	- remove unnecessary log message from msm_dss_parse_clock (Jordan 
Crouse)

- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 254 
++

 drivers/gpu/drm/msm/dpu_io_util.c |  57 +
 drivers/gpu/drm/msm/msm_drv.c |  26 ++-
 drivers/gpu/drm/msm/msm_drv.h |   2 +-
 drivers/gpu/drm/msm/msm_kms.h |   1 +
 include/linux/dpu_io_util.h   |   2 +
 16 files changed, 339 insertions(+), 226 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c



/snip

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c

new file mode 100644
index 000..ce680ea
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c


/snip


+
+int dpu_mdss_init(struct drm_device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev->dev);
+   struct msm_drm_private *priv = dev->dev_private;
+   struct dpu_mdss *dpu_mdss;
+   struct dss_module_power *mp;
+   int ret = 0;
+
+   dpu_mdss = devm_kzalloc(dev->dev, sizeof(*dpu_mdss), GFP_KERNEL);
+   if (!dpu_mdss)
+   return -ENOMEM;
+
+   dpu_mdss->mmio = msm_ioremap(pdev, "mdss_phys", "mdss_phys");
+   if (IS_ERR(dpu_mdss->mmio)) {
+   ret = PTR_ERR(dpu_mdss->mmio);


remove this ...


+   DPU_ERROR("mdss register memory map failed: %d\n", ret);
+   dpu_mdss->mmio = NULL;
+   return ret;


... and replace with
return PTR_ERR(dpu_mdss->mmio);


Sure, I'll update in v3.


+   }

Re: [PATCH] video: fbdev: remove unused auo_k190xfb drivers

[Bartlomiej Zolnierkiewicz]

On Friday, April 27, 2018 05:07:41 PM Heiko Stuebner wrote:
> Am Freitag, 27. April 2018, 13:04:24 CEST schrieb Bartlomiej Zolnierkiewicz:
> > auo_k1900fb and auo_k1901fb drivers have been introduced six
> > years ago by following commits:
> > 
> > commit 2c8304d3125b ("video: auo_k190x: add code shared by controller 
> > drivers")
> > commit 96b1d500e028 ("video: auo_k190x: add driver for AUO-K1900 variant")
> > commit 53027cdf2a67 ("video: auo_k190x: add driver for AUO-K1901 variant")
> > 
> > They never had any in-kernel user so just remove them (since
> > they are platform drivers they need corresponding platform
> > devices to be registered by kernel and it has never happened).
> > 
> > Cc: Heiko Stübner 
> > Signed-off-by: Bartlomiej Zolnierkiewicz 
> 
> While I still hold the ereaders using these controllers in high regard
> as my first kernel hacking project, reality is that I don't think I'll
> ever continue on trying to mainline these and if later someone wants
> to resurrect these (very old now) devices, they'll probably need a drm-
> driver anyway. So for the removal
> 
> Reviewed-by: Heiko Stuebner 

Thanks, I've queued the patch for v4.18.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

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

[Andrzej Hajda]

On 14.05.2018 11:38, Philippe CORNU wrote:
> Hi Laurent, Archit, Andrzej & Yannick,
>
> Do you have any comments on this v2 driver part?
> (more details regarding v1/v2 differences in the cover letter 
> https://www.spinics.net/lists/dri-devel/msg174137.html)
>
> Thank you,
> Philippe :-)
>
>
> On 04/25/2018 09:53 AM, Philippe Cornu wrote:
>> Add the optional power supplies using the description found in
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> The sii902x input IOs are not "io safe" so it is important to
>> enable/disable voltage regulators during probe/remove phases to
>> avoid damages.

What exactly does it mean? Ie I understand that the chip has some
limitations, but why enabling/disabling regulators in probe/remove
should solve it?

Regards
Andrzej

>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>   drivers/gpu/drm/bridge/sii902x.c | 38 
>> ++
>>   1 file changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index 60373d7eb220..c367d7b91ade 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -24,6 +24,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   
>>   #include 
>>   #include 
>> @@ -86,6 +87,7 @@ struct sii902x {
>>  struct drm_bridge bridge;
>>  struct drm_connector connector;
>>  struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[2];
>>   };
>>   
>>   static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
>> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
>>  return PTR_ERR(sii902x->reset_gpio);
>>  }
>>   
>> +sii902x->supplies[0].supply = "iovcc";
>> +sii902x->supplies[1].supply = "vcc12";
>> +ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
>> +  sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "Failed to get power supplies: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
>> +sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "Failed to enable power supplies: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +usleep_range(1, 2);
>> +
>>  sii902x_reset(sii902x);
>>   
>>  ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>>  if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>   
>>  ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>> , 4);
>>  if (ret) {
>>  dev_err(dev, "regmap_read failed %d\n", ret);
>> -return ret;
>> +goto err_disable_regulator;
>>  }
>>   
>>  if (chipid[0] != 0xb0) {
>>  dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>>  chipid[0]);
>> -return -EINVAL;
>> +ret = -EINVAL;
>> +goto err_disable_regulator;
>>  }
>>   
>>  /* Clear all pending interrupts */
>> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
>>  IRQF_ONESHOT, dev_name(dev),
>>  sii902x);
>>  if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>  }
>>   
>>  sii902x->bridge.funcs = _bridge_funcs;
>> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
>>  i2c_set_clientdata(client, sii902x);
>>   
>>  return 0;
>> +
>> +err_disable_regulator:
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> +   sii902x->supplies);
>> +
>> +return ret;
>>   }
>>   
>>   static int sii902x_remove(struct i2c_client *client)
>> @@ -443,6 +470,9 @@ static int sii902x_remove(struct i2c_client *client)
>>   
>>  drm_bridge_remove(>bridge);
>>   
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> +   sii902x->supplies);
>> +
>>  return 0;
>>   }
>>   


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

Re: [PATCH v2 09/11] docs: Fix some broken references

[Masami Hiramatsu]

On Wed,  9 May 2018 10:18:52 -0300
Mauro Carvalho Chehab  wrote:

> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
>   ./scripts/documentation-file-ref-check --fix-rst
> 
> Manually checked if the produced result is valid, removing a few
> false-positives.

The part of kprobes and trace_kprobe changes look good to me :)

Acked-by: Masami Hiramatsu 

Thank you,

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  .../admin-guide/kernel-parameters.txt |  4 ++--
>  .../bindings/input/rotary-encoder.txt |  2 +-
>  Documentation/driver-api/gpio/consumer.rst|  2 +-
>  Documentation/kprobes.txt |  4 ++--
>  Documentation/trace/coresight.txt |  2 +-
>  Documentation/trace/events.rst|  2 +-
>  Documentation/trace/ftrace-uses.rst   |  2 +-
>  Documentation/trace/histogram.txt |  2 +-
>  Documentation/trace/intel_th.rst  |  2 +-
>  Documentation/trace/tracepoint-analysis.rst   |  6 +++---
>  Documentation/translations/ja_JP/howto.rst|  4 ++--
>  .../translations/zh_CN/magic-number.txt   |  4 ++--
>  .../zh_CN/video4linux/omap3isp.txt|  4 ++--
>  MAINTAINERS   | 20 +--
>  arch/Kconfig  |  2 +-
>  arch/arm/include/asm/cacheflush.h |  2 +-
>  arch/arm64/include/asm/cacheflush.h   |  2 +-
>  arch/microblaze/include/asm/cacheflush.h  |  2 +-
>  arch/um/Kconfig.um|  2 +-
>  arch/unicore32/include/asm/cacheflush.h   |  2 +-
>  arch/x86/entry/vsyscall/vsyscall_64.c |  2 +-
>  arch/xtensa/include/asm/cacheflush.h  |  4 ++--
>  block/Kconfig |  2 +-
>  certs/Kconfig |  2 +-
>  crypto/asymmetric_keys/asymmetric_type.c  |  2 +-
>  crypto/asymmetric_keys/signature.c|  2 +-
>  drivers/char/Kconfig  |  2 +-
>  drivers/clk/clk.c |  4 ++--
>  drivers/clk/ingenic/cgu.h |  2 +-
>  drivers/gpu/vga/Kconfig   |  2 +-
>  drivers/gpu/vga/vgaarb.c  |  2 +-
>  drivers/input/joystick/Kconfig| 10 +-
>  drivers/input/joystick/iforce/Kconfig |  2 +-
>  drivers/input/joystick/walkera0701.c  |  2 +-
>  drivers/input/misc/Kconfig|  4 ++--
>  drivers/input/misc/rotary_encoder.c   |  2 +-
>  drivers/input/mouse/Kconfig   |  6 +++---
>  drivers/input/mouse/alps.c|  2 +-
>  drivers/input/touchscreen/wm97xx-core.c   |  2 +-
>  drivers/lightnvm/pblk-rb.c|  2 +-
>  drivers/md/bcache/Kconfig |  2 +-
>  drivers/md/bcache/btree.c |  2 +-
>  drivers/md/bcache/extents.c   |  2 +-
>  drivers/media/dvb-core/dvb_ringbuffer.c   |  2 +-
>  drivers/media/pci/meye/Kconfig|  2 +-
>  drivers/media/platform/pxa_camera.c   |  4 ++--
>  .../soc_camera/sh_mobile_ceu_camera.c |  2 +-
>  drivers/media/radio/Kconfig   |  2 +-
>  drivers/media/radio/si470x/Kconfig|  2 +-
>  drivers/media/usb/dvb-usb-v2/lmedm04.c|  2 +-
>  drivers/media/usb/zr364xx/Kconfig |  2 +-
>  drivers/parport/Kconfig   |  6 +++---
>  drivers/staging/media/bcm2048/TODO|  2 +-
>  include/keys/asymmetric-subtype.h |  2 +-
>  include/keys/asymmetric-type.h|  2 +-
>  include/linux/assoc_array.h   |  2 +-
>  include/linux/assoc_array_priv.h  |  2 +-
>  include/linux/circ_buf.h  |  2 +-
>  include/linux/ftrace.h|  2 +-
>  include/linux/rculist_nulls.h |  2 +-
>  include/uapi/linux/prctl.h|  2 +-
>  include/xen/interface/io/kbdif.h  |  2 +-
>  kernel/cgroup/cpuset.c|  2 +-
>  kernel/trace/Kconfig  | 16 +++
>  lib/Kconfig   |  2 +-
>  security/selinux/hooks.c  |  2 +-
>  sound/core/Kconfig|  4 ++--
>  sound/drivers/Kconfig |  4 ++--
>  sound/pci/Kconfig | 10 +-
>  tools/include/uapi/linux/prctl.h  |  2 +-
>  tools/lib/api/fs/fs.c |  2 +-
>  tools/memory-model/README | 10 +-
>  tools/perf/util/bpf-prologue.c|  2 +-
>  .../config/custom-timeline-functions.cfg  |  4 ++--
>  74 files changed, 120 insertions(+), 120 deletions(-)
> 


-- 
Masami Hiramatsu 

[Bug 106513] AMDGPU not working on ubuntu 18.04

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 105760 ***

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

Re: [PATCH v3 3/4] phy: rockchip-typec: support variable phy config value

[Sean Paul]

On Mon, May 14, 2018 at 05:53:54PM +0800, Lin Huang wrote:
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - delete need_software_training variable
> - add default phy config value, if dts do not define phy config value, use 
> these value
> 
>  drivers/phy/rockchip/phy-rockchip-typec.c | 305 
> --
>  include/soc/rockchip/rockchip_phy_typec.h |  63 ++
>  2 files changed, 270 insertions(+), 98 deletions(-)
>  create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 76a4b58..10253ad 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c

/snip

>  
> +/* default phy config */
> +struct phy_config configs[3][4] = {

static const

Also, configs isn't a good name. How about tcphy_default_config?


> + {{ 0x2a, 0x00 },

Can you please expand the assignment for all of these, ie:

 { .swing = 0x2a, .pe = 0x00 },

> +  { 0x1f, 0x15 },
> +  { 0x14, 0x22 },
> +  { 0x02, 0x2b } },
> +
> + {{ 0x21, 0x00 },
> +  { 0x12, 0x15 },
> +  { 0x02, 0x22 },
> +  {0,0 } },
> +
> + {{ 0x15, 0x00 },
> +  { 0x00, 0x15 },
> +  {0,0 },
> +  {0,0 } },
> +};
> +

/snip

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

Re: [PATCH] Add SPDX idenitifier and clarify license

[Alex Deucher]

On Wed, May 2, 2018 at 10:00 AM, Christian König
 wrote:
> Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom:
>>
>> From: Dirk Hohndel 
>>
>> This is dual licensed under GPL-2.0 or MIT.
>>
>> Cc: "Christian König" 
>> Signed-off-by: Dirk Hohndel (VMware) 
>> Signed-off-by: Thomas Hellstrom 
>
>
> Acked-by: Christian König 
>
> If nobody objects I'm going to push it into our internal branch before the
> weekend.

Did you ever push these?  I don't see them in the tree.

Alex


>
> Thanks,
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/ttm/ttm_agp_backend.c  | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo_manager.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo_util.c  | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo_vm.c| 1 +
>>   drivers/gpu/drm/ttm/ttm_execbuf_util.c | 1 +
>>   drivers/gpu/drm/ttm/ttm_lock.c | 1 +
>>   drivers/gpu/drm/ttm/ttm_memory.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_module.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_object.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_tt.c   | 1 +
>>   11 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> b/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> index 7c2485fe88d8..ea4d59eb8966 100644
>> --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 98e06f8bf23b..68bcdd703cbd 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> index a7c232dc39cb..18d3debcc949 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2007-2010 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index 2ebbae6067ab..1c17aa6a7c3c 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index 8eba95b3c737..c7ece7613a6a 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> index 3dca206e85f7..e73ae0d22897 100644
>> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_lock.c
>> b/drivers/gpu/drm/ttm/ttm_lock.c
>> index 913f4318cdc0..20694b8a01ca 100644
>> --- a/drivers/gpu/drm/ttm/ttm_lock.c
>> +++ b/drivers/gpu/drm/ttm/ttm_lock.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index 27856c55dc84..450387c92b63 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_module.c
>> b/drivers/gpu/drm/ttm/ttm_module.c
>> index 66fc6395eb54..6ff40c041d79 100644
>> --- a/drivers/gpu/drm/ttm/ttm_module.c
>> +++ 

Re: [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines

[Ramalingam C]

On Wednesday 09 May 2018 03:36 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines

In preparation for implementing HDCP2.2 in I915, this patch adds HDCP register
definitions for HDMI and DP HDCP adaptations.

I believe we can just keep this message generic at drm layer, instead of 
calling out
i915 specifically. Currently it may be enabled for i915, but it will used for 
other
drivers as well in future.

ok



HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h, where are

Make it "where as".

ok



HDCP2.2 register offsets in DPCD offsets are defined at drm_dp_helper.h.

v2:
  bit_field definitions are replaced by macros. [Tomas and Jany]

Typo in "Jani's" name.

Sorry Jani.



v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
include/drm/drm_dp_helper.h | 54
+
include/drm/drm_hdcp.h  | 29 
2 files changed, 83 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
4de97e94ef9d..2185b3a88911 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -887,6 +887,60 @@
#define DP_AUX_HDCP_KSV_FIFO0x6802C
#define DP_AUX_HDCP_AINFO   0x6803B

+/**
+ * DP HDCP2.2 parameter offsets in DPCD address space  */

Rectify the comment style

ok



+#define DP_HDCP_2_2_REG_RTX_OFFSET 0x69000
+#define DP_HDCP_2_2_REG_TXCAPS_OFFSET  0x69008
+#define DP_HDCP_2_2_REG_CERT_RX_OFFSET 0x6900B
+#define DP_HDCP_2_2_REG_RRX_OFFSET 0x69215
+#define DP_HDCP_2_2_REG_RX_CAPS_OFFSET 0x6921D
+#define DP_HDCP_2_2_REG_EKPUB_KM_OFFSET0x69220
+#define DP_HDCP_2_2_REG_EKH_KM_OFFSET  0x692A0
+#define DP_HDCP_2_2_REG_M_OFFSET   0x692B0
+#define DP_HDCP_2_2_REG_HPRIME_OFFSET  0x692C0
+#define DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET   0x692E0
+#define DP_HDCP_2_2_REG_RN_OFFSET  0x692F0
+#define DP_HDCP_2_2_REG_LPRIME_OFFSET  0x692F8
+#define DP_HDCP_2_2_REG_EDKEY_KS_OFFSET0x69318
+#defineDP_HDCP_2_2_REG_RIV_OFFSET  0x69328
+#define DP_HDCP_2_2_REG_RXINFO_OFFSET  0x69330
+#define DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET   0x69332
+#define DP_HDCP_2_2_REG_VPRIME_OFFSET  0x69335
+#define DP_HDCP_2_2_REG_RECV_ID_LIST_OFFSET0x69345
+#define DP_HDCP_2_2_REG_V_OFFSET   0x693E0
+#define DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET   0x693F0
+#define DP_HDCP_2_2_REG_K_OFFSET   0x693F3
+#define DP_HDCP_2_2_REG_STREAM_ID_TYPE_OFFSET  0x693F5
+#define DP_HDCP_2_2_REG_MPRIME_OFFSET  0x69473
+#define DP_HDCP_2_2_REG_RXSTATUS_OFFSET0x69493
+#define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494

This is not matching to the spec. Seems reserved in spec.

Not really. Register is defined in the DP HDCP2.2 Spec.



+#define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518
+
+/**
+ * DP HDCP message start offsets in DPCD address space  */

Rectify comment style


+#define DP_HDCP_2_2_AKE_INIT_OFFSET
DP_HDCP_2_2_REG_RTX_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET
DP_HDCP_2_2_REG_CERT_RX_OFFSET
+#define DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET
DP_HDCP_2_2_REG_EKPUB_KM_OFFSET
+#define DP_HDCP_2_2_AKE_STORED_KM_OFFSET
DP_HDCP_2_2_REG_EKH_KM_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET
DP_HDCP_2_2_REG_HPRIME_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_PARING_INFO_OFFSET

Typo in pairing

Fixed.



DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET
+#define DP_HDCP_2_2_LC_INIT_OFFSET
DP_HDCP_2_2_REG_RN_OFFSET
+#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET
DP_HDCP_2_2_REG_LPRIME_OFFSET
+#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_RXINFO_OFFSET
+#define DP_HDCP_2_2_REP_SEND_ACK_OFFSET
DP_HDCP_2_2_REG_V_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET
DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_READY_OFFSET
DP_HDCP_2_2_REG_MPRIME_OFFSET
+
+#define HDCP_2_2_DP_RXSTATUS_LEN   1
+#define HDCP_2_2_DP_RXSTATUS_READY(x)  (x & BIT(0))
+#define HDCP_2_2_DP_RXSTATUS_H_PRIME(x)(x & BIT(1))
+#define HDCP_2_2_DP_RXSTATUS_PAIRING(x)(x & BIT(2))
+#define HDCP_2_2_DP_RXSTATUS_REAUTH_REQ(x) (x & BIT(3))
+#define HDCP_2_2_DP_RXSTATUS_LINK_FAILED(x)(x & 

Re: drm SPDX updates

[Daniel Vetter]

On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel wrote:
> On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote:
> > > I haven't seen any comments in the week since I wrote this. I'm not
> > > familiar with the process for the drm changes - so what are the usual next
> > > steps? Do I need to submit all or part of this somewhere else? Or does
> > > Dave simply take the series (since it has no executable code changes at
> > > all)?
> > 
> > There are a number of teams sending pull requests to Dave. One option would
> > be to have it all go through the drm-misc tree. (CC'ing Daniel Vetter about
> > that). Another option would perhaps be to send a pull request directly to
> > Dave (Dave?) And finally, one option would be to rely on the maintainers of
> > each submodule to take the patches that touch that module. If you go for
> > this last option, I can surely take the patches that touch vmwgfx, and
> > Christian the TTM patches.
> 
> Again, since this involves no code changes, I think I'd prefer the path
> directly via Dave, simply as it makes it more likely that none of them get
> lost... assuming you are willing to do that, Dave, where would you like that 
> PR?

Cc: dri-devel and send it to Dave and you should be good. But I thought
Alex pulled this all in now? In the end probably doesn't matter really if
it gets merged twice :-)

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

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

[Daniel Vetter]

On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > Change how dma_fence_add_callback() behaves, when the fence
> > has error-signaled by the time it is being add. After this commit,
> > dma_fence_add_callback() returns the fence error, if it
> > has error-signaled before dma_fence_add_callback() is called.
> 
> Why? What problem are you trying to solve? fence->error does not imply
> that the fence has yet been signaled, and the caller wants a callback
> when it is signaled.

On top this is incosistent, e.g. we don't do the same for any of the other
dma_fence interfaces. Plus there's the issue that you might alias errno
values with fence errno values.

I think keeping the error codes from the functions you're calling distinct
from the error code of the fence itself makes a lot of sense. The first
tells you whether your request worked out (or why not), the second tells
you whether the asynchronous dma operation (gpu rendering, page flip,
whatever) that the dma_fence represents worked out (or why not). That's 2
distinct things imo.

Might be good to show us the driver code that needs this behaviour so we
can discuss how to best handle your use-case.

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

Re: [PATCH v3 4/4] drm/rockchip: support dp training outside dp firmware

[Sean Paul]

On Mon, May 14, 2018 at 05:53:55PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So if the phy is using custom config values, do software
> link training instead of relying on firmware, if software training
> fail, keep firmware training as a fallback if sw training fails.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> 
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 416 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 501 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> 
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
>  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> + cdn-dp-link-training.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index cce64c1..d9d0d4d 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
>   goto out;
>   }
>   }
> -
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> +   "Failed to idle video %d\n", ret);
> + goto out;
> + }
>   }
>  
>   ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
>   goto out;
>   }
>  
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to valid video %d\n", ret);
> + goto out;
> + }
>   }
> +
>  out:
>   mutex_unlock(>lock);
>  }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..77a9793 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
>   bool connected;
>   bool active;
>   bool suspended;
> + bool use_fw_training;
>  
>   const struct firmware *fw;  /* cdn dp firmware */
>   unsigned int fw_version;/* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
>   u8 ports;
>   u8 lanes;
>   int active_port;
> + u8 train_set[4];
>  
>   u8 dpcd[DP_RECEIVER_CAP_SIZE];
>   bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 000..b8fd5bc
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c

/snip

> +static int cdn_dp_get_lower_link_rate(struct cdn_dp_device *dp)
> +{
> + if (dp->link.rate == DP_LINK_BW_1_62)
> + return -EINVAL;
> + else if (dp->link.rate == DP_LINK_BW_2_7)
> + dp->link.rate = DP_LINK_BW_1_62;

Extra indent

> + else
> + dp->link.rate = DP_LINK_BW_2_7;


This is better expressed as a switch statement:


switch 

[DPU PATCH v3 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[Rajesh Yadav]

SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.

Currently, in dpu driver, all the power resource
management is part of power_handle which manages
these resources via a custom implementation. And
the resource relationships are not modelled properly
in dt.  Moreover the irq domain handling code is part
of dpu device (which is a child device) due to lack
of a dedicated driver for MDSS top level wrapper
device.

This change adds dpu_mdss top level driver to handle
common clock like - core clock, ahb clock
(for register access), main power supply (i.e. gdsc)
and irq management.
The top level mdss device/driver acts as an interrupt
controller and manage hwirq mapping for its child
devices.

It implements runtime_pm support for resource management.
Child nodes can control these resources via runtime_pm
get/put calls on their corresponding devices due to parent
child relationship defined in dt.

Changes in v3:
- use "clock-frequency" dt-binding instead of "clock-rate",
  is it an optional binding (Sean Paul)
- remove handling of "clock-max-rate" proprietary
  dt-binding (Sean Paul)
- remove intermediate storing of msm_ioremap() retcode
  on failure instead return retcode directly (Sean Paul)
- msm_ioremap() prints error log in case of failure,
  so remove additional log from it's caller
- updated max core clock rate
- dropped (Reviewed-by: Jordan Crouse) due to above changes

Changes in v2:
- merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
- merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
- fix indentation for irq_find_mapping call (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant param checks from
  dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
- remove redundant param checks from
  dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)
- remove redundant param check from dpu_mdss_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove extra line before dpu_mdss_init (Sean Paul)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- remove redundant param check from dpu_mdss_irq (Jordan Crouse)
- change mdss address space log message to debug and use %pK for
  kernel pointers (Jordan Crouse)
- remove unnecessary log message from msm_dss_parse_clock (Jordan 
Crouse)
- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 251 ++
 drivers/gpu/drm/msm/dpu_io_util.c |  49 +
 drivers/gpu/drm/msm/msm_drv.c |  26 ++-
 drivers/gpu/drm/msm/msm_drv.h |   2 +-
 drivers/gpu/drm/msm/msm_kms.h |   1 +
 include/linux/dpu_io_util.h   |   2 +
 17 files changed, 329 insertions(+), 227 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d7558ed..d9826c1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -81,6 +81,7 @@ msm-y := \
disp/dpu1/dpu_reg_dma.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+   disp/dpu1/dpu_mdss.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 

[DPU PATCH v3 07/12] drm/msm/dpu: remove clock management code from dpu_power_handle

[Rajesh Yadav]

MDSS and dpu drivers manage their respective clocks via
runtime_pm. Remove custom clock management code from
dpu_power_handle.

Also dpu core clock management code is restricted to
dpu_core_perf module.

Changes in v3:
- none

Changes in v2:
- remove local variable to hold and return error code
  in _dpu_core_perf_set_core_clk_rate() instead return
  retcode directly from msm_dss_clk_set_rate() call (Sean Paul)
- dpu_core_perf_init() is called from dpu_kms_hw_init() and
  most of the params passed are already validated so remove
  redundant checks from dpu_core_perf_init() (Sean Paul)
- return >clk_config[i] directly to avoid local variable
  in _dpu_kms_get_clk() (Sean Paul)
- invert conditional check to eliminate local rate variable
  from dpu_kms_get_clk_rate() (Sean Paul)
- remove end label from dpu_power_resource_init() and return
  directly on dpu_power_parse_dt_supply() failure as no cleanup
  is needed (Sean Paul)
- remove checks for vtotal and vrefresh from
  dpu_encoder_phys_cmd_tearcheck_config() as they should be
  valid in mode_set call (Sean Paul)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  41 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h  |   8 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  28 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   9 +
 drivers/gpu/drm/msm/dpu_power_handle.c | 196 +
 drivers/gpu/drm/msm/dpu_power_handle.h |  40 -
 7 files changed, 63 insertions(+), 268 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 981f77f..5b79077 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -365,6 +365,17 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
}
 }
 
+static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
+{
+   struct dss_clk *core_clk = kms->perf.core_clk;
+
+   if (core_clk->max_rate && (rate > core_clk->max_rate))
+   rate = core_clk->max_rate;
+
+   core_clk->rate = rate;
+   return msm_dss_clk_set_rate(core_clk, 1);
+}
+
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
 {
u64 clk_rate = kms->perf.perf_tune.min_core_clk;
@@ -376,7 +387,8 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
dpu_cstate = to_dpu_crtc_state(crtc->state);
clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
clk_rate);
-   clk_rate = clk_round_rate(kms->perf.core_clk, clk_rate);
+   clk_rate = clk_round_rate(kms->perf.core_clk->clk,
+   clk_rate);
}
}
 
@@ -484,15 +496,11 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
DPU_EVT32(kms->dev, stop_req, clk_rate);
 
-   /* Temp change to avoid crash in clk_set_rate API. */
-#ifdef QCOM_DPU_SET_CLK
-   if (dpu_power_clk_set_rate(>phandle,
-  kms->perf.clk_name, clk_rate)) {
+   if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
DPU_ERROR("failed to set %s clock rate %llu\n",
-   kms->perf.clk_name, clk_rate);
+   kms->perf.core_clk->clk_name, clk_rate);
return;
}
-#endif
 
kms->perf.core_clk_rate = clk_rate;
DPU_DEBUG("update clk rate = %lld HZ\n", clk_rate);
@@ -656,7 +664,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
dpu_core_perf_debugfs_destroy(perf);
perf->max_core_clk_rate = 0;
perf->core_clk = NULL;
-   perf->clk_name = NULL;
perf->phandle = NULL;
perf->catalog = NULL;
perf->dev = NULL;
@@ -667,9 +674,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
struct dpu_power_client *pclient,
-   char *clk_name)
+   struct dss_clk *core_clk)
 {
-   if (!perf || !dev || !catalog || !phandle || !pclient || !clk_name) {
+   if (!pclient) {
DPU_ERROR("invalid parameters\n");
return -EINVAL;
}
@@ -678,23 +685,13 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
perf->catalog = catalog;
perf->phandle = phandle;
perf->pclient = pclient;
-   perf->clk_name = clk_name;
-
-   

[DPU PATCH v3 04/12] drm/msm/dpu: create new platform driver for dpu device

[Rajesh Yadav]

Current MSM display controller HW matches a tree like
hierarchy where MDSS top level wrapper is parent device
and mdp5/dpu, dsi, dp are child devices.

Each child device like mdp5, dsi etc. have a separate driver,
but currently dpu handling is tied to a single driver which
was managing both mdss and dpu resources.

Inorder to have the cleaner one to one device and driver
association, this change adds a new platform_driver for dpu
child device node which implements the kms functionality.

The dpu driver implements runtime_pm support for managing clocks
and bus bandwidth etc.

Changes in v3:
- none

Changes in v2:
- remove redundant param check from _dpu_kms_hw_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul)
- merge dpu_init into dpu_bind (Sean Paul)
- merge dpu_destroy into dpu_unbind (Sean Paul)
- use %pK for kernel pointer printing (Jordan Crouse)
- remove explicit devm allocation failure message (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Jordan Crouse 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 238 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   4 +
 drivers/gpu/drm/msm/msm_drv.c   |   2 +
 drivers/gpu/drm/msm/msm_drv.h   |   3 +
 4 files changed, 196 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e4ab753..85f3dbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1030,16 +1030,12 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms, 
unsigned long rate,
return rate;
 }
 
-static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
-   struct platform_device *pdev)
+static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
 {
struct drm_device *dev;
struct msm_drm_private *priv;
int i;
 
-   if (!dpu_kms || !pdev)
-   return;
-
dev = dpu_kms->dev;
if (!dev)
return;
@@ -1091,15 +1087,15 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
dpu_kms->core_client = NULL;
 
if (dpu_kms->vbif[VBIF_NRT])
-   msm_iounmap(pdev, dpu_kms->vbif[VBIF_NRT]);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_NRT]);
dpu_kms->vbif[VBIF_NRT] = NULL;
 
if (dpu_kms->vbif[VBIF_RT])
-   msm_iounmap(pdev, dpu_kms->vbif[VBIF_RT]);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_RT]);
dpu_kms->vbif[VBIF_RT] = NULL;
 
if (dpu_kms->mmio)
-   msm_iounmap(pdev, dpu_kms->mmio);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->mmio);
dpu_kms->mmio = NULL;
 
dpu_reg_dma_deinit();
@@ -1172,8 +1168,6 @@ int dpu_kms_mmu_attach(struct dpu_kms *dpu_kms, bool 
secure_only)
 static void dpu_kms_destroy(struct msm_kms *kms)
 {
struct dpu_kms *dpu_kms;
-   struct drm_device *dev;
-   struct platform_device *platformdev;
 
if (!kms) {
DPU_ERROR("invalid kms\n");
@@ -1181,20 +1175,7 @@ static void dpu_kms_destroy(struct msm_kms *kms)
}
 
dpu_kms = to_dpu_kms(kms);
-   dev = dpu_kms->dev;
-   if (!dev) {
-   DPU_ERROR("invalid device\n");
-   return;
-   }
-
-   platformdev = to_platform_device(dev->dev);
-   if (!platformdev) {
-   DPU_ERROR("invalid platform device\n");
-   return;
-   }
-
-   _dpu_kms_hw_destroy(dpu_kms, platformdev);
-   kfree(dpu_kms);
+   _dpu_kms_hw_destroy(dpu_kms);
 }
 
 static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
@@ -1550,7 +1531,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
struct dpu_kms *dpu_kms;
struct drm_device *dev;
struct msm_drm_private *priv;
-   struct platform_device *platformdev;
int i, rc = -EINVAL;
 
if (!kms) {
@@ -1565,34 +1545,28 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
goto end;
}
 
-   platformdev = to_platform_device(dev->dev);
-   if (!platformdev) {
-   DPU_ERROR("invalid platform device\n");
-   goto end;
-   }
-
priv = dev->dev_private;
if (!priv) {
DPU_ERROR("invalid private data\n");
goto end;
}
 
-   dpu_kms->mmio = msm_ioremap(platformdev, "mdp_phys", "mdp_phys");
+   dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp_phys", "mdp_phys");
if (IS_ERR(dpu_kms->mmio)) {
rc = PTR_ERR(dpu_kms->mmio);
DPU_ERROR("mdp register memory map failed: %d\n", rc);
dpu_kms->mmio = NULL;
goto error;
}
-   DRM_INFO("mapped mdp address space @%p\n", dpu_kms->mmio);
-   

[DPU PATCH v3 12/12] drm/msm/dpu: add error handling in dpu_core_perf_crtc_update

[Rajesh Yadav]

dpu_core_perf_crtc_update() is responsible for aggregating
the data bus bandwidth and dpu core clock rate requirements
and request the same for all active crtcs.
Currently, there is no error handling support in this function
so there is no way caller can know if the perf request fails.
This change adds error handling code in dpu_core_perf_crtc_update().
The caller side error handling is not added in this patch.

Changes in v3:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  3 ++-
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index d3a1ed9..85c0229 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -248,7 +248,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
-static void _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
+static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
struct drm_crtc *crtc, u32 bus_id)
 {
u64 bw_sum_of_intfs = 0, bus_ab_quota, bus_ib_quota;
@@ -257,6 +257,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
= dpu_crtc_get_client_type(crtc);
struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
+   int ret = 0;
 
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
@@ -286,25 +287,28 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 
switch (curr_client_type) {
case NRT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   ret = dpu_power_data_bus_set_quota(
+   >phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
-   bus_id, bus_ab_quota, bus_ib_quota);
+ bus_id, bus_ab_quota, bus_ib_quota);
break;
 
case RT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   ret = dpu_power_data_bus_set_quota(
+   >phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
-   bus_id, bus_ab_quota, bus_ib_quota);
+ bus_id, bus_ab_quota, bus_ib_quota);
break;
 
default:
DPU_ERROR("invalid client type:%d\n", curr_client_type);
break;
}
+   return ret;
 }
 
 /**
@@ -399,7 +403,7 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
return clk_rate;
 }
 
-void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
+int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
int params_changed, bool stop_req)
 {
struct dpu_core_perf_params *new, *old;
@@ -410,16 +414,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
int i;
struct msm_drm_private *priv;
struct dpu_kms *kms;
+   int ret;
 
if (!crtc) {
DPU_ERROR("invalid crtc\n");
-   return;
+   return -EINVAL;
}
 
kms = _dpu_crtc_get_kms(crtc);
if (!kms || !kms->catalog) {
DPU_ERROR("invalid kms\n");
-   return;
+   return -EINVAL;
}
priv = kms->dev->dev_private;
 
@@ -482,8 +487,14 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
update_bus, update_clk);
 
for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
-   if (update_bus & BIT(i))
-   _dpu_core_perf_crtc_update_bus(kms, crtc, i);
+   if (update_bus & BIT(i)) {
+   ret = _dpu_core_perf_crtc_update_bus(kms, crtc, i);
+   if (ret) {
+   DPU_ERROR("crtc-%d: failed to update bw vote 
for bus-%d\n",
+ crtc->base.id, i);
+   return ret;
+   }
+   }
}
 
/*
@@ -495,15 +506,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
DPU_EVT32(kms->dev, stop_req, clk_rate);
 
-   if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
+   ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
+ 

[DPU PATCH v3 10/12] drm/msm/dpu: use runtime_pm calls in dpu_dbg

[Rajesh Yadav]

Currently, msm_drv was creating dpu_power_handle client
which was used by dpu_dbg module to enable power resources
before register debug dumping.

Now since, the mdss core power resource handling is
implemented via runtime_pm and same has been removed
from dpu_power_handle. Remove dpu_power_handle dependency
from msm_drv and use pm_runtime_get/put_sync calls from
dpu_dbg module on dpu_mdss top level device for core,
ahb clock and power resource management (for register access).

Changes in v3:
- none

Changes in v2:
- resolved conflict in dpu_core_perf_init
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  7 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  4 
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  3 +--
 drivers/gpu/drm/msm/dpu_dbg.c | 18 +++---
 drivers/gpu/drm/msm/dpu_dbg.h | 13 ++---
 drivers/gpu/drm/msm/msm_drv.c | 27 +--
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 7 files changed, 11 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 5b79077..2cf3fca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -673,18 +673,11 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
-   struct dpu_power_client *pclient,
struct dss_clk *core_clk)
 {
-   if (!pclient) {
-   DPU_ERROR("invalid parameters\n");
-   return -EINVAL;
-   }
-
perf->dev = dev;
perf->catalog = catalog;
perf->phandle = phandle;
-   perf->pclient = pclient;
perf->core_clk = core_clk;
 
perf->max_core_clk_rate = core_clk->max_rate;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 015b5f0..5198e3c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -53,7 +53,6 @@ struct dpu_core_perf_tune {
  * @debugfs_root: top level debug folder
  * @catalog: Pointer to catalog configuration
  * @phandle: Pointer to power handler
- * @pclient: Pointer to power client
  * @core_clk: Pointer to core clock structure
  * @core_clk_rate: current core clock rate
  * @max_core_clk_rate: maximum allowable core clock rate
@@ -68,7 +67,6 @@ struct dpu_core_perf {
struct dentry *debugfs_root;
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle *phandle;
-   struct dpu_power_client *pclient;
struct dss_clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -115,14 +113,12 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
  * @dev: Pointer to drm device
  * @catalog: Pointer to catalog
  * @phandle: Pointer to power handle
- * @pclient: Pointer to power client
  * @core_clk: pointer to core clock
  */
 int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
-   struct dpu_power_client *pclient,
struct dss_clk *core_clk);
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 349bda5..9c3b220 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1721,8 +1721,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
 #endif
 
rc = dpu_core_perf_init(_kms->perf, dev, dpu_kms->catalog,
-   >phandle, priv->pclient,
-   _dpu_kms_get_clk(dpu_kms, "core_clk"));
+   >phandle, _dpu_kms_get_clk(dpu_kms, "core_clk"));
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
goto perf_err;
diff --git a/drivers/gpu/drm/msm/dpu_dbg.c b/drivers/gpu/drm/msm/dpu_dbg.c
index 4a39b82..27538bc 100644
--- a/drivers/gpu/drm/msm/dpu_dbg.c
+++ b/drivers/gpu/drm/msm/dpu_dbg.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dpu_dbg.h"
 #include "disp/dpu1/dpu_hw_catalog.h"
@@ -167,7 +168,6 @@ struct dpu_dbg_vbif_debug_bus {
  * @evtlog: event log instance
  * @reg_base_list: list of register dumping regions
  * @dev: device pointer
- * @power_ctrl: callback structure for enabling power for reading hw registers
  * @req_dump_blks: list of blocks requested for dumping
  * @panic_on_err: whether to kernel panic after triggering dump via debugfs
  * @dump_work: work struct for deferring register dump work to separate thread
@@ -182,7 

Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t

[Daniel Vetter]

On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
> > Hi Sean,
> > 
> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder  
> > wrote:
> > > Use new return type vm_fault_t for fault handler.
> > >
> > > Signed-off-by: Souptick Joarder 
> > > Reviewed-by: Matthew Wilcox 
> > > ---
> > >  drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
> > > b/drivers/gpu/drm/vgem/vgem_drv.c
> > > index 2524ff1..c64a859 100644
> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct 
> > > drm_gem_object *obj)
> > > kfree(vgem_obj);
> > >  }
> > >
> > > -static int vgem_gem_fault(struct vm_fault *vmf)
> > > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> > >  {
> > > struct vm_area_struct *vma = vmf->vma;
> > > struct drm_vgem_gem_object *obj = vma->vm_private_data;
> > > /* We don't use vmf->pgoff since that has the fake offset */
> > > unsigned long vaddr = vmf->address;
> > > -   int ret;
> > > +   vm_fault_t ret = VM_FAULT_SIGBUS;
> > > loff_t num_pages;
> > > pgoff_t page_offset;
> > > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> > > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> > > if (page_offset > num_pages)
> > > return VM_FAULT_SIGBUS;
> > >
> > > -   ret = -ENOENT;
> > > mutex_lock(>pages_lock);
> > > if (obj->pages) {
> > > get_page(obj->pages[page_offset]);
> > > --
> > > 1.9.1
> > >
> > 
> > Any further comment on this patch ?
> 
> Patch looks good to me. My build test fails, though, since vm_fault_t doesn't
> exist in drm-misc-next yet.

vm_fault_t is already in upstream, just needs Maarten to do a backmerge.
Which I think he's done by now ... Otherwise nag him more :-)
-Daniel

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

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

Re: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg definitions

[Ramalingam C]

Thank you for the review comments Uma Shankar!


On Wednesday 09 May 2018 03:31 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg 
definitions

This patch defines the hdcp2.2 protocol messages for the

Drop redundant "the" and one of the hdcp2.2. Not required.

ok



HDCP2.2 authentication.

v2:
  bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
  prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
include/drm/drm_hdcp.h | 183
+
1 file changed, 183 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
562fa7df2637..5e0a5ed1a08e 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -38,4 +38,187 @@
#define DRM_HDCP_DDC_BSTATUS0x41
#define DRM_HDCP_DDC_KSV_FIFO   0x43

+#define DRM_HDCP_1_4_SRM_ID0x8
+#define DRM_HDCP_1_4_VRL_LENGTH_SIZE   3
+#define DRM_HDCP_1_4_DCP_SIG_SIZE  40
+
+/**
+ * Protocol message definition for HDCP2.2 specification  */

Multi Line comment style not needed here.

Ok



+
+#define HDCP_STREAM_TYPE0  0x00
+#define HDCP_STREAM_TYPE1  0x01
+
+/* HDCP2.2 Msg IDs */
+#define HDCP_2_2_NULL_MSG  1
+#define HDCP_2_2_AKE_INIT  2
+#define HDCP_2_2_AKE_SEND_CERT 3
+#define HDCP_2_2_AKE_NO_STORED_KM  4
+#define HDCP_2_2_AKE_STORED_KM 5
+#define HDCP_2_2_AKE_SEND_HPRIME   7
+#define HDCP_2_2_AKE_SEND_PARING_INFO  8

Typo in Pairing

Fixed



+#define HDCP_2_2_LC_INIT   9
+#define HDCP_2_2_LC_SEND_LPRIME10
+#define HDCP_2_2_SKE_SEND_EKS  11
+#define HDCP_2_2_REP_SEND_RECVID_LIST  12
+#define HDCP_2_2_REP_SEND_ACK  15
+#define HDCP_2_2_REP_STREAM_MANAGE 16
+#define HDCP_2_2_REP_STREAM_READY  17
+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
+
+#define HDCP_2_2_RTX_LEN   8
+#define HDCP_2_2_RRX_LEN   8
+
+#define HDCP_2_2_K_PUB_RX_MOD_N_LEN128
+#define HDCP_2_2_K_PUB_RX_EXP_E_LEN3
+#define HDCP_2_2_K_PUB_RX_LEN
(HDCP_2_2_K_PUB_RX_MOD_N_LEN + \
+
HDCP_2_2_K_PUB_RX_EXP_E_LEN)
+
+#define HDCP_2_2_DCP_LLC_SIG_LEN   384
+
+#define HDCP_2_2_E_KPUB_KM_LEN 128
+#define HDCP_2_2_E_KH_KM_M_LEN (16 + 16)
+#define HDCP_2_2_H_PRIME_LEN   32
+#define HDCP_2_2_E_KH_KM_LEN   16
+#define HDCP_2_2_RN_LEN8
+#define HDCP_2_2_L_PRIME_LEN   32
+#define HDCP_2_2_E_DKEY_KS_LEN 16
+#define HDCP_2_2_RIV_LEN   8
+#define HDCP_2_2_SEQ_NUM_LEN   3
+#define HDCP_2_2_LPRIME_HALF_LEN   (HDCP_2_2_L_PRIME_LEN / 2)
+#define HDCP_2_2_RECEIVER_ID_LEN   DRM_HDCP_KSV_LEN
+#define HDCP_2_2_MAX_DEVICE_COUNT  31
+#define HDCP_2_2_RECEIVER_IDS_MAX_LEN
(HDCP_2_2_RECEIVER_ID_LEN * \
+
HDCP_2_2_MAX_DEVICE_COUNT)
+#define HDCP_2_2_MPRIME_LEN32
+
+/**

Remove an extra "*".


+ * TODO: This has to be changed for DP MST, as multiple stream on
+ * same port is possible.
+ * For HDCP2.2 on HDMI and DP SST this value is always 1.
+ */
+#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT   1
+#define HDCP_2_2_TXCAP_MASK_LEN2
+#define HDCP_2_2_RXCAPS_LEN3
+#define HDCP_2_2_RX_REPEATER(x)(x & BIT(0))
+#define HDCP_2_2_DP_HDCP_CAPABLE(x)(x & BIT(1))
+#define HDCP_2_2_RXINFO_LEN2
+
+/* HDCP1.x compliant device in downstream */
+#define HDCP_2_2_HDCP1_DEVICE_CONNECTED(x) (x & BIT(0))
+
+/* HDCP2.0 Compliant repeater in downstream */
+#define HDCP_2_2_HDCP_2_0_REP_CONNECTED(x) (x & BIT(1))
+#define HDCP_2_2_MAX_CASCADE_EXCEEDED(x)   (x & BIT(2))
+#define HDCP_2_2_MAX_DEVS_EXCEEDED(x)  (x & BIT(3))
+#define HDCP_2_2_DEV_COUNT_LO(x)   ((x & (0xF << 4)) >> 4)
+#define HDCP_2_2_DEV_COUNT_HI(x)   (x & BIT(0))

As per 2.2 spec this is a 5 bit field and no mention of HI and LO is there for 
dev count.
A comment explaining why this masking style is chosen will be helpful since it 
doesn't
match exactly with spec.

dev 

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Daniel Vetter]

On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
> On 2018-05-10 10:10, Andrzej Hajda wrote:
> > On 04.05.2018 15:52, Peter Rosin wrote:
> >> If the bridge supplier is unbound, this will bring the bridge consumer
> >> down along with the bridge. Thus, there will no longer linger any
> >> dangling pointers from the bridge consumer (the drm_device) to some
> >> non-existent bridge supplier.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/drm_bridge.c | 18 ++
> >>  include/drm/drm_bridge.h |  2 ++
> >>  2 files changed, 20 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >> index 78d186b6831b..0259f0a3ff27 100644
> >> --- a/drivers/gpu/drm/drm_bridge.c
> >> +++ b/drivers/gpu/drm/drm_bridge.c
> >> @@ -26,6 +26,7 @@
> >>  #include 
> >>  
> >>  #include 
> >> +#include 
> >>  #include 
> >>  
> >>  #include "drm_crtc_internal.h"
> >> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
> >> struct drm_bridge *bridge,
> >>if (bridge->dev)
> >>return -EBUSY;
> >>  
> >> +  if (encoder->dev->dev != bridge->odev) {
> > 
> > I wonder why device_link_add does not handle this case (self dependency)
> > silently as noop, as it seems to be a correct behavior.
> 
> It's kind-of a silly corner-case though, so perfectly understandable
> that it isn't handled.
> 
> >> +  bridge->link = device_link_add(encoder->dev->dev,
> >> + bridge->odev, 0);
> >> +  if (!bridge->link) {
> >> +  dev_err(bridge->odev, "failed to link bridge to %s\n",
> >> +  dev_name(encoder->dev->dev));
> >> +  return -EINVAL;
> >> +  }
> >> +  }
> >> +
> >>bridge->dev = encoder->dev;
> >>bridge->encoder = encoder;
> >>  
> >>if (bridge->funcs->attach) {
> >>ret = bridge->funcs->attach(bridge);
> >>if (ret < 0) {
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >>bridge->dev = NULL;
> >>bridge->encoder = NULL;
> >>return ret;
> >> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >>if (bridge->funcs->detach)
> >>bridge->funcs->detach(bridge);
> >>  
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >> +
> >>bridge->dev = NULL;
> >>  }
> >>  
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index b656e505d11e..804189c63a4c 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> >>   * @list: to keep track of all added bridges
> >>   * @timings: the timing specification for the bridge, if any (may
> >>   * be NULL)
> >> + * @link: drm consumer <-> bridge supplier
> > 
> > Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> > to the bridge" would be better.
> 
> I meant "<->" to indicate that the link is bidirectional, not that the
> relationship is in any way symmetric. I wasn't aware of any implication
> of a symmetric relationship when using "<->", do you have a reference?
> But I guess the different arrow notations in math are somewhat overloaded
> and that someone at some point must have used "<->" to indicate a
> symmetric relationship...

Yeah I agree with Andrzej here, for me <-> implies a symmetric
relationship. Spelling it out like Andrzej suggested sounds like the
better idea.
-Daniel

> 
> > Anyway:
> > Reviewed-by: Andrzej Hajda 
> 
> Thanks!
> 
> Cheers,
> Peter
> 
> >  --
> > Regards
> > Andrzej
> > 
> >>   * @funcs: control functions
> >>   * @driver_private: pointer to the bridge driver's internal context
> >>   */
> >> @@ -271,6 +272,7 @@ struct drm_bridge {
> >>struct drm_bridge *next;
> >>struct list_head list;
> >>const struct drm_bridge_timings *timings;
> >> +  struct device_link *link;
> >>  
> >>const struct drm_bridge_funcs *funcs;
> >>void *driver_private;
> > 
> > 
> 

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

[DPU PATCH v3 02/12] drm/msm/mdp5: subclass msm_mdss for mdp5

[Rajesh Yadav]

SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.

Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.

Add mdss helper interface (msm_mdss_funcs) to msm_mdss
base for mdp5/dpu mdss specific implementation calls.

This change subclasses msm_mdss for mdp5, dpu specific
changes will be done separately.

Changes in v3:
- none

Changes in v2:
- fixed indentation for irq_domain_add_linear call (Sean Paul)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154 --
 drivers/gpu/drm/msm/msm_drv.c |  23 +++--
 drivers/gpu/drm/msm/msm_kms.h |  20 ++--
 3 files changed, 110 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
index f2a0db7..1cc4e57 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
@@ -20,12 +20,10 @@
 #include "msm_drv.h"
 #include "mdp5_kms.h"
 
-/*
- * If needed, this can become more specific: something like struct mdp5_mdss,
- * which contains a 'struct msm_mdss base' member.
- */
-struct msm_mdss {
-   struct drm_device *dev;
+#define to_mdp5_mdss(x) container_of(x, struct mdp5_mdss, base)
+
+struct mdp5_mdss {
+   struct msm_mdss base;
 
void __iomem *mmio, *vbif;
 
@@ -41,22 +39,22 @@ struct msm_mdss {
} irqcontroller;
 };
 
-static inline void mdss_write(struct msm_mdss *mdss, u32 reg, u32 data)
+static inline void mdss_write(struct mdp5_mdss *mdp5_mdss, u32 reg, u32 data)
 {
-   msm_writel(data, mdss->mmio + reg);
+   msm_writel(data, mdp5_mdss->mmio + reg);
 }
 
-static inline u32 mdss_read(struct msm_mdss *mdss, u32 reg)
+static inline u32 mdss_read(struct mdp5_mdss *mdp5_mdss, u32 reg)
 {
-   return msm_readl(mdss->mmio + reg);
+   return msm_readl(mdp5_mdss->mmio + reg);
 }
 
 static irqreturn_t mdss_irq(int irq, void *arg)
 {
-   struct msm_mdss *mdss = arg;
+   struct mdp5_mdss *mdp5_mdss = arg;
u32 intr;
 
-   intr = mdss_read(mdss, REG_MDSS_HW_INTR_STATUS);
+   intr = mdss_read(mdp5_mdss, REG_MDSS_HW_INTR_STATUS);
 
VERB("intr=%08x", intr);
 
@@ -64,7 +62,7 @@ static irqreturn_t mdss_irq(int irq, void *arg)
irq_hw_number_t hwirq = fls(intr) - 1;
 
generic_handle_irq(irq_find_mapping(
-   mdss->irqcontroller.domain, hwirq));
+   mdp5_mdss->irqcontroller.domain, hwirq));
intr &= ~(1 << hwirq);
}
 
@@ -84,19 +82,19 @@ static irqreturn_t mdss_irq(int irq, void *arg)
 
 static void mdss_hw_mask_irq(struct irq_data *irqd)
 {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
 
smp_mb__before_atomic();
-   clear_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   clear_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
 }
 
 static void mdss_hw_unmask_irq(struct irq_data *irqd)
 {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
 
smp_mb__before_atomic();
-   set_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   set_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
 }
 
@@ -109,13 +107,13 @@ static void mdss_hw_unmask_irq(struct irq_data *irqd)
 static int mdss_hw_irqdomain_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hwirq)
 {
-   struct msm_mdss *mdss = d->host_data;
+   struct mdp5_mdss *mdp5_mdss = d->host_data;
 
if (!(VALID_IRQS & (1 << hwirq)))
return -EPERM;
 
irq_set_chip_and_handler(irq, _hw_irq_chip, handle_level_irq);
-   irq_set_chip_data(irq, mdss);
+   irq_set_chip_data(irq, mdp5_mdss);
 
return 0;
 }
@@ -126,90 +124,99 @@ static int mdss_hw_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
 };
 
 
-static int mdss_irq_domain_init(struct msm_mdss *mdss)
+static int mdss_irq_domain_init(struct mdp5_mdss *mdp5_mdss)
 {
-   struct device *dev = mdss->dev->dev;
+   struct device *dev = mdp5_mdss->base.dev->dev;
struct irq_domain *d;
 
d = irq_domain_add_linear(dev->of_node, 32, _hw_irqdomain_ops,
- mdss);
+ mdp5_mdss);
if (!d) {
dev_err(dev, "mdss irq domain add failed\n");
return -ENXIO;
}
 
-   mdss->irqcontroller.enabled_mask = 0;
-   mdss->irqcontroller.domain = d;
+   mdp5_mdss->irqcontroller.enabled_mask = 0;
+   

[DPU PATCH v3 11/12] drm/msm/dpu: move dpu_power_handle to dpu folder

[Rajesh Yadav]

Now, since dpu_power_handle manages only bus scaling
and power enable/disable notifications which are restricted
to dpu driver, move dpu_power_handle to dpu folder.

Changes in v3:
- none

Changes in v2:
- resolved conflict in dpu_unbind
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/Makefile |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c|   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  39 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 688 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 288 ++
 drivers/gpu/drm/msm/dpu_power_handle.c   | 688 ---
 drivers/gpu/drm/msm/dpu_power_handle.h   | 288 --
 drivers/gpu/drm/msm/msm_drv.c|   9 -
 drivers/gpu/drm/msm/msm_drv.h|   4 -
 14 files changed, 1008 insertions(+), 1015 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
 delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.c
 delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d9826c1..f578d5a 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -82,10 +82,10 @@ msm-y := \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
disp/dpu1/dpu_mdss.o \
+   disp/dpu1/dpu_power_handle.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
-   dpu_power_handle.o \
msm_prop.o \
msm_atomic.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 5c5cc56..33ab2ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -18,7 +18,6 @@
 #include 
 
 #include "dpu_core_irq.h"
-#include "dpu_power_handle.h"
 
 /**
  * dpu_core_irq_callback_handler - dispatch core interrupts
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 2cf3fca..d3a1ed9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -257,7 +257,6 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
= dpu_crtc_get_client_type(crtc);
struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
-   struct msm_drm_private *priv = kms->dev->dev_private;
 
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
@@ -287,7 +286,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 
switch (curr_client_type) {
case NRT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
@@ -295,7 +294,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
break;
 
case RT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e2d2e32..99c5e75 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -598,6 +598,7 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
_dpu_crtc_destroy_dest_scaler(dpu_crtc);
 
_dpu_crtc_deinit_events(dpu_crtc);
+   dpu_crtc->phandle = NULL;
 
drm_crtc_cleanup(crtc);
mutex_destroy(_crtc->crtc_lock);
@@ -2572,7 +2573,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
}
 
if (dpu_crtc->power_event)
-   dpu_power_handle_unregister_event(>phandle,
+   dpu_power_handle_unregister_event(dpu_crtc->phandle,
dpu_crtc->power_event);
 
 
@@ -2643,7 +2644,7 @@ 

[DPU PATCH v3 08/12] drm/msm/dpu: remove power management code from dpu_power_handle

[Rajesh Yadav]

Mdss main power supply (mdss_gdsc) is implemented as a
generic power domain and mdss top level wrapper device
manage it via runtime_pm. Remove custom power management
code from dpu_power_handle.

Changes in v3:
- remove redundant param check from
  dpu_power_resource_init() (Sean Paul)

Changes in v2:
- resolved merge conflict in dpu_power_resource_init
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/dpu_power_handle.c | 195 +
 drivers/gpu/drm/msm/dpu_power_handle.h |   2 -
 2 files changed, 1 insertion(+), 196 deletions(-)

diff --git a/drivers/gpu/drm/msm/dpu_power_handle.c 
b/drivers/gpu/drm/msm/dpu_power_handle.c
index 12602ae..bdf18de 100644
--- a/drivers/gpu/drm/msm/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/dpu_power_handle.c
@@ -101,150 +101,6 @@ void dpu_power_client_destroy(struct dpu_power_handle 
*phandle,
}
 }
 
-static int dpu_power_parse_dt_supply(struct platform_device *pdev,
-   struct dss_module_power *mp)
-{
-   int i = 0, rc = 0;
-   u32 tmp = 0;
-   struct device_node *of_node = NULL, *supply_root_node = NULL;
-   struct device_node *supply_node = NULL;
-
-   if (!pdev || !mp) {
-   pr_err("invalid input param pdev:%pK mp:%pK\n", pdev, mp);
-   return -EINVAL;
-   }
-
-   of_node = pdev->dev.of_node;
-
-   mp->num_vreg = 0;
-   supply_root_node = of_get_child_by_name(of_node,
-   "qcom,platform-supply-entries");
-   if (!supply_root_node) {
-   pr_debug("no supply entry present\n");
-   return rc;
-   }
-
-   for_each_child_of_node(supply_root_node, supply_node)
-   mp->num_vreg++;
-
-   if (mp->num_vreg == 0) {
-   pr_debug("no vreg\n");
-   return rc;
-   }
-
-   pr_debug("vreg found. count=%d\n", mp->num_vreg);
-   mp->vreg_config = devm_kzalloc(>dev, sizeof(struct dss_vreg) *
-   mp->num_vreg, GFP_KERNEL);
-   if (!mp->vreg_config) {
-   rc = -ENOMEM;
-   return rc;
-   }
-
-   for_each_child_of_node(supply_root_node, supply_node) {
-
-   const char *st = NULL;
-
-   rc = of_property_read_string(supply_node,
-   "qcom,supply-name", );
-   if (rc) {
-   pr_err("error reading name. rc=%d\n", rc);
-   goto error;
-   }
-
-   strlcpy(mp->vreg_config[i].vreg_name, st,
-   sizeof(mp->vreg_config[i].vreg_name));
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-min-voltage", );
-   if (rc) {
-   pr_err("error reading min volt. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].min_voltage = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-max-voltage", );
-   if (rc) {
-   pr_err("error reading max volt. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].max_voltage = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-enable-load", );
-   if (rc) {
-   pr_err("error reading enable load. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].enable_load = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-disable-load", );
-   if (rc) {
-   pr_err("error reading disable load. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].disable_load = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-pre-on-sleep", );
-   if (rc)
-   pr_debug("error reading supply pre sleep value. 
rc=%d\n",
-   rc);
-
-   mp->vreg_config[i].pre_on_sleep = (!rc ? tmp : 0);
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-pre-off-sleep", );
-   if (rc)
-   pr_debug("error reading supply pre sleep value. 
rc=%d\n",
-   rc);
-
-   mp->vreg_config[i].pre_off_sleep = (!rc ? tmp : 0);
-
-   rc = of_property_read_u32(supply_node,
-  

[DPU PATCH v3 09/12] drm/msm/dp: remove dpu_power_handle calls from dp driver

[Rajesh Yadav]

DP driver was dependent on dpu_power_handle for MDSS
common clocks and gdsc (main power supply).
The common clocks and power is managed by MDSS top
wrapper device now which is parent of all sub-devices
like DP device.
For same reason, clock and power management code is
removed from dpu_power_handle. Hence, remove the
dpu_power_handle calls from dp driver.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/dp/dp_power.c | 32 +---
 drivers/gpu/drm/msm/dp/dp_power.h |  4 +---
 2 files changed, 2 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_power.c 
b/drivers/gpu/drm/msm/dp/dp_power.c
index f6e341b..2a85b38 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -26,8 +26,6 @@ struct dp_power_private {
struct clk *pixel_parent;
 
struct dp_power dp_power;
-   struct dpu_power_client *dp_core_client;
-   struct dpu_power_handle *phandle;
 
bool core_clks_on;
bool link_clks_on;
@@ -410,8 +408,7 @@ static int dp_power_config_gpios(struct dp_power_private 
*power, bool flip,
return 0;
 }
 
-static int dp_power_client_init(struct dp_power *dp_power,
-   struct dpu_power_handle *phandle)
+static int dp_power_client_init(struct dp_power *dp_power)
 {
int rc = 0;
struct dp_power_private *power;
@@ -436,19 +433,8 @@ static int dp_power_client_init(struct dp_power *dp_power,
goto error_clk;
}
 
-   power->phandle = phandle;
-   snprintf(dp_client_name, DP_CLIENT_NAME_SIZE, "dp_core_client");
-   power->dp_core_client = dpu_power_client_create(phandle,
-   dp_client_name);
-   if (IS_ERR_OR_NULL(power->dp_core_client)) {
-   pr_err("[%s] client creation failed for DP", dp_client_name);
-   rc = -EINVAL;
-   goto error_client;
-   }
return 0;
 
-error_client:
-   dp_power_clk_init(power, false);
 error_clk:
dp_power_regulator_deinit(power);
 error_power:
@@ -466,7 +452,6 @@ static void dp_power_client_deinit(struct dp_power 
*dp_power)
 
power = container_of(dp_power, struct dp_power_private, dp_power);
 
-   dpu_power_client_destroy(power->phandle, power->dp_core_client);
dp_power_clk_init(power, false);
dp_power_regulator_deinit(power);
 }
@@ -521,13 +506,6 @@ static int dp_power_init(struct dp_power *dp_power, bool 
flip)
goto err_gpio;
}
 
-   rc = dpu_power_resource_enable(power->phandle,
-   power->dp_core_client, true);
-   if (rc) {
-   pr_err("Power resource enable failed\n");
-   goto err_dpu_power;
-   }
-
rc = dp_power_clk_enable(dp_power, DP_CORE_PM, true);
if (rc) {
pr_err("failed to enable DP core clocks\n");
@@ -537,8 +515,6 @@ static int dp_power_init(struct dp_power *dp_power, bool 
flip)
return 0;
 
 err_clk:
-   dpu_power_resource_enable(power->phandle, power->dp_core_client, false);
-err_dpu_power:
dp_power_config_gpios(power, flip, false);
 err_gpio:
dp_power_pinctrl_set(power, false);
@@ -562,12 +538,6 @@ static int dp_power_deinit(struct dp_power *dp_power)
power = container_of(dp_power, struct dp_power_private, dp_power);
 
dp_power_clk_enable(dp_power, DP_CORE_PM, false);
-   rc = dpu_power_resource_enable(power->phandle,
-   power->dp_core_client, false);
-   if (rc) {
-   pr_err("Power resource enable failed, rc=%d\n", rc);
-   goto exit;
-   }
dp_power_config_gpios(power, false, false);
dp_power_pinctrl_set(power, false);
dp_power_regulator_ctrl(power, false);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.h 
b/drivers/gpu/drm/msm/dp/dp_power.h
index 84fe01d..d9dab72 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.h
+++ b/drivers/gpu/drm/msm/dp/dp_power.h
@@ -16,7 +16,6 @@
 #define _DP_POWER_H_
 
 #include "dp_parser.h"
-#include "dpu_power_handle.h"
 
 /**
  * sruct dp_power - DisplayPort's power related data
@@ -32,8 +31,7 @@ struct dp_power {
int (*clk_enable)(struct dp_power *power, enum dp_pm_type pm_type,
bool enable);
int (*set_pixel_clk_parent)(struct dp_power *power);
-   int (*power_client_init)(struct dp_power *power,
-   struct dpu_power_handle *phandle);
+   int (*power_client_init)(struct dp_power *power);
void (*power_client_deinit)(struct dp_power *power);
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[DPU PATCH v3 06/12] drm/msm/dpu: use runtime_pm calls on dpu device

[Rajesh Yadav]

The dpu driver implements runtime_pm support for managing
dpu specific resources like - clocks, bus bandwidth etc.

Use pm_runtime_get/put_sync calls on dpu device.

The common clocks and power management for all child nodes
(mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver
via runtime_pm due to parent child relationship.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c |  8 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 16 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 45 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c|  6 ++--
 5 files changed, 31 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 977adc4..5c5cc56 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -452,10 +452,10 @@ void dpu_core_irq_preinstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
 
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, true);
+   pm_runtime_get_sync(_kms->pdev->dev);
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, false);
+   pm_runtime_put_sync(_kms->pdev->dev);
 
spin_lock_init(_kms->irq_obj.cb_lock);
 
@@ -496,7 +496,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
 
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, true);
+   pm_runtime_get_sync(_kms->pdev->dev);
for (i = 0; i < dpu_kms->irq_obj.total_irqs; i++)
if (atomic_read(_kms->irq_obj.enable_counts[i]) ||
!list_empty(_kms->irq_obj.irq_cb_tbl[i]))
@@ -504,7 +504,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
 
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, false);
+   pm_runtime_put_sync(_kms->pdev->dev);
 
kfree(dpu_kms->irq_obj.irq_cb_tbl);
kfree(dpu_kms->irq_obj.enable_counts);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 48920b05..e2d2e32 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -86,8 +86,12 @@ static inline int _dpu_crtc_power_enable(struct dpu_crtc 
*dpu_crtc, bool enable)
 
dpu_kms = to_dpu_kms(priv->kms);
 
-   return dpu_power_resource_enable(>phandle, dpu_kms->core_client,
-   enable);
+   if (enable)
+   pm_runtime_get_sync(_kms->pdev->dev);
+   else
+   pm_runtime_put_sync(_kms->pdev->dev);
+
+   return 0;
 }
 
 /**
@@ -2250,7 +2254,6 @@ static int _dpu_crtc_vblank_enable_no_lock(
 
/* drop lock since power crtc cb may try to re-acquire lock */
mutex_unlock(_crtc->crtc_lock);
-   pm_runtime_get_sync(dev->dev);
ret = _dpu_crtc_power_enable(dpu_crtc, true);
mutex_lock(_crtc->crtc_lock);
if (ret)
@@ -2580,7 +2583,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
-   pm_runtime_put_sync(crtc->dev->dev);
 
mutex_unlock(_crtc->crtc_lock);
 }
@@ -2611,8 +2613,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
return;
}
 
-   pm_runtime_get_sync(crtc->dev->dev);
-
drm_for_each_encoder(encoder, crtc->dev) {
if (encoder->crtc != crtc)
continue;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4386360..298a6ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -268,8 +268,12 @@ static inline int _dpu_encoder_power_enable(struct 
dpu_encoder_virt *dpu_enc,
 
dpu_kms = to_dpu_kms(priv->kms);
 
-   return dpu_power_resource_enable(>phandle, dpu_kms->core_client,
-   enable);
+   if (enable)
+   pm_runtime_get_sync(_kms->pdev->dev);
+   else
+   pm_runtime_put_sync(_kms->pdev->dev);
+
+   return 0;
 }
 
 void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys *phys_enc,
@@ -796,10 +800,8 @@ static void _dpu_encoder_resource_control_helper(struct 
drm_encoder *drm_enc,
}
 
if (enable) {
- 

[DPU PATCH v3 05/12] drm/msm/dpu: update dpu sub-block offsets wrt dpu base address

[Rajesh Yadav]

The dpu sub-block offsets were defined wrt mdss base address
instead of dpu base address.
Since, dpu is now defined as a separate device, update hw catalog
offsets for all dpu sub blocks wrt dpu base address.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 68 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 +++---
 2 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c5b370f..2fd3254 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -80,7 +80,7 @@
 static struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
-   .base = 0x1000, .len = 0x45C,
+   .base = 0x0, .len = 0x45C,
.features = 0,
.highest_bank_bit = 0x2,
.has_dest_scaler = true,
@@ -111,27 +111,27 @@
 static struct dpu_ctl_cfg sdm845_ctl[] = {
{
.name = "ctl_0", .id = CTL_0,
-   .base = 0x2000, .len = 0xE4,
+   .base = 0x1000, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_1", .id = CTL_1,
-   .base = 0x2200, .len = 0xE4,
+   .base = 0x1200, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_2", .id = CTL_2,
-   .base = 0x2400, .len = 0xE4,
+   .base = 0x1400, .len = 0xE4,
.features = 0
},
{
.name = "ctl_3", .id = CTL_3,
-   .base = 0x2600, .len = 0xE4,
+   .base = 0x1600, .len = 0xE4,
.features = 0
},
{
.name = "ctl_4", .id = CTL_4,
-   .base = 0x2800, .len = 0xE4,
+   .base = 0x1800, .len = 0xE4,
.features = 0
},
 };
@@ -211,21 +211,21 @@
}
 
 static struct dpu_sspp_cfg sdm845_sspp[] = {
-   SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x5000,
+   SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
-   SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x7000,
+   SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
-   SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x9000,
+   SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
-   SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xb000,
+   SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
-   SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x25000,
+   SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
-   SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x27000,
+   SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
-   SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x29000,
+   SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
-   SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2b000,
+   SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
 };
 
@@ -252,17 +252,17 @@
.lm_pair_mask = (1 << _lmpair) \
}
 static struct dpu_lm_cfg sdm845_lm[] = {
-   LM_BLK("lm_0", LM_0, 0x45000, DSPP_0,
+   LM_BLK("lm_0", LM_0, 0x44000, DSPP_0,
DS_0, PINGPONG_0, LM_1),
-   LM_BLK("lm_1", LM_1, 0x46000, DSPP_1,
+   LM_BLK("lm_1", LM_1, 0x45000, DSPP_1,
DS_1, PINGPONG_1, LM_0),
-   LM_BLK("lm_2", LM_2, 0x47000, DSPP_2,
+   LM_BLK("lm_2", LM_2, 0x46000, DSPP_2,
DS_MAX, PINGPONG_2, LM_5),
LM_BLK("lm_3", LM_3, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
LM_BLK("lm_4", LM_4, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
-   LM_BLK("lm_5", LM_5, 0x4a000, DSPP_3,
+   LM_BLK("lm_5", LM_5, 0x49000, DSPP_3,
DS_MAX, PINGPONG_3, LM_2),
 };
 
@@ -270,7 +270,7 @@
  * DSPP sub blocks config
  */
 static struct dpu_dspp_top_cfg sdm845_dspp_top = {
-   .name = "dspp_top", .base = 0x1300, .len = 0xc
+   .name = "dspp_top", .base = 0x300, .len = 0xc
 };
 
 static const struct dpu_dspp_sub_blks sdm845_dspp_sblk = {
@@ -304,10 +304,10 @@
}
 
 static struct dpu_dspp_cfg sdm845_dspp[] = {
-   DSPP_BLK("dspp_0", DSPP_0, 0x55000),
-   DSPP_BLK("dspp_1", DSPP_1, 0x57000),
-   DSPP_BLK("dspp_2", DSPP_2, 0x59000),
-   DSPP_BLK("dspp_3", DSPP_3, 0x5b000),
+   DSPP_BLK("dspp_0", DSPP_0, 0x54000),
+   DSPP_BLK("dspp_1", DSPP_1, 0x56000),
+   DSPP_BLK("dspp_2", DSPP_2, 0x58000),
+   DSPP_BLK("dspp_3", DSPP_3, 0x5a000),
 };
 
 

[DPU PATCH v3 00/12] Refactor DPU device/driver hierarchy and add runtime_pm support

[Rajesh Yadav]

SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes
sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper
manages common resources like common clocks, main power supply and
interrupts for its sub-blocks.

But current dpu driver implementation is based on a flat device hierarchy
where MDSS/DPU HW blocks were represented by single device and DSI/DP etc.
are represented as independent devices w/o any relationships b/t these
nodes which doesn't model the HW associations precisely.

A minimal MDSS and DPU controller device separation is done in following
patch series [1] but currently both these devices match to a single driver
which is getting probed two times and all the resources are still tied to
DPU device.

Moreover, all the power resource management in DPU driver is part of
power_handle module which manages these resources via a custom
implementation.

Irq domain handling is part of DPU device, due to lack of a dedicated
driver for MDSS top level wrapper device.

This patch series aims at adding separate drivers for MDSS top level
wrapper device and DPU child device. MDP5 device/driver is used as a
reference for this refactoring effort. Both the drivers implement
runtime_pm support for their power resource management. Child nodes can
control common resources managed by parent device due to parent child
relationship defined in dt. The top level MDSS device acts as an
interrupt controller and manages hwirq mappings for its child devices. 

Inorder to add MDP5 and DPU specific MDSS driver implementation, this patch
series also subclasses existing msm_mdss define. A helper interface
(msm_mdss_funcs) is added to invoke the platform specific implementations.

This change also corrects hw catalog offsets for all sub blocks present
within DPU device. The offset are now defined wrt DPU base address
(instead of using MDSS base address).

Clock and Power handling code have been removed from dpu_power_handle since
each device manages it's resources via runtime_pm. Now, since
dpu_power_handle manages only bus scaling and power enable/disable
notifications and it's usage is restricted to DPU driver only, moved
dpu_power_handle code to DPU folder.

The dt bindings update patch will be sent subsequently.

This patch series depends on [1].

1 - https://lists.freedesktop.org/archives/freedreno/2018-April/002354.html

Changes in v3:
- use "clock-frequency" dt-binding instead of "clock-rate",
  is it an optional binding (Sean Paul)
- remove handling of "clock-max-rate" proprietary
  dt-binding (Sean Paul)
- remove intermediate storing of msm_ioremap() retcode
  on failure instead return retcode directly (Sean Paul)
- remove redundant param check from
  dpu_power_resource_init() (Sean Paul)
- msm_ioremap() prints error log in case of failure,
  so remove additional log from it's caller
- updated max core clock rate

Changes in v2:
- fix indentation issues in dpu_mdss (Sean Paul)
- merge tiny static functions (like _dpu_mdss_hw_rev_init()
  and _dpu_mdss_get_intr_sources()) in caller functions (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant input param checks from dpu_mdss
  and dpu_kms (Sean Paul/Jordan Crouse)
- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- use %pK for kernel pointers (Jordan Crouse)
- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)
- merge dpu_init into dpu_bind and dpu_destroy into dpu_unbind (Sean 
Paul)
- remove explicit devm allocation failure message (Jordan Crouse)
- remove local variable to hold and return error code
  in _dpu_core_perf_set_core_clk_rate() instead return
  retcode directly from msm_dss_clk_set_rate() call (Sean Paul)
- return >clk_config[i] directly to avoid local variable
  in _dpu_kms_get_clk() (Sean Paul)
- invert conditional check to eliminate local rate variable
  from dpu_kms_get_clk_rate() (Sean Paul)
- remove end label from dpu_power_resource_init() and return
  directly on dpu_power_parse_dt_supply() failure as no cleanup
  is needed (Sean Paul)
- remove checks for vtotal and vrefresh from
  

[DPU PATCH v3 01/12] drm/msm: remove redundant pm_runtime_enable call from msm_drv

[Rajesh Yadav]

MDSS top level device includes the common power resources
and it's corresponding driver (i.e. mdp5_mdss) handles call
to enable/disable runtime_pm for enabling these resources.
Remove redundant pm_runtime_enable call from msm_drv.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index ebc40a9..9bb436f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -581,7 +581,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
goto fail;
}
priv->kms = kms;
-   pm_runtime_enable(dev);
 
/**
 * Since kms->funcs->hw_init(kms) might call
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs

[Chen-Yu Tsai]

On Mon, May 14, 2018 at 1:20 AM, Jagan Teki  wrote:
> On Tue, May 1, 2018 at 9:53 PM, Chen-Yu Tsai  wrote:
>> On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki  
>> wrote:
>>> Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them
>>> as default.
>>>
>>> Signed-off-by: Jagan Teki 
>>> ---
>>>  drivers/clk/sunxi-ng/Kconfig | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
>>> index 79dfd296c3d1..1fffd3bf6ff3 100644
>>> --- a/drivers/clk/sunxi-ng/Kconfig
>>> +++ b/drivers/clk/sunxi-ng/Kconfig
>>> @@ -58,6 +58,8 @@ config SUN8I_V3S_CCU
>>>
>>>  config SUN8I_DE2_CCU
>>> bool "Support for the Allwinner SoCs DE2 CCU"
>>> +   default ARM64 && ARCH_SUNXI
>>> +   depends on (DRM_SUN4I && (ARM64 && ARCH_SUNXI)) || COMPILE_TEST
>>
>> There is no reason to depend on DRM_SUN4I. There is no compile dependency.
>
> Since this CCU is for DE2 I've make DRM_SUN4I for that matter, any problem?

Users may very well be just using simplefb, but with all the clock drivers
enabled. That is a valid, if very limited, use case. So again, you should
not limit this driver based on DRM_SUN4I. There is no compile dependency.

>
>>
>> Also, this is needed on SUN8I as well, pretty much anything with DE 2.0.
>> So you shouldn't limit it to ARM64. That pretty much breaks things for
>> people with A83T's or H3's. In fact you should enable it by default for
>> these as well.
>
> True, I've skipped SUN8I since this series for A64.

And yet you are breaking existing users, which is a big no-no.

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

Re: [PATCH 3/3] drm/vc4: Attach underscan props to the HDMI connector

[Daniel Vetter]

On Wed, May 09, 2018 at 04:52:38PM +0200, Boris Brezillon wrote:
> On Mon, 7 May 2018 17:24:08 +0200
> Daniel Vetter  wrote:
> 
> > On Mon, May 07, 2018 at 04:44:34PM +0200, Boris Brezillon wrote:
> > > Now that the plane code takes the underscan setup into account, we can
> > > safely attach the underscan props to the HDMI connector.
> > > 
> > > We also take care of filling AVI infoframes correctly to expose the
> > > top/botton/left/right bar.
> > > 
> > > Note that these underscan props match pretty well the
> > > overscan_{left,right,top,bottom} properties defined in config.txt and
> > > parsed by the VC4 firmware.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > >  drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> > >  1 file changed, 25 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c 
> > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > index 1a6db291d48b..17464b5981f9 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > @@ -323,6 +323,16 @@ static struct drm_connector 
> > > *vc4_hdmi_connector_init(struct drm_device *dev,
> > >  DRM_MODE_CONNECTOR_HDMIA);
> > >   drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
> > >  
> > > + /* The hborder and vborder limit is arbitrarily set to 1024 which
> > > +  * should be more than enough for real use cases. Note that the actual
> > > +  * limitation comes from the display mode:
> > > +  *  hborder < hdisplay && vborder < vdisplay
> > > +  */
> > > + drm_connector_attach_underscan_properties(connector,  
> > 
> > We should probably sprinkle __must_check over all these :-)
> 
> I'm perfectly fine adding __must_check to
> drm_connector_attach_underscan_properties(), but I'm definitely not
> volunteering for a massive __must_check sanitization :P.

Yeah I just meant for this one here. The others might be a good candidate
for Documentation/gpu/todo.rst.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||mathieu.dut...@gmail.com

--- Comment #9 from Alex Deucher  ---
*** Bug 106513 has been marked as a duplicate of this bug. ***

-- 
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] Add SPDX idenitifier and clarify license

[Christian König]

Am 14.05.2018 um 18:00 schrieb Alex Deucher:

On Wed, May 2, 2018 at 10:00 AM, Christian König
 wrote:

Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom:

From: Dirk Hohndel 

This is dual licensed under GPL-2.0 or MIT.

Cc: "Christian König" 
Signed-off-by: Dirk Hohndel (VMware) 
Signed-off-by: Thomas Hellstrom 


Acked-by: Christian König 

If nobody objects I'm going to push it into our internal branch before the
weekend.

Did you ever push these?  I don't see them in the tree.


Ah, yes totally forgot about that. I think they (and another patch) 
ended up in the blacklist.


Need to ping John once more and probably work with those guys to change 
our server side rules for pushing license changes a bit.


Christian.



Alex



Thanks,
Christian.



---
   drivers/gpu/drm/ttm/ttm_agp_backend.c  | 1 +
   drivers/gpu/drm/ttm/ttm_bo.c   | 1 +
   drivers/gpu/drm/ttm/ttm_bo_manager.c   | 1 +
   drivers/gpu/drm/ttm/ttm_bo_util.c  | 1 +
   drivers/gpu/drm/ttm/ttm_bo_vm.c| 1 +
   drivers/gpu/drm/ttm/ttm_execbuf_util.c | 1 +
   drivers/gpu/drm/ttm/ttm_lock.c | 1 +
   drivers/gpu/drm/ttm/ttm_memory.c   | 1 +
   drivers/gpu/drm/ttm/ttm_module.c   | 1 +
   drivers/gpu/drm/ttm/ttm_object.c   | 1 +
   drivers/gpu/drm/ttm/ttm_tt.c   | 1 +
   11 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 7c2485fe88d8..ea4d59eb8966 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 98e06f8bf23b..68bcdd703cbd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index a7c232dc39cb..18d3debcc949 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2007-2010 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2ebbae6067ab..1c17aa6a7c3c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 8eba95b3c737..c7ece7613a6a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3dca206e85f7..e73ae0d22897 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_lock.c
b/drivers/gpu/drm/ttm/ttm_lock.c
index 913f4318cdc0..20694b8a01ca 100644
--- a/drivers/gpu/drm/ttm/ttm_lock.c
+++ b/drivers/gpu/drm/ttm/ttm_lock.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index 27856c55dc84..450387c92b63 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_module.c
b/drivers/gpu/drm/ttm/ttm_module.c
index 66fc6395eb54..6ff40c041d79 100644
--- a/drivers/gpu/drm/ttm/ttm_module.c
+++ b/drivers/gpu/drm/ttm/ttm_module.c
@@ -1,3 +1,4 @@
+/* 

Re: [PATCH 0/4] DRM helpers for Display Stream Compression PPS infoframes

[Daniel Vetter]

On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote:
> VESA Display Stream Compression is a specification for visually losless
> video compression over display links. The DSC standard also defines
> a picture parameter set (PPS) which encoder must communicate to decoders.
> This is done by encapsulating PPS header and payload bytes in an infoframe
> that can be sent to the display sink using secondary data packets
> as defined in DP 1.4 spec.
> 
> This patch series creates a new files drm_dsc.h and drm_dsc.c
> which define all the DSC related structures and helpers that
> can be called by drivers to form DSC PPS infoframes before
> enabling Display Stream compression on eDP/DP/MIPI

Just an aside: At least here the threading for this patch series seems
off. And patchwork also didn't pick up your cover letter:

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

> 
> These files can be used to add more DSC spec related helpers
> common to all drivers.
> 
> Gaurav K Singh (1):
>   drm/dsc: Define VESA Display Stream Compression Capabilities
> 
> Manasi Navare (3):
>   drm/dp: Define payload size for DP SDP PPS packet
>   drm/dsc: Define Display Stream Compression PPS infoframe
>   drm/dsc: Add helpers for DSC picture parameter set infoframes
> 
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_dsc.c   | 222 ++
>  include/drm/drm_dp_helper.h |   1 +
>  include/drm/drm_dsc.h   | 539 
> 

Please include these new files into the overall kernel-doc structure (and
make sure stuff is sufficiently documented).

Thanks, Daniel

>  4 files changed, 763 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dsc.c
>  create mode 100644 include/drm/drm_dsc.h
> 
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 106513] AMDGPU not working on ubuntu 18.04

[bugzilla-daemon]

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

Bug ID: 106513
   Summary: AMDGPU not working on ubuntu 18.04
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mathieu.dut...@gmail.com

Created attachment 139556
  --> https://bugs.freedesktop.org/attachment.cgi?id=139556=edit
the dmesg output

WHAT HAPPENS
- Amdgpu refuses to start without any information as of why.
- The problem happened between Ubuntu 17.10 and Ubuntu 18.04
- Three behaviors are occurring:
  a) The login happens normally (very rare, only 2 times)
  b) The login fails, the screen remain stuck and nothing happens
  c) The login fails and I am sent back to the login screen
- The mouse cursor does not respond to movements.
- I can access to the console via Ctrl+Alt F4
- The "dmesg" output is in attachment. The smoking gun in my opinion is
[  170.244044] [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for
more than 5secs aborting

TIPS
- I can access to login screen and to all the data on the computer. But only in
text mode. So I can update 

The crashes that allows ssh connection almost always happens when firefox is
openned and running a video (netflix, youtube) or whatsapp web.
- The crashes that simply hangs the entire computer may occur at any time.

OBSERVATIONS
- No modification were done to the driver, only standard driver from ubuntu
18.04.

SYSTEM SPECS
- Dell Inspiron 5767 is used. Kernel from Ubuntu

-- 
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: drm SPDX updates

[Thomas Hellstrom]

On 05/14/2018 04:54 PM, Dirk Hohndel wrote:

On Mon, May 14, 2018 at 07:59:56AM +0200, Thomas Gleixner wrote:

Dirk,

On Mon, 7 May 2018, Dirk Hohndel (VMware) wrote:


License clarifications and SPDX headers for a bunch of files which were
authored by VMware.

This should address the comments made on the previous series.
I added Thomas as Cc (sorry, forgot on the first version) and added a
couple of SOBs that I had received in the meantime.

Thanks for cleaning that up.

FWIW: Acked-by: Thomas Gleixner 

I haven't seen any comments in the week since I wrote this. I'm not
familiar with the process for the drm changes - so what are the usual next
steps? Do I need to submit all or part of this somewhere else? Or does
Dave simply take the series (since it has no executable code changes at
all)?

/D


There are a number of teams sending pull requests to Dave. One option 
would be to have it all go through the drm-misc tree. (CC'ing Daniel 
Vetter about that). Another option would perhaps be to send a pull 
request directly to Dave (Dave?) And finally, one option would be to 
rely on the maintainers of each submodule to take the patches that touch 
that module. If you go for this last option, I can surely take the 
patches that touch vmwgfx, and Christian the TTM patches.


/Thomas


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

[Bug 106499] [regression, bisected] Several games crash on start

[bugzilla-daemon]

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

--- Comment #2 from Gregor Münch  ---
There is another bug Report, bisecting to another commit (which might make more
sense): https://bugs.freedesktop.org/show_bug.cgi?id=106511

Was in a hurry while bisecting it, cant test until Friday. Feel free to mark
this as duplicate.

-- 
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 v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

[Paul Kocialkowski]

Hi and thanks for the review!

Le vendredi 11 mai 2018 à 16:36 +0200, Maxime Ripard a écrit :
> On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> > @@ -0,0 +1,297 @@
> > +/*
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> 
> This really should be the first line, and with a C++ style comment, as
> in:
> 
> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> /*
>  * Copyright (C) ...
> 
> See Documentation/process/license-rules.rst

Okay, will do in v5.

> > +   backlight: backlight {
> > +   compatible = "pwm-backlight";
> > +   pwms = < 0 5 PWM_POLARITY_INVERTED>;
> > +   brightness-levels = <  0   1   1   1   1   2   2   2
> > +  2   3   3   3   3   4   4   4
> > +  5   5   5   6   6   6   7   7
> > +  8   8   8   9   9   9  10  10
> > + 10  11  11  12  12  12  13  13
> > + 14  14  14  15  15  16  16  17
> > + 17  17  18  18  19  19  20  20
> > + 21  21  21  22  22  23  23  24
> > + 24  25  25  26  26  27  27  28
> > + 28  29  30  30  31  31  32  32
> > + 33  33  34  35  35  36  36  37
> > + 38  38  39  39  40  41  41  42
> > + 43  43  44  44  45  46  47  47
> > + 48  49  49  50  51  51  52  53
> > + 54  54  55  56  57  57  58  59
> > + 60  61  61  62  63  64  65  65
> > + 66  67  68  69  70  71  71  72
> > + 73  74  75  76  77  78  79  80
> > + 81  82  83  84  85  86  87  88
> > + 89  90  91  92  93  94  95  96
> > + 97  98  99 101 102 103 104 105
> > +106 108 109 110 111 112 114 115
> > +116 117 119 120 121 123 124 125
> > +127 128 129 131 132 133 135 136
> > +138 139 141 142 144 145 147 148
> > +150 151 153 154 156 157 159 161
> > +162 164 166 167 169 171 173 174
> > +176 178 180 181 183 185 187 189
> > +191 192 194 196 198 200 202 204
> > +206 208 210 212 214 216 219 221
> > +223 225 227 229 232 234 236 238
> > +241 242 244 246 248 250 253 255>;
> 
> You kind of overdid it here :)
> 
> What I meant to say before was that if you have 10 elements (and you
> really should have something in that magnitude) each step should
> increase the perceived brightness by 10%.

Mhh I think 10 elements would fall too short to really depict the curve
with appropriate precision. Given the usual size for brightness cursors
in e.g. gnome-shell, it feels like a bigger number would be more
appropriate. Let's make it to 100 with values from 0 to 255!

> In this particular case, I really think having something close to <0 4
> 8 16 32 64 128 255> would be enough.
> 
> And in general, that kind of odd looking table without any more
> context is just screaming for a comment :)

Noted, I will explain the idea, but probably without the exact formula
that's really a nasty hack written down on a piece of paper sitting in
my garbage at this point.

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

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

Re: [PATCH v3 1/4] drm/rockchip: add transfer function for cdn-dp

[Enric Balletbo Serra]

Hi Lin,

2018-05-14 11:53 GMT+02:00 Lin Huang :
> From: Chris Zhong 
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> Reviewed-by: Sean Paul 
> Reviewed-by: Enric Balletbo 

If you need to send another version, could you use the following name
and email address instead?

Reviewed-by: Enric Balletbo i Serra 

Thanks :)
 Enric

> ---
> Changes in v2:
> - update patch following Enric suggest
> - None
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++
>  drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 69 
> ++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++-
>  4 files changed, 122 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device 
> *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> -   ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
> -   if (ret)
> +   ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
> +   if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct 
> cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> -   ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> -  DP_RECEIVER_CAP_SIZE);
> -   if (ret) {
> +   ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
> +  sizeof(dp->dpcd));
> +   if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
> *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> -   if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> -DP_LINK_STATUS_SIZE)) {
> +   if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
> +   DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
>  }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> +  struct drm_dp_aux_msg *msg)
> +{
> +   struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, 
> aux);
> +   int ret;
> +   u8 status;
> +
> +   switch (msg->request & ~DP_AUX_I2C_MOT) {
> +   case DP_AUX_NATIVE_WRITE:
> +   case DP_AUX_I2C_WRITE:
> +   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +   ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> +   msg->size);
> +   break;
> +   case DP_AUX_NATIVE_READ:
> +   case DP_AUX_I2C_READ:
> +   ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> +  msg->size);
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   status = cdn_dp_get_aux_status(dp);
> +   if (status == AUX_STATUS_ACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> +   else if (status == AUX_STATUS_NACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> +   else if (status == AUX_STATUS_DEFER)
> +   msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> +   return ret;
> +}
> +
>  static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>  {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct 
> device *master, void *data)
> dp->active = false;
> dp->active_port = -1;
> dp->fw_loaded = false;
> +   dp->aux.name = "DP-AUX";
> +   dp->aux.transfer = cdn_dp_aux_transfer;
> +   dp->aux.dev = dev;
> +
> +   ret = drm_dp_aux_register(>aux);
> +   if (ret)
> +   return ret;
>
> INIT_WORK(>event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct 

Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90

[Paul Kocialkowski]

Hi,

Le vendredi 11 mai 2018 à 10:59 +0200, Maxime Ripard a écrit :
> On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > > as found on the Ainol AW1 tablet.
> > > > 
> > > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > > the two extra lanes per component are grounded.
> > > > 
> > > > In the future, it might become necessary to introduce a dedicated
> > > > device-tree property to specify the bus format to use instead of the
> > > > default one for the panel. This will allow supporting different bus
> > > > formats for the same panel modes.
> > > > 
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  drivers/gpu/drm/panel/panel-simple.c | 26 ++
> > > >  1 file changed, 26 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 
> > > > = {
> > > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | 
> > > > DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > >  };
> > > >  
> > > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > > +   .clock = 4,
> > > > +   .hdisplay = 800,
> > > > +   .hsync_start = 800 + 112,
> > > > +   .hsync_end = 800 + 112 + 1,
> > > > +   .htotal = 800 + 112 + 1 + 87,
> > > > +   .vdisplay = 480,
> > > > +   .vsync_start = 480 + 141,
> > > > +   .vsync_end = 480 + 141 + 1,
> > > > +   .vtotal = 480 + 141 + 1 + 38,
> > > > +   .vrefresh = 60,
> > > > +};
> > > > +
> > > > +static const struct panel_desc innolux_at070tn90 = {
> > > > +   .modes = _at070tn90_mode,
> > > > +   .num_modes = 1,
> > > > +   .size = {
> > > > +   .width = 154,
> > > > +   .height = 86,
> > > > +   },
> > > > +   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > > +};
> > > > +
> > > 
> > > I'm not really convinced this is the right approach. You said it
> > > yourself, the panel is using a 24-bits interface, and you just happen
> > > to have a tablet that routed it using a 18-bits interface instead.
> > > 
> > > That doesn't belong in the driver, especially associated to the
> > > compatible, but where the routing is described: in the device
> > > tree. And given that the panel interface is a 24 bits panel, if we
> > > were to have a default, we should have this one, and not the one
> > > fitting your use case.
> > 
> > I fully agree, this is why I suggested introducing a dedicated dt
> > property for selecting the bus format (in the commit message). I still
> > proposed this patch as a temporary solution, but I'm definitely willing
> > to craft a proper solution as well.
> > 
> > Here is an initial proposition:
> > 1. Making bus_format an array in struct panel_desc and listing all the
> > relevant bus formats that the panel can support there;
> 
> I'm not sure this is needed, the input format is always the same in
> your case, the panel will always take a 24 bits RGB value. What you
> want to change is the encoder output format (and I guess you want that
> to be meaningful to enable or not the dithering).

Isn't the panel format supposed to match what the encoder's output
should be aiming for? In my case, that would be RGB666, so the idea
would be specifying both MEDIA_BUS_FMT_RGB666_1X18 and
MEDIA_BUS_FMT_RGB888_1X24 in a list of supported bus formats for the
panel. This way, both my setup and RGB888 setups can be supported.

> > 2. Introducing an optional "bus-format" dt property that indicates which
> > bus format to use, and using the first index of the bus formats array if
> > the property is not present;
> 
> I guess the width would be enough, and that way we can take the
> bus-width format that is already defined (but used in the v4l2
> framework, not in DRM yet).

Well, we already have bus-format defines on the DRM side and it feels
like mapping these directly in device-tree would be more useful as a
description of the hardware than just having the bus width.

Cheers,

Paul

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

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

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

Bug ID: 106519
   Summary: Is it normal that the 4K video on the Vega 56 GPU
played with loud turbine noise, 200% load of the
desktop Core i7 CPU and at the same time playable with
jerks and dropping frames?
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

Created attachment 139566
  --> https://bugs.freedesktop.org/attachment.cgi?id=139566=edit
htop and xsensors

Is it normal that the 4K video on the Vega 56 GPU played with loud turbine
noise, 200% load of the desktop Core i7 CPU and at the same time playable with
jerks and dropping frames?

$ mpv --hwdec=vaapi Downloads/WE\ GOT\ INTEL\'S\ PROTOTYPE\ GRAPHICS\ CARD.webm 
Playing: Downloads/WE GOT INTEL'S PROTOTYPE GRAPHICS CARD.webm
 (+) Video --vid=1 (*) (vp9 3840x2160 29.970fps)
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object
file: No such file or directory
VO: [gpu] 3840x2160 yuv420p
V: 00:00:19 / 00:14:44 (2%) Dropped: 24


Exiting... (Quit)

-- 
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 106517] IGT commit rights

[bugzilla-daemon]

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

--- Comment #1 from Dhinakaran Pandiyan  ---
Created attachment 139563
  --> https://bugs.freedesktop.org/attachment.cgi?id=139563=edit
SSH public key

-- 
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 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
$ inxi -bM
System:Host: localhost.localdomain Kernel: 4.17.0-0.rc3.git4.1.fc29.x86_64
x86_64 bits: 64
   Desktop: Gnome 3.29.1 Distro: Fedora release 29 (Rawhide)
Machine:   Device: desktop System: Gigabyte product: Z87M-D3H serial: N/A
   Mobo: Gigabyte model: Z87M-D3H serial: N/A UEFI: American Megatrends
v: F11 date: 08/12/2014
Batteryhidpp__0: charge: N/A condition: NA/NA Wh
CPU:   Quad core Intel Core i7-4770 (-MT-MCP-) speed/max: 3790/3900 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Vega 10 XT [Radeon RX Vega
64]
   Display Server: wayland (X.org 11.5 ) drivers:
modesetting,fbdev,vesa
   Resolution: 3840x2160@59.98hz
   OpenGL: renderer: Radeon RX Vega (VEGA10, DRM 3.25.0,
4.17.0-0.rc3.git4.1.fc29.x86_64, LLVM 6.0.0)
   version: 4.5 Mesa 18.1.0-rc3
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller driver: r8169
Drives:HDD Total Size: 16241.0GB (19.6% used)
Info:  Processes: 429 Uptime: 1 day Memory: 16145.4/32037.0MB Client: Shell
(bash) inxi: 2.3.56

-- 
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 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 139567
  --> https://bugs.freedesktop.org/attachment.cgi?id=139567=edit
Video in Totem player

-- 
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 106517] IGT commit rights

[bugzilla-daemon]

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

Bug ID: 106517
   Summary: IGT commit rights
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: dhinakaran.pandi...@intel.com

Created attachment 139561
  --> https://bugs.freedesktop.org/attachment.cgi?id=139561=edit
GPG key

-- 
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 2/2] drm/bridge: sii902x: add optional power supplies

[Philippe CORNU]

Hi Andrzej,

On 05/14/2018 12:33 PM, Andrzej Hajda wrote:
> On 14.05.2018 11:38, Philippe CORNU wrote:
>> Hi Laurent, Archit, Andrzej & Yannick,
>>
>> Do you have any comments on this v2 driver part?
>> (more details regarding v1/v2 differences in the cover letter
>> https://www.spinics.net/lists/dri-devel/msg174137.html)
>>
>> Thank you,
>> Philippe :-)
>>
>>
>> On 04/25/2018 09:53 AM, Philippe Cornu wrote:
>>> Add the optional power supplies using the description found in
>>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>>
>>> The sii902x input IOs are not "io safe" so it is important to
>>> enable/disable voltage regulators during probe/remove phases to
>>> avoid damages.
> 
> What exactly does it mean? Ie I understand that the chip has some
> limitations, but why enabling/disabling regulators in probe/remove
> should solve it?

thank you for your comment.

And sorry for the "bad" explanation in the 2nd paragraph about the fact 
that inputs are not "io safe". I added this 2nd paragraph in v2 
following a good comment from Laurent on adding the management of the 
regulators outside the probe/remove for a better power consumption 
management (enable/disable regulators only when the ic is used for 
displaying something for instance...). But after a deeper analysis, I 
realized that the only way to improve the power consumption is to 
implement & test the sii902x various sleep modes, that is out-of-scope 
of this small patch and also out-of-scope of my test board I use on 
which the sii902x bridge ic power consumption is very low compare to the 
rest of the system...

I will remove this "explanation" in v3 as it creates confusion.

Many thanks,
Philippe :-)

> 
> Regards
> Andrzej
> 
>>>
>>> Signed-off-by: Philippe Cornu 
>>> ---
>>>drivers/gpu/drm/bridge/sii902x.c | 38 
>>> ++
>>>1 file changed, 34 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
>>> b/drivers/gpu/drm/bridge/sii902x.c
>>> index 60373d7eb220..c367d7b91ade 100644
>>> --- a/drivers/gpu/drm/bridge/sii902x.c
>>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>>> @@ -24,6 +24,7 @@
>>>#include 
>>>#include 
>>>#include 
>>> +#include 
>>>
>>>#include 
>>>#include 
>>> @@ -86,6 +87,7 @@ struct sii902x {
>>> struct drm_bridge bridge;
>>> struct drm_connector connector;
>>> struct gpio_desc *reset_gpio;
>>> +   struct regulator_bulk_data supplies[2];
>>>};
>>>
>>>static inline struct sii902x *bridge_to_sii902x(struct drm_bridge 
>>> *bridge)
>>> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
>>> return PTR_ERR(sii902x->reset_gpio);
>>> }
>>>
>>> +   sii902x->supplies[0].supply = "iovcc";
>>> +   sii902x->supplies[1].supply = "vcc12";
>>> +   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
>>> + sii902x->supplies);
>>> +   if (ret) {
>>> +   dev_err(dev, "Failed to get power supplies: %d\n", ret);
>>> +   return ret;
>>> +   }
>>> +
>>> +   ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
>>> +   sii902x->supplies);
>>> +   if (ret) {
>>> +   dev_err(dev, "Failed to enable power supplies: %d\n", ret);
>>> +   return ret;
>>> +   }
>>> +
>>> +   usleep_range(1, 2);
>>> +
>>> sii902x_reset(sii902x);
>>>
>>> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>>> if (ret)
>>> -   return ret;
>>> +   goto err_disable_regulator;
>>>
>>> ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>>>, 4);
>>> if (ret) {
>>> dev_err(dev, "regmap_read failed %d\n", ret);
>>> -   return ret;
>>> +   goto err_disable_regulator;
>>> }
>>>
>>> if (chipid[0] != 0xb0) {
>>> dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>>> chipid[0]);
>>> -   return -EINVAL;
>>> +   ret = -EINVAL;
>>> +   goto err_disable_regulator;
>>> }
>>>
>>> /* Clear all pending interrupts */
>>> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
>>> IRQF_ONESHOT, dev_name(dev),
>>> sii902x);
>>> if (ret)
>>> -   return ret;
>>> +   goto err_disable_regulator;
>>> }
>>>
>>> sii902x->bridge.funcs = _bridge_funcs;
>>> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
>>> i2c_set_clientdata(client, sii902x);
>>>
>>> return 0;
>>> +
>>> +err_disable_regulator:
>>> +   regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>>> +  sii902x->supplies);
>>> +
>>> +   return ret;
>>>}
>>>
>>>static int sii902x_remove(struct i2c_client 

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[Pavel Machek]

Hi!

> WLED4 peripheral is present on some PMICs like pmi8998
> and pm660l. It has a different register map and also
> configurations are different. Add support for it.
> 
> Signed-off-by: Kiran Gunda 
> ---
>  .../bindings/leds/backlight/qcom-wled.txt  | 172 -
>  drivers/video/backlight/qcom-wled.c| 749 
> +++--
>  2 files changed, 696 insertions(+), 225 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
> b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> index fb39e32..0ceffa1 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> @@ -1,30 +1,129 @@
>  Binding for Qualcomm Technologies, Inc. WLED driver
>  
> -Required properties:
> -- compatible: should be "qcom,pm8941-wled"
> -- reg: slave address
> -
> -Optional properties:
> -- default-brightness: brightness value on boot, value from: 0-4095
> - default: 2048
> +- compatible
> + Usage:required
> + Value type:   
> + Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
> +   or "qcom,pm660l-wled".
> +
> +- reg
> + Usage:required
> + Value type:   
> + Definition:   Base address of the WLED modules.

I'm not sure if this change of format is good idea here...

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

[Bug 106500] GPU Recovery + DC deadlock

[bugzilla-daemon]

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

--- Comment #1 from Andrey Grodzovsky  ---
Created attachment 139562
  --> https://bugs.freedesktop.org/attachment.cgi?id=139562=edit
Quick try to avoid deadlock

Can u give this a quick try and seed if it helps ?

-- 
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 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #202 from Ioannis Panagiotopoulos  ---
Can confirm that worked with kernel 4.16.7-300 on Fedora 28 Gnome with wayland
and the right boot arguments. However this worked when I had the R9 390
installed alone. When I used both the R9 390 and Rx 550 on the same system, the
display plugged on the R9 390 did not work correctly and produced broken UI
elements from time to time. Furthermore UI was very slow on response.
When tried Fedora 28 KDE, SDDM was constantly crashing when it tried to start
and stuck on a loop try-to-start->crash->try-to-start.
Kubuntu 18.04 KDE worked, but had the same issues as Fedora 28 Gnome.
So it seems the dpm bug is at last solved despite the other problems that might
be unrelated to dpm.

(In reply to heavyjoe from comment #201)
> (In reply to Sandeep from comment #200)
> > You can probably ignore the warnings, I get them too and nothing bad has
> > happened so far. As long as GPU hang doesn't occur, it's all good.
> 
> Thanks for the reply.
> In the problem reporting app it is written as
> "Unexpeted System Error" The system has encountered a problem and recovered.
> 
> The reason is as i wrote:
> WARNING: CPU: 1 PID: 369 at
> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
> generic_reg_update_ex+0x12c/0x160 [amdgpu]
> 
> so the system errors can occur as warnings? then i can live with it but i
> wasn't sure because it was labeled as system error...
> 
> thanks again. i will go on with that and hope no freezes appear.

if you installed the kernel manually, then try to install the
kernel-modules-extra package of this kernel version as well.

-- 
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 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Laurent Pinchart]

Hi Philippe,

On Monday, 14 May 2018 12:22:16 EEST Philippe CORNU wrote:
> On 04/26/2018 12:05 AM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote:
> >> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote:
> >>> On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
>  On 04/25/2018 11:01 AM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
> >> Add optional power supplies using the description found in
> >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> >>
> >> There is a single 1v2 supply voltage named vcc12 from which cvcc12
> >> (digital core) and avcc12 (TMDS analog) are derived because
> >> according to this data sheet:
> >> "cvcc12 and avcc12 can be derived from the same power source"
> >
> > Shouldn't the power supplies be mandatory, as explained by Mark in
> > https://lists.freedesktop.org/archives/dri-devel/2018-April/
> > 172400.html ?
> 
>  Laurent,
>  Many thanks Laurent for your comment, I understood the merge of the
>  two 1v2 power supplies but missed the "mandatory" part... maybe because
>  this patch (with optional power supplies) already got the reviewed-by
>  from Rob, I thought the discussion thread you pointed out was
>  applicable "only" to totally new driver documentation.
> 
>  So, on my side, as a "new user" of sii902x IC, no problem to put these
>  power supplies as mandatory instead of optional properties but I would
>  like to be sure this is applicable to both old and new bindings doc :
>  )
> >>>
> >>> We obviously need to retain backward compatibility, so on the driver
> >>> side you need to treat those power supplies as optional. From a DT
> >>> bindings point of view, however, I think they should be mandatory for
> >>> new DT.
> >>
> >> We don't really have a way to describe these 3 conditions (required for
> >> all, optional for all, and required for new). So generally we make
> >> additions optional. The exception sometimes is if we update all the dts
> >> files.
> > 
> > Can't we just make it mandatory in the bindings, as long as we treat it
> > as optional in drivers ?
> 
> How to progress on this patch? Do you have any suggestions?

By seeing what Rob thinks about my proposal above ? :-)

>  Rob,
>  could you please confirm these power supply properties should be
>  "mandatory"? if yes, should we then modify other optional properties
>  like the reset-gpios too in the future?
> >>>
> >>> The GPIOs properties are different in my opinion, as there's no
> >>> requirement to connect for instance the reset pin to a GPIO controllable
> >>> by the SoC. The pin could be hardwired to VCC, or connected to a system
> >>> reset that is automatically managed without SoC intervention. The power
> >>> supplies, however, are mandatory, in the sense that the chip will not
> >>> work if you leave the power supplies unconnected.
> >>
> >> DT only needs to describe what matters to s/w. If a regulator is
> >> fixed and you don't need to know its voltage (or other read-only
> >> parameters), then there's not much point in putting it in DT.
> >>
> >> I'd probably base this more at a platform level and you either use
> >> regulator binding or you don't. It's perfectly valid that you want to do
> >> things like regulator setup, pin ctrl and muxing setup, etc. all in
> >> firmware and the OS doesn't touch any of that.
> >>
> >> That's all a big can of worms which we shouldn't solve on this 2 line
> >> change. I think this change is fine as-is, so:
> >>
> >> Reviewed-by: Rob Herring 

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)

[Rob Herring]

On Mon, May 14, 2018 at 10:36 AM, Lukasz Majewski  wrote:
> Dear All,

It is only Thierry that you need to ping. It goes thru his tree as I
mentioned on another panel you sent.

>> This commit adds support for AUO's 7.0" display.
>
> If I may gentle remind about this patch
>
>>
>> Signed-off-by: Lukasz Majewski 

You failed to add my Reviewed-by.

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

Re: [PATCH 0/4] DRM helpers for Display Stream Compression PPS infoframes

[Manasi Navare]

On Mon, May 14, 2018 at 06:50:28PM +0200, Daniel Vetter wrote:
> On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote:
> > VESA Display Stream Compression is a specification for visually losless
> > video compression over display links. The DSC standard also defines
> > a picture parameter set (PPS) which encoder must communicate to decoders.
> > This is done by encapsulating PPS header and payload bytes in an infoframe
> > that can be sent to the display sink using secondary data packets
> > as defined in DP 1.4 spec.
> > 
> > This patch series creates a new files drm_dsc.h and drm_dsc.c
> > which define all the DSC related structures and helpers that
> > can be called by drivers to form DSC PPS infoframes before
> > enabling Display Stream compression on eDP/DP/MIPI
> 
> Just an aside: At least here the threading for this patch series seems
> off. And patchwork also didn't pick up your cover letter:
> 
> https://patchwork.freedesktop.org/series/42969/
>

Yes the cover letter didnt get sent to the dri-devel, only to the
intel-gfx M-L: https://patchwork.freedesktop.org/series/42968/
 
> > 
> > These files can be used to add more DSC spec related helpers
> > common to all drivers.
> > 
> > Gaurav K Singh (1):
> >   drm/dsc: Define VESA Display Stream Compression Capabilities
> > 
> > Manasi Navare (3):
> >   drm/dp: Define payload size for DP SDP PPS packet
> >   drm/dsc: Define Display Stream Compression PPS infoframe
> >   drm/dsc: Add helpers for DSC picture parameter set infoframes
> > 
> >  drivers/gpu/drm/Makefile|   2 +-
> >  drivers/gpu/drm/drm_dsc.c   | 222 ++
> >  include/drm/drm_dp_helper.h |   1 +
> >  include/drm/drm_dsc.h   | 539 
> > 
> 
> Please include these new files into the overall kernel-doc structure (and
> make sure stuff is sufficiently documented).

I have added the necessary headers and documentation in the files itself
but will update the kernel-doc structure as wellf or these.

Manasi

> 
> Thanks, Daniel
> 
> >  4 files changed, 763 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_dsc.c
> >  create mode 100644 include/drm/drm_dsc.h
> > 
> > -- 
> > 2.7.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ville Syrjälä]

On Tue, May 08, 2018 at 10:44:56AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
> 
> v2:
>  * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
> 
> v3:
>  * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
> 
> v4:
>  * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
> 
> v5:
>  * Moved patch revision's description to commit messages.
> 
> v6:
>  * Minor naming fix for the content type enumeration string.
> 
> v7:
>  * Fix parameter name for documentation and parameter alignment
>in order not to get warning. Added Content Type description to
>new HDMI connector properties section.
> 
> v8:
>  * Thrown away unneeded numbers from HDMI content-type property
>description. Switch to strings desription instead of plain
>definitions.
> 
> v9:
>  * Moved away hdmi specific content-type enum from
>drm_connector_state. Content type property should probably not
>be bound to any specific connector interface in
>drm_connector_state.
>Same probably should be done to hdmi_picture_aspect_ration enum
>which is also contained in drm_connector_state. Added special
>helper function to get derive hdmi specific relevant infoframe
>fields.
> 
> v10:
>  * Added usage description to HDMI properties kernel doc.
> 
> Acked-by: Hans Verkuil 
> Acked-by: Daniel Vetter 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  Documentation/gpu/drm-kms.rst|  6 +++
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c |  4 ++
>  drivers/gpu/drm/drm_connector.c  | 80 
>  drivers/gpu/drm/drm_edid.c   | 55 +++
>  include/drm/drm_connector.h  | 12 +
>  include/drm/drm_edid.h   |  6 +++
>  include/drm/drm_mode_config.h|  5 ++
>  include/uapi/drm/drm_mode.h  |  7 +++
>  9 files changed, 176 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 1dffd1ac4cd4..e233c2626bd0 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -517,6 +517,12 @@ Standard Connector Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :doc: standard connector properties
>  
> +HDMI Specific Connector Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> +   :doc: HDMI connector properties
> +
>  Plane Composition Properties
>  
>  
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 07ed22ea3bd6..bfde04eddd14 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property 
> to suggest an X offset for a connector
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest 
> an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
> ""Cinema"", ""Game"" }",Connector,TBD
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3d9ae057a6cd..6c1e1e774517 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1270,6 +1270,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->link_status = val;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio 

[RFC PATCH 4/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Neil Armstrong]

From: Stefan Adolfsson 

The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.

Signed-off-by: Stefan Adolfsson 
Signed-off-by: Neil Armstrong 
---
 drivers/platform/chrome/cros_ec_proto.c | 42 +
 include/linux/mfd/cros_ec.h |  2 +-
 include/linux/mfd/cros_ec_commands.h| 80 +
 3 files changed, 114 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..ba47f79 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,29 +504,53 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
 }
 EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
 
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+  struct cros_ec_command *msg,
+  int version, uint32_t size)
+{
+   int ret;
+
+   msg->version = version;
+   msg->command = EC_CMD_GET_NEXT_EVENT;
+   msg->insize = size;
+   msg->outsize = 0;
+
+   ret = cros_ec_cmd_xfer(ec_dev, msg);
+   if (ret > 0) {
+   ec_dev->event_size = ret - 1;
+   memcpy(_dev->event_data, msg->data, size);
+   }
+
+   return ret;
+}
+
 static int get_next_event(struct cros_ec_device *ec_dev)
 {
u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
struct cros_ec_command *msg = (struct cros_ec_command *)
+   static int cmd_version = 1;
int ret;
 
+   BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
if (ec_dev->suspended) {
dev_dbg(ec_dev->dev, "Device suspended.\n");
return -EHOSTDOWN;
}
 
-   msg->version = 0;
-   msg->command = EC_CMD_GET_NEXT_EVENT;
-   msg->insize = sizeof(ec_dev->event_data);
-   msg->outsize = 0;
+   if (cmd_version == 1) {
+   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(ec_dev->event_data));
+   if (ret != EC_RES_INVALID_VERSION)
+   return ret;
 
-   ret = cros_ec_cmd_xfer(ec_dev, msg);
-   if (ret > 0) {
-   ec_dev->event_size = ret - 1;
-   memcpy(_dev->event_data, msg->data,
-  sizeof(ec_dev->event_data));
+   /* Fallback to version 0 for future send attempts */
+   cmd_version = 0;
}
 
+   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event));
+
return ret;
 }
 
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2d4e23c..f3415eb 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
bool mkbp_event_supported;
struct blocking_notifier_head event_notifier;
 
-   struct ec_response_get_next_event event_data;
+   struct ec_response_get_next_event_v1 event_data;
int event_size;
u32 host_event_wake_mask;
 };
diff --git a/include/linux/mfd/cros_ec_commands.h 
b/include/linux/mfd/cros_ec_commands.h
index f2edd99..18df466 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
EC_FEATURE_MOTION_SENSE_FIFO = 24,
/* EC has RTC feature that can be controlled by host commands */
EC_FEATURE_RTC = 27,
+   /* EC supports CEC commands */
+   EC_FEATURE_CEC = 35,
 };
 
 #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
/* EC sent a sysrq command */
EC_MKBP_EVENT_SYSRQ = 6,
 
+   /* Notify the AP that something happened on CEC */
+   EC_MKBP_CEC_EVENT = 8,
+
+   /* Send an incoming CEC message to the AP */
+   EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
 };
@@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
uint32_t   sysrq;
 } __packed;
 
+union ec_response_get_next_data_v1 {
+   uint8_t   key_matrix[16];
+
+   /* Unaligned */
+   uint32_t  host_event;
+
+   uint32_t   buttons;
+   uint32_t   switches;
+   uint32_t   sysrq;
+   uint32_t   cec_events;
+   uint8_tcec_message[16];
+} __packed;
+
 struct ec_response_get_next_event {
uint8_t event_type;
/* Followed by event data if any */
union ec_response_get_next_data data;
 } __packed;
 
+struct ec_response_get_next_event_v1 {
+   uint8_t event_type;
+  

[RFC PATCH 1/5] mfd: cros_ec_dev: Add CEC sub-device registration

[Neil Armstrong]

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.

Signed-off-by: Neil Armstrong 
---
 drivers/mfd/cros_ec_dev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index eafd06f..57064ec 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
kfree(msg);
 }
 
+static void cros_ec_cec_register(struct cros_ec_dev *ec)
+{
+   int ret;
+   struct mfd_cell cec_cell = {
+   .name = "cros-ec-cec",
+   };
+
+   ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
+   if (ret)
+   dev_err(ec->dev, "failed to add EC CEC\n");
+}
+
 static int ec_device_probe(struct platform_device *pdev)
 {
int retval = -ENOMEM;
@@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
 
+   /* check whether this EC handles CEC. */
+   if (cros_ec_check_features(ec, EC_FEATURE_CEC))
+   cros_ec_cec_register(ec);
+
/* Take control of the lightbar from the EC. */
lb_manual_suspend_ctrl(ec, 1);
 
-- 
2.7.4

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

[RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name

[Neil Armstrong]

In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.

This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.

But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.

Signed-off-by: Neil Armstrong 
---
 drivers/media/cec/cec-notifier.c | 30 ---
 include/media/cec-notifier.h | 44 ++--
 2 files changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..716070a 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *dev;
+   const char *conn;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
 
@@ -30,13 +31,34 @@ struct cec_notifier {
 static LIST_HEAD(cec_notifiers);
 static DEFINE_MUTEX(cec_notifiers_lock);
 
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_byname(const char *name,
+const char *conn)
 {
struct cec_notifier *n;
 
mutex_lock(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (!strcmp(dev_name(n->dev), name) &&
+   (!conn || !strcmp(n->conn, conn))) {
+   kref_get(>kref);
+   mutex_unlock(_notifiers_lock);
+   return n;
+   }
+   }
+   mutex_unlock(_notifiers_lock);
+
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(cec_notifier_get_byname);
+
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char 
*conn)
+{
+   struct cec_notifier *n;
+
+   mutex_lock(_notifiers_lock);
+   list_for_each_entry(n, _notifiers, head) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_notifiers_lock);
return n;
@@ -46,6 +68,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
if (!n)
goto unlock;
n->dev = dev;
+   if (conn)
+   n->conn = devm_kstrdup(dev, conn, GFP_KERNEL);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(>lock);
kref_init(>kref);
@@ -54,7 +78,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_notifiers_lock);
return n;
 }
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
 
 static void cec_notifier_release(struct kref *kref)
 {
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..70f2974 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,6 +20,37 @@ struct cec_notifier;
 #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
 
 /**
+ * cec_notifier_get_byname - find a cec_notifier for the given device name
+ * and connector tuple.
+ * @name: device name that sends the events.
+ * @conn: the connector name from which the event occurs
+ *
+ * If a notifier for device @name exists, then increase the refcount and
+ * return that notifier.
+ *
+ * If it doesn't exist, return NULL
+ */
+struct cec_notifier *cec_notifier_get_byname(const char *name,
+const char *conn);
+
+/**
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
+ * @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+  const char *conn);
+
+/**
  * cec_notifier_get - find or create a new cec_notifier for the given device.
  * @dev: device that sends the events.
  *
@@ -31,7 +62,10 @@ struct cec_notifier;
  *
  * Return NULL if the memory could not be allocated.
  */
-struct cec_notifier *cec_notifier_get(struct device *dev);
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+   return cec_notifier_get_conn(dev, NULL);
+}
 
 /**
  * cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,12 +119,18 @@ 

[RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/i915/intel_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
+   struct cec_notifier *notifier;
 };
 
 struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..9b94d72 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
connected = true;
}
 
+   cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
+
return connected;
 }
 
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 {
enum drm_connector_status status;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
+
return status;
 }
 
@@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
+
+   intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

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

[RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

[Neil Armstrong]

The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.

This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.

The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.

When the logical address is invalid, the controller will act as a CEC sniffer
and transfer all messages on the bus.

Signed-off-by: Neil Armstrong 
---
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cros-ec/Makefile  |   1 +
 drivers/media/platform/cros-ec/cros-ec-cec.c | 331 +++
 4 files changed, 345 insertions(+)
 create mode 100644 drivers/media/platform/cros-ec/Makefile
 create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..e55a8ed2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config VIDEO_CROS_EC_CEC
+   tristate "Chrome OS EC CEC driver"
+   depends on MFD_CROS_EC || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ If you say yes here you will get support for the
+ Chrome OS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..0e0582e 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
 obj-y  += meson/
+
+obj-y  += cros-ec/
diff --git a/drivers/media/platform/cros-ec/Makefile 
b/drivers/media/platform/cros-ec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c 
b/drivers/media/platform/cros-ec/cros-ec-cec.c
new file mode 100644
index 000..fea90da
--- /dev/null
+++ b/drivers/media/platform/cros-ec/cros-ec-cec.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rc_msg: storage for a received message
+ */
+struct cros_ec_cec {
+   struct cros_ec_device *cros_ec;
+   struct notifier_block notifier;
+   struct cec_adapter *adap;
+   struct cec_notifier *notify;
+   struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+   uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+   unsigned int len = cros_ec->event_size;
+
+   cros_ec_cec->rx_msg.len = len;
+   memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+   cec_received_msg(cros_ec_cec->adap, _ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+   uint32_t events = cros_ec->event_data.data.cec_events;
+
+   if (events & EC_MKBP_CEC_SEND_OK)
+   cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+   if (events & EC_MKBP_CEC_SEND_FAILED)
+   cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_ERROR);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+   unsigned long queued_during_suspend, void *_notify)
+{
+   struct cros_ec_cec *cros_ec_cec;
+   struct cros_ec_device *cros_ec;
+
+   cros_ec_cec = container_of(nb, struct cros_ec_cec, notifier);
+   cros_ec = cros_ec_cec->cros_ec;
+
+   if (cros_ec->event_data.event_type == EC_MKBP_CEC_EVENT) {
+   handle_cec_event(cros_ec_cec);
+   return NOTIFY_OK;
+   }
+
+   if (cros_ec->event_data.event_type ==