Re: [PATCH v5 06/12] drm/i915: SRM revocation check for HDCP1.4 and 2.2

[Daniel Vetter]

On Thu, Apr 18, 2019 at 02:27:59PM +0530, Ramalingam C wrote:
> DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
> and 2.2 revocation check during the respective authentication flow.
> 
> v2:
>   Rebased.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 57 ---
>  1 file changed, 44 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 772974697b5a..de634f3fbd1b 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -492,9 +492,11 @@ int intel_hdcp_validate_v_prime(struct 
> intel_digital_port *intel_dig_port,
>  
>  /* Implements Part 2 of the HDCP authorization procedure */
>  static
> -int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> -const struct intel_hdcp_shim *shim)
> +int intel_hdcp_auth_downstream(struct intel_connector *connector)
>  {
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> + struct drm_device *dev = connector->base.dev;
>   u8 bstatus[2], num_downstream, *ksv_fifo;
>   int ret, i, tries = 3;
>  
> @@ -533,6 +535,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   if (ret)
>   goto err;
>  
> + if (drm_hdcp_ksvs_revocated(dev, ksv_fifo, num_downstream)) {
> + DRM_ERROR("Revocated Ksv(s) in ksv_fifo\n");
> + return -EPERM;
> + }
> +
>   /*
>* When V prime mismatches, DP Spec mandates re-read of
>* V prime atleast twice.
> @@ -559,9 +566,12 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>  }
>  
>  /* Implements Part 1 of the HDCP authorization procedure */
> -static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
> -const struct intel_hdcp_shim *shim)
> +static int intel_hdcp_auth(struct intel_connector *connector)
>  {
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + struct drm_device *dev = connector->base.dev;
> + const struct intel_hdcp_shim *shim = hdcp->shim;
>   struct drm_i915_private *dev_priv;
>   enum port port;
>   unsigned long r0_prime_gen_start;
> @@ -627,6 +637,11 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>   if (ret < 0)
>   return ret;
>  
> + if (drm_hdcp_ksvs_revocated(dev, bksv.shim, 1)) {
> + DRM_ERROR("BKSV is revocated\n");
> + return -EPERM;
> + }
> +
>   I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
>   I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
>  
> @@ -700,7 +715,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
> *intel_dig_port,
>*/
>  
>   if (repeater_present)
> - return intel_hdcp_auth_downstream(intel_dig_port, shim);
> + return intel_hdcp_auth_downstream(connector);
>  
>   DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
>   return 0;
> @@ -763,7 +778,7 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
>  
>   /* Incase of authentication failures, HDCP spec expects reauth. */
>   for (i = 0; i < tries; i++) {
> - ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
> + ret = intel_hdcp_auth(connector);
>   if (!ret) {
>   hdcp->hdcp_encrypted = true;
>   return 0;
> @@ -779,12 +794,6 @@ static int _intel_hdcp_enable(struct intel_connector 
> *connector)
>   return ret;
>  }
>  
> -static inline
> -struct intel_connector *intel_hdcp_to_connector(struct intel_hdcp *hdcp)
> -{
> - return container_of(hdcp, struct intel_connector, hdcp);
> -}
> -
>  /* Implements Part 3 of the HDCP authorization procedure */
>  static int intel_hdcp_check_link(struct intel_connector *connector)
>  {
> @@ -845,6 +854,12 @@ static int intel_hdcp_check_link(struct intel_connector 
> *connector)
>   return ret;
>  }
>  
> +static inline
> +struct intel_connector *intel_hdcp_to_connector(struct intel_hdcp *hdcp)
> +{
> + return container_of(hdcp, struct intel_connector, hdcp);
> +}

Moving intel_hdcp_to_connector around doesn't seem to be necessary?

> +
>  static void intel_hdcp_prop_work(struct work_struct *work)
>  {
>   struct intel_hdcp *hdcp = container_of(work, struct intel_hdcp,
> @@ -1162,6 +1177,7 @@ static int hdcp2_authentication_key_exchange(struct 
> intel_connector *connector)
>  {
>   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>   struct intel_hdcp *hdcp = &connector->hdcp;
> + struct drm_device *dev = connector->base.dev;
>   union {
>   struct hdcp2_ake_init ake_init;
>

Re: [PATCH v4 6/9] dt-bindings: display: hdmi-connector: Add DDC power supply

[Ondřej Jirman]

On Fri, Apr 26, 2019 at 03:02:50PM -0500, Rob Herring wrote:
> On Fri, Apr 26, 2019 at 2:20 PM Ondřej Jirman  wrote:
> >
> > On Fri, Apr 26, 2019 at 01:23:37PM -0500, Rob Herring wrote:
> > > On Sat, Apr 13, 2019 at 06:54:15PM +0200, meg...@megous.com wrote:
> > > > From: Ondrej Jirman 
> > > >
> > > > Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
> > > > on-board voltage shifting logic for the DDC bus to be usable. Use
> > > > ddc-supply on the hdmi-connector to model this.
> > > >
> > > > Add binding documentation for optional ddc-supply property.
> > > >
> > > > Signed-off-by: Ondrej Jirman 
> > > > ---
> > > >  .../devicetree/bindings/display/connector/hdmi-connector.txt | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> > > >  
> > > > b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> > > > index 508aee461e0d..33085aeb0bb9 100644
> > > > --- 
> > > > a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> > > > +++ 
> > > > b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> > > > @@ -9,6 +9,7 @@ Optional properties:
> > > >  - label: a symbolic name for the connector
> > > >  - hpd-gpios: HPD GPIO number
> > > >  - ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID 
> > > > probing
> > > > +- ddc-supply: the power supply for the DDC bus
> > >
> > > It's not just for DDC. It powers the chips in bridge dongles for
> > > example. Pretty much every diagram I find just calls it 5V or +5V.
> > >
> > > So how about '5V-supply' or 'v5V-supply'?
> >
> > Just to be sure, the schematic that inspired this change looks like this:
> >
> > https://megous.com/dl/tmp/33b2971de6943e9d.png
> >
> > HDMI-5V is always on, and what is really being enabled here are mosfets
> > connected to DDC_CEC_EN and not the HDMI-5V power supply. So in this case it
> > really is just for DDC. It is conceivable that some boards may need both to
> > enable 5V for HDMI circuitry and some separate power shifting logic for
> > DDC bus.
> 
> Okay, not what I thought you were defining. DDC_CEC_EN is a GPIO line?
> I wouldn't characterize this as a voltage rail, so I don't think it
> should be a supply. Perhaps 'ddc-en-gpios'?

Yes it's GPIO. I'll implement it as GPIO.

> We certainly want to make it clear this is not the 5V supply.

Right. Thank you for review.

regards,
Ondrej

> Rob
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/2] drm/panel: simple: Add KOE tx14d24vm1bpa display support (320x240)

[Lukasz Majewski]

Dear All,

> This commit adds support for KOE's 5.7" display.
> 
> Signed-off-by: Lukasz Majewski 
> Reviewed-by: Rob Herring 
> 
> ---
> Previous discussion (and Rob's Reviewed-by) about this patch
> https://patchwork.kernel.org/patch/10339595/
> 
> It must have been lost during the development process, so
> I do resend it now.
> 
> Changes for v3 :
> - Rebase this patch on top of newest kernel (5.1-rc3):
>   SHA1: 145f47c7381d43c789cbad55d4dbfd28fc6c46a4
> - Split this patch to have separate Documentation entry

Gentle ping on this patch...

> ---
>  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
> 9e8218f6a3f2..196c6adf8168 100644 ---
> a/drivers/gpu/drm/panel/panel-simple.c +++
> b/drivers/gpu/drm/panel/panel-simple.c @@ -1549,6 +1549,29 @@ static
> const struct panel_desc innolux_zj070na_01p = { },
>  };
>  
> +static const struct display_timing koe_tx14d24vm1bpa_timing = {
> + .pixelclock = { 558, 585, 620 },
> + .hactive = { 320, 320, 320 },
> + .hfront_porch = { 30, 30, 30 },
> + .hback_porch = { 30, 30, 30 },
> + .hsync_len = { 1, 5, 17 },
> + .vactive = { 240, 240, 240 },
> + .vfront_porch = { 6, 6, 6 },
> + .vback_porch = { 5, 5, 5 },
> + .vsync_len = { 1, 2, 11 },
> + .flags = DISPLAY_FLAGS_DE_HIGH,
> +};
> +
> +static const struct panel_desc koe_tx14d24vm1bpa = {
> + .timings = &koe_tx14d24vm1bpa_timing,
> + .num_timings = 1,
> + .bpc = 6,
> + .size = {
> + .width = 115,
> + .height = 86,
> + },
> +};
> +
>  static const struct display_timing koe_tx31d200vm0baa_timing = {
>   .pixelclock = { 3960, 4320, 4800 },
>   .hactive = { 1280, 1280, 1280 },
> @@ -2680,6 +2703,9 @@ static const struct of_device_id
> platform_of_match[] = { .compatible = "innolux,zj070na-01p",
>   .data = &innolux_zj070na_01p,
>   }, {
> + .compatible = "koe,tx14d24vm1bpa",
> + .data = &koe_tx14d24vm1bpa,
> + }, {
>   .compatible = "koe,tx31d200vm0baa",
>   .data = &koe_tx31d200vm0baa,
>   }, {




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

[PATCH -next] drm/komeda: remove set but not used variable 'kcrtc'

[Yue Haibing]

From: YueHaibing 

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/arm/display/komeda/komeda_plane.c: In function 
komeda_plane_atomic_check:
drivers/gpu/drm/arm/display/komeda/komeda_plane.c:49:22: warning: variable 
kcrtc set but not used [-Wunused-but-set-variable]

It is never used since introduction in
commit 7d31b9e7a550 ("drm/komeda: Add komeda_plane/plane_helper_funcs")

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 07ed0cc..0753892 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -55,7 +55,6 @@ komeda_plane_atomic_check(struct drm_plane *plane,
struct komeda_plane_state *kplane_st = to_kplane_st(state);
struct komeda_layer *layer = kplane->layer;
struct drm_crtc_state *crtc_st;
-   struct komeda_crtc *kcrtc;
struct komeda_crtc_state *kcrtc_st;
struct komeda_data_flow_cfg dflow;
int err;
@@ -73,7 +72,6 @@ komeda_plane_atomic_check(struct drm_plane *plane,
if (!crtc_st->active)
return 0;
 
-   kcrtc = to_kcrtc(state->crtc);
kcrtc_st = to_kcrtc_st(crtc_st);
 
err = komeda_plane_init_data_flow(state, &dflow);
-- 
2.7.4


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

Re: [PATCH v4 6/9] dt-bindings: display: hdmi-connector: Add DDC power supply

[Ondřej Jirman]

On Fri, Apr 26, 2019 at 01:23:37PM -0500, Rob Herring wrote:
> On Sat, Apr 13, 2019 at 06:54:15PM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman 
> > 
> > Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
> > on-board voltage shifting logic for the DDC bus to be usable. Use
> > ddc-supply on the hdmi-connector to model this.
> > 
> > Add binding documentation for optional ddc-supply property.
> > 
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  .../devicetree/bindings/display/connector/hdmi-connector.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt 
> > b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> > index 508aee461e0d..33085aeb0bb9 100644
> > --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> > +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
> > @@ -9,6 +9,7 @@ Optional properties:
> >  - label: a symbolic name for the connector
> >  - hpd-gpios: HPD GPIO number
> >  - ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
> > +- ddc-supply: the power supply for the DDC bus
> 
> It's not just for DDC. It powers the chips in bridge dongles for 
> example. Pretty much every diagram I find just calls it 5V or +5V.
> 
> So how about '5V-supply' or 'v5V-supply'?

Just to be sure, the schematic that inspired this change looks like this:

https://megous.com/dl/tmp/33b2971de6943e9d.png

HDMI-5V is always on, and what is really being enabled here are mosfets
connected to DDC_CEC_EN and not the HDMI-5V power supply. So in this case it
really is just for DDC. It is conceivable that some boards may need both to
enable 5V for HDMI circuitry and some separate power shifting logic for
DDC bus.

So if I renamed this, the DTS would not describe the real HW very well
on Orange Pi 3.

thank you and regards,
Ondrej

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

[PATCH 01/12] dma-buf: add dynamic caching of sg_table

[Liam Mark]

On Tue, 16 Apr 2019, Christian K??nig wrote:

> To allow a smooth transition from pinning buffer objects to dynamic
> invalidation we first start to cache the sg_table for an attachment
> unless the driver explicitly says to not do so.
> 
> ---
>  drivers/dma-buf/dma-buf.c | 24 
>  include/linux/dma-buf.h   | 11 +++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 7c858020d14b..65161a82d4d5 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -573,6 +573,20 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
>   list_add(&attach->node, &dmabuf->attachments);
>  
>   mutex_unlock(&dmabuf->lock);
> +
> + if (!dmabuf->ops->dynamic_sgt_mapping) {
> + struct sg_table *sgt;
> +
> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> + if (!sgt)
> + sgt = ERR_PTR(-ENOMEM);
> + if (IS_ERR(sgt)) {
> + dma_buf_detach(dmabuf, attach);
> + return ERR_CAST(sgt);
> + }
> + attach->sgt = sgt;
> + }
> +
>   return attach;
>  
>  err_attach:
> @@ -595,6 +609,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
> dma_buf_attachment *attach)
>   if (WARN_ON(!dmabuf || !attach))
>   return;
>  
> + if (attach->sgt)
> + dmabuf->ops->unmap_dma_buf(attach, attach->sgt,
> +DMA_BIDIRECTIONAL);
> +
>   mutex_lock(&dmabuf->lock);
>   list_del(&attach->node);
>   if (dmabuf->ops->detach)
> @@ -630,6 +648,9 @@ struct sg_table *dma_buf_map_attachment(struct 
> dma_buf_attachment *attach,
>   if (WARN_ON(!attach || !attach->dmabuf))
>   return ERR_PTR(-EINVAL);
>  
> + if (attach->sgt)
> + return attach->sgt;
> +

I am concerned by this change to make caching the sg_table the default 
behavior as this will result in the exporter's map_dma_buf/unmap_dma_buf 
calls are no longer being called in 
dma_buf_map_attachment/dma_buf_unmap_attachment.

This seems concerning to me as it appears to ignore the cache maintenance 
aspect of the map_dma_buf/unmap_dma_buf calls.
For example won't this potentially cause issues for clients of ION.

If we had the following
- #1 dma_buf_attach coherent_device
- #2 dma_buf attach non_coherent_device
- #3 dma_buf_map_attachment non_coherent_device
- #4 non_coherent_device writes to buffer
- #5 dma_buf_unmap_attachment non_coherent_device
- #6 dma_buf_map_attachment coherent_device
- #7 coherent_device reads buffer
- #8 dma_buf_unmap_attachment coherent_device   

There wouldn't be any CMO at step #5 anymore (specifically no invalidate) 
so now at step #7 the coherent_device could read a stale cache line.

Also, now by default dma_buf_unmap_attachment no longer removes the 
mappings from the iommu, so now by default dma_buf_unmap_attachment is not 
doing what I would expect and clients are losing the potential sandboxing 
benefits of removing the mappings.
Shouldn't this caching behavior be something that clients opt into instead 
of being the default?

Liam

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v5 07/12] drm/hdcp: gathering hdcp related code into drm_hdcp.c

[Daniel Vetter]

On Thu, Apr 18, 2019 at 02:28:00PM +0530, Ramalingam C wrote:
> Considering the significant size of hdcp related code in drm, all
> hdcp related codes are moved into separate file called drm_hdcp.c.
> 
> v2:
>   Rebased.
> 
> Signed-off-by: Ramalingam C 
> Suggested-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_connector.c | 78 ---
>  drivers/gpu/drm/drm_hdcp.c  | 81 +

Need to make sure this is still included into
Documenation/gpu/drm-kms-helpers.rst. But an earlier patch should take
care of that, so

Reviewed-by: Daniel Vetter 

>  include/drm/drm_connector.h |  2 -
>  include/drm/drm_hdcp.h  |  3 ++
>  4 files changed, 84 insertions(+), 80 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 03907d13ef66..436cf8e764cc 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -823,13 +823,6 @@ static const struct drm_prop_enum_list 
> drm_tv_subconnector_enum_list[] = {
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> -static struct drm_prop_enum_list drm_cp_enum_list[] = {
> - { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
> - { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> - { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> -};
> -DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> -
>  static const struct drm_prop_enum_list hdmi_colorspaces[] = {
>   /* For Default case, driver will set the colorspace */
>   { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> @@ -857,13 +850,6 @@ static const struct drm_prop_enum_list 
> hdmi_colorspaces[] = {
>   { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
>  };
>  
> -static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
> - { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
> - { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
> -};
> -DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
> -  drm_hdcp_content_type_enum_list)
> -
>  /**
>   * DOC: standard connector properties
>   *
> @@ -1539,70 +1525,6 @@ int drm_connector_attach_scaling_mode_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
>  
> -/**
> - * drm_connector_attach_content_protection_property - attach content 
> protection
> - * property
> - *
> - * @connector: connector to attach CP property on.
> - * @hdcp_content_type: is HDCP Content Type property needed for connector
> - *
> - * This is used to add support for content protection on select connectors.
> - * Content Protection is intentionally vague to allow for different 
> underlying
> - * technologies, however it is most implemented by HDCP.
> - *
> - * When hdcp_content_type is true enum property called HDCP Content Type is
> - * created (if it is not already) and attached to the connector.
> - *
> - * This property is used for sending the protected content's stream type
> - * from userspace to kernel on selected connectors. Protected content 
> provider
> - * will decide their type of their content and declare the same to kernel.
> - *
> - * Content type will be used during the HDCP 2.2 authentication.
> - * Content type will be set to &drm_connector_state.hdcp_content_type.
> - *
> - * The content protection will be set to 
> &drm_connector_state.content_protection
> - *
> - * Returns:
> - * Zero on success, negative errno on failure.
> - */
> -int drm_connector_attach_content_protection_property(
> - struct drm_connector *connector, bool hdcp_content_type)
> -{
> - struct drm_device *dev = connector->dev;
> - struct drm_property *prop =
> - dev->mode_config.content_protection_property;
> -
> - if (!prop)
> - prop = drm_property_create_enum(dev, 0, "Content Protection",
> - drm_cp_enum_list,
> - ARRAY_SIZE(drm_cp_enum_list));
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(&connector->base, prop,
> -DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
> - dev->mode_config.content_protection_property = prop;
> -
> - if (!hdcp_content_type)
> - return 0;
> -
> - prop = dev->mode_config.hdcp_content_type_property;
> - if (!prop)
> - prop = drm_property_create_enum(dev, 0, "HDCP Content Type",
> - drm_hdcp_content_type_enum_list,
> - ARRAY_SIZE(
> - drm_hdcp_content_type_enum_list));
> - if (!prop)
> - return -ENOMEM;
> -
> - drm_object_attach_property(&connector->base, prop,
> -DRM_MODE_HDCP_CONTENT_TYPE0);
> - dev->mode_config.hdcp_content_type_property = prop;
> 

Re: [PATCH v5 05/12] drm: revocation check at drm subsystem

[Daniel Vetter]

On Thu, Apr 18, 2019 at 02:27:58PM +0530, Ramalingam C wrote:
> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
> 
> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
> implements the HDCP authentication)
> 
> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> 
> v2:
>   moved the uAPI to request_firmware_direct() [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Suggested-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/Makefile   |   2 +-
>  drivers/gpu/drm/drm_hdcp.c | 336 +

Please add an include stanza for this new file to
Documentation/gpu/drm-kms-helpers.rst, somewhere near the other dp/hdcp
related sink helpers.

>  drivers/gpu/drm/drm_internal.h |   4 +
>  drivers/gpu/drm/drm_sysfs.c|   2 +
>  include/drm/drm_hdcp.h |  36 
>  5 files changed, 379 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 3d0c75cd687c..fe8400af2426 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -19,7 +19,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>   drm_plane.o drm_color_mgmt.o drm_print.o \
>   drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
>   drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> - drm_atomic_uapi.o
> + drm_atomic_uapi.o drm_hdcp.o
>  
>  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
>  drm-$(CONFIG_DRM_VM) += drm_vm.o
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> new file mode 100644
> index ..78b043c8195e
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -0,0 +1,336 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Intel Corporation.
> + *
> + * Authors:
> + * Ramalingam C 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct hdcp_srm {
> + u8 *srm_buf;
> + size_t received_srm_sz;
> + u32 revocated_ksv_cnt;
> + u8 *revocated_ksv_list;
> +
> + /* Mutex to protect above struct member */
> + struct mutex mutex;
> +} *srm_data;
> +
> +static inline void drm_hdcp_print_ksv(const char *ksv)
> +{
> + DRM_DEBUG("\t%#04x, %#04x, %#04x, %#04x, %#04x\n", *ksv & 0xff,

Why 04? 8 bit only needs 02 I think.

> +   *(ksv + 1) & 0xff, *(ksv + 2) & 0xff, *(ksv + 3) & 0xff,
> +   *(ksv + 4) & 0xff);

The 0xff is redundant, char is always only 8 bits. You could also simplify
the array derefe using ksv[0], ksv[1], ... it's the same expression.

Another one: There's a bit a confusion between const char * and u8* for
parsing the buffer. I think it'd be good to standardize on const u8* for
everything. I think that should also remove the need for 0xff completely,
because no more sign extensions to the full int.

> +}
> +
> +static u32 drm_hdcp_get_revocated_ksv_count(const char *buf, u32 vrls_length)
> +{
> + u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> +
> + do {
> + vrl_ksv_cnt = *buf;
> + ksv_count += vrl_ksv_cnt;
> +
> + vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> + buf += vrl_sz;
> + parsed_bytes += vrl_sz;
> + } while (parsed_bytes < vrls_length);

Hm, if we overflow here (i.e. parsed_bytes > vrls_lenght) then we return
garbage, since we already incremented ksv_count. Plus there's no error
checking of this. Kernel shouldn't trust root this much, and if the
vrls_length and our ksv parsing don't agree, we should abort the srm load.
So maybe switch the return value to int, and on error return -EINVAL and
abort?

> +
> + return ksv_count;
> +}
> +
> +static u32 drm_hdcp_get_revocated_ksvs(const char *buf, u8 
> *revocated_ksv_list,
> +u32 vrls_length)

This function here doesn't need to be paranoid, since we already checked
the SRM by this point.

> +{
> + u32 parsed_bytes = 0, ksv_count = 0;
> + u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
> +
> + do {
> + vrl_ksv_cnt = *buf;
> + vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
> +
> + buf++;
> +
> + DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
> +   vrl_ksv_cnt);
> + memcpy(revocated_ksv_list, buf, vrl_ksv_sz);
> +
> + ksv_count += vrl_ksv_cnt;
> + revocated_ksv_list += vrl_ksv_sz;
> + buf += vrl_ksv_sz;
> +
> + parsed_bytes += (vrl_ksv_sz + 1);
> + } while (parsed_bytes < vrls_length);
> +
> + return ksv_count;
> +}
> +
> +static int drm_hdcp_parse_hdcp1_srm(const char *buf, size_t count)
> +{
> + struct hdcp_srm_header *header;
> + u32 vrl_length, ksv_co

Re: [PATCHv2 02/22] drm/bridge: tc358767: reset voltage-swing & pre-emphasis

[Andrey Smirnov]

On Fri, Apr 26, 2019 at 7:14 AM Tomi Valkeinen  wrote:
>
> On 20/04/2019 23:30, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Tue, Mar 26, 2019 at 12:31:26PM +0200, Tomi Valkeinen wrote:
> >> We need to reset DPCD voltage-swing & pre-emphasis before starting the
> >> link training, as otherwise tc358767 will use the previous values as
> >> minimums.
> >>
> >> Signed-off-by: Tomi Valkeinen 
> >> ---
> >>  drivers/gpu/drm/bridge/tc358767.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> >> b/drivers/gpu/drm/bridge/tc358767.c
> >> index 7031c4f52c57..11a50f7bb4be 100644
> >> --- a/drivers/gpu/drm/bridge/tc358767.c
> >> +++ b/drivers/gpu/drm/bridge/tc358767.c
> >> @@ -956,6 +956,12 @@ static int tc_main_link_setup(struct tc_data *tc)
> >>  if (ret < 0)
> >>  goto err_dpcd_write;
> >>
> >> +// Reset voltage-swing & pre-emphasis
> >
> > The driver uses C-style comments, I think it would be best to stick to
> > them to avoid a style mismatch.
>
> Oops. Yep. I often use c++ comments when hacking/developing as they're
> often easier to use. Sometimes I miss converting them to c comments...
>
> >
> >> +tmp[0] = tmp[1] = DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | 
> >> DP_TRAIN_PRE_EMPH_LEVEL_0;
> >
> > You may want to wrap the line.
>
> Well, I personally don't think wrapping at 80 is a good idea.

Trying to read two files side by side on a 13" laptop screen might
change your mind :-) +1 on wrapping the code around 80 character from
me.

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

Re: [PATCH v3 1/2] dt-bindings: display/panel: Add KOE tx14d24vm1bpa display description

[Lukasz Majewski]

Dear All,

> This commit adds documentation entry description for KOE's 5.7"
> display.
> 
> Signed-off-by: Lukasz Majewski 
> 
> ---
> Previous discussion (and Rob's Reviewed-by) about this patch
> https://patchwork.kernel.org/patch/10339595/
> 
> Changes for v3 :
> - New patch

Gentle ping on this patch...

> ---
>  .../bindings/display/panel/koe,tx14d24vm1bpa.txt   | 42
> ++ 1 file changed, 42 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> 
> diff --git
> a/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> new file mode 100644 index ..be7ac666807b --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> @@ -0,0 +1,42 @@ +Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x
> 240) TFT LCD panel +
> +Required properties:
> +- compatible: should be "koe,tx14d24vm1bpa"
> +- backlight: phandle of the backlight device attached to the panel
> +- power-supply: single regulator to provide the supply voltage
> +
> +Required nodes:
> +- port: Parallel port mapping to connect this display
> +
> +This panel needs single power supply voltage. Its backlight is
> conntrolled +via PWM signal.
> +
> +Example:
> +
> +
> +Example device-tree definition when connected to iMX53 based board
> +
> + lcd_panel: lcd-panel {
> + compatible = "koe,tx14d24vm1bpa";
> + backlight = <&backlight_lcd>;
> + power-supply = <®_3v3>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> +
> +Then one needs to extend the dispX node:
> +
> + lcd_display: disp1 {
> +
> + port@1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <&lcd_panel_in>;
> + };
> + };
> + };




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


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

Re: [PATCH v13 10/20] kernel, arm64: untag user pointers in prctl_set_mm*

[Catalin Marinas]

On Mon, Apr 01, 2019 at 06:44:34PM +0200, Andrey Konovalov wrote:
> On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas  
> wrote:
> > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long 
> > > addr,
> > >   if (opt == PR_SET_MM_AUXV)
> > >   return prctl_set_auxv(mm, addr, arg4);
> > >
> > > - if (addr >= TASK_SIZE || addr < mmap_min_addr)
> > > + if (untagged_addr(addr) >= TASK_SIZE ||
> > > + untagged_addr(addr) < mmap_min_addr)
> > >   return -EINVAL;
> > >
> > >   error = -EINVAL;
> > >
> > >   down_write(&mm->mmap_sem);
> > > - vma = find_vma(mm, addr);
> > > + vma = find_vma(mm, untagged_addr(addr));
> > >
> > >   prctl_map.start_code= mm->start_code;
> > >   prctl_map.end_code  = mm->end_code;
> >
> > Does this mean that we are left with tagged addresses for the
> > mm->start_code etc. values? I really don't think we should allow this,
> > I'm not sure what the implications are in other parts of the kernel.
> >
> > Arguably, these are not even pointer values but some address ranges. I
> > know we decided to relax this notion for mmap/mprotect/madvise() since
> > the user function prototypes take pointer as arguments but it feels like
> > we are overdoing it here (struct prctl_mm_map doesn't even have
> > pointers).
> >
> > What is the use-case for allowing tagged addresses here? Can user space
> > handle untagging?
> 
> I don't know any use cases for this. I did it because it seems to be
> covered by the relaxed ABI. I'm not entirely sure what to do here,
> should I just drop this patch?

If we allow tagged addresses to be passed here, we'd have to untag them
before they end up in the mm->start_code etc. members.

I know we are trying to relax the ABI here w.r.t. address ranges but
mostly because we couldn't figure out a way to document unambiguously
the difference between a user pointer that may be dereferenced by the
kernel (tags allowed) and an address typically used for managing the
address space layout. Suggestions welcomed.

I'd say just drop this patch and capture it in the ABI document.

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

Linux Kernel community

[Adam Alami]

Dear Linux Kernel community,

I’m doing a PhD in the subject of Open Source Software. I’m currently running a 
study on patch assessment in open source communities. It is a short survey to 
complete.

What value is there in participating?

I will be sharing the results with the community in the form of a report 
(slides containing results and analysis). For example, the report will answer 
these questions:
- What does the Linux Kernel as a community value in patches assessment (e.g. 
trust, relationships, technical expertise, etc.)?
- What is the patches assessment strategy Linux Kernel has in place?
- Does the process in place value the contributor, technical expertise or 
social norms? Etc.

Please, participate: https://icse2020.limequery.com/913965?lang=en


Kind regards

Adam Alami
PhD Fellow

IT UNIVERSITY OF COPENHAGEN
Rued Langgaards Vej 7
DK-2300 Copenhagen S
4D04

E-mail: a...@itu.dk
PHONE (+45) 72 18 50 71
www.itu.dk

[cid:image001.jpg@01D31BF2.3AE0C140]

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

Re: [PATCH v5 05/12] drm: revocation check at drm subsystem

[Daniel Vetter]

On Mon, Apr 29, 2019 at 09:26:07AM +0200, Daniel Vetter wrote:
> On Thu, Apr 18, 2019 at 02:27:58PM +0530, Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file
> > /lib/firmware/display_hdcp_srm.bin
> > 
> > SRM table is parsed and stored at drm_hdcp.c, with functions exported
> > for the services for revocation check from drivers (which
> > implements the HDCP authentication)
> > 
> > This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> > 
> > v2:
> >   moved the uAPI to request_firmware_direct() [Daniel]
> > 
> > Signed-off-by: Ramalingam C 
> > Suggested-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/Makefile   |   2 +-
> >  drivers/gpu/drm/drm_hdcp.c | 336 +
> 
> Please add an include stanza for this new file to
> Documentation/gpu/drm-kms-helpers.rst, somewhere near the other dp/hdcp
> related sink helpers.
> 
> >  drivers/gpu/drm/drm_internal.h |   4 +
> >  drivers/gpu/drm/drm_sysfs.c|   2 +
> >  include/drm/drm_hdcp.h |  36 
> >  5 files changed, 379 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> > 
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 3d0c75cd687c..fe8400af2426 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -19,7 +19,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
> > drm_plane.o drm_color_mgmt.o drm_print.o \
> > drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
> > drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
> > -   drm_atomic_uapi.o
> > +   drm_atomic_uapi.o drm_hdcp.o
> >  
> >  drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> >  drm-$(CONFIG_DRM_VM) += drm_vm.o
> > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> > new file mode 100644
> > index ..78b043c8195e
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -0,0 +1,336 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Intel Corporation.
> > + *
> > + * Authors:
> > + * Ramalingam C 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct hdcp_srm {
> > +   u8 *srm_buf;
> > +   size_t received_srm_sz;
> > +   u32 revocated_ksv_cnt;
> > +   u8 *revocated_ksv_list;

So not sure this is from the standard or not, but my dictionary says the
verb is revoke, not revocate. Please change everywhere from revocated to
revoked.

So drm_hdcp_check_ksvs_revoked() for the one exported function.
-Daniel


> > +
> > +   /* Mutex to protect above struct member */
> > +   struct mutex mutex;
> > +} *srm_data;
> > +
> > +static inline void drm_hdcp_print_ksv(const char *ksv)
> > +{
> > +   DRM_DEBUG("\t%#04x, %#04x, %#04x, %#04x, %#04x\n", *ksv & 0xff,
> 
> Why 04? 8 bit only needs 02 I think.
> 
> > + *(ksv + 1) & 0xff, *(ksv + 2) & 0xff, *(ksv + 3) & 0xff,
> > + *(ksv + 4) & 0xff);
> 
> The 0xff is redundant, char is always only 8 bits. You could also simplify
> the array derefe using ksv[0], ksv[1], ... it's the same expression.
> 
> Another one: There's a bit a confusion between const char * and u8* for
> parsing the buffer. I think it'd be good to standardize on const u8* for
> everything. I think that should also remove the need for 0xff completely,
> because no more sign extensions to the full int.
> 
> > +}
> > +
> > +static u32 drm_hdcp_get_revocated_ksv_count(const char *buf, u32 
> > vrls_length)
> > +{
> > +   u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
> > +
> > +   do {
> > +   vrl_ksv_cnt = *buf;
> > +   ksv_count += vrl_ksv_cnt;
> > +
> > +   vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
> > +   buf += vrl_sz;
> > +   parsed_bytes += vrl_sz;
> > +   } while (parsed_bytes < vrls_length);
> 
> Hm, if we overflow here (i.e. parsed_bytes > vrls_lenght) then we return
> garbage, since we already incremented ksv_count. Plus there's no error
> checking of this. Kernel shouldn't trust root this much, and if the
> vrls_length and our ksv parsing don't agree, we should abort the srm load.
> So maybe switch the return value to int, and on error return -EINVAL and
> abort?
> 
> > +
> > +   return ksv_count;
> > +}
> > +
> > +static u32 drm_hdcp_get_revocated_ksvs(const char *buf, u8 
> > *revocated_ksv_list,
> > +  u32 vrls_length)
> 
> This function here doesn't need to be paranoid, since we already checked
> the SRM by this point.
> 
> > +{
> > +   u32 parsed_bytes = 0, ksv_count = 0;
> > +   u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
> > +
> > +   do {
> > +   vrl_ksv_cnt = *buf;
> > +   vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
> > +
> > +   buf++;
> > +
> > +   DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
> >

Re: [PATCH v5 08/12] drm: uevent for connector status change

[Daniel Vetter]

On Thu, Apr 18, 2019 at 02:28:01PM +0530, Ramalingam C wrote:
> DRM API for generating uevent for a status changes of connector's
> property.
> 
> This uevent will have following details related to the status change:
> 
>   HOTPLUG=1, CONNECTOR= and PROPERTY=
> v2:
>   Minor fixes at KDoc comments [Daniel]
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/drm_sysfs.c | 31 +++
>  include/drm/drm_sysfs.h |  5 -
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 18b1ac442997..e8f1fd73677f 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -320,6 +320,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
>   * Send a uevent for the DRM device specified by @dev.  Currently we only
>   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
>   * deal with other types of events.
> + *
> + * Any new uapi should be using the drm_sysfs_connector_status_event()
> + * for uevents on connector status change.
>   */
>  void drm_sysfs_hotplug_event(struct drm_device *dev)
>  {
> @@ -332,6 +335,34 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
>  
> +/**
> + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> + * property status change
> + * @connector: connector on which property status changed
> + * @property: connector property whoes status changed.
> + *
> + * Send a uevent for the DRM device specified by @dev.  Currently we
> + * set HOTPLUG=1 and connector id along with the attached property id
> + * related to the status change.
> + */
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +   struct drm_property *property)
> +{
> + struct drm_device *dev = connector->dev;
> + char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> + char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> +
> + snprintf(conn_id, ARRAY_SIZE(conn_id),
> +  "CONNECTOR=%u", connector->base.id);
> + snprintf(prop_id, ARRAY_SIZE(prop_id),
> +  "PROPERTY=%u", property->base.id);

Maybe double-check that property is attached to connector, and WARN if
not? Just to catch mistakes in driver programming.

With that: Reviewed-by: Daniel Vetter 


> +
> + DRM_DEBUG("generating connector status event\n");
> +
> + kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
> +}
> +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> +
>  static void drm_sysfs_release(struct device *dev)
>  {
>   kfree(dev);
> diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> index 4f311e836cdc..d454ef617b2c 100644
> --- a/include/drm/drm_sysfs.h
> +++ b/include/drm/drm_sysfs.h
> @@ -4,10 +4,13 @@
>  
>  struct drm_device;
>  struct device;
> +struct drm_connector;
> +struct drm_property;
>  
>  int drm_class_device_register(struct device *dev);
>  void drm_class_device_unregister(struct device *dev);
>  
>  void drm_sysfs_hotplug_event(struct drm_device *dev);
> -
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +   struct drm_property *property);
>  #endif
> -- 
> 2.19.1
> 

-- 
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 v5 10/12] drm/i915: update the hdcp state with uevent

[Daniel Vetter]

On Thu, Apr 18, 2019 at 02:28:03PM +0530, Ramalingam C wrote:
> drm function to update the content protection property state and to
> generate a uevent is invoked from the intel hdcp property work.
> 
> Hence whenever kernel changes the property state, userspace will be
> updated with a uevent.
> 
> v2:
>   state update is moved into drm function [daniel]
> 
> Signed-off-by: Ramalingam C 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index de634f3fbd1b..84ac23ea75af 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -866,7 +866,6 @@ static void intel_hdcp_prop_work(struct work_struct *work)
>  prop_work);
>   struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
>   struct drm_device *dev = connector->base.dev;
> - struct drm_connector_state *state;
>  
>   drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>   mutex_lock(&hdcp->mutex);
> @@ -876,10 +875,9 @@ static void intel_hdcp_prop_work(struct work_struct 
> *work)
>* those to UNDESIRED is handled by core. If value == UNDESIRED,
>* we're running just after hdcp has been disabled, so just exit
>*/
> - if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
> - state = connector->base.state;
> - state->content_protection = hdcp->value;
> - }
> + if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + drm_hdcp_update_content_protection(&connector->base,
> +hdcp->value);
>  
>   mutex_unlock(&hdcp->mutex);
>   drm_modeset_unlock(&dev->mode_config.connection_mutex);
> -- 
> 2.19.1
> 

-- 
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 v5 09/12] drm/hdcp: update content protection property with uevent

[Daniel Vetter]

On Thu, Apr 18, 2019 at 02:28:02PM +0530, Ramalingam C wrote:
> drm function is defined and exported to update a connector's
> content protection property state and to generate a uevent along
> with it.
> 
> v2:
>   Update only when state is different from old one.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/drm_hdcp.c | 16 
>  include/drm/drm_hdcp.h |  2 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index a0960507e4ff..5640c4e744fe 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -415,3 +415,19 @@ int drm_connector_attach_content_protection_property(
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
> +

Needs kerneldoc. Plus I think a note in the attach function that sets up
hdcp for a connector that it should be used.

Plus we need an ack from userspace people (weston?) that they're using
this new uapi and are happy with it.

> +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> + u64 val)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_connector_state *state = connector->state;
> +
> + WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
> + if (state->content_protection == val)
> + return;
> +
> + state->content_protection = val;
> + drm_sysfs_connector_status_event(connector,
> +  dev->mode_config.content_protection_property);
> +}
> +EXPORT_SYMBOL(drm_hdcp_update_content_protection);

With all that addressed has my Reviewed-by: Daniel Vetter 


> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index 145c81ba1e09..9457c7ec0d37 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -304,4 +304,6 @@ struct drm_connector;
>  bool drm_hdcp_ksvs_revocated(struct drm_device *dev, u8 *ksvs, u32 
> ksv_count);
>  int drm_connector_attach_content_protection_property(
>   struct drm_connector *connector, bool hdcp_content_type);
> +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> + u64 val);
>  #endif
> -- 
> 2.19.1
> 

-- 
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 v5 11/12] drm: Add CP downstream_info property

[Daniel Vetter]

On Thu, Apr 18, 2019 at 02:28:04PM +0530, Ramalingam C wrote:
> This patch adds a optional CP downstream info blob property to the
> connectors. This enables the Userspace to read the information of HDCP
> authenticated downstream topology.
> 
> Driver will update this blob with all downstream information at the
> end of the authentication.
> 
> In case userspace configures this platform as repeater, then this
> information is needed for the authentication with upstream HDCP
> transmitter.
> 
> v2:
>   s/cp_downstream/content_protection_downstream [daniel]
> v3:
>   s/content_protection_downstream/hdcp_topology [daniel]
> v4:
>   hdcp_topology_info struct is added with explicit padding [Daniel]
> v5:
>   Rebased.
> 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c |  3 ++
>  drivers/gpu/drm/drm_connector.c   | 20 ++
>  drivers/gpu/drm/drm_hdcp.c| 65 +++
>  include/drm/drm_connector.h   |  6 +++
>  include/drm/drm_hdcp.h|  6 +++
>  include/drm/drm_mode_config.h |  6 +++
>  include/uapi/drm/drm_mode.h   | 37 ++
>  7 files changed, 143 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 0b0747869963..1c9e1ab0d536 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -813,6 +813,9 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->content_protection;
>   } else if (property == config->hdcp_content_type_property) {
>   *val = state->hdcp_content_type;
> + } else if (property == config->hdcp_topology_property) {
> + *val = connector->hdcp_topology_blob_ptr ?
> + connector->hdcp_topology_blob_ptr->base.id : 0;
>   } else if (property == config->writeback_fb_id_property) {
>   /* Writeback framebuffer is one-shot, write and forget */
>   *val = 0;
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 436cf8e764cc..033ced774d37 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -246,6 +246,7 @@ int drm_connector_init(struct drm_device *dev,
>   mutex_init(&connector->mutex);
>   connector->edid_blob_ptr = NULL;
>   connector->tile_blob_ptr = NULL;
> + connector->hdcp_topology_blob_ptr = NULL;
>   connector->status = connector_status_unknown;
>   connector->display_info.panel_orientation =
>   DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> @@ -972,6 +973,25 @@ static const struct drm_prop_enum_list 
> hdmi_colorspaces[] = {
>   *   authentication process. If content type is changed when
>   *   content_protection is not UNDESIRED, then kernel will disable the HDCP
>   *   and re-enable with new type in the same atomic commit
> + * HDCP Topology:
> + *   This blob property is used to pass the HDCP downstream topology details
> + *   of a HDCP encrypted connector, from kernel to userspace.
> + *   This provides all required information to userspace, so that userspace
> + *   can implement the HDCP repeater using the kernel as downstream ports of
> + *   the repeater. as illustrated below:
> + *
> + *  HDCP Repeaters
> + * +--+
> + * |  |
> + * |   |  |
> + * |   Userspace HDCP Receiver  +->KMD HDCP transmitters  |
> + * |  (Upstream Port)  <--+ (Downstream Ports)|
> + * |   |  |
> + * |  |
> + * +--+

Hm I think this misrenders, since the table isn't indented or marked as
fixed with. Did you check the output of $make htmldocs?

> + *
> + *   Kernel will populate this blob only when the HDCP authentication is
> + *   successful.
>   *
>   * max bpc:
>   *   This range property is used by userspace to limit the bit depth. When
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index 5640c4e744fe..c0d3fc93fc50 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -431,3 +431,68 @@ void drm_hdcp_update_content_protection(struct 
> drm_connector *connector,
>dev->mode_config.content_protection_property);
>  }
>  EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> +
> +/**
> + * drm_connector_attach_hdcp_topology_property - attach hdcp topology 
> property
> + *
> + * @connector: connector to attach hdcp topology property with.
> + *
> + * This is used to add support for hdcp topology support on select 
> connectors.
> + * When Intel platform is configured as repeater, this downstream info is 
> used
> + * b

Re: [PATCH] Revert "drm/qxl: drop prime import/export callbacks"

[Daniel Vetter]

On Fri, Apr 26, 2019 at 05:42:23PM +0200, Thomas Hellstrom wrote:
> On 4/26/19 4:21 PM, Daniel Vetter wrote:
> > On Fri, Apr 26, 2019 at 7:33 AM Gerd Hoffmann  wrote:
> > > This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8.
> > > 
> > > Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime
> > > import/export callbacks".  We have to do the same with qxl,
> > > for the same reasons (it breaks DRI3).
> > > 
> > > Drop the WARN_ON_ONCE().
> > > 
> > > Fixes: f4c34b1e2a37d5676180901fa6ff188bcb6371f8
> > > Signed-off-by: Gerd Hoffmann 
> > Maybe we need some helpers for virtual drivers which only allow
> > self-reimport and nothing else at all? I think there's qxl, virgl,
> > vmwgfx and maybe also vbox one who could use this ... Just a quick
> > idea.
> > -Daniel
> 
> I think vmwgfx could, in theory, support the full range of operations,
> at least for reasonably recent device versions. However, it wouldn't be
> terribly efficient since the exported dma-buf sglist would basically be a
> bounce-buffer.

Yeah not sure that makes sense to support really ...
-Daniel

> 
> /Thomas
> 
> 
> > > ---
> > >   drivers/gpu/drm/qxl/qxl_drv.c   |  4 
> > >   drivers/gpu/drm/qxl/qxl_prime.c | 12 
> > >   2 files changed, 16 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > > index 578d867a81d5..f33e349c4ec5 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > > @@ -255,10 +255,14 @@ static struct drm_driver qxl_driver = {
> > >   #if defined(CONFIG_DEBUG_FS)
> > >  .debugfs_init = qxl_debugfs_init,
> > >   #endif
> > > +   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > > +   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > >  .gem_prime_export = drm_gem_prime_export,
> > >  .gem_prime_import = drm_gem_prime_import,
> > >  .gem_prime_pin = qxl_gem_prime_pin,
> > >  .gem_prime_unpin = qxl_gem_prime_unpin,
> > > +   .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
> > > +   .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
> > >  .gem_prime_vmap = qxl_gem_prime_vmap,
> > >  .gem_prime_vunmap = qxl_gem_prime_vunmap,
> > >  .gem_prime_mmap = qxl_gem_prime_mmap,
> > > diff --git a/drivers/gpu/drm/qxl/qxl_prime.c 
> > > b/drivers/gpu/drm/qxl/qxl_prime.c
> > > index 8b448eca1cd9..114653b471c6 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_prime.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_prime.c
> > > @@ -42,6 +42,18 @@ void qxl_gem_prime_unpin(struct drm_gem_object *obj)
> > >  qxl_bo_unpin(bo);
> > >   }
> > > 
> > > +struct sg_table *qxl_gem_prime_get_sg_table(struct drm_gem_object *obj)
> > > +{
> > > +   return ERR_PTR(-ENOSYS);
> > > +}
> > > +
> > > +struct drm_gem_object *qxl_gem_prime_import_sg_table(
> > > +   struct drm_device *dev, struct dma_buf_attachment *attach,
> > > +   struct sg_table *table)
> > > +{
> > > +   return ERR_PTR(-ENOSYS);
> > > +}
> > > +
> > >   void *qxl_gem_prime_vmap(struct drm_gem_object *obj)
> > >   {
> > >  struct qxl_bo *bo = gem_to_qxl_bo(obj);
> > > --
> > > 2.18.1
> > > 
> > 
> 

-- 
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 110514] [CI][BAT] igt@* - skip - Test requirement: is_i915_device(fd) && has_known_intel_chipset(fd), Skip

[bugzilla-daemon]

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

--- Comment #20 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- CML: igt@gem_render_copy_redux@interruptible - skip - no render-copy
function -}
{+ CML: igt@gem_render_copy_redux@.* - skip - no render-copy function +}

New failures caught by the filter:

  *
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_266/fi-cml-u/igt@gem_render_copy_re...@normal.html
  *
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_266/fi-cml-u/igt@gem_render_copy_re...@flink.html
  *
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_266/fi-cml-u/igt@gem_render_copy_re...@flink-interruptible.html

-- 
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: [Spice-devel] [PATCH] Revert "drm/qxl: drop prime import/export callbacks"

[Daniel Vetter]

On Mon, Apr 29, 2019 at 9:54 AM Gerd Hoffmann  wrote:
>
> On Fri, Apr 26, 2019 at 04:21:37PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 26, 2019 at 7:33 AM Gerd Hoffmann  wrote:
> > >
> > > This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8.
> > >
> > > Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime
> > > import/export callbacks".  We have to do the same with qxl,
> > > for the same reasons (it breaks DRI3).
> > >
> > > Drop the WARN_ON_ONCE().
> > >
> > > Fixes: f4c34b1e2a37d5676180901fa6ff188bcb6371f8
> > > Signed-off-by: Gerd Hoffmann 
> >
> > Maybe we need some helpers for virtual drivers which only allow
> > self-reimport and nothing else at all?
>
> The current gem prime helpers handle this reasonable well,
> I don't see a need for that.
>
> More useful would be some way to signal this self-reimport capability
> to userspace somehow.  See DRM_PRIME_CAP_LOCAL patch.

Userspace is supposed to test whether import/export works for a
specific combo, not blindly assume it does and then keel over. I think
we need to fix that, not add more flags - there's lots of reasons why
a given pair of devices can't share buffers (e.g. all the contiguous
allocations stuff on socs).

> Right now I have the choice to set DRM_PRIME_CAP_{IMPORT,EXPORT}, in
> which case some userspace assumes it can do cross-driver export/import
> and trips over that not working.  Or I do not set
> DRM_PRIME_CAP_{IMPORT,EXPORT}, which breaks DRI3 ...

Yeah that's not an option.
-Daniel

> > I think there's qxl, virgl,
>
> export is implemented for virgl, and import should be possible too.
>
> qxl/bochs is simliar to vmgfx, it could be done but dma-bufs would
> basically be bounce buffers (need copy from/to vram) so probably not
> worth the effort.
>
> cheers,
>   Gerd
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/meson: Add support for XBGR8888 & ABGR8888 formats

[Neil Armstrong]

Add missing XBGR & ABGR formats variants from the primary plane.

Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_plane.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_plane.c 
b/drivers/gpu/drm/meson/meson_plane.c
index bf8f1fab63aa..b8f6b08a89a6 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -165,6 +165,13 @@ static void meson_plane_atomic_update(struct drm_plane 
*plane,
priv->viu.osd1_blk0_cfg[0] |= OSD_BLK_MODE_32 |
  OSD_COLOR_MATRIX_32_ARGB;
break;
+   case DRM_FORMAT_XBGR:
+   /* For XRGB, replace the pixel's alpha by 0xFF */
+   writel_bits_relaxed(OSD_REPLACE_EN, OSD_REPLACE_EN,
+   priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
+   priv->viu.osd1_blk0_cfg[0] |= OSD_BLK_MODE_32 |
+ OSD_COLOR_MATRIX_32_ABGR;
+   break;
case DRM_FORMAT_ARGB:
/* For ARGB, use the pixel's alpha */
writel_bits_relaxed(OSD_REPLACE_EN, 0,
@@ -172,6 +179,13 @@ static void meson_plane_atomic_update(struct drm_plane 
*plane,
priv->viu.osd1_blk0_cfg[0] |= OSD_BLK_MODE_32 |
  OSD_COLOR_MATRIX_32_ARGB;
break;
+   case DRM_FORMAT_ABGR:
+   /* For ARGB, use the pixel's alpha */
+   writel_bits_relaxed(OSD_REPLACE_EN, 0,
+   priv->io_base + _REG(VIU_OSD1_CTRL_STAT2));
+   priv->viu.osd1_blk0_cfg[0] |= OSD_BLK_MODE_32 |
+ OSD_COLOR_MATRIX_32_ABGR;
+   break;
case DRM_FORMAT_RGB888:
priv->viu.osd1_blk0_cfg[0] |= OSD_BLK_MODE_24 |
  OSD_COLOR_MATRIX_24_RGB;
@@ -356,7 +370,9 @@ static const struct drm_plane_funcs meson_plane_funcs = {
 
 static const uint32_t supported_drm_formats[] = {
DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
DRM_FORMAT_RGB888,
DRM_FORMAT_RGB565,
 };
-- 
2.21.0

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

[PATCH] drm/meson: Add zpos immutable property to planes

[Neil Armstrong]

Add immutable zpos property to primary and overlay planes to specify
the current fixed zpos position.

Fixes: f9a2348196d1 ("drm/meson: Support Overlay plane for video rendering")
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_overlay.c | 3 +++
 drivers/gpu/drm/meson/meson_plane.c   | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
b/drivers/gpu/drm/meson/meson_overlay.c
index bdbf925ff3e8..dceb3df5e652 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -578,6 +578,9 @@ int meson_overlay_create(struct meson_drm *priv)
 
drm_plane_helper_add(plane, &meson_overlay_helper_funcs);
 
+   /* For now, VD Overlay plane is always on the back */
+   drm_plane_create_zpos_immutable_property(plane, 0);
+
priv->overlay_plane = plane;
 
DRM_DEBUG_DRIVER("\n");
diff --git a/drivers/gpu/drm/meson/meson_plane.c 
b/drivers/gpu/drm/meson/meson_plane.c
index b8f6b08a89a6..2f7f4dfce45b 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -399,6 +399,9 @@ int meson_plane_create(struct meson_drm *priv)
 
drm_plane_helper_add(plane, &meson_plane_helper_funcs);
 
+   /* For now, OSD Primary plane is always on the front */
+   drm_plane_create_zpos_immutable_property(plane, 1);
+
priv->primary_plane = plane;
 
return 0;
-- 
2.21.0

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

Re: [Spice-devel] [PATCH] Revert "drm/qxl: drop prime import/export callbacks"

[Gerd Hoffmann]

On Fri, Apr 26, 2019 at 04:21:37PM +0200, Daniel Vetter wrote:
> On Fri, Apr 26, 2019 at 7:33 AM Gerd Hoffmann  wrote:
> >
> > This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8.
> >
> > Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime
> > import/export callbacks".  We have to do the same with qxl,
> > for the same reasons (it breaks DRI3).
> >
> > Drop the WARN_ON_ONCE().
> >
> > Fixes: f4c34b1e2a37d5676180901fa6ff188bcb6371f8
> > Signed-off-by: Gerd Hoffmann 
> 
> Maybe we need some helpers for virtual drivers which only allow
> self-reimport and nothing else at all?

The current gem prime helpers handle this reasonable well,
I don't see a need for that.

More useful would be some way to signal this self-reimport capability
to userspace somehow.  See DRM_PRIME_CAP_LOCAL patch.

Right now I have the choice to set DRM_PRIME_CAP_{IMPORT,EXPORT}, in
which case some userspace assumes it can do cross-driver export/import
and trips over that not working.  Or I do not set
DRM_PRIME_CAP_{IMPORT,EXPORT}, which breaks DRI3 ...

> I think there's qxl, virgl,

export is implemented for virgl, and import should be possible too.

qxl/bochs is simliar to vmgfx, it could be done but dma-bufs would
basically be bounce buffers (need copy from/to vram) so probably not
worth the effort.

cheers,
  Gerd

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

[Bug 110514] [CI][BAT] igt@* - skip - Test requirement: is_i915_device(fd) && has_known_intel_chipset(fd), Skip

[bugzilla-daemon]

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

--- Comment #19 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- CML: igt@*stolen* - skip - Test requirement:
gem_create__has_stolen_support(fd) && (gem_total_stolen_size(fd) >
0), SKIP -}
{+ CML: igt@*stolen* | igt@gem_pread@pagefault-pread - skip - Test requirement:
gem_create__has_stolen_support(fd) && (gem_total_stolen_size(fd) >
0), SKIP +}

New failures caught by the filter:

  *
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_266/fi-cml-u/igt@gem_pr...@pagefault-pread.html
  *
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_pr...@pagefault-pread.html
  *
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_pr...@pagefault-pread.html
  *
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/igt@gem_pr...@pagefault-pread.html

-- 
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 110514] [CI][BAT] igt@* - skip - Test requirement: is_i915_device(fd) && has_known_intel_chipset(fd), Skip

[bugzilla-daemon]

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

--- Comment #21 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- CML: igt@gem_render_copy_redux@.* - skip - no render-copy function -}
{+ CML: igt@gem_render_copy_redux@.* - skip - no render-copy function +}


  No new failures caught with the new filter

-- 
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 110514] [CI][BAT] igt@* - skip - Test requirement: is_i915_device(fd) && has_known_intel_chipset(fd), Skip

[bugzilla-daemon]

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

--- Comment #22 from CI Bug Log  ---
The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* CML: igt@gem_mocs_settings@.* - skip - Test requirement:
get_mocs_settings(fd, &table, false), SKIP
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-ctx-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-ctx-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-ctx-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-ctx-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-ctx-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-blt.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-blt.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-blt.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_267/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-ctx-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-blt.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-ctx-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-ctx-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-ctx-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-ctx-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-ctx-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-blt.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-blt.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-ctx-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_268/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-blt.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/igt@gem_mocs_setti...@mocs-settings-ctx-dirty-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/igt@gem_mocs_setti...@mocs-rc6-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/igt@gem_mocs_setti...@mocs-isolation-vebox.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/igt@gem_mocs_setti...@mocs-reset-render.html
  -
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_269/fi-cml-u/ig

Re: [PATCH 01/12] dma-buf: add struct dma_buf_attach_info

[Daniel Vetter]

On Fri, Apr 26, 2019 at 02:36:27PM +0200, Christian König wrote:
> Add a structure for the parameters of dma_buf_attach, this makes it much 
> easier
> to add new parameters later on.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/dma-buf/dma-buf.c   | 13 +++--
>  drivers/gpu/drm/armada/armada_gem.c |  6 +-
>  drivers/gpu/drm/drm_prime.c |  6 +-
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c  |  6 +-

omapdrm seems to be missing.

>  drivers/gpu/drm/tegra/gem.c |  6 +-
>  drivers/gpu/drm/udl/udl_dmabuf.c|  6 +-
>  .../common/videobuf2/videobuf2-dma-contig.c |  6 +-
>  .../media/common/videobuf2/videobuf2-dma-sg.c   |  6 +-

videobuf2-dma-sg seems to be missing.

>  drivers/staging/media/tegra-vde/tegra-vde.c |  6 +-

fastrpc and gntdev-dmabuf also missing.

I guess all just rebase fallout. With those all compiling:

Reviewed-by: Daniel Vetter 

Would also be good to cc: everyone on the next round per
get_mainteiners.pl for this patch.
-Daniel


>  include/linux/dma-buf.h | 17 +++--
>  10 files changed, 62 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 7c858020d14b..50b4c6af04c7 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -532,8 +532,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>  /**
>   * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
>   * calls attach() of dma_buf_ops to allow device-specific attach 
> functionality
> - * @dmabuf:  [in]buffer to attach device to.
> - * @dev: [in]device to be attached.
> + * @info:[in]holds all the attach related information provided
> + *   by the importer. see &struct dma_buf_attach_info
> + *   for further details.
>   *
>   * Returns struct dma_buf_attachment pointer for this attachment. Attachments
>   * must be cleaned up by calling dma_buf_detach().
> @@ -547,20 +548,20 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>   * accessible to @dev, and cannot be moved to a more suitable place. This is
>   * indicated with the error code -EBUSY.
>   */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> -   struct device *dev)
> +struct dma_buf_attachment *dma_buf_attach(const struct dma_buf_attach_info 
> *info)
>  {
> + struct dma_buf *dmabuf = info->dmabuf;
>   struct dma_buf_attachment *attach;
>   int ret;
>  
> - if (WARN_ON(!dmabuf || !dev))
> + if (WARN_ON(!dmabuf || !info->dev))
>   return ERR_PTR(-EINVAL);
>  
>   attach = kzalloc(sizeof(*attach), GFP_KERNEL);
>   if (!attach)
>   return ERR_PTR(-ENOMEM);
>  
> - attach->dev = dev;
> + attach->dev = info->dev;
>   attach->dmabuf = dmabuf;
>  
>   mutex_lock(&dmabuf->lock);
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 642d0e70d0f8..19c47821032f 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -501,6 +501,10 @@ armada_gem_prime_export(struct drm_device *dev, struct 
> drm_gem_object *obj,
>  struct drm_gem_object *
>  armada_gem_prime_import(struct drm_device *dev, struct dma_buf *buf)
>  {
> + struct dma_buf_attach_info attach_info = {
> + .dev = dev->dev,
> + .dmabuf = buf
> + };
>   struct dma_buf_attachment *attach;
>   struct armada_gem_object *dobj;
>  
> @@ -516,7 +520,7 @@ armada_gem_prime_import(struct drm_device *dev, struct 
> dma_buf *buf)
>   }
>   }
>  
> - attach = dma_buf_attach(buf, dev->dev);
> + attach = dma_buf_attach(&attach_info);
>   if (IS_ERR(attach))
>   return ERR_CAST(attach);
>  
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 231e3f6d5f41..1fadf5d5ed33 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -709,6 +709,10 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct 
> drm_device *dev,
>   struct dma_buf *dma_buf,
>   struct device *attach_dev)
>  {
> + struct dma_buf_attach_info attach_info = {
> + .dev = attach_dev,
> + .dmabuf = dma_buf
> + };
>   struct dma_buf_attachment *attach;
>   struct sg_table *sgt;
>   struct drm_gem_object *obj;
> @@ -729,7 +733,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct 
> drm_device *dev,
>   if (!dev->driver->gem_prime_import_sg_table)
>   return ERR_PTR(-EINVAL);
>  
> - attach = dma_buf_attach(dma_buf, attach_dev);
> + attach = dma_buf_attach(&attach_info);
>   if (IS_ERR(attach))
>   return ERR_CAST(attach);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmab

[Bug 110381] Failed to updateMST allocation table forpipe idx:0

[bugzilla-daemon]

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

--- Comment #1 from Paul Menzel  ---
This still happens with Linux 5.1-rc6.

```
[Fri Apr 26 16:02:16 2019] [drm] DM_MST: stopping TM on aconnector:
c53c37c4 [id: 59]
[Fri Apr 26 16:02:16 2019] [drm] DM_MST: Disabling connector: d00286a1
[id: 70] [master: c53c37c4]
[Fri Apr 26 16:02:16 2019] [drm] DM_MST: Disabling connector: e78a9cad
[id: 75] [master: c53c37c4]
[Fri Apr 26 16:02:19 2019] usb 1-10: USB disconnect, device number 9
[Mon Apr 29 10:16:33 2019] [drm] DM_MST: starting TM on aconnector:
c53c37c4 [id: 59]
[Mon Apr 29 10:16:33 2019] [drm] DM_MST: added connector: f322b7c6 [id:
83] [master: c53c37c4]
[Mon Apr 29 10:16:33 2019] [drm] SADs count is: -2, don't need to read it
[Mon Apr 29 10:16:33 2019] [drm] DM_MST: added connector: d75129fc [id:
103] [master: c53c37c4]
[Mon Apr 29 10:16:34 2019] [drm] Failed to updateMST allocation table forpipe
idx:0
[Mon Apr 29 10:16:34 2019] [drm] SADs count is: -2, don't need to read it
[Mon Apr 29 10:16:34 2019] [drm] Failed to updateMST allocation table forpipe
idx:0
[Mon Apr 29 10:16:34 2019] [drm] Failed to updateMST allocation table forpipe
idx:0
[Mon Apr 29 10:16:34 2019] WARNING: CPU: 3 PID: 466 at
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2354
update_mst_stream_alloc_table+0x144/0x150 [amdgpu]
[Mon Apr 29 10:16:34 2019] Modules linked in: fuse rpcsec_gss_krb5 nfsv4 nfs
8021q garp stp mrp llc input_leds led_class amdgpu snd_hda_codec_realtek
snd_hda_codec_generic i915 chash gpu_sched ttm iosf_mbi snd_hda_codec_hdmi
drm_kms_helper snd_hda_intel intel_gtt snd_hda_codec drm x86_pkg_temp_thermal
fb_sys_fops syscopyarea snd_hda_core kvm_intel snd_pcm kvm snd_timer snd
sysfillrect irqbypass wmi_bmof soundcore crc32c_intel sysimgblt video wmi nfsd
auth_rpcgss oid_registry nfs_acl lockd grace sunrpc efivarfs ip_tables x_tables
unix ipv6 autofs4
[Mon Apr 29 10:16:34 2019] CPU: 3 PID: 466 Comm: Xorg Kdump: loaded Not tainted
5.1.0-rc6.mx64.258 #1
[Mon Apr 29 10:16:34 2019] Hardware name: Dell Inc. Precision 3630
Tower/0NNNCT, BIOS 1.0.4 07/17/2018
[Mon Apr 29 10:16:34 2019] RIP: 0010:update_mst_stream_alloc_table+0x144/0x150
[amdgpu]
[Mon Apr 29 10:16:34 2019] Code: 63 d0 48 83 c2 13 48 c1 e2 04 4d 8b 4c 10 08
4d 8b 54 10 10 4d 89 0c 24 4d 89 54 24 08 39 c1 75 81 e9 67 ff ff ff 31 c0 eb
f3 <0f> 0b e9 14 ff ff ff e8 f0 15 88 e0 0f 1f 44 00 00 41 55 41 54 49
[Mon Apr 29 10:16:34 2019] RSP: 0018:c9000252b6b0 EFLAGS: 00010202
[Mon Apr 29 10:16:34 2019] RAX: 0002 RBX: 88846410c5c0 RCX:

[Mon Apr 29 10:16:34 2019] RDX: c9000252b784 RSI: 88844d848a80 RDI:
c9000252b710
[Mon Apr 29 10:16:34 2019] RBP: c9000252b750 R08: 888460a53c00 R09:
88838460
[Mon Apr 29 10:16:34 2019] R10: c9000252b768 R11: c9000252b6b0 R12:
888460a53c00
[Mon Apr 29 10:16:34 2019] R13: 88846410c000 R14: 0002 R15:
888454a7
[Mon Apr 29 10:16:34 2019] FS:  7f906be66540()
GS:88846c0c() knlGS:
[Mon Apr 29 10:16:34 2019] CS:  0010 DS:  ES:  CR0: 80050033
[Mon Apr 29 10:16:34 2019] CR2: 006c7448 CR3: 00044c81c006 CR4:
003606e0
[Mon Apr 29 10:16:34 2019] DR0:  DR1:  DR2:

[Mon Apr 29 10:16:34 2019] DR3:  DR6: fffe0ff0 DR7:
0400
[Mon Apr 29 10:16:34 2019] Call Trace:
[Mon Apr 29 10:16:34 2019]  ? mutex_lock+0xe/0x30
[Mon Apr 29 10:16:34 2019]  ? core_link_enable_stream+0x47a/0x1090 [amdgpu]
[Mon Apr 29 10:16:34 2019]  core_link_enable_stream+0x47a/0x1090 [amdgpu]
[Mon Apr 29 10:16:34 2019]  dce110_apply_ctx_to_hw+0x3f1/0x480 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? dce110_apply_ctx_for_surface+0x250/0x2b0 [amdgpu]
[Mon Apr 29 10:16:34 2019]  dc_commit_state+0x2d6/0x560 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? drm_calc_timestamping_constants+0xe5/0x150 [drm]
[Mon Apr 29 10:16:34 2019]  amdgpu_dm_atomic_commit_tail+0x388/0x1960 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? bw_calcs+0x6f8/0x1cd0 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? dce112_validate_bandwidth+0x3e/0x70 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? dc_validate_global_state+0x2d4/0x360 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? amdgpu_bo_pin_restricted+0x68/0x290 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? _cond_resched+0x15/0x40
[Mon Apr 29 10:16:34 2019]  ? wait_for_common+0x3d/0x180
[Mon Apr 29 10:16:34 2019]  ? _cond_resched+0x15/0x40
[Mon Apr 29 10:16:34 2019]  ? wait_for_common+0x3d/0x180
[Mon Apr 29 10:16:34 2019]  ? dm_plane_helper_prepare_fb+0x117/0x370 [amdgpu]
[Mon Apr 29 10:16:34 2019]  ? commit_tail+0x3d/0x70 [drm_kms_helper]
[Mon Apr 29 10:16:34 2019]  commit_tail+0x3d/0x70 [drm_kms_helper]
[Mon Apr 29 10:16:34 2019]  drm_atomic_helper_commit+0xfc/0x110
[drm_kms_helper]
[Mon Apr 29 10:16:34 2019]  drm_atomic_helper_set_config+0x80/0x90
[drm_kms_helper]
[Mon Apr 29 10:16

Re: [PATCH 02/12] dma-buf: add explicit buffer pinning v2

[Daniel Vetter]

On Fri, Apr 26, 2019 at 02:36:28PM +0200, Christian König wrote:
> Add optional explicit pinning callbacks instead of implicitly assume the
> exporter pins the buffer when a mapping is created.
> 
> v2: move in patchset and pin the dma-buf in the old mapping code paths.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/dma-buf/dma-buf.c | 49 ++-
>  include/linux/dma-buf.h   | 38 +-
>  2 files changed, 80 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 50b4c6af04c7..0656dcf289be 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -529,6 +529,41 @@ void dma_buf_put(struct dma_buf *dmabuf)
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_put);
>  
> +/**
> + * dma_buf_pin - Lock down the DMA-buf
> + *
> + * @dmabuf:  [in]DMA-buf to lock down.
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int dma_buf_pin(struct dma_buf *dmabuf)

I think this should be on the attachment, not on the buffer. Or is the
idea that a pin is for the entire buffer, and all subsequent
dma_buf_map_attachment must work for all attachments? I think this matters
for sufficiently contrived p2p scenarios.

Either way, docs need to clarify this.

> +{
> + int ret = 0;
> +
> + reservation_object_assert_held(dmabuf->resv);
> +
> + if (dmabuf->ops->pin)
> + ret = dmabuf->ops->pin(dmabuf);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_pin);
> +
> +/**
> + * dma_buf_unpin - Remove lock from DMA-buf
> + *
> + * @dmabuf:  [in]DMA-buf to unlock.
> + */
> +void dma_buf_unpin(struct dma_buf *dmabuf)
> +{
> + reservation_object_assert_held(dmabuf->resv);
> +
> + if (dmabuf->ops->unpin)
> + dmabuf->ops->unpin(dmabuf);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
> +
>  /**
>   * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
>   * calls attach() of dma_buf_ops to allow device-specific attach 
> functionality
> @@ -548,7 +583,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
>   * accessible to @dev, and cannot be moved to a more suitable place. This is
>   * indicated with the error code -EBUSY.
>   */
> -struct dma_buf_attachment *dma_buf_attach(const struct dma_buf_attach_info 
> *info)
> +struct dma_buf_attachment *
> +dma_buf_attach(const struct dma_buf_attach_info *info)
>  {
>   struct dma_buf *dmabuf = info->dmabuf;
>   struct dma_buf_attachment *attach;
> @@ -625,12 +661,19 @@ struct sg_table *dma_buf_map_attachment(struct 
> dma_buf_attachment *attach,
>   enum dma_data_direction direction)
>  {
>   struct sg_table *sg_table;
> + int r;
>  
>   might_sleep();
>  
>   if (WARN_ON(!attach || !attach->dmabuf))
>   return ERR_PTR(-EINVAL);
>  
> + reservation_object_lock(attach->dmabuf->resv, NULL);
> + r = dma_buf_pin(attach->dmabuf);
> + reservation_object_unlock(attach->dmabuf->resv);

This adds an unconditional reservat lock to map/unmap, which is think
pisses off drivers. This gets fixed later on with the caching, but means
the series is broken here.

Also, that super-fine grained split-up makes it harder for me to review
the docs, since only until the very end are all the bits present for full
dynamic dma-buf mappings.

I think it'd be best to squash all the patches from pin up to the one that
adds the invalidate callback into one patch. It's all changes to
dma-buf.[hc] only anyway. If that is too big we can think about how to
split it up again, but at least for me the current splitting doesn't make
sense at all.

> + if (r)
> + return ERR_PTR(r);
> +
>   sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>   if (!sg_table)
>   sg_table = ERR_PTR(-ENOMEM);

Leaks the pin if we fail here.

> @@ -660,6 +703,10 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
>  
>   attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
>   direction);
> +
> + reservation_object_lock(attach->dmabuf->resv, NULL);
> + dma_buf_unpin(attach->dmabuf);
> + reservation_object_unlock(attach->dmabuf->resv);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>  
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 2c312dfd31a1..0321939b1c3d 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -51,6 +51,34 @@ struct dma_buf_attachment;
>   * @vunmap: [optional] unmaps a vmap from the buffer
>   */
>  struct dma_buf_ops {
> + /**
> +  * @pin:
> +  *
> +  * This is called by dma_buf_pin and lets the exporter know that the
> +  * DMA-buf can't be moved any more.
> +  *
> +  * This is called with the dmabuf->resv object locked.
> +  *
> +  * This callback is optional.
> +  *
> +  * Returns:
> +  *
> +  * 0 on success, nega

Re: [PATCH 06/12] dma-buf: add optional invalidate_mappings callback v5

[Daniel Vetter]

On Fri, Apr 26, 2019 at 02:36:32PM +0200, Christian König wrote:
> Each importer can now provide an invalidate_mappings callback.
> 
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
> 
> v2: don't try to invalidate mappings when the callback is NULL,
> lock the reservation obj while using the attachments,
> add helper to set the callback
> v3: move flag for invalidation support into the DMA-buf,
> use new attach_info structure to set the callback
> v4: use importer_priv field instead of mangling exporter priv.
> v5: drop invalidation_supported flag
> 
> Signed-off-by: Christian König 
> ---
>  drivers/dma-buf/dma-buf.c | 51 +--
>  include/linux/dma-buf.h   | 30 +--
>  2 files changed, 71 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 95bcd2ed795b..1b5cdae68cd6 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -607,7 +607,9 @@ dma_buf_attach(const struct dma_buf_attach_info *info)
>   if (ret)
>   goto err_attach;
>   }
> + reservation_object_lock(dmabuf->resv, NULL);
>   list_add(&attach->node, &dmabuf->attachments);
> + reservation_object_unlock(dmabuf->resv);
>  
>   mutex_unlock(&dmabuf->lock);
>  
> @@ -651,7 +653,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
> dma_buf_attachment *attach)
>  DMA_BIDIRECTIONAL);
>  
>   mutex_lock(&dmabuf->lock);
> + reservation_object_lock(dmabuf->resv, NULL);
>   list_del(&attach->node);
> + reservation_object_unlock(dmabuf->resv);
>   if (dmabuf->ops->detach)
>   dmabuf->ops->detach(dmabuf, attach);
>  
> @@ -672,10 +676,7 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
>   * Returns sg_table containing the scatterlist to be returned; returns 
> ERR_PTR
>   * on error. May return -EINTR if it is interrupted by a signal.
>   *
> - * A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
> - * the underlying backing storage is pinned for as long as a mapping exists,
> - * therefore users/importers should not hold onto a mapping for undue 
> amounts of
> - * time.
> + * A mapping must be unmapped by using dma_buf_unmap_attachment().
>   */
>  struct sg_table *
>  dma_buf_map_attachment_locked(struct dma_buf_attachment *attach,
> @@ -690,11 +691,22 @@ dma_buf_map_attachment_locked(struct dma_buf_attachment 
> *attach,
>   if (attach->sgt)
>   return attach->sgt;
>  
> - r = dma_buf_pin(attach->dmabuf);
> - if (r)
> - return ERR_PTR(r);
> + if (attach->invalidate) {
> + /*
> +  * Mapping a DMA-buf can trigger its invalidation, prevent
> +  * sending this event to the caller by temporary removing
> +  * this attachment from the list.
> +  */
> + list_del(&attach->node);
> + } else {
> + r = dma_buf_pin(attach->dmabuf);
> + if (r)
> + return ERR_PTR(r);
> + }
>  
>   sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> + if (attach->invalidate)
> + list_add(&attach->node, &attach->dmabuf->attachments);
>   if (!sg_table)
>   return ERR_PTR(-ENOMEM);
>  
> @@ -761,7 +773,8 @@ void dma_buf_unmap_attachment_locked(struct 
> dma_buf_attachment *attach,
>  
>   attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
>   direction);
> - dma_buf_unpin(attach->dmabuf);
> + if (!attach->invalidate)
> + dma_buf_unpin(attach->dmabuf);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
>  
> @@ -793,6 +806,26 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>  
> +/**
> + * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
> + *
> + * @dmabuf:  [in]buffer which mappings should be invalidated
> + *
> + * Informs all attachmenst that they need to destroy and recreated all their
> + * mappings.
> + */
> +void dma_buf_invalidate_mappings(struct dma_buf *dmabuf)
> +{
> + struct dma_buf_attachment *attach;
> +
> + reservation_object_assert_held(dmabuf->resv);
> +
> + list_for_each_entry(attach, &dmabuf->attachments, node)
> + if (attach->invalidate)
> + attach->invalidate(attach);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_invalidate_mappings);
> +
>  /**
>   * DOC: cpu access
>   *
> @@ -1205,10 +1238,12 @@ static int dma_buf_debug_show(struct seq_file *s, 
> void *unused)
>   seq_puts(s, "\tAttached Devices:\n");
>   attach_count = 0;
>  
> + reservation_object_lock(buf_obj->resv, NULL);
>   list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
>   seq_pr

Re: [PATCH 03/12] dma-buf: start caching of sg_table objects

[Daniel Vetter]

On Fri, Apr 26, 2019 at 02:36:29PM +0200, Christian König wrote:
> To allow a smooth transition from pinning buffer objects to dynamic
> invalidation we first start to cache the sg_table for an attachment
> unless the driver has implemented the explicite pin/unpin callbacks.
> 
> Signed-off-by: Christian König 

Correction on my "squash everything" suggestion: I think this patch here
still needs to be separate, so that "why did this cause a regression" is
easier to understand. But with a small nit.

> ---
>  drivers/dma-buf/dma-buf.c | 24 
>  include/linux/dma-buf.h   |  1 +
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0656dcf289be..a18d10c4425a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -610,6 +610,20 @@ dma_buf_attach(const struct dma_buf_attach_info *info)
>   list_add(&attach->node, &dmabuf->attachments);
>  
>   mutex_unlock(&dmabuf->lock);
> +
> + if (!dmabuf->ops->pin) {

I think a static inline dma_buf_is_dynamic_attachment() would be good
here, which in this patch (since it's ealier) would always return false.

Aside: I think only checking pin here (i.e. can the exporter do dynamic
mappings) isn't good enough, we also need to check for the importers
->invalidate. Hence _is_dynamic_attachment, not _is_dynamic_dma_buf. If we
don't also check for the importer we again have a reservation lock in
dma_buf_map/unmap, which we know will anger the lockdep gods ...
-Daniel

> + struct sg_table *sgt;
> +
> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> + if (!sgt)
> + sgt = ERR_PTR(-ENOMEM);
> + if (IS_ERR(sgt)) {
> + dma_buf_detach(dmabuf, attach);
> + return ERR_CAST(sgt);
> + }
> + attach->sgt = sgt;
> + }
> +
>   return attach;
>  
>  err_attach:
> @@ -632,6 +646,10 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
> dma_buf_attachment *attach)
>   if (WARN_ON(!dmabuf || !attach))
>   return;
>  
> + if (attach->sgt)
> + dmabuf->ops->unmap_dma_buf(attach, attach->sgt,
> +DMA_BIDIRECTIONAL);
> +
>   mutex_lock(&dmabuf->lock);
>   list_del(&attach->node);
>   if (dmabuf->ops->detach)
> @@ -668,6 +686,9 @@ struct sg_table *dma_buf_map_attachment(struct 
> dma_buf_attachment *attach,
>   if (WARN_ON(!attach || !attach->dmabuf))
>   return ERR_PTR(-EINVAL);
>  
> + if (attach->sgt)
> + return attach->sgt;
> +
>   reservation_object_lock(attach->dmabuf->resv, NULL);
>   r = dma_buf_pin(attach->dmabuf);
>   reservation_object_unlock(attach->dmabuf->resv);
> @@ -701,6 +722,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
>   if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
>   return;
>  
> + if (attach->sgt == sg_table)
> + return;
> +
>   attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
>   direction);
>  
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index 0321939b1c3d..b9d0719581cd 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -345,6 +345,7 @@ struct dma_buf_attachment {
>   struct dma_buf *dmabuf;
>   struct device *dev;
>   struct list_head node;
> + struct sg_table *sgt;
>   void *priv;
>  };
>  
> -- 
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH libdrm] xf86drm: Fix possible memory leak with drmModeGetPropertyPtr()

[Seung-Woo Kim]

In drmModeGetPropertyPtr(), from upper error path, it calls free
but with just next error path, it does not call. Fix the possible
memory leak.

Signed-off-by: Seung-Woo Kim 
---
 xf86drmMode.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index c878d9e..207d7be 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -650,7 +650,7 @@ drm_public drmModePropertyPtr drmModeGetProperty(int fd, 
uint32_t property_id)
}
 
if (!(r = drmMalloc(sizeof(*r
-   return NULL;
+   goto err_allocs;
 
r->prop_id = prop.prop_id;
r->count_values = prop.count_values;
-- 
1.7.4.1

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

Re: [PATCHv2 21/22] drm/bridge: tc358767: add IRQ and HPD support

[Tomi Valkeinen]

Hi,

On 17/04/2019 10:32, Andrzej Hajda wrote:
> On 15.04.2019 12:59, Tomi Valkeinen wrote:
>> On 15/04/2019 13:42, Andrzej Hajda wrote:
>>
>>> Ok we have here 4 combinations:
>>>
>>> 1. noHPD + eDP.
>>>
>>> 2. noHPD + DP.
>>>
>>> 3. HPD + eDP.
>>>
>>> 4. HPD + DP.
>>>
>>>
>>> Which ones do you want to support, disallow. It is not clear to me.
>> They all should work.
>>
>> If there is HPD, we use it to return connected/disconnected.
> 
> 
> OK, I though that eDP does not use HPD at all.
> 
> 
>> If we don't have HPD:
>> - If there's a panel (i.e. eDP), we presume that it is always there, as
>> by definition it can't be disconnected.
>> - If there's no panel (i.e. DP), we can't know if the cable is connected
>> or not, so we return unknown. I think this could be improved by trying
>> to "ping" the monitor with an AUX transaction, but I didn't look at that.
>>
>>> Moreover what connector_status_unknown should mean here for users?
>> The the driver does not know if there's a monitor or not.
> 
> :)
> 
> More specifically, what user can do with such information.
> 
> OK, he can ensure monitor is connected and then force connected state.

Yes, something like that. I haven't really been testing that kind of
setups, but afaik, that's more about how DRM exposes and expects the
userspace to handle "unknown" connection status than what TC358767 does.

> But shall we expect existence of such configurations, I hoped we could
> eliminate such combination (DP+noHPD) during probe.

Eliminate how? Make HPD required for DP and fail if there's no HPD? I
guess that's an option.

Then again, the solutions the HW people come up with in the embedded
space never ceases to amaze me, so while I don't expect such
configurations, I would not be surprised to see one.

 +  if (tc->hpd_num >= 0 && tc->bridge.dev) {
 +  bool h = val & INT_GPIO_H(tc->hpd_num);
 +  bool lc = val & INT_GPIO_LC(tc->hpd_num);
 +
 +  dev_dbg(tc->dev, "GPIO%d: %s %s\n", tc->hpd_num,
 +  h ? "H" : "", lc ? "LC" : "");
>>>
>>> What does "h" and "lc" mean?
>> These are from the func spec. H means high, LC means low-counter. H is
>> triggered immediately when the HPD line goes high, LC is triggered when
>> the line has been low for the counter-specified time (the counter is
>> configured at probe time).
> 
> 
> It would be good to add this info somewhere, it is hard to guess what lc
> means.

Ok.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/komeda: Add writeback support

[james qian wang (Arm Technology China)]

From: "james qian wang (Arm Technology China)" 

Komeda driver uses a individual component to describe the HW's writeback
caps, but drivers doesn't define a new structure and still uses the
existing "struct komeda_layer" to describe this new component.
The detailed changes as follow:

1. Initialize wb_layer according to HW and report it to CORE.
2. CORE exposes wb_layer as a resource to KMS by private_obj.
3. Report writeback supporting by add a wb_connector to KMS, and then
   wb_connector will take act as a component resources user,
   so the func komeda_wb_encoder_atomic_check claims komeda resources
   (scaler and wb_layer) accroding to its state configuration to the
   wb_connector. and the wb_state configuration will be validated on the
   specific component resources to see if the caps of component can
   meet the requirement of wb_connector. if not check failed.
4. Update irq_handler to notify the completion of writeback.

NOTE:
This change doesn't add scaling writeback support, that support will
be added in the future after the scaler support.

v2: Rebase

Signed-off-by: James Qian Wang (Arm Technology China) 
---
 drivers/gpu/drm/arm/display/komeda/Makefile   |   1 +
 .../arm/display/komeda/d71/d71_component.c|  90 -
 .../gpu/drm/arm/display/komeda/komeda_crtc.c  |  15 ++
 .../arm/display/komeda/komeda_framebuffer.c   |  19 ++
 .../gpu/drm/arm/display/komeda/komeda_kms.c   |   4 +
 .../gpu/drm/arm/display/komeda/komeda_kms.h   |  27 +++
 .../drm/arm/display/komeda/komeda_pipeline.h  |   7 +
 .../display/komeda/komeda_pipeline_state.c|  51 -
 .../arm/display/komeda/komeda_private_obj.c   |   6 +
 .../arm/display/komeda/komeda_wb_connector.c  | 181 ++
 10 files changed, 398 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c

diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
b/drivers/gpu/drm/arm/display/komeda/Makefile
index 62bd1bff66a3..d7e29fc688c3 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -14,6 +14,7 @@ komeda-y := \
komeda_kms.o \
komeda_crtc.o \
komeda_plane.o \
+   komeda_wb_connector.o \
komeda_private_obj.o
 
 komeda-y += \
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 031e5f305a3c..1561806431eb 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -288,10 +288,98 @@ static int d71_layer_init(struct d71_dev *d71,
return 0;
 }
 
+static void d71_wb_layer_update(struct komeda_component *c,
+   struct komeda_component_state *state)
+{
+   struct komeda_layer_state *st = to_layer_st(state);
+   struct drm_connector_state *conn_st = state->wb_conn->state;
+   struct drm_framebuffer *fb = conn_st->writeback_job->fb;
+   struct komeda_fb *kfb = to_kfb(fb);
+   u32 __iomem *reg = c->reg;
+   u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
+   int i;
+
+   for (i = 0; i < fb->format->num_planes; i++) {
+   malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_LOW,
+  lower_32_bits(st->addr[i]));
+   malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_HIGH,
+  upper_32_bits(st->addr[i]));
+
+   malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_STRIDE,
+  fb->pitches[i] & 0x);
+   }
+
+   malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
+   malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
+   malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
+   malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
+}
+
+static void d71_wb_layer_dump(struct komeda_component *c, struct seq_file *sf)
+{
+   u32 v[12], i;
+
+   dump_block_header(sf, c->reg);
+
+   get_values_from_reg(c->reg, 0x80, 1, v);
+   seq_printf(sf, "LW_INPUT_ID0:\t\t0x%X\n", v[0]);
+
+   get_values_from_reg(c->reg, 0xD0, 3, v);
+   seq_printf(sf, "LW_CONTROL:\t\t0x%X\n", v[0]);
+   seq_printf(sf, "LW_PROG_LINE:\t\t0x%X\n", v[1]);
+   seq_printf(sf, "LW_FORMAT:\t\t0x%X\n", v[2]);
+
+   get_values_from_reg(c->reg, 0xE0, 1, v);
+   seq_printf(sf, "LW_IN_SIZE:\t\t0x%X\n", v[0]);
+
+   for (i = 0; i < 2; i++) {
+   get_values_from_reg(c->reg, 0x100 + i * 0x10, 3, v);
+   seq_printf(sf, "LW_P%u_PTR_LOW:\t\t0x%X\n", i, v[0]);
+   seq_printf(sf, "LW_P%u_PTR_HIGH:\t\t0x%X\n", i, v[1]);
+   seq_printf(sf, "LW_P%u_STRIDE:\t\t0x%X\n", i, v[2]);
+   }
+
+   get_values_from_reg(c->reg, 0x130, 12, v);
+   for (i = 0; i < 12; i++)
+   seq_printf(sf, "LW_RGB_YUV_COEFF%u:\t0x%X\n", i, v[i]);
+}
+
+static void d71

Re: [PATCH -next] drm/komeda: remove set but not used variable 'kcrtc'

[james qian wang (Arm Technology China)]

On Sat, Apr 27, 2019 at 12:42:02AM +0800, Yue Haibing wrote:
> From: YueHaibing 
> 
> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c: In function 
> komeda_plane_atomic_check:
> drivers/gpu/drm/arm/display/komeda/komeda_plane.c:49:22: warning: variable 
> kcrtc set but not used [-Wunused-but-set-variable]
> 
> It is never used since introduction in
> commit 7d31b9e7a550 ("drm/komeda: Add komeda_plane/plane_helper_funcs")
> 
> Signed-off-by: YueHaibing 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> index 07ed0cc..0753892 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> @@ -55,7 +55,6 @@ komeda_plane_atomic_check(struct drm_plane *plane,
>   struct komeda_plane_state *kplane_st = to_kplane_st(state);
>   struct komeda_layer *layer = kplane->layer;
>   struct drm_crtc_state *crtc_st;
> - struct komeda_crtc *kcrtc;
>   struct komeda_crtc_state *kcrtc_st;
>   struct komeda_data_flow_cfg dflow;
>   int err;
> @@ -73,7 +72,6 @@ komeda_plane_atomic_check(struct drm_plane *plane,
>   if (!crtc_st->active)
>   return 0;
>  
> - kcrtc = to_kcrtc(state->crtc);
>   kcrtc_st = to_kcrtc_st(crtc_st);
>  
>   err = komeda_plane_init_data_flow(state, &dflow);
> -- 
> 2.7.4
> 

Thank you for the patch.

Reviewed-by: James Qian Wang (Arm Technology China) 

@liviu:
Could you help to apply this patch to our tree.

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

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

[bugzilla-daemon]

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

--- Comment #18 from Jaap Buurman  ---
I was aware of that. I was more curious if the bug that is causing the crash
can be identified and hopefully fixed. I can provide traces if required, since
it seems I can easily reproduce the crash.

-- 
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 109955] amdgpu [RX Vega 64] system freeze while gaming

[bugzilla-daemon]

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

--- Comment #20 from Jaap Buurman  ---
I already run LLVM 8.0.0, since it's the latest stable in Arch's repository.
Thanks for the tip though :)

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

Re: [PATCH v7 6/6] drm/bridge: sii902x: Implement HDMI audio support

[Andrzej Hajda]

On 26.04.2019 15:23, Jyri Sarha wrote:
> Implement HDMI audio support by using ASoC HDMI codec. The commit
> implements the necessary callbacks and configuration for the HDMI
> codec and registers a virtual platform device for the codec to attach.
>
> Signed-off-by: Jyri Sarha 

Reviewed-by: Andrzej Hajda 

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

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

[bugzilla-daemon]

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

--- Comment #19 from Mauro Gaspari  ---
(In reply to Jaap Buurman from comment #15)
> That's bad to hear :( Worth a try though. How often do you experience
> freezes by the way? And is this for all games, or are some games completely
> stable? For me, I am getting crashes in Kerbal Space Program, but not in
> Final Fantasy XII or World of Warcraft, even after hundreds of hours in both
> of these stable games.
> 
> Also, have you ever figured out which kernel parameter in particular makes
> your setup stable? It might help identify where the problem exists. Or do
> you need that exact combination of all those parameters to get your system
> stable?

Hi, regarding the parameters I am using.
Unfortunately for me the issue is not easy to reproduce. Without the parameters
enabled, it still takes hours for a crash to happen. On top of that, mesa and
kernel updates are really frequent on Tumbleweed, that is another variable that
makes it a bit harder to troubleshoot. Unless I can find a really fast way to
reproduce the issue.

Regarding which game crash, with those kernel parameters applied, the only
crashes I noticed were when I tried to run games through Wine in DX11 mode with
DXVK. Which i believe to be stable on Vega GPUs, would need at least LLVM8.
Currently on my Tumbleweed I have LLVM7 so I just stick to NON-DXVK games, or
even better native ones, until LLVM8 is available for tumbleweed.

If you want to give it a try and you run on ubuntu, you can check this article:
https://github.com/lutris/lutris/wiki/Installing-drivers

If you do so, I recommend you run a full system backup using clonezilla or
similar software, those ppas are marked as unstable.

-- 
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 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3)

[Kazlauskas, Nicholas]

On 4/26/19 5:40 PM, Mario Kleiner wrote:
> Pre-DCE12 needs special treatment for BTR / low framerate
> compensation for more stable behaviour:
> 
> According to comments in the code and some testing on DCE-8
> and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
> programming with a lag of one frame, so the special BTR hw
> programming for intermediate fixed duration frames must be
> done inside the current frame at flip submission in atomic
> commit tail, ie. one vblank earlier, and the fixed refresh
> intermediate frame mode must be also terminated one vblank
> earlier on pre-DCE12 display engines.
> 
> To achieve proper termination on < DCE-12 shift the point
> when the switch-back from fixed vblank duration to variable
> vblank duration happens from the start of VBLANK (vblank irq,
> as done on DCE-12+) to back-porch or end of VBLANK (handled
> by vupdate irq handler). We must leave the switch-back code
> inside VBLANK irq for DCE12+, as before.
> 
> Doing this, we get much better behaviour of BTR for up-sweeps,
> ie. going from short to long frame durations (~high to low fps)
> and for constant framerate flips, as tested on DCE-8 and
> DCE-11. Behaviour is still not quite as good as on DCN-1
> though.
> 
> On down-sweeps, going from long to short frame durations
> (low fps to high fps) < DCE-12 is a little bit improved,
> although by far not as much as for up-sweeps and constant
> fps.
> 
> v2: Fix some wrong locking, as pointed out by Nicholas.
> v3: Simplify if-condition in vupdate-irq - nit by Nicholas.
> Signed-off-by: Mario Kleiner 

Reviewed-by: Nicholas Kazlauskas 

I'd like to push patches 1+3 if you're okay with this.

I can see the value in the 2nd patch from the graphs and test 
application you've posted but it'll likely take some time to do thorough 
review and testing on this.

The question that needs to be examined with the second is what the 
optimal margin is, if any, for typical usecases across common monitor 
ranges. Not all monitors that support BTR have the same range, and many 
have a lower bound of ~48Hz. To me ~53Hz sounds rather early to be 
entering, but I'm not sure how it affects the user experience overall.

Nicholas Kazlauskas

> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 48 +--
>   1 file changed, 44 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 76b6e621793f..92b3c2cec7dd 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -364,6 +364,7 @@ static void dm_vupdate_high_irq(void *interrupt_params)
>   struct amdgpu_device *adev = irq_params->adev;
>   struct amdgpu_crtc *acrtc;
>   struct dm_crtc_state *acrtc_state;
> + unsigned long flags;
>   
>   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_VUPDATE);
>   
> @@ -379,8 +380,25 @@ static void dm_vupdate_high_irq(void *interrupt_params)
>* page-flip completion events that have been queued to us
>* if a pageflip happened inside front-porch.
>*/
> - if (amdgpu_dm_vrr_active(acrtc_state))
> + if (amdgpu_dm_vrr_active(acrtc_state)) {
>   drm_crtc_handle_vblank(&acrtc->base);
> +
> + /* BTR processing for pre-DCE12 ASICs */
> + if (acrtc_state->stream &&
> + adev->family < AMDGPU_FAMILY_AI) {
> + spin_lock_irqsave(&adev->ddev->event_lock, 
> flags);
> + mod_freesync_handle_v_update(
> + adev->dm.freesync_module,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params);
> +
> + dc_stream_adjust_vmin_vmax(
> + adev->dm.dc,
> + acrtc_state->stream,
> + &acrtc_state->vrr_params.adjust);
> + spin_unlock_irqrestore(&adev->ddev->event_lock, 
> flags);
> + }
> + }
>   }
>   }
>   
> @@ -390,6 +408,7 @@ static void dm_crtc_high_irq(void *interrupt_params)
>   struct amdgpu_device *adev = irq_params->adev;
>   struct amdgpu_crtc *acrtc;
>   struct dm_crtc_state *acrtc_state;
> + unsigned long flags;
>   
>   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_VBLANK);
>   
> @@ -412,9 +431,10 @@ static void dm_crtc_high_irq(void *interrupt_params)
>*/
>   amdgpu_dm_crtc_handle_crc_irq(&acrtc->base);
>   
> - if (acrtc_state->stream &&
> + if (acrtc_state->stream && adev->family >= AMDGPU_FAMILY_AI &&
>   acrtc_state->vrr_params.supported &&
>   acrtc_state->freesync_config.s

[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering

[bugzilla-daemon]

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

--- Comment #31 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
With the third patch in that series the bug should be fixed (ncorrect IRQ
handling for older ASICs). I imagine it'll be merged soon.

You'll still likely see minor luminance flickering when you're going from a
relatively framerate (short front porch duration) to low framerate (long front
porch duration).

It depends on the panel characteristics for the display and supported VRR
range, however. Not all displays will exhibit the same luminance delta between
min and max front porch duration.

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

[Bug 110509] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout

[bugzilla-daemon]

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

--- Comment #6 from james.dut...@gmail.com ---
I think I have found the problem.
[  657.526313] amdgpu :43:00.0: GPU reset begin!
[  657.526318] Evicting PASID 32782 queues
[  667.756000] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* [CRTC:49:crtc-0]
hw_done or flip_done timed out


The intention is to do a GPU reset, but the implementation in the code is just
to try and do a suspend.
Part of the suspend does this:

Apr 29 14:29:19 thread kernel: [  363.445607] INFO: task kworker/u258:0:55
blocked for more than 120 seconds.
Apr 29 14:29:19 thread kernel: [  363.445612]   Not tainted 5.0.10-dirty
#26
Apr 29 14:29:19 thread kernel: [  363.445613] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 29 14:29:19 thread kernel: [  363.445615] kworker/u258:0  D055 
2 0x8000
Apr 29 14:29:19 thread kernel: [  363.445628] Workqueue: events_unbound
commit_work [drm_kms_helper]
Apr 29 14:29:19 thread kernel: [  363.445629] Call Trace:
Apr 29 14:29:19 thread kernel: [  363.445635]  __schedule+0x2c0/0x880
Apr 29 14:29:19 thread kernel: [  363.445637]  schedule+0x2c/0x70
Apr 29 14:29:19 thread kernel: [  363.445639]  schedule_timeout+0x1db/0x360
Apr 29 14:29:19 thread kernel: [  363.445641]  ? update_load_avg+0x8b/0x590
Apr 29 14:29:19 thread kernel: [  363.445645] 
dma_fence_default_wait+0x1eb/0x270
Apr 29 14:29:19 thread kernel: [  363.445647]  ? dma_fence_release+0xa0/0xa0
Apr 29 14:29:19 thread kernel: [  363.445649] 
dma_fence_wait_timeout+0xfd/0x110
Apr 29 14:29:19 thread kernel: [  363.445651] 
reservation_object_wait_timeout_rcu+0x17d/0x370
Apr 29 14:29:19 thread kernel: [  363.445710]  amdgpu_dm_do_flip+0x14a/0x4a0
[amdgpu]
Apr 29 14:29:19 thread kernel: [  363.445767] 
amdgpu_dm_atomic_commit_tail+0x7b7/0xc10 [amdgpu]
Apr 29 14:29:19 thread kernel: [  363.445820]  ?
amdgpu_dm_atomic_commit_tail+0x7b7/0xc10 [amdgpu]
Apr 29 14:29:19 thread kernel: [  363.445828]  commit_tail+0x42/0x70
[drm_kms_helper]
Apr 29 14:29:19 thread kernel: [  363.445835]  commit_work+0x12/0x20
[drm_kms_helper]
Apr 29 14:29:19 thread kernel: [  363.445838]  process_one_work+0x1fd/0x400
Apr 29 14:29:19 thread kernel: [  363.445840]  worker_thread+0x34/0x410
Apr 29 14:29:19 thread kernel: [  363.445841]  kthread+0x121/0x140
Apr 29 14:29:19 thread kernel: [  363.445843]  ? process_one_work+0x400/0x400
Apr 29 14:29:19 thread kernel: [  363.445844]  ? kthread_park+0x90/0x90
Apr 29 14:29:19 thread kernel: [  363.445847]  ret_from_fork+0x22/0x40


So, amggpu_dm_do_flip()  is the bit that hangs.
If the GPU needs to be reset because some of it has hung, trying a "flip" is
unlikely to work.
It is failing/hanging when doing "suspend of IP block " in
amdgpu_device_ip_suspend_phase1().

I would suggest creating code that actually tries to reset the GPU, instead of
trying to suspend it while GPU is hung.

-- 
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 109955] amdgpu [RX Vega 64] system freeze while gaming

[bugzilla-daemon]

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

--- Comment #21 from Mauro Gaspari  ---
(In reply to Jaap Buurman from comment #20)
> I already run LLVM 8.0.0, since it's the latest stable in Arch's repository.
> Thanks for the tip though :)

Since it is very easy for you to reproduce the freeze, it would be great if you
could add those kernel parameters, and see if they help.

-- 
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 108893] Slow redrawing of menu in Gothic 2 under wine

[bugzilla-daemon]

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

--- Comment #6 from andrew.m.mcma...@gmail.com ---
I can't replicate any performance issues with Gothic 2 Gold on my setup.

I'm using the latest installer provided by GOG:
> setup_gothic_2_gold_2.7_(14553).exe
I'm installing the game into a clean wine 4.7-devel prefix by using:
> WINEPREFIX=~/.wineprefix/gothic2 wine setup_gothic_2_gold_2.7_(14553).exe
The game will crash at the main menu without directmusic. 
Latest winetricks (github) can handle that:
> WINEPREFIX=~/.wineprefix/gothic2 winetricks directmusic
Then I'm just running the game normally via the desktop shortcut that's
automatically created.

I've recorded a video with SimpleScreenRecorder of the game running @ 1440x900
in wine's virtual desktop. I've got MESA_HUD enabled so you can see my
framerate and other info:
https://drive.google.com/file/d/11t2akNusJh0hvaNEftV_oLbLd9lnozYX/view?usp=sharing

Phenom II x4 955
Debian Testing
OpenGL renderer string: AMD Radeon R9 200 Series (TONGA, DRM 3.30.0,
5.1.0-rc7-mainline-amd64, LLVM 8.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.0-devel
(git-812288bf0f)
Wine-devel 4.7

-- 
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 109345] drm-next-2018-12-14 -Linux PPC

[bugzilla-daemon]

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

--- Comment #12 from Christian Zigotzky  ---
Any news? The issue still exists with the kernel 5.1-RC7.

-- 
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 v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

[Grodzovsky, Andrey]

Thanks David, with that only patches 5 and 6 are left for the series to be 
reviewed.

Christian, any more comments on those patches ?

Andrey

On 4/27/19 10:56 PM, Zhou, David(ChunMing) wrote:
Sorry, I only can put my Acked-by: Chunming Zhou 
 on patch#3.

I cannot fully judge patch #4, #5, #6.

-David

From: amd-gfx 

 On Behalf Of Grodzovsky, Andrey
Sent: Friday, April 26, 2019 10:09 PM
To: Koenig, Christian 
; Zhou, 
David(ChunMing) ; 
dri-devel@lists.freedesktop.org; 
amd-...@lists.freedesktop.org; 
e...@anholt.net; 
etna...@lists.freedesktop.org
Cc: Kazlauskas, Nicholas 
; Liu, Monk 

Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.


Ping (mostly David and Monk).

Andrey
On 4/24/19 3:09 AM, Christian König wrote:
Am 24.04.19 um 05:02 schrieb Zhou, David(ChunMing):
>> -drm_sched_stop(&ring->sched, &job->base);
>> -
>>   /* after all hw jobs are reset, hw fence is meaningless, so 
>> force_completion */
>>   amdgpu_fence_driver_force_completion(ring);
>>   }

HW fence are already forced completion, then we can just disable irq fence 
process and ignore hw fence signal when we are trying to do GPU reset, I think. 
Otherwise which will make the logic much more complex.
If this situation happens because of long time execution, we can increase 
timeout of reset detection.

You are not thinking widely enough, forcing the hw fence to complete can 
trigger other to start other activity in the system.

We first need to stop everything and make sure that we don't do any processing 
any more and then start with our reset procedure including forcing all hw 
fences to complete.

Christian.



-David

From: amd-gfx 

 On Behalf Of Grodzovsky, Andrey
Sent: Wednesday, April 24, 2019 12:00 AM
To: Zhou, David(ChunMing) ; 
dri-devel@lists.freedesktop.org; 
amd-...@lists.freedesktop.org; 
e...@anholt.net; 
etna...@lists.freedesktop.org; 
ckoenig.leichtzumer...@gmail.com
Cc: Kazlauskas, Nicholas 
; Liu, Monk 

Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.


No, i mean the actual HW fence which signals when the job finished execution on 
the HW.

Andrey
On 4/23/19 11:19 AM, Zhou, David(ChunMing) wrote:
do you mean fence timer? why not stop it as well when stopping sched for the 
reason of hw reset?

 Original Message 
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already 
signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)" 
,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,e...@anholt.net,etna...@lists.freedesktop.org,ckoenig.leichtzumer...@gmail.com
CC: "Kazlauskas, Nicholas" ,"Liu, Monk"

On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if the job is already
> set to guilty? set it wrongly?
>
>
> -David


It's possible that the job does completes at a later time then it's
timeout handler started processing so in this patch we try to protect
against this by rechecking the HW fence after stopping all SW
schedulers. We do it BEFORE marking guilty on the job's sched_entity so
at the point we check the guilty flag is not set yet.

Andrey


>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> Also reject TDRs if another one already running.
>>
>> v2:
>> Stop all schedulers across device and entire XGMI hive before
>> force signaling HW fences.
>> Avoid passing job_signaled to helper fnctions to keep all the decision
>> making about skipping HW reset in one place.
>>
>> v3:
>> Fix SW sched. hang after non HW reset. sched.hw_rq_count has to be balanced
>> against it's decrement in drm_sched_stop in non HW reset case.
>> v4: rebase
>> v5: Revert v3 as we do it now in sceduler code.
>>
>> Signed-off-by: Andrey Grodzovsky 
>> 
>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 143 
>> +++--
>>1 file changed, 95 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index a

[Bug 109345] drm-next-2018-12-14 -Linux PPC

[bugzilla-daemon]

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

--- Comment #13 from Michel Dänzer  ---
(In reply to Christian Zigotzky from comment #12)
> Any news? The issue still exists with the kernel 5.1-RC7.

I wouldn't expect anything to happen without the result of git bisect.

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

Re: [PATCH 3/3] drm/amd/display: Compensate for pre-DCE12 BTR-VRR hw limitations. (v3)

[Mario Kleiner]

On Mon, Apr 29, 2019 at 2:51 PM Kazlauskas, Nicholas
 wrote:
>
> On 4/26/19 5:40 PM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some testing on DCE-8
> > and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
> > programming with a lag of one frame, so the special BTR hw
> > programming for intermediate fixed duration frames must be
> > done inside the current frame at flip submission in atomic
> > commit tail, ie. one vblank earlier, and the fixed refresh
> > intermediate frame mode must be also terminated one vblank
> > earlier on pre-DCE12 display engines.
> >
> > To achieve proper termination on < DCE-12 shift the point
> > when the switch-back from fixed vblank duration to variable
> > vblank duration happens from the start of VBLANK (vblank irq,
> > as done on DCE-12+) to back-porch or end of VBLANK (handled
> > by vupdate irq handler). We must leave the switch-back code
> > inside VBLANK irq for DCE12+, as before.
> >
> > Doing this, we get much better behaviour of BTR for up-sweeps,
> > ie. going from short to long frame durations (~high to low fps)
> > and for constant framerate flips, as tested on DCE-8 and
> > DCE-11. Behaviour is still not quite as good as on DCN-1
> > though.
> >
> > On down-sweeps, going from long to short frame durations
> > (low fps to high fps) < DCE-12 is a little bit improved,
> > although by far not as much as for up-sweeps and constant
> > fps.
> >
> > v2: Fix some wrong locking, as pointed out by Nicholas.
> > v3: Simplify if-condition in vupdate-irq - nit by Nicholas.
> > Signed-off-by: Mario Kleiner 
>
> Reviewed-by: Nicholas Kazlauskas 
>

Thanks.

> I'd like to push patches 1+3 if you're okay with this.
>

Yes please! I'd love to have these in Linux 5.2, so that would be the
first well suitable kernel to target for my specific VRR use cases.

> I can see the value in the 2nd patch from the graphs and test
> application you've posted but it'll likely take some time to do thorough
> review and testing on this.
>

I understand.

> The question that needs to be examined with the second is what the
> optimal margin is, if any, for typical usecases across common monitor
> ranges. Not all monitors that support BTR have the same range, and many
> have a lower bound of ~48Hz. To me ~53Hz sounds rather early to be
> entering, but I'm not sure how it affects the user experience overall.
>

That's indeed a tricky tuning problem and i didn't spend much thought
on that. Just took the BTR_EXIT_MARGIN already defined as 2 msecs,
because it was conveniently there for the exit path and this way it
was nicely symmetric to the BTR exit path. 1 msec or less might just
be as good, or something more fancy and adaptive. But most value comes
from patch 3/3 anyway.

Atm. i don't have a Freesync capable display at all, so i don't know
how well this patch works out wrt. flicker etc, i can only look at my
plots and the output of the kms_vrr igt test. I just hacked the driver
to accept any DP or HDMI display as VRR capable, so i can run the
synthetic timing tests blindly (A G-Sync display mostly goes blank or
tells me a sad "Out of range signal" on its OSD, a HDMI->VGA connected
CRT monitor cycles between "Out of range", black, and some heavily
distorted image). The G-Sync display has a 30 - 144 Hz range and my
faking patch even set a range 25 - 144 Hz for most tests.

I also thought about sending my "fake VRR display" patch after
cleaning it up. I could add some amdgpu module parameter, e.g., bool
amdgpu.fakevrroutput,
that if set to 1 would allow the driver to accept any DP/HDMI display
as VRR capable, parsing the VRR range from EDID if present (that works
for G-Sync displays) or just faking a range like 30 - 144 Hz or
whatever is realistic? A blanked out display is boring to look at, but
at least it allows to run timing tests or the IGT kms_vrr tests
without the need for a dedicated FreeSync display.

From reading on the web I understand that "FreeSync2 HDR" displays are
also HDR capable and go through some testing and certification at AMD
wrt. to minimal flicker? Would you have some recommendation or
pointers to a display i could buy if i needed a large VRR range,
minimal flicker and also good HDR capabilities - ideally with locally
dimmable backlight or such? I will probably have the money to buy one
FreeSync display, but that should also be useable for working on HDR
related stuff.

Thanks,
-mario

> Nicholas Kazlauskas
>
> > ---
> >   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 48 +--
> >   1 file changed, 44 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 76b6e621793f..92b3c2cec7dd 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -364,

Re: [Spice-devel] [PATCH] Revert "drm/qxl: drop prime import/export callbacks"

[Gerd Hoffmann]

  Hi,

> > More useful would be some way to signal this self-reimport capability
> > to userspace somehow.  See DRM_PRIME_CAP_LOCAL patch.
> 
> Userspace is supposed to test whether import/export works for a
> specific combo, not blindly assume it does and then keel over. I think
> we need to fix that, not add more flags - there's lots of reasons why
> a given pair of devices can't share buffers (e.g. all the contiguous
> allocations stuff on socs).

Ok.  Lets scratch the DRM_PRIME_CAP_LOCAL idea then and blame userspace
instead.

> > Right now I have the choice to set DRM_PRIME_CAP_{IMPORT,EXPORT}, in
> > which case some userspace assumes it can do cross-driver export/import
> > and trips over that not working.  Or I do not set
> > DRM_PRIME_CAP_{IMPORT,EXPORT}, which breaks DRI3 ...
> 
> Yeah that's not an option.

Good.  Can I get an ack for this patch then, as it unbreaks DRI3 with qxl?

thanks,
  Gerd

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

[PATCH v3 03/19] drm: Add |struct drm_gem_vram_object| callbacks for |struct drm_driver|

[Thomas Zimmermann]

The provided helpers can be used for the respective callback functions
in |struct drm_driver|.

v2:
* documentation fixes

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 48 +++
 include/drm/drm_gem_vram_helper.h | 10 ++
 2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index fcf6e78d92f7..31bf6c1079b0 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -458,3 +458,51 @@ int drm_gem_vram_bo_driver_verify_access(struct 
ttm_buffer_object *bo,
  filp->private_data);
 }
 EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
+
+/*
+ * Helpers for struct drm_driver
+ */
+
+/**
+ * drm_gem_vram_driver_gem_free_object_unlocked() - \
+   Implements &struct drm_driver.gem_free_object_unlocked
+ * @gem:   GEM object. Refers to &struct drm_gem_vram_object.gem
+ */
+void drm_gem_vram_driver_gem_free_object_unlocked(struct drm_gem_object *gem)
+{
+   struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
+   drm_gem_vram_put(gbo);
+}
+EXPORT_SYMBOL(drm_gem_vram_driver_gem_free_object_unlocked);
+
+/**
+ * drm_gem_vram_driver_dumb_mmap_offset() - \
+   Implements &struct drm_driver.dumb_mmap_offset
+ * @file:  DRM file pointer.
+ * @dev:   DRM device.
+ * @handle:GEM handle
+ * @offset:Returns the mapping's memory offset on success
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative errno code otherwise.
+ */
+int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file *file,
+struct drm_device *dev,
+uint32_t handle, uint64_t *offset)
+{
+   struct drm_gem_object *gem;
+   struct drm_gem_vram_object *gbo;
+
+   gem = drm_gem_object_lookup(file, handle);
+   if (!gem)
+   return -ENOENT;
+
+   gbo = drm_gem_vram_of_gem(gem);
+   *offset = drm_gem_vram_mmap_offset(gbo);
+
+   drm_gem_object_put_unlocked(gem);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
diff --git a/include/drm/drm_gem_vram_helper.h 
b/include/drm/drm_gem_vram_helper.h
index 4872edb09fe9..99982590e32a 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -99,4 +99,14 @@ void drm_gem_vram_bo_driver_evict_flags(struct 
ttm_buffer_object *bo,
 int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
 struct file *filp);
 
+/*
+ * Helpers for struct drm_driver
+ */
+
+void drm_gem_vram_driver_gem_free_object_unlocked(struct drm_gem_object *gem);
+
+int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file *file,
+struct drm_device *dev,
+uint32_t handle, uint64_t *offset);
+
 #endif
-- 
2.21.0

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

[PATCH v3 00/19] Share TTM code among DRM framebuffer drivers

[Thomas Zimmermann]

Several simple framebuffer drivers copy most of the TTM code from each
other. The implementation is always the same; except for the name of
some data structures.

As recently discussed, this patch set provides generic memory-management
code for simple framebuffers with dedicated video memory. It further
converts the respective drivers to the generic code. The shared code
is basically the same implementation as the one copied among individual
drivers.

The patch set contains two major changes: first, it introduces
|struct drm_gem_vram_object| and helpers (GEM VRAM). It's a GEM object
that is backed by VRAM. The type's purpose is somewhat similar to
|struct drm_gem_{cma, shmem}_object|: it provides an commom implementation
that handles all the basic cases. Second, the patch set introduces
|struct drm_vram_mm| and helpers (VRAM MM). It's an implementation of a
basic memory manager for VRAM.

Both, GEM VRAM and VRAM MM, support buffer placement in VRAM and system
memory. Both can be used independedly from each other if desired by the
DRM driver.

Currently ast, bochs, mgag200, vboxvideo and hisilicon/hibmc can use
these helpers.

Future directions: with these changes, the respective drivers can also
share some of their mode-setting or fbdev code. GEM VRAM could implement
PRIME helpers, which would allow for using the generic fbcon.

The patch set is against a recent drm-tip.

v3:
* share VRAM MM callback structure among drivers
* move VRAM MM instances to drm_device and share rsp. code
v2:
* rename |struct drm_gem_ttm_object| to |struct drm_gem_vram_object|
* rename |struct drm_simple_ttm| to |struct drm_vram_mm|
* make drm_is_gem_ttm() an internal helper
* add drm_gem_vram_kmap_at()
* return is_iomem from kmap functions
* redefine TTM placement flags for public interface
* add drm_vram_mm_mmap() helper
* replace almost all of driver's TTM code with these helpers
* documentation fixes

Thomas Zimmermann (19):
  drm: Add |struct drm_gem_vram_object| and helpers
  drm: Add |struct drm_gem_vram_object| callbacks for |struct
ttm_bo_driver|
  drm: Add |struct drm_gem_vram_object| callbacks for |struct
drm_driver|
  drm: Add drm_gem_vram_fill_create_dumb() to create dumb buffers
  drm: Add VRAM MM, a simple memory manager for dedicated VRAM
  drm: Add default instance for VRAM MM callback functions
  drm: Integrate VRAM MM into struct drm_device
  drm/ast: Convert AST driver to |struct drm_gem_vram_object|
  drm/ast: Convert AST driver to VRAM MM
  drm/ast: Replace mapping code with drm_gem_vram_{kmap/kunmap}()
  drm/bochs: Convert bochs driver to |struct drm_gem_vram_object|
  drm/bochs: Convert bochs driver to VRAM MM
  drm/mgag200: Convert mgag200 driver to |struct drm_gem_vram_object|
  drm/mgag200: Convert mgag200 driver to VRAM MM
  drm/mgag200: Replace mapping code with drm_gem_vram_{kmap/kunmap}()
  drm/vboxvideo: Convert vboxvideo driver to |struct
drm_gem_vram_object|
  drm/vboxvideo: Convert vboxvideo driver to VRAM MM
  drm/hisilicon: Convert hibmc-drm driver to |struct
drm_gem_vram_object|
  drm/hisilicon: Convert hibmc-drm driver to VRAM MM

 Documentation/gpu/drm-mm.rst  |  25 +-
 drivers/gpu/drm/Kconfig   |  20 +
 drivers/gpu/drm/Makefile  |   5 +
 drivers/gpu/drm/ast/Kconfig   |   3 +-
 drivers/gpu/drm/ast/ast_drv.c |  13 +-
 drivers/gpu/drm/ast/ast_drv.h |  71 +-
 drivers/gpu/drm/ast/ast_fb.c  |  30 +-
 drivers/gpu/drm/ast/ast_main.c|  77 +--
 drivers/gpu/drm/ast/ast_mode.c| 124 ++--
 drivers/gpu/drm/ast/ast_ttm.c | 302 +
 drivers/gpu/drm/bochs/Kconfig |   2 +
 drivers/gpu/drm/bochs/bochs.h |  47 +-
 drivers/gpu/drm/bochs/bochs_drv.c |  13 +-
 drivers/gpu/drm/bochs/bochs_kms.c |  18 +-
 drivers/gpu/drm/bochs/bochs_mm.c  | 408 +---
 drivers/gpu/drm/drm_gem_vram_helper.c | 612 ++
 drivers/gpu/drm/drm_vram_helper_common.c  |   6 +
 drivers/gpu/drm/drm_vram_mm_helper.c  | 278 
 drivers/gpu/drm/hisilicon/hibmc/Kconfig   |   2 +
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c|  21 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  13 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |  33 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  30 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c   | 341 +-
 drivers/gpu/drm/mgag200/Kconfig   |   2 +
 drivers/gpu/drm/mgag200/mgag200_cursor.c  |  88 +--
 drivers/gpu/drm/mgag200/mgag200_drv.c |  13 +-
 drivers/gpu/drm/mgag200/mgag200_drv.h |  74 +--
 drivers/gpu/drm/mgag200/mgag200_fb.c  |  30 +-
 drivers/gpu/drm/mgag200/mgag200_main.c|  87 +--
 drivers/gpu/drm/mgag200/mgag200_mode.c|  52 +-
 drivers/g

[PATCH v3 02/19] drm: Add |struct drm_gem_vram_object| callbacks for |struct ttm_bo_driver|

[Thomas Zimmermann]

The provided helpers can be used for the respective callback functions
in |struct ttm_bo_driver|.

v2:
* drm_is_gem_vram() is now a private function
* documentation fixes

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 50 +++
 include/drm/drm_gem_vram_helper.h | 10 ++
 2 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index d39d8a5f36df..fcf6e78d92f7 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -408,3 +408,53 @@ void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
drm_gem_vram_kunmap_at(gbo, &gbo->kmap);
 }
 EXPORT_SYMBOL(drm_gem_vram_kunmap);
+
+/*
+ * Helpers for struct ttm_bo_driver
+ */
+
+static bool drm_is_gem_vram(struct ttm_buffer_object *bo)
+{
+   return (bo->destroy == ttm_buffer_object_destroy);
+}
+
+/**
+ * drm_gem_vram_bo_driver_evict_flags() - \
+   Implements &struct ttm_bo_driver.evict_flags
+ * @bo:TTM buffer object. Refers to &struct drm_gem_vram_object.bo
+ * @pl:TTM placement information.
+ */
+void drm_gem_vram_bo_driver_evict_flags(struct ttm_buffer_object *bo,
+   struct ttm_placement *pl)
+{
+   struct drm_gem_vram_object *gbo;
+
+   /* TTM may pass BOs that are not GEM VRAM BOs. */
+   if (!drm_is_gem_vram(bo))
+   return;
+
+   gbo = drm_gem_vram_of_bo(bo);
+   drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM);
+   *pl = gbo->placement;
+}
+EXPORT_SYMBOL(drm_gem_vram_bo_driver_evict_flags);
+
+/**
+ * drm_gem_vram_bo_driver_verify_access() - \
+   Implements &struct ttm_bo_driver.verify_access
+ * @bo:TTM buffer object. Refers to &struct 
drm_gem_vram_object.bo
+ * @filp:  File pointer.
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative errno code otherwise.
+ */
+int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
+struct file *filp)
+{
+   struct drm_gem_vram_object *gbo = drm_gem_vram_of_bo(bo);
+
+   return drm_vma_node_verify_access(&gbo->gem.vma_node,
+ filp->private_data);
+}
+EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
diff --git a/include/drm/drm_gem_vram_helper.h 
b/include/drm/drm_gem_vram_helper.h
index 167616f552e5..4872edb09fe9 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -89,4 +89,14 @@ void drm_gem_vram_kunmap_at(struct drm_gem_vram_object *gbo,
struct ttm_bo_kmap_obj *kmap);
 void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo);
 
+/*
+ * Helpers for struct ttm_bo_driver
+ */
+
+void drm_gem_vram_bo_driver_evict_flags(struct ttm_buffer_object *bo,
+   struct ttm_placement *pl);
+
+int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
+struct file *filp);
+
 #endif
-- 
2.21.0

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

[PATCH v3 05/19] drm: Add VRAM MM, a simple memory manager for dedicated VRAM

[Thomas Zimmermann]

The VRAM MM memory manager is a helper library that manages dedicated video
memory of simple framebuffer devices. It is supported to be used with
struct drm_gem_vram_object, but does not depend on it.

The implementation is based on the respective code from ast, bochs, and
mgag200. These drivers share the exact same implementation except for type
names. The helpers are currently build with TTM. This may change in future
revisions.

v2:
* renamed to struct drm_vram_mm
* add drm_vram_mm_mmap() helper
* documentation fixes

Signed-off-by: Thomas Zimmermann 
---
 Documentation/gpu/drm-mm.rst |  13 +-
 drivers/gpu/drm/Kconfig  |   7 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_vram_mm_helper.c | 210 +++
 include/drm/drm_vram_mm_helper.h |  67 +
 5 files changed, 297 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_vram_mm_helper.c
 create mode 100644 include/drm/drm_vram_mm_helper.h

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index d5327ed608d7..a6ce10675638 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -79,7 +79,6 @@ count for the TTM, which will call your initialization 
function.
 
 See the radeon_ttm.c file for an example of usage.
 
-
 The Graphics Execution Manager (GEM)
 
 
@@ -392,6 +391,18 @@ GEM VRAM Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
:export:
 
+VRAM MM Helper Functions Reference
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_vram_mm_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
+   :export:
+
 VMA Offset Manager
 ==
 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c0d49a6c09d2..c122f2d843ce 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -166,6 +166,13 @@ config DRM_VRAM_HELPER
help
  Helpers for VRAM memory management
 
+config DRM_VRAM_MM_HELPER
+   tristate
+   depends on DRM && DRM_TTM
+   select DRM_VRAM_HELPER
+   help
+ Choose this if you need the VRAM MM helper functions
+
 config DRM_GEM_CMA_HELPER
bool
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index dbe38fe1bcb3..063c22b25fa8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -34,6 +34,7 @@ drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 
 drm_vram_helper-y := drm_vram_helper_common.o
 drm_vram_helper-$(CONFIG_DRM_GEM_VRAM_HELPER) += drm_gem_vram_helper.o
+drm_vram_helper-$(CONFIG_DRM_VRAM_MM_HELPER) += drm_vram_mm_helper.o
 obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o 
drm_probe_helper.o \
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c 
b/drivers/gpu/drm/drm_vram_mm_helper.c
new file mode 100644
index ..d19f46d7a4e7
--- /dev/null
+++ b/drivers/gpu/drm/drm_vram_mm_helper.c
@@ -0,0 +1,210 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include 
+#include 
+#include 
+
+/**
+ * DOC: overview
+ *
+ * The data structure &struct drm_vram_mm and its helpers implement a memory
+ * manager for simple framebuffer devices with dedicated video memory. Buffer
+ * object s are either placed in VRAM or evicted to system ram. The functions
+ * work well with &struct drm_gem_vram_object.
+ */
+
+/*
+ * TTM TT
+ */
+
+static void backend_func_destroy(struct ttm_tt *tt)
+{
+   ttm_tt_fini(tt);
+   kfree(tt);
+}
+
+static struct ttm_backend_func backend_func = {
+   .destroy = backend_func_destroy
+};
+
+/*
+ * TTM BO device
+ */
+
+static struct ttm_tt *bo_driver_ttm_tt_create(struct ttm_buffer_object *bo,
+ uint32_t page_flags)
+{
+   struct ttm_tt *tt;
+   int ret;
+
+   tt = kzalloc(sizeof(*tt), GFP_KERNEL);
+   if (!tt)
+   return NULL;
+
+   tt->func = &backend_func;
+
+   ret = ttm_tt_init(tt, bo, page_flags);
+   if (ret < 0)
+   goto err_ttm_tt_init;
+
+   return tt;
+
+err_ttm_tt_init:
+   kfree(tt);
+   return NULL;
+}
+
+static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
+  struct ttm_mem_type_manager *man)
+{
+   switch (type) {
+   case TTM_PL_SYSTEM:
+   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->available_caching = TTM_PL_MASK_CACHING;
+   man->default_caching = TTM_PL_FLAG_CACHED;
+   break;
+   case TTM_PL_VRAM:
+   man->func = &ttm_bo_manager_func;
+   man->flags = TTM_MEMTYPE_FLAG_FIXED |
+TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->available_caching = TTM_PL_FLAG_U

[PATCH v3 11/19] drm/bochs: Convert bochs driver to |struct drm_gem_vram_object|

[Thomas Zimmermann]

The data structure |struct drm_gem_vram_object| and its helpers replace
|struct bochs_bo|. It's the same implementation; except for the type
names.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/bochs/Kconfig |   1 +
 drivers/gpu/drm/bochs/bochs.h |  34 +---
 drivers/gpu/drm/bochs/bochs_drv.c |   4 +-
 drivers/gpu/drm/bochs/bochs_kms.c |  18 +-
 drivers/gpu/drm/bochs/bochs_mm.c  | 270 +++---
 5 files changed, 34 insertions(+), 293 deletions(-)

diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig
index bd2718015cdb..c04f8041a2b9 100644
--- a/drivers/gpu/drm/bochs/Kconfig
+++ b/drivers/gpu/drm/bochs/Kconfig
@@ -3,6 +3,7 @@ config DRM_BOCHS
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
select DRM_TTM
+   select DRM_GEM_VRAM_HELPER
help
  Choose this option for qemu.
  If M is selected the module will be called bochs-drm.
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 341cc9d1bab4..4ccf82e1ca68 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -10,6 +10,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -81,30 +82,6 @@ struct bochs_device {
} ttm;
 };
 
-struct bochs_bo {
-   struct ttm_buffer_object bo;
-   struct ttm_placement placement;
-   struct ttm_bo_kmap_obj kmap;
-   struct drm_gem_object gem;
-   struct ttm_place placements[3];
-   int pin_count;
-};
-
-static inline struct bochs_bo *bochs_bo(struct ttm_buffer_object *bo)
-{
-   return container_of(bo, struct bochs_bo, bo);
-}
-
-static inline struct bochs_bo *gem_to_bochs_bo(struct drm_gem_object *gem)
-{
-   return container_of(gem, struct bochs_bo, gem);
-}
-
-static inline u64 bochs_bo_mmap_offset(struct bochs_bo *bo)
-{
-   return drm_vma_node_offset_addr(&bo->bo.vma_node);
-}
-
 /* -- */
 
 /* bochs_hw.c */
@@ -124,17 +101,8 @@ int bochs_mm_init(struct bochs_device *bochs);
 void bochs_mm_fini(struct bochs_device *bochs);
 int bochs_mmap(struct file *filp, struct vm_area_struct *vma);
 
-int bochs_gem_create(struct drm_device *dev, u32 size, bool iskernel,
-struct drm_gem_object **obj);
-int bochs_gem_init_object(struct drm_gem_object *obj);
-void bochs_gem_free_object(struct drm_gem_object *obj);
 int bochs_dumb_create(struct drm_file *file, struct drm_device *dev,
  struct drm_mode_create_dumb *args);
-int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
-  uint32_t handle, uint64_t *offset);
-
-int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag);
-int bochs_bo_unpin(struct bochs_bo *bo);
 
 int bochs_gem_prime_pin(struct drm_gem_object *obj);
 void bochs_gem_prime_unpin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 6b6e037258c3..4f269f464e6d 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -82,9 +82,9 @@ static struct drm_driver bochs_driver = {
.date   = "20130925",
.major  = 1,
.minor  = 0,
-   .gem_free_object_unlocked = bochs_gem_free_object,
+   .gem_free_object_unlocked = 
drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create= bochs_dumb_create,
-   .dumb_map_offset= bochs_dumb_mmap_offset,
+   .dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
 
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 5e905f50449d..9e3ee7b511fb 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -30,16 +30,16 @@ static const uint32_t bochs_formats[] = {
 static void bochs_plane_update(struct bochs_device *bochs,
   struct drm_plane_state *state)
 {
-   struct bochs_bo *bo;
+   struct drm_gem_vram_object *gbo;
 
if (!state->fb || !bochs->stride)
return;
 
-   bo = gem_to_bochs_bo(state->fb->obj[0]);
+   gbo = drm_gem_vram_of_gem(state->fb->obj[0]);
bochs_hw_setbase(bochs,
 state->crtc_x,
 state->crtc_y,
-bo->bo.offset);
+gbo->bo.offset);
bochs_hw_setformat(bochs, state->fb->format);
 }
 
@@ -72,23 +72,23 @@ static void bochs_pipe_update(struct 
drm_simple_display_pipe *pipe,
 static int bochs_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
 struct drm_plane_state *new_state)
 {
-   struct bochs_bo *bo;
+   struct drm_gem_vram_object *gbo;
 
if (!new_state->fb)
return 0;
-   bo = gem_to_bochs_bo(new_st

[PATCH v3 10/19] drm/ast: Replace mapping code with drm_gem_vram_{kmap/kunmap}()

[Thomas Zimmermann]

The AST driver establishes several memory mappings for frame buffers
and cursors. This patch converts the driver to use the equivalent
drm_gem_vram_kmap() functions. It removes the dependencies on TTM
and cleans up the code.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  |  1 -
 drivers/gpu/drm/ast/ast_fb.c   | 22 +-
 drivers/gpu/drm/ast/ast_mode.c | 54 --
 3 files changed, 53 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 32096a191aaf..b6cac9511796 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -256,7 +256,6 @@ struct ast_fbdev {
struct ast_framebuffer afb;
void *sysram;
int size;
-   struct ttm_bo_kmap_obj mapping;
int x1, y1, x2, y2; /* dirty rect */
spinlock_t dirty_lock;
 };
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 4fd80e31ad55..af0b56cfeab3 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -53,6 +53,7 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
int src_offset, dst_offset;
int bpp = afbdev->afb.base.format->cpp[0];
int ret = -EBUSY;
+   u8 *dst;
bool unmap = false;
bool store_for_later = false;
int x2, y2;
@@ -101,24 +102,29 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
afbdev->x2 = afbdev->y2 = 0;
spin_unlock_irqrestore(&afbdev->dirty_lock, flags);
 
-   if (!gbo->kmap.virtual) {
-   ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &gbo->kmap);
-   if (ret) {
+   dst = drm_gem_vram_kmap(gbo, false, NULL);
+   if (IS_ERR(dst)) {
+   DRM_ERROR("failed to kmap fb updates\n");
+   goto out;
+   } else if (!dst) {
+   dst = drm_gem_vram_kmap(gbo, true, NULL);
+   if (IS_ERR(dst)) {
DRM_ERROR("failed to kmap fb updates\n");
-   drm_gem_vram_unreserve(gbo);
-   return;
+   goto out;
}
unmap = true;
}
+
for (i = y; i <= y2; i++) {
/* assume equal stride for now */
src_offset = dst_offset = i * afbdev->afb.base.pitches[0] + (x 
* bpp);
-   memcpy_toio(gbo->kmap.virtual + src_offset, afbdev->sysram + 
src_offset, (x2 - x + 1) * bpp);
-
+   memcpy_toio(dst + dst_offset, afbdev->sysram + src_offset, (x2 
- x + 1) * bpp);
}
+
if (unmap)
-   ttm_bo_kunmap(&gbo->kmap);
+   drm_gem_vram_kunmap(gbo);
 
+out:
drm_gem_vram_unreserve(gbo);
 }
 
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index b75ed3816642..3475591a22c3 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -532,6 +532,7 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc,
struct drm_gem_vram_object *gbo;
int ret;
s64 gpu_addr;
+   void *base;
 
/* push the previous fb to system ram */
if (!atomic && fb) {
@@ -564,11 +565,13 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc,
 
if (&ast->fbdev->afb == ast_fb) {
/* if pushing console in kmap it */
-   ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &gbo->kmap);
-   if (ret)
+   base = drm_gem_vram_kmap(gbo, true, NULL);
+   if (IS_ERR(base)) {
+   ret = PTR_ERR(base);
DRM_ERROR("failed to kmap fbcon\n");
-   else
+   } else {
ast_fbdev_set_base(ast, gpu_addr);
+   }
}
drm_gem_vram_unreserve(gbo);
 
@@ -928,6 +931,7 @@ static int ast_cursor_init(struct drm_device *dev)
struct drm_gem_object *obj;
struct drm_gem_vram_object *gbo;
s64 gpu_addr;
+   void *base;
 
size = (AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE) * AST_DEFAULT_HWC_NUM;
 
@@ -951,9 +955,11 @@ static int ast_cursor_init(struct drm_device *dev)
}
 
/* kmap the object */
-   ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &ast->cache_kmap);
-   if (ret)
+   base = drm_gem_vram_kmap_at(gbo, true, NULL, &ast->cache_kmap);
+   if (IS_ERR(base)) {
+   ret = PTR_ERR(base);
goto fail;
+   }
 
ast->cursor_cache = obj;
ast->cursor_cache_gpu_addr = gpu_addr;
@@ -966,7 +972,9 @@ static int ast_cursor_init(struct drm_device *dev)
 static void ast_cursor_fini(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
-   ttm_bo_kunmap(&ast->cache_kmap);
+   struct drm_gem_vram_object *gbo =
+   drm_gem_vram_of_gem(ast->cursor_cache);
+   drm_gem_vram_kunmap_at(gbo, &ast->cache_kmap);
drm_gem_object_put_

[PATCH v3 07/19] drm: Integrate VRAM MM into struct drm_device

[Thomas Zimmermann]

There's no a pointer to struct drm_vram_mm stored in struct drm_device.
DRM drivers that use VRAM MM should use this field to refer to their
instance of the data structure. Appropriate helpers are now provided as
well.

Adding struct drm_vram_mm to struct drm_device further avoids wrappers
and boilerplate code in drivers. This patch implements default functions
for callbacks in struct drm_driver and struct file_operations that use
the struct drm_vram_mm stored in struct drm_device. Drivers that need to
provide their own implementations can still do so.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 28 +++
 drivers/gpu/drm/drm_vram_mm_helper.c  | 68 +++
 include/drm/drm_device.h  |  4 ++
 include/drm/drm_gem_vram_helper.h | 18 ++-
 include/drm/drm_vram_mm_helper.h  | 32 +
 5 files changed, 149 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 37979fb3062b..001ed8e7bfae 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -551,6 +552,33 @@ void drm_gem_vram_driver_gem_free_object_unlocked(struct 
drm_gem_object *gem)
 }
 EXPORT_SYMBOL(drm_gem_vram_driver_gem_free_object_unlocked);
 
+/**
+ * drm_gem_vram_driver_create_dumb() - \
+   Implements &struct drm_driver.dumb_create
+ * @file:  the DRM file
+ * @dev:   the DRM device
+ * @args:  the arguments as provided to \
+   &struct drm_driver.dumb_create
+ *
+ * This function requires the driver to use @drm_device.vram_mm for its
+ * instance of VRAM MM.
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative error code otherwise.
+ */
+int drm_gem_vram_driver_dumb_create(struct drm_file *file,
+   struct drm_device *dev,
+   struct drm_mode_create_dumb *args)
+{
+   if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
+   return -EINVAL;
+
+   return drm_gem_vram_fill_create_dumb(file, dev, &dev->vram_mm->bdev, 0,
+false, args);
+}
+EXPORT_SYMBOL(drm_gem_vram_driver_dumb_create);
+
 /**
  * drm_gem_vram_driver_dumb_mmap_offset() - \
Implements &struct drm_driver.dumb_mmap_offset
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c 
b/drivers/gpu/drm/drm_vram_mm_helper.c
index d19f46d7a4e7..62ce8d2cd4c1 100644
--- a/drivers/gpu/drm/drm_vram_mm_helper.c
+++ b/drivers/gpu/drm/drm_vram_mm_helper.c
@@ -208,3 +208,71 @@ int drm_vram_mm_mmap(struct file *filp, struct 
vm_area_struct *vma,
return ttm_bo_mmap(filp, vma, &vmm->bdev);
 }
 EXPORT_SYMBOL(drm_vram_mm_mmap);
+
+/*
+ * Helpers for integration with struct drm_device
+ */
+
+struct drm_vram_mm* drm_vram_helper_alloc_mm(
+   struct drm_device *dev, u64 vram_base, unsigned long vram_size,
+   const struct drm_vram_mm_funcs* funcs)
+{
+   int ret;
+
+   if (WARN_ON(dev->vram_mm))
+   return dev->vram_mm;
+
+   dev->vram_mm = kzalloc(sizeof(*dev->vram_mm), GFP_KERNEL);
+   if (!dev->vram_mm)
+   return ERR_PTR(-ENOMEM);
+
+   ret = drm_vram_mm_init(dev->vram_mm, dev, vram_base, vram_size, funcs);
+   if (ret)
+   goto err_kfree;
+
+   return dev->vram_mm;
+
+err_kfree:
+   kfree(dev->vram_mm);
+   dev->vram_mm = NULL;
+   return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(drm_vram_helper_alloc_mm);
+
+void drm_vram_helper_release_mm(struct drm_device *dev)
+{
+   if (!dev->vram_mm)
+   return;
+
+   drm_vram_mm_cleanup(dev->vram_mm);
+   kfree(dev->vram_mm);
+   dev->vram_mm = NULL;
+}
+EXPORT_SYMBOL(drm_vram_helper_release_mm);
+
+/*
+ * Helpers for &struct file_operations
+ */
+
+/**
+ * drm_vram_mm_file_operations_mmap() - \
+   Implements &struct file_operations.mmap()
+ * @filp:  the mapping's file structure
+ * @vma:   the mapping's memory area
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative error code otherwise.
+ */
+int drm_vram_mm_file_operations_mmap(
+   struct file *filp, struct vm_area_struct *vma)
+{
+   struct drm_file *file_priv = filp->private_data;
+   struct drm_device *dev = file_priv->minor->dev;
+
+   if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
+   return -EINVAL;
+
+   return drm_vram_mm_mmap(filp, vma, dev->vram_mm);
+}
+EXPORT_SYMBOL(drm_vram_mm_file_operations_mmap);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7f9ef709b2b6..1acfc3bbd3fb 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -17,6 +17,7 @@ struct drm_vblank_crtc;
 struct drm_sg_mem;
 struct drm_local_map;
 struct drm_vma_offset_manager;
+struct drm_vram_mm;
 struct drm_fb_hel

[PATCH v3 09/19] drm/ast: Convert AST driver to VRAM MM

[Thomas Zimmermann]

The data structure |struct drm_vram_mm| and its helpers replace ast's
TTM-based memory manager. It's the same implementation; except for the
type names.

v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement ast_mmap() with drm_vram_mm_mmap()

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/Kconfig|   1 +
 drivers/gpu/drm/ast/ast_drv.c  |  13 +---
 drivers/gpu/drm/ast/ast_drv.h  |  18 +
 drivers/gpu/drm/ast/ast_main.c |  13 +---
 drivers/gpu/drm/ast/ast_ttm.c  | 134 ++---
 5 files changed, 14 insertions(+), 165 deletions(-)

diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index d1d90f8c7a8f..ecc9c905b81b 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -4,6 +4,7 @@ config DRM_AST
select DRM_TTM
select DRM_KMS_HELPER
select DRM_GEM_VRAM_HELPER
+   select DRM_VRAM_MM_HELPER
help
 Say yes for experimental AST GPU driver. Do not enable
 this driver without having a working -modesetting,
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 69f05625fc2d..3811997e78c4 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -205,13 +205,7 @@ static struct pci_driver ast_pci_driver = {
 
 static const struct file_operations ast_fops = {
.owner = THIS_MODULE,
-   .open = drm_open,
-   .release = drm_release,
-   .unlocked_ioctl = drm_ioctl,
-   .mmap = ast_mmap,
-   .poll = drm_poll,
-   .compat_ioctl = drm_compat_ioctl,
-   .read = drm_read,
+   DRM_VRAM_MM_FILE_OPERATIONS
 };
 
 static struct drm_driver driver = {
@@ -228,10 +222,7 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
 
-   .gem_free_object_unlocked = 
drm_gem_vram_driver_gem_free_object_unlocked,
-   .dumb_create = ast_dumb_create,
-   .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
-
+   DRM_GEM_VRAM_DRIVER
 };
 
 static int __init ast_init(void)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 712838f725dc..32096a191aaf 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -31,15 +31,11 @@
 #include 
 #include 
 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 
@@ -104,10 +100,6 @@ struct ast_private {
 
int fb_mtrr;
 
-   struct {
-   struct ttm_bo_device bdev;
-   } ttm;
-
struct drm_gem_object *cursor_cache;
uint64_t cursor_cache_gpu_addr;
/* Acces to this cache is protected by the crtc->mutex of the only crtc
@@ -325,10 +317,6 @@ void ast_fbdev_set_base(struct ast_private *ast, unsigned 
long gpu_addr);
 #define AST_MM_ALIGN_SHIFT 4
 #define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
 
-extern int ast_dumb_create(struct drm_file *file,
-  struct drm_device *dev,
-  struct drm_mode_create_dumb *args);
-
 int ast_mm_init(struct ast_private *ast);
 void ast_mm_fini(struct ast_private *ast);
 
@@ -336,8 +324,6 @@ int ast_gem_create(struct drm_device *dev,
   u32 size, bool iskernel,
   struct drm_gem_object **obj);
 
-int ast_mmap(struct file *filp, struct vm_area_struct *vma);
-
 /* ast post */
 void ast_enable_vga(struct drm_device *dev);
 void ast_enable_mmio(struct drm_device *dev);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 61fc7b8ea470..4c7e31cb45ff 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -593,7 +593,6 @@ int ast_gem_create(struct drm_device *dev,
   u32 size, bool iskernel,
   struct drm_gem_object **obj)
 {
-   struct ast_private *ast = dev->dev_private;
struct drm_gem_vram_object *gbo;
int ret;
 
@@ -603,7 +602,7 @@ int ast_gem_create(struct drm_device *dev,
if (size == 0)
return -EINVAL;
 
-   gbo = drm_gem_vram_create(dev, &ast->ttm.bdev, size, 0, false);
+   gbo = drm_gem_vram_create(dev, &dev->vram_mm->bdev, size, 0, false);
if (IS_ERR(gbo)) {
ret = PTR_ERR(gbo);
if (ret != -ERESTARTSYS)
@@ -613,13 +612,3 @@ int ast_gem_create(struct drm_device *dev,
*obj = &gbo->gem;
return 0;
 }
-
-int ast_dumb_create(struct drm_file *file,
-   struct drm_device *dev,
-   struct drm_mode_create_dumb *args)
-{
-   struct ast_private *ast = dev->dev_private;
-
-   return drm_gem_vram_fill_create_dumb(file, dev, &ast->ttm.bdev, 0,
-false, args);
-}
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 794ebb755a5d..779c53efee8e 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ 

[PATCH v3 01/19] drm: Add |struct drm_gem_vram_object| and helpers

[Thomas Zimmermann]

The type |struct drm_gem_vram_object| implements a GEM object for simple
framebuffer devices with dedicated video memory. The BO is either located
in VRAM or system memory.

The implementation has been created from the respective code in ast,
bochs and mgag200. These drivers copy their implementation from each
other; except for the names of several data types. The helpers are
currently build with TTM, but this is considered an implementation
detail and may change in future updates.

v2:
* rename to |struct drm_gem_vram_object|
* move drm_is_gem_ttm() to a later patch in the series
* add drm_gem_vram_kmap_at()
* return is_iomem from kmap functions
* redefine TTM placement flags for public interface
* documentation fixes

Signed-off-by: Thomas Zimmermann 
---
 Documentation/gpu/drm-mm.rst |  12 +
 drivers/gpu/drm/Kconfig  |  13 +
 drivers/gpu/drm/Makefile |   4 +
 drivers/gpu/drm/drm_gem_vram_helper.c| 410 +++
 drivers/gpu/drm/drm_vram_helper_common.c |   6 +
 include/drm/drm_gem_vram_helper.h|  92 +
 6 files changed, 537 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_gem_vram_helper.c
 create mode 100644 drivers/gpu/drm/drm_vram_helper_common.c
 create mode 100644 include/drm/drm_gem_vram_helper.h

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 54a696d961a7..d5327ed608d7 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -380,6 +380,18 @@ GEM CMA Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
:export:
 
+GEM VRAM Helper Functions Reference
+--
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_vram_helper.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
+   :export:
+
 VMA Offset Manager
 ==
 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2267e84d5cb4..c0d49a6c09d2 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -160,6 +160,12 @@ config DRM_TTM
  GPU memory types. Will be enabled automatically if a device driver
  uses it.
 
+config DRM_VRAM_HELPER
+   tristate
+   depends on DRM && DRM_TTM
+   help
+ Helpers for VRAM memory management
+
 config DRM_GEM_CMA_HELPER
bool
depends on DRM
@@ -179,6 +185,13 @@ config DRM_GEM_SHMEM_HELPER
help
  Choose this if you need the GEM shmem helper functions
 
+config DRM_GEM_VRAM_HELPER
+   bool
+   depends on DRM
+   select DRM_VRAM_HELPER
+   help
+ Choose this if you need the GEM VRAM helper functions
+
 config DRM_VM
bool
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..dbe38fe1bcb3 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,10 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 
+drm_vram_helper-y := drm_vram_helper_common.o
+drm_vram_helper-$(CONFIG_DRM_GEM_VRAM_HELPER) += drm_gem_vram_helper.o
+obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
+
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o 
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
new file mode 100644
index ..d39d8a5f36df
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -0,0 +1,410 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#include 
+#include 
+
+/**
+ * DOC: overview
+ *
+ * This library provides a GEM object that is backed by VRAM. It
+ * can be used for simple framebuffer devices with dedicated memory.
+ */
+
+/*
+ * Buffer-objects helpers
+ */
+
+static void drm_gem_vram_cleanup(struct drm_gem_vram_object *gbo)
+{
+   /* We got here via ttm_bo_put(), which means that the
+* TTM buffer object in 'bo' has already been cleaned
+* up; only release the GEM object. */
+   drm_gem_object_release(&gbo->gem);
+}
+
+static void drm_gem_vram_destroy(struct drm_gem_vram_object *gbo)
+{
+   drm_gem_vram_cleanup(gbo);
+   kfree(gbo);
+}
+
+static void ttm_buffer_object_destroy(struct ttm_buffer_object *bo)
+{
+   struct drm_gem_vram_object *gbo = drm_gem_vram_of_bo(bo);
+   drm_gem_vram_destroy(gbo);
+}
+
+static void drm_gem_vram_placement(struct drm_gem_vram_object *gbo, int 
pl_flag)
+{
+   unsigned int i;
+   unsigned int c = 0;
+
+   gbo->placement.placement = gbo->placements;
+   gbo->placement.busy_placement = gbo->placements;
+
+   if (pl_flag & TTM_PL_FLAG_VRAM)
+ 

[PATCH v3 08/19] drm/ast: Convert AST driver to |struct drm_gem_vram_object|

[Thomas Zimmermann]

The data structure |struct drm_gem_vram_object| and its helpers replace
|struct ast_bo|. It's the same implementation; except for the type names.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/Kconfig|   2 +-
 drivers/gpu/drm/ast/ast_drv.c  |   4 +-
 drivers/gpu/drm/ast/ast_drv.h  |  52 +-
 drivers/gpu/drm/ast/ast_fb.c   |  18 ++--
 drivers/gpu/drm/ast/ast_main.c |  74 ++
 drivers/gpu/drm/ast/ast_mode.c |  78 +--
 drivers/gpu/drm/ast/ast_ttm.c  | 172 +
 7 files changed, 70 insertions(+), 330 deletions(-)

diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index 9647e1f07088..d1d90f8c7a8f 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -3,7 +3,7 @@ config DRM_AST
depends on DRM && PCI && MMU
select DRM_TTM
select DRM_KMS_HELPER
-   select DRM_TTM
+   select DRM_GEM_VRAM_HELPER
help
 Say yes for experimental AST GPU driver. Do not enable
 this driver without having a working -modesetting,
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 3871b39d4dea..69f05625fc2d 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -228,9 +228,9 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
 
-   .gem_free_object_unlocked = ast_gem_free_object,
+   .gem_free_object_unlocked = 
drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create = ast_dumb_create,
-   .dumb_map_offset = ast_dumb_mmap_offset,
+   .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
 
 };
 
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 1cf0c75e411d..712838f725dc 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -38,6 +38,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -321,25 +322,6 @@ void ast_fbdev_fini(struct drm_device *dev);
 void ast_fbdev_set_suspend(struct drm_device *dev, int state);
 void ast_fbdev_set_base(struct ast_private *ast, unsigned long gpu_addr);
 
-struct ast_bo {
-   struct ttm_buffer_object bo;
-   struct ttm_placement placement;
-   struct ttm_bo_kmap_obj kmap;
-   struct drm_gem_object gem;
-   struct ttm_place placements[3];
-   int pin_count;
-};
-#define gem_to_ast_bo(gobj) container_of((gobj), struct ast_bo, gem)
-
-static inline struct ast_bo *
-ast_bo(struct ttm_buffer_object *bo)
-{
-   return container_of(bo, struct ast_bo, bo);
-}
-
-
-#define to_ast_obj(x) container_of(x, struct ast_gem_object, base)
-
 #define AST_MM_ALIGN_SHIFT 4
 #define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
 
@@ -347,45 +329,13 @@ extern int ast_dumb_create(struct drm_file *file,
   struct drm_device *dev,
   struct drm_mode_create_dumb *args);
 
-extern void ast_gem_free_object(struct drm_gem_object *obj);
-extern int ast_dumb_mmap_offset(struct drm_file *file,
-   struct drm_device *dev,
-   uint32_t handle,
-   uint64_t *offset);
-
 int ast_mm_init(struct ast_private *ast);
 void ast_mm_fini(struct ast_private *ast);
 
-int ast_bo_create(struct drm_device *dev, int size, int align,
- uint32_t flags, struct ast_bo **pastbo);
-
 int ast_gem_create(struct drm_device *dev,
   u32 size, bool iskernel,
   struct drm_gem_object **obj);
 
-int ast_bo_pin(struct ast_bo *bo, u32 pl_flag, u64 *gpu_addr);
-int ast_bo_unpin(struct ast_bo *bo);
-
-static inline int ast_bo_reserve(struct ast_bo *bo, bool no_wait)
-{
-   int ret;
-
-   ret = ttm_bo_reserve(&bo->bo, true, no_wait, NULL);
-   if (ret) {
-   if (ret != -ERESTARTSYS && ret != -EBUSY)
-   DRM_ERROR("reserve failed %p\n", bo);
-   return ret;
-   }
-   return 0;
-}
-
-static inline void ast_bo_unreserve(struct ast_bo *bo)
-{
-   ttm_bo_unreserve(&bo->bo);
-}
-
-void ast_ttm_placement(struct ast_bo *bo, int domain);
-int ast_bo_push_sysram(struct ast_bo *bo);
 int ast_mmap(struct file *filp, struct vm_area_struct *vma);
 
 /* ast post */
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index e718d0f60d6b..4fd80e31ad55 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -49,7 +49,7 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
 {
int i;
struct drm_gem_object *obj;
-   struct ast_bo *bo;
+   struct drm_gem_vram_object *gbo;
int src_offset, dst_offset;
int bpp = afbdev->afb.base.format->cpp[0];
int ret = -EBUSY;
@@ -59,7 +59,7 @@ static void ast_dirty_update(struct ast_fbdev *afbdev,
unsigned long flags;
 
obj = afbdev->afb.obj;
-   bo = gem_to_ast_bo(obj);
+   gbo = drm

[PATCH v3 14/19] drm/mgag200: Convert mgag200 driver to VRAM MM

[Thomas Zimmermann]

The data structure |struct drm_vram_mm| and its helpers replace mgag200's
TTM-based memory manager. It's the same implementation; except for the type
names.

v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement mgag200_mmap() with drm_vram_mm_mmap()

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/Kconfig|   1 +
 drivers/gpu/drm/mgag200/mgag200_drv.c  |  13 +--
 drivers/gpu/drm/mgag200/mgag200_drv.h  |  11 +-
 drivers/gpu/drm/mgag200/mgag200_main.c |  17 +---
 drivers/gpu/drm/mgag200/mgag200_ttm.c  | 133 ++---
 5 files changed, 16 insertions(+), 159 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
index 52b7c3ee3064..8368fc5f4ca9 100644
--- a/drivers/gpu/drm/mgag200/Kconfig
+++ b/drivers/gpu/drm/mgag200/Kconfig
@@ -4,6 +4,7 @@ config DRM_MGAG200
select DRM_KMS_HELPER
select DRM_TTM
select DRM_GEM_VRAM_HELPER
+   select DRM_VRAM_MM_HELPER
help
 This is a KMS driver for the MGA G200 server chips, it
  does not support the original MGA G200 or any of the desktop
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 85c3ed7f0385..93bd1589e50e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -59,13 +59,7 @@ static void mga_pci_remove(struct pci_dev *pdev)
 
 static const struct file_operations mgag200_driver_fops = {
.owner = THIS_MODULE,
-   .open = drm_open,
-   .release = drm_release,
-   .unlocked_ioctl = drm_ioctl,
-   .mmap = mgag200_mmap,
-   .poll = drm_poll,
-   .compat_ioctl = drm_compat_ioctl,
-   .read = drm_read,
+   DRM_VRAM_MM_FILE_OPERATIONS
 };
 
 static struct drm_driver driver = {
@@ -79,10 +73,7 @@ static struct drm_driver driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
-
-   .gem_free_object_unlocked = 
drm_gem_vram_driver_gem_free_object_unlocked,
-   .dumb_create = mgag200_dumb_create,
-   .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
+   DRM_GEM_VRAM_DRIVER
 };
 
 static struct pci_driver mgag200_pci_driver = {
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h 
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 86b33e23ab7f..16ce6b338dce 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -17,15 +17,12 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 
@@ -212,10 +209,6 @@ struct mga_device {
 
int fb_mtrr;
 
-   struct {
-   struct ttm_bo_device bdev;
-   } ttm;
-
/* SE model number stored in reg 0x1e24 */
u32 unique_rev_id;
 };
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 59a4028a5c6c..f3687fed4075 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -230,10 +230,10 @@ int mgag200_driver_load(struct drm_device *dev, unsigned 
long flags)
}
 
/* Make small buffers to store a hardware cursor (double buffered icon 
updates) */
-   mdev->cursor.pixels_1 = drm_gem_vram_create(dev, &mdev->ttm.bdev,
+   mdev->cursor.pixels_1 = drm_gem_vram_create(dev, &dev->vram_mm->bdev,
roundup(48*64, PAGE_SIZE),
0, 0);
-   mdev->cursor.pixels_2 = drm_gem_vram_create(dev, &mdev->ttm.bdev,
+   mdev->cursor.pixels_2 = drm_gem_vram_create(dev, &dev->vram_mm->bdev,
roundup(48*64, PAGE_SIZE),
0, 0);
if (IS_ERR(mdev->cursor.pixels_2) || IS_ERR(mdev->cursor.pixels_1)) {
@@ -274,7 +274,6 @@ int mgag200_gem_create(struct drm_device *dev,
   u32 size, bool iskernel,
   struct drm_gem_object **obj)
 {
-   struct mga_device *mdev = dev->dev_private;
struct drm_gem_vram_object *gbo;
int ret;
 
@@ -284,7 +283,7 @@ int mgag200_gem_create(struct drm_device *dev,
if (size == 0)
return -EINVAL;
 
-   gbo = drm_gem_vram_create(dev, &mdev->ttm.bdev, size, 0, false);
+   gbo = drm_gem_vram_create(dev, &dev->vram_mm->bdev, size, 0, false);
if (IS_ERR(gbo)) {
ret = PTR_ERR(gbo);
if (ret != -ERESTARTSYS)
@@ -294,13 +293,3 @@ int mgag200_gem_create(struct drm_device *dev,
*obj = &gbo->gem;
return 0;
 }
-
-int mgag200_dumb_create(struct drm_file *file,
-   struct drm_device *dev,
-   struct drm_mode_create_dumb *args)
-{
-   struct mga_device *mdev = dev->dev_private;
-
-   return drm_gem_vram_fill_create_dumb(file

Re: [PATCH v5 11/12] drm: Add CP downstream_info property

[Ramalingam C]

On 2019-04-29 at 09:38:32 +0200, Daniel Vetter wrote:
> On Thu, Apr 18, 2019 at 02:28:04PM +0530, Ramalingam C wrote:
> > This patch adds a optional CP downstream info blob property to the
> > connectors. This enables the Userspace to read the information of HDCP
> > authenticated downstream topology.
> > 
> > Driver will update this blob with all downstream information at the
> > end of the authentication.
> > 
> > In case userspace configures this platform as repeater, then this
> > information is needed for the authentication with upstream HDCP
> > transmitter.
> > 
> > v2:
> >   s/cp_downstream/content_protection_downstream [daniel]
> > v3:
> >   s/content_protection_downstream/hdcp_topology [daniel]
> > v4:
> >   hdcp_topology_info struct is added with explicit padding [Daniel]
> > v5:
> >   Rebased.
> > 
> > Signed-off-by: Ramalingam C 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c |  3 ++
> >  drivers/gpu/drm/drm_connector.c   | 20 ++
> >  drivers/gpu/drm/drm_hdcp.c| 65 +++
> >  include/drm/drm_connector.h   |  6 +++
> >  include/drm/drm_hdcp.h|  6 +++
> >  include/drm/drm_mode_config.h |  6 +++
> >  include/uapi/drm/drm_mode.h   | 37 ++
> >  7 files changed, 143 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 0b0747869963..1c9e1ab0d536 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -813,6 +813,9 @@ drm_atomic_connector_get_property(struct drm_connector 
> > *connector,
> > *val = state->content_protection;
> > } else if (property == config->hdcp_content_type_property) {
> > *val = state->hdcp_content_type;
> > +   } else if (property == config->hdcp_topology_property) {
> > +   *val = connector->hdcp_topology_blob_ptr ?
> > +   connector->hdcp_topology_blob_ptr->base.id : 0;
> > } else if (property == config->writeback_fb_id_property) {
> > /* Writeback framebuffer is one-shot, write and forget */
> > *val = 0;
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 436cf8e764cc..033ced774d37 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -246,6 +246,7 @@ int drm_connector_init(struct drm_device *dev,
> > mutex_init(&connector->mutex);
> > connector->edid_blob_ptr = NULL;
> > connector->tile_blob_ptr = NULL;
> > +   connector->hdcp_topology_blob_ptr = NULL;
> > connector->status = connector_status_unknown;
> > connector->display_info.panel_orientation =
> > DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > @@ -972,6 +973,25 @@ static const struct drm_prop_enum_list 
> > hdmi_colorspaces[] = {
> >   * authentication process. If content type is changed when
> >   * content_protection is not UNDESIRED, then kernel will disable the HDCP
> >   * and re-enable with new type in the same atomic commit
> > + * HDCP Topology:
> > + * This blob property is used to pass the HDCP downstream topology details
> > + * of a HDCP encrypted connector, from kernel to userspace.
> > + * This provides all required information to userspace, so that userspace
> > + * can implement the HDCP repeater using the kernel as downstream ports of
> > + * the repeater. as illustrated below:
> > + *
> > + *  HDCP Repeaters
> > + * +--+
> > + * |  |
> > + * |   |  |
> > + * |   Userspace HDCP Receiver  +->KMD HDCP transmitters  |
> > + * |  (Upstream Port)  <--+ (Downstream Ports)|
> > + * |   |  |
> > + * |  |
> > + * +--+
> 
> Hm I think this misrenders, since the table isn't indented or marked as
> fixed with. Did you check the output of $make htmldocs?
Yes checked on doc output. corrupted. I will fix it.

> 
> > + *
> > + * Kernel will populate this blob only when the HDCP authentication is
> > + * successful.
> >   *
> >   * max bpc:
> >   * This range property is used by userspace to limit the bit depth. When
> > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> > index 5640c4e744fe..c0d3fc93fc50 100644
> > --- a/drivers/gpu/drm/drm_hdcp.c
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -431,3 +431,68 @@ void drm_hdcp_update_content_protection(struct 
> > drm_connector *connector,
> >  dev->mode_config.content_protection_property);
> >  }
> >  EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> > +
> > +/**
> > + * drm_connector_attach_hdcp_topology_property - attach hdcp topology 
> > 

[PATCH v3 12/19] drm/bochs: Convert bochs driver to VRAM MM

[Thomas Zimmermann]

The data structure |struct drm_vram_mm| and its helpers replace bochs'
TTM-based memory manager. It's the same implementation; except for the
type names.

v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement bochs_mmap() with drm_vram_mm_mmap()

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/bochs/Kconfig |   1 +
 drivers/gpu/drm/bochs/bochs.h |  13 +--
 drivers/gpu/drm/bochs/bochs_drv.c |  13 +--
 drivers/gpu/drm/bochs/bochs_mm.c  | 148 ++
 4 files changed, 13 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig
index c04f8041a2b9..7ad1cfe47b38 100644
--- a/drivers/gpu/drm/bochs/Kconfig
+++ b/drivers/gpu/drm/bochs/Kconfig
@@ -4,6 +4,7 @@ config DRM_BOCHS
select DRM_KMS_HELPER
select DRM_TTM
select DRM_GEM_VRAM_HELPER
+   select DRM_VRAM_MM_HELPER
help
  Choose this option for qemu.
  If M is selected the module will be called bochs-drm.
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 4ccf82e1ca68..323dcca256a3 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -12,8 +12,7 @@
 #include 
 #include 
 
-#include 
-#include 
+#include 
 
 /* -- */
 
@@ -74,12 +73,6 @@ struct bochs_device {
struct drm_device *dev;
struct drm_simple_display_pipe pipe;
struct drm_connector connector;
-
-   /* ttm */
-   struct {
-   struct ttm_bo_device bdev;
-   bool initialized;
-   } ttm;
 };
 
 /* -- */
@@ -99,10 +92,6 @@ int bochs_hw_load_edid(struct bochs_device *bochs);
 /* bochs_mm.c */
 int bochs_mm_init(struct bochs_device *bochs);
 void bochs_mm_fini(struct bochs_device *bochs);
-int bochs_mmap(struct file *filp, struct vm_area_struct *vma);
-
-int bochs_dumb_create(struct drm_file *file, struct drm_device *dev,
- struct drm_mode_create_dumb *args);
 
 int bochs_gem_prime_pin(struct drm_gem_object *obj);
 void bochs_gem_prime_unpin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 4f269f464e6d..f3bb5fba30bf 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -63,14 +63,8 @@ static int bochs_load(struct drm_device *dev)
 
 static const struct file_operations bochs_fops = {
.owner  = THIS_MODULE,
-   .open   = drm_open,
-   .release= drm_release,
-   .unlocked_ioctl = drm_ioctl,
-   .compat_ioctl   = drm_compat_ioctl,
-   .poll   = drm_poll,
-   .read   = drm_read,
.llseek = no_llseek,
-   .mmap   = bochs_mmap,
+   DRM_VRAM_MM_FILE_OPERATIONS
 };
 
 static struct drm_driver bochs_driver = {
@@ -82,9 +76,8 @@ static struct drm_driver bochs_driver = {
.date   = "20130925",
.major  = 1,
.minor  = 0,
-   .gem_free_object_unlocked = 
drm_gem_vram_driver_gem_free_object_unlocked,
-   .dumb_create= bochs_dumb_create,
-   .dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
+
+   DRM_GEM_VRAM_DRIVER,
 
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 5837adc6ae17..9675d83fde37 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -9,157 +9,25 @@
 
 /* -- */
 
-static inline struct bochs_device *bochs_bdev(struct ttm_bo_device *bd)
-{
-   return container_of(bd, struct bochs_device, ttm.bdev);
-}
-
-static int bochs_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
- struct ttm_mem_type_manager *man)
-{
-   switch (type) {
-   case TTM_PL_SYSTEM:
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
-   man->available_caching = TTM_PL_MASK_CACHING;
-   man->default_caching = TTM_PL_FLAG_CACHED;
-   break;
-   case TTM_PL_VRAM:
-   man->func = &ttm_bo_manager_func;
-   man->flags = TTM_MEMTYPE_FLAG_FIXED |
-   TTM_MEMTYPE_FLAG_MAPPABLE;
-   man->available_caching = TTM_PL_FLAG_UNCACHED |
-   TTM_PL_FLAG_WC;
-   man->default_caching = TTM_PL_FLAG_WC;
-   break;
-   default:
-   DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
-   return -EINVAL;
-   }
-   return 0;
-}
-
-static int bochs_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
-  

[PATCH v3 04/19] drm: Add drm_gem_vram_fill_create_dumb() to create dumb buffers

[Thomas Zimmermann]

The helper function drm_gem_vram_fill_create_dumb() implements most of
struct drm_driver.dumb_create() for GEM-VRAM buffer objects. It's not a
full implemenation of the callback, as several driver-specific parameters
are still required.

v2:
* documentation fixes

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 62 +++
 include/drm/drm_gem_vram_helper.h |  8 
 2 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 31bf6c1079b0..e5a0dcf97ba8 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0-or-later */
 
 #include 
+#include 
 #include 
 
 /**
@@ -409,6 +410,67 @@ void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
 }
 EXPORT_SYMBOL(drm_gem_vram_kunmap);
 
+/**
+ * drm_gem_vram_fill_create_dumb() - \
+   Helper for implementing &struct drm_driver.dumb_create
+ * @file:  the DRM file
+ * @dev:   the DRM device
+ * @bdev:  the TTM BO device managing the buffer object
+ * @pg_align:  the buffer's alignment in multiples of the page size
+ * @interruptible: sleep interruptible if waiting for memory
+ * @args:  the arguments as provided to \
+   &struct drm_driver.dumb_create
+ *
+ * This helper function fills &struct drm_mode_create_dumb, which is used
+ * by &struct drm_driver.dumb_create. Implementations of this interface
+ * should forwards their arguments to this helper, plus the driver-specific
+ * parameters.
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative error code otherwise.
+ */
+int drm_gem_vram_fill_create_dumb(struct drm_file *file,
+ struct drm_device *dev,
+ struct ttm_bo_device *bdev,
+ uint32_t pg_align,
+ bool interruptible,
+ struct drm_mode_create_dumb *args)
+{
+   size_t pitch, size;
+   struct drm_gem_vram_object *gbo;
+   int ret;
+   u32 handle;
+
+   pitch = args->width * ((args->bpp + 7) / 8);
+   size = pitch * args->height;
+
+   size = roundup(size, PAGE_SIZE);
+   if (!size)
+   return -EINVAL;
+
+   gbo = drm_gem_vram_create(dev, bdev, size, pg_align, interruptible);
+   if (IS_ERR(gbo))
+   return PTR_ERR(gbo);
+
+   ret = drm_gem_handle_create(file, &gbo->gem, &handle);
+   if (ret)
+   goto err_drm_gem_object_put_unlocked;
+
+   drm_gem_object_put_unlocked(&gbo->gem);
+
+   args->pitch = pitch;
+   args->size = size;
+   args->handle = handle;
+
+   return 0;
+
+err_drm_gem_object_put_unlocked:
+   drm_gem_object_put_unlocked(&gbo->gem);
+   return ret;
+}
+EXPORT_SYMBOL(drm_gem_vram_fill_create_dumb);
+
 /*
  * Helpers for struct ttm_bo_driver
  */
diff --git a/include/drm/drm_gem_vram_helper.h 
b/include/drm/drm_gem_vram_helper.h
index 99982590e32a..1eb42919b9fb 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -8,6 +8,7 @@
 #include 
 #include  /* for container_of() */
 
+struct drm_mode_create_dumb;
 struct filp;
 
 #define DRM_GEM_VRAM_PL_FLAG_VRAM  TTM_PL_FLAG_VRAM
@@ -89,6 +90,13 @@ void drm_gem_vram_kunmap_at(struct drm_gem_vram_object *gbo,
struct ttm_bo_kmap_obj *kmap);
 void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo);
 
+int drm_gem_vram_fill_create_dumb(struct drm_file *file,
+ struct drm_device *dev,
+ struct ttm_bo_device *bdev,
+ uint32_t pg_align,
+ bool interruptible,
+ struct drm_mode_create_dumb *args);
+
 /*
  * Helpers for struct ttm_bo_driver
  */
-- 
2.21.0

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

[PATCH v3 13/19] drm/mgag200: Convert mgag200 driver to |struct drm_gem_vram_object|

[Thomas Zimmermann]

The data structure |struct drm_gem_vram_object| and its helpers replace
|struct mgag200_bo|. It's the same implementation; except for the type
names.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/Kconfig  |   1 +
 drivers/gpu/drm/mgag200/mgag200_cursor.c |  63 +
 drivers/gpu/drm/mgag200/mgag200_drv.c|   4 +-
 drivers/gpu/drm/mgag200/mgag200_drv.h|  62 ++--
 drivers/gpu/drm/mgag200/mgag200_fb.c |  18 +--
 drivers/gpu/drm/mgag200/mgag200_main.c   |  84 +++
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  45 +++---
 drivers/gpu/drm/mgag200/mgag200_ttm.c| 172 +--
 8 files changed, 102 insertions(+), 347 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig
index db58578719d2..52b7c3ee3064 100644
--- a/drivers/gpu/drm/mgag200/Kconfig
+++ b/drivers/gpu/drm/mgag200/Kconfig
@@ -3,6 +3,7 @@ config DRM_MGAG200
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
select DRM_TTM
+   select DRM_GEM_VRAM_HELPER
help
 This is a KMS driver for the MGA G200 server chips, it
  does not support the original MGA G200 or any of the desktop
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c 
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index 968e20379d54..cca3922f9f67 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -23,9 +23,9 @@ static void mga_hide_cursor(struct mga_device *mdev)
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
if (mdev->cursor.pixels_1->pin_count)
-   mgag200_bo_unpin(mdev->cursor.pixels_1);
+   drm_gem_vram_unpin(mdev->cursor.pixels_1);
if (mdev->cursor.pixels_2->pin_count)
-   mgag200_bo_unpin(mdev->cursor.pixels_2);
+   drm_gem_vram_unpin(mdev->cursor.pixels_2);
 }
 
 int mga_crtc_cursor_set(struct drm_crtc *crtc,
@@ -36,12 +36,12 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
struct mga_device *mdev = (struct mga_device *)dev->dev_private;
-   struct mgag200_bo *pixels_1 = mdev->cursor.pixels_1;
-   struct mgag200_bo *pixels_2 = mdev->cursor.pixels_2;
-   struct mgag200_bo *pixels_current = mdev->cursor.pixels_current;
-   struct mgag200_bo *pixels_prev = mdev->cursor.pixels_prev;
+   struct drm_gem_vram_object *pixels_1 = mdev->cursor.pixels_1;
+   struct drm_gem_vram_object *pixels_2 = mdev->cursor.pixels_2;
+   struct drm_gem_vram_object *pixels_current = 
mdev->cursor.pixels_current;
+   struct drm_gem_vram_object *pixels_prev = mdev->cursor.pixels_prev;
struct drm_gem_object *obj;
-   struct mgag200_bo *bo = NULL;
+   struct drm_gem_vram_object *gbo = NULL;
int ret = 0;
unsigned int i, row, col;
uint32_t colour_set[16];
@@ -50,7 +50,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
uint32_t this_colour;
bool found = false;
int colour_count = 0;
-   u64 gpu_addr;
+   s64 gpu_addr;
u8 reg_index;
u8 this_row[48];
 
@@ -79,44 +79,55 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
if (!obj)
return -ENOENT;
 
-   ret = mgag200_bo_reserve(pixels_1, true);
+   ret = drm_gem_vram_reserve(pixels_1, true);
if (ret) {
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
goto out_unref;
}
-   ret = mgag200_bo_reserve(pixels_2, true);
+   ret = drm_gem_vram_reserve(pixels_2, true);
if (ret) {
WREG8(MGA_CURPOSXL, 0);
WREG8(MGA_CURPOSXH, 0);
-   mgag200_bo_unreserve(pixels_1);
+   drm_gem_vram_unreserve(pixels_1);
goto out_unreserve1;
}
 
/* Move cursor buffers into VRAM if they aren't already */
if (!pixels_1->pin_count) {
-   ret = mgag200_bo_pin(pixels_1, TTM_PL_FLAG_VRAM,
-&mdev->cursor.pixels_1_gpu_addr);
+   ret = drm_gem_vram_pin(pixels_1, DRM_GEM_VRAM_PL_FLAG_VRAM);
if (ret)
goto out1;
+   gpu_addr = drm_gem_vram_offset(pixels_1);
+   if (gpu_addr < 0) {
+   drm_gem_vram_unpin(pixels_1);
+   goto out1;
+   }
+   mdev->cursor.pixels_1_gpu_addr = gpu_addr;
}
if (!pixels_2->pin_count) {
-   ret = mgag200_bo_pin(pixels_2, TTM_PL_FLAG_VRAM,
-&mdev->cursor.pixels_2_gpu_addr);
+   ret = drm_gem_vram_pin(pixels_2, DRM_GEM_VRAM_PL_FLAG_VRAM);
if (ret) {
-   mgag200_bo_unpin(pixels_1);
+   drm_gem_vram_unpin(pixels_1);
+   goto out1;
+   }
+   gpu_addr = drm_gem_vram_offset(pixels_2);

[PATCH v3 06/19] drm: Add default instance for VRAM MM callback functions

[Thomas Zimmermann]

VRAM MM is most likely be used with GEM VRAM. The latter now provides the
required instance of struct drm_vram_mm_funcs for drivers to use.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 14 ++
 include/drm/drm_gem_vram_helper.h |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index e5a0dcf97ba8..37979fb3062b 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -521,6 +522,19 @@ int drm_gem_vram_bo_driver_verify_access(struct 
ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
 
+/**
+ * drm_gem_vram_mm_funcs - Functions for &struct drm_vram_mm
+ *
+ * Most users of @struct drm_gem_vram_object will also use
+ * @struct drm_vram_mm. This instance of &struct drm_vram_mm_funcs
+ * can be used to connect both.
+ */
+const struct drm_vram_mm_funcs drm_gem_vram_mm_funcs = {
+   .evict_flags = drm_gem_vram_bo_driver_evict_flags,
+   .verify_access = drm_gem_vram_bo_driver_verify_access
+};
+EXPORT_SYMBOL(drm_gem_vram_mm_funcs);
+
 /*
  * Helpers for struct drm_driver
  */
diff --git a/include/drm/drm_gem_vram_helper.h 
b/include/drm/drm_gem_vram_helper.h
index 1eb42919b9fb..3f250f59eaa5 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -9,6 +9,7 @@
 #include  /* for container_of() */
 
 struct drm_mode_create_dumb;
+struct drm_vram_mm_funcs;
 struct filp;
 
 #define DRM_GEM_VRAM_PL_FLAG_VRAM  TTM_PL_FLAG_VRAM
@@ -107,6 +108,8 @@ void drm_gem_vram_bo_driver_evict_flags(struct 
ttm_buffer_object *bo,
 int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
 struct file *filp);
 
+extern const struct drm_vram_mm_funcs drm_gem_vram_mm_funcs;
+
 /*
  * Helpers for struct drm_driver
  */
-- 
2.21.0

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

[PATCH v3 15/19] drm/mgag200: Replace mapping code with drm_gem_vram_{kmap/kunmap}()

[Thomas Zimmermann]

The mgag200 driver establishes several memory mappings for frame buffers
and cursors. This patch converts the driver to use the equivalent
drm_gem_vram_kmap() functions. It removes the dependencies on TTM
and cleans up the code.
---
 drivers/gpu/drm/mgag200/mgag200_cursor.c | 35 +++-
 drivers/gpu/drm/mgag200/mgag200_drv.h|  1 -
 drivers/gpu/drm/mgag200/mgag200_fb.c | 22 +--
 drivers/gpu/drm/mgag200/mgag200_mode.c   |  9 --
 4 files changed, 36 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c 
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index cca3922f9f67..6c1a9d724d85 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -43,6 +43,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
struct drm_gem_object *obj;
struct drm_gem_vram_object *gbo = NULL;
int ret = 0;
+   u8 *src, *dst;
unsigned int i, row, col;
uint32_t colour_set[16];
uint32_t *next_space = &colour_set[0];
@@ -126,18 +127,17 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
dev_err(&dev->pdev->dev, "failed to reserve user bo\n");
goto out1;
}
-   if (!gbo->kmap.virtual) {
-   ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, &gbo->kmap);
-   if (ret) {
-   dev_err(&dev->pdev->dev, "failed to kmap user buffer 
updates\n");
-   goto out2;
-   }
+   src = drm_gem_vram_kmap(gbo, true, NULL);
+   if (IS_ERR(src)) {
+   ret = PTR_ERR(src);
+   dev_err(&dev->pdev->dev, "failed to kmap user buffer 
updates\n");
+   goto out2;
}
 
memset(&colour_set[0], 0, sizeof(uint32_t)*16);
/* width*height*4 = 16384 */
for (i = 0; i < 16384; i += 4) {
-   this_colour = ioread32(gbo->kmap.virtual + i);
+   this_colour = ioread32(src + i);
/* No transparency */
if (this_colour>>24 != 0xff &&
this_colour>>24 != 0x0) {
@@ -189,21 +189,18 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
 
/* Map up-coming buffer to write colour indices */
-   if (!pixels_prev->kmap.virtual) {
-   ret = ttm_bo_kmap(&pixels_prev->bo, 0,
- pixels_prev->bo.num_pages,
- &pixels_prev->kmap);
-   if (ret) {
-   dev_err(&dev->pdev->dev, "failed to kmap cursor 
updates\n");
-   goto out3;
-   }
+   dst = drm_gem_vram_kmap(pixels_prev, true, NULL);
+   if (IS_ERR(dst)) {
+   ret = PTR_ERR(dst);
+   dev_err(&dev->pdev->dev, "failed to kmap cursor updates\n");
+   goto out3;
}
 
/* now write colour indices into hardware cursor buffer */
for (row = 0; row < 64; row++) {
memset(&this_row[0], 0, 48);
for (col = 0; col < 64; col++) {
-   this_colour = ioread32(gbo->kmap.virtual + 4*(col + 
64*row));
+   this_colour = ioread32(src + 4*(col + 64*row));
/* write transparent pixels */
if (this_colour>>24 == 0x0) {
this_row[47 - col/8] |= 0x80>>(col%8);
@@ -221,7 +218,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
}
}
-   memcpy_toio(pixels_prev->kmap.virtual + row*48, &this_row[0], 
48);
+   memcpy_toio(dst + row*48, &this_row[0], 48);
}
 
/* Program gpu address of cursor buffer */
@@ -247,9 +244,9 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,
}
ret = 0;
 
-   ttm_bo_kunmap(&pixels_prev->kmap);
+   drm_gem_vram_kunmap(pixels_prev);
  out3:
-   ttm_bo_kunmap(&gbo->kmap);
+   drm_gem_vram_kunmap(gbo);
  out2:
drm_gem_vram_unreserve(gbo);
  out1:
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h 
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 16ce6b338dce..6180acbca7ca 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -115,7 +115,6 @@ struct mga_fbdev {
struct mga_framebuffer mfb;
void *sysram;
int size;
-   struct ttm_bo_kmap_obj mapping;
int x1, y1, x2, y2; /* dirty rect */
spinlock_t dirty_lock;
 };
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 508ec2dddbba..7c457dad5d9e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -27,6 +27,7 @@ static void mga_dirty_update(struct mga_fbdev *mfbdev,
int src_offset, dst_offset;
int bpp = mfbdev->mfb.base.format->cpp[0];
int ret = -EBUSY;
+   u8 *dst;
bool unmap = f

[PATCH v3 19/19] drm/hisilicon: Convert hibmc-drm driver to VRAM MM

[Thomas Zimmermann]

The data structure |struct drm_vram_mm| and its helpers replace hibmc's
TTM-based memory manager. It's the same implementation; except for the
type names.

v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement hibmc_mmap() with drm_vram_mm_mmap()

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/hibmc/Kconfig   |   1 +
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |   8 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |   8 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c   | 139 ++
 4 files changed, 13 insertions(+), 143 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig 
b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
index 11720303ca40..7c63c2f7d249 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
+++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI_HIBMC
select DRM_KMS_HELPER
select DRM_TTM
select DRM_GEM_VRAM_HELPER
+   select DRM_VRAM_MM_HELPER
 
help
  Choose this option if you have a Hisilicon Hibmc soc chipset.
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7027a1a05768..7243603de261 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -27,14 +27,8 @@
 
 static const struct file_operations hibmc_fops = {
.owner  = THIS_MODULE,
-   .open   = drm_open,
-   .release= drm_release,
-   .unlocked_ioctl = drm_ioctl,
-   .compat_ioctl   = drm_compat_ioctl,
-   .mmap   = hibmc_mmap,
-   .poll   = drm_poll,
-   .read   = drm_read,
.llseek = no_llseek,
+   DRM_VRAM_MM_FILE_OPERATIONS
 };
 
 static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 6b3430fc5148..3967693ecbdc 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 struct hibmc_framebuffer {
struct drm_framebuffer fb;
@@ -49,13 +49,8 @@ struct hibmc_drm_private {
struct drm_device  *dev;
bool mode_config_initialized;
 
-   /* ttm */
-   struct ttm_bo_device bdev;
-   bool initialized;
-
/* fbdev */
struct hibmc_fbdev *fbdev;
-   bool mm_inited;
 };
 
 #define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
@@ -81,7 +76,6 @@ int hibmc_mm_init(struct hibmc_drm_private *hibmc);
 void hibmc_mm_fini(struct hibmc_drm_private *hibmc);
 int hibmc_dumb_create(struct drm_file *file, struct drm_device *dev,
  struct drm_mode_create_dumb *args);
-int hibmc_mmap(struct file *filp, struct vm_area_struct *vma);
 
 extern const struct drm_mode_config_funcs hibmc_mode_funcs;
 
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index fbf8eb048ebc..52fba8cb8ddd 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -17,157 +17,38 @@
  */
 
 #include 
-#include 
 
 #include "hibmc_drm_drv.h"
 
-static inline struct hibmc_drm_private *
-hibmc_bdev(struct ttm_bo_device *bd)
-{
-   return container_of(bd, struct hibmc_drm_private, bdev);
-}
-
-static int
-hibmc_bo_init_mem_type(struct ttm_bo_device *bdev, u32 type,
-  struct ttm_mem_type_manager *man)
-{
-   switch (type) {
-   case TTM_PL_SYSTEM:
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
-   man->available_caching = TTM_PL_MASK_CACHING;
-   man->default_caching = TTM_PL_FLAG_CACHED;
-   break;
-   case TTM_PL_VRAM:
-   man->func = &ttm_bo_manager_func;
-   man->flags = TTM_MEMTYPE_FLAG_FIXED |
-   TTM_MEMTYPE_FLAG_MAPPABLE;
-   man->available_caching = TTM_PL_FLAG_UNCACHED |
-   TTM_PL_FLAG_WC;
-   man->default_caching = TTM_PL_FLAG_WC;
-   break;
-   default:
-   DRM_ERROR("unsupported memory type %u\n", type);
-   return -EINVAL;
-   }
-   return 0;
-}
-
-static int hibmc_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
-   struct ttm_mem_reg *mem)
-{
-   struct ttm_mem_type_manager *man = &bdev->man[mem->mem_type];
-   struct hibmc_drm_private *hibmc = hibmc_bdev(bdev);
-
-   mem->bus.addr = NULL;
-   mem->bus.offset = 0;
-   mem->bus.size = mem->num_pages << PAGE_SHIFT;
-   mem->bus.base = 0;
-   mem->bus.is_iomem = false;
-   if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
-   return -EINVAL;
-   switch (mem->mem_type) {
-   case TTM_PL_SYSTEM:
- 

[PATCH v3 16/19] drm/vboxvideo: Convert vboxvideo driver to |struct drm_gem_vram_object|

[Thomas Zimmermann]

This patch replaces |struct vbox_bo| and its helpers with the generic
implementation of |struct drm_gem_vram_object|. The only change in
semantics is that &ttm_bo_driver.verify_access() now does the actual
verification.

v3:
* remove forward declaration of struct vbox_gem_object
v2:
nothing

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Hans de Goede 
---
 drivers/gpu/drm/vboxvideo/Kconfig |   1 +
 drivers/gpu/drm/vboxvideo/vbox_drv.c  |   5 +-
 drivers/gpu/drm/vboxvideo/vbox_drv.h  |  60 +--
 drivers/gpu/drm/vboxvideo/vbox_fb.c   |  22 +--
 drivers/gpu/drm/vboxvideo/vbox_main.c |  70 +---
 drivers/gpu/drm/vboxvideo/vbox_mode.c |  36 +++--
 drivers/gpu/drm/vboxvideo/vbox_ttm.c  | 223 +-
 7 files changed, 45 insertions(+), 372 deletions(-)

diff --git a/drivers/gpu/drm/vboxvideo/Kconfig 
b/drivers/gpu/drm/vboxvideo/Kconfig
index 1f4182e2e980..96c794a39c56 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -3,6 +3,7 @@ config DRM_VBOXVIDEO
depends on DRM && X86 && PCI
select DRM_KMS_HELPER
select DRM_TTM
+   select DRM_GEM_VRAM_HELPER
select GENERIC_ALLOCATOR
help
  This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index fb6a0f0b8167..336a8e03e151 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -215,9 +215,10 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
 
-   .gem_free_object_unlocked = vbox_gem_free_object,
+   .gem_free_object_unlocked =
+   drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create = vbox_dumb_create,
-   .dumb_map_offset = vbox_dumb_mmap_offset,
+   .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h 
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index ece31f395540..12e47392b2f9 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -96,8 +97,6 @@ struct vbox_private {
 #undef CURSOR_PIXEL_COUNT
 #undef CURSOR_DATA_SIZE
 
-struct vbox_gem_object;
-
 struct vbox_connector {
struct drm_connector base;
char name[32];
@@ -170,73 +169,16 @@ int vboxfb_create(struct drm_fb_helper *helper,
  struct drm_fb_helper_surface_size *sizes);
 void vbox_fbdev_fini(struct vbox_private *vbox);
 
-struct vbox_bo {
-   struct ttm_buffer_object bo;
-   struct ttm_placement placement;
-   struct ttm_bo_kmap_obj kmap;
-   struct drm_gem_object gem;
-   struct ttm_place placements[3];
-   int pin_count;
-};
-
-#define gem_to_vbox_bo(gobj) container_of((gobj), struct vbox_bo, gem)
-
-static inline struct vbox_bo *vbox_bo(struct ttm_buffer_object *bo)
-{
-   return container_of(bo, struct vbox_bo, bo);
-}
-
-#define to_vbox_obj(x) container_of(x, struct vbox_gem_object, base)
-
-static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
-{
-   return bo->bo.offset;
-}
-
 int vbox_dumb_create(struct drm_file *file,
 struct drm_device *dev,
 struct drm_mode_create_dumb *args);
 
-void vbox_gem_free_object(struct drm_gem_object *obj);
-int vbox_dumb_mmap_offset(struct drm_file *file,
- struct drm_device *dev,
- u32 handle, u64 *offset);
-
 int vbox_mm_init(struct vbox_private *vbox);
 void vbox_mm_fini(struct vbox_private *vbox);
 
-int vbox_bo_create(struct vbox_private *vbox, int size, int align,
-  u32 flags, struct vbox_bo **pvboxbo);
-
 int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-
-int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag);
-int vbox_bo_unpin(struct vbox_bo *bo);
-
-static inline int vbox_bo_reserve(struct vbox_bo *bo, bool no_wait)
-{
-   int ret;
-
-   ret = ttm_bo_reserve(&bo->bo, true, no_wait, NULL);
-   if (ret) {
-   if (ret != -ERESTARTSYS && ret != -EBUSY)
-   DRM_ERROR("reserve failed %p\n", bo);
-   return ret;
-   }
-   return 0;
-}
-
-static inline void vbox_bo_unreserve(struct vbox_bo *bo)
-{
-   ttm_bo_unreserve(&bo->bo);
-}
-
-void vbox_ttm_placement(struct vbox_bo *bo, int domain);
-int vbox_bo_push_sysram(struct vbox_bo *bo);
 int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
-void *vbox_bo_kmap(struct vbox_bo *bo);
-void vbox_bo_kunmap(struct vbox_bo *bo);
 
 /* vbox_prime.c */
 int vbox_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/driv

[PATCH v3 18/19] drm/hisilicon: Convert hibmc-drm driver to |struct drm_gem_vram_object|

[Thomas Zimmermann]

The data structure |struct drm_gem_vram_object| and its helpers replace
|struct hibmc_bo|. It's the same implementation; except for the type
names.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/hibmc/Kconfig   |   1 +
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c|  21 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |   5 +-
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h   |  25 +--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |  30 +--
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c   | 210 +-
 6 files changed, 44 insertions(+), 248 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig 
b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
index c7129dc3bdfc..11720303ca40 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
+++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
@@ -3,6 +3,7 @@ config DRM_HISI_HIBMC
depends on DRM && PCI && MMU
select DRM_KMS_HELPER
select DRM_TTM
+   select DRM_GEM_VRAM_HELPER
 
help
  Choose this option if you have a Hisilicon Hibmc soc chipset.
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 9316b724e7a2..db0dfa57844e 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -96,27 +96,32 @@ static void hibmc_plane_atomic_update(struct drm_plane 
*plane,
struct drm_plane_state  *state  = plane->state;
u32 reg;
int ret;
-   u64 gpu_addr = 0;
+   s64 gpu_addr = 0;
unsigned int line_l;
struct hibmc_drm_private *priv = plane->dev->dev_private;
struct hibmc_framebuffer *hibmc_fb;
-   struct hibmc_bo *bo;
+   struct drm_gem_vram_object *gbo;
 
if (!state->fb)
return;
 
hibmc_fb = to_hibmc_framebuffer(state->fb);
-   bo = gem_to_hibmc_bo(hibmc_fb->obj);
-   ret = ttm_bo_reserve(&bo->bo, true, false, NULL);
+   gbo = drm_gem_vram_of_gem(hibmc_fb->obj);
+   ret = drm_gem_vram_reserve(gbo, false);
if (ret) {
-   DRM_ERROR("failed to reserve ttm_bo: %d", ret);
+   DRM_ERROR("failed to reserve BO: %d", ret);
return;
}
 
-   ret = hibmc_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
-   ttm_bo_unreserve(&bo->bo);
+   ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
+   drm_gem_vram_unreserve(gbo);
if (ret) {
-   DRM_ERROR("failed to pin hibmc_bo: %d", ret);
+   DRM_ERROR("failed to pin bo: %d", ret);
+   return;
+   }
+   gpu_addr = drm_gem_vram_offset(gbo);
+   if (gpu_addr < 0) {
+   drm_gem_vram_unpin(gbo);
return;
}
 
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 8ed94fcd42a7..7027a1a05768 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -63,9 +63,10 @@ static struct drm_driver hibmc_driver = {
.desc   = "hibmc drm driver",
.major  = 1,
.minor  = 0,
-   .gem_free_object_unlocked = hibmc_gem_free_object,
+   .gem_free_object_unlocked =
+   drm_gem_vram_driver_gem_free_object_unlocked,
.dumb_create= hibmc_dumb_create,
-   .dumb_map_offset= hibmc_dumb_mmap_offset,
+   .dumb_map_offset= drm_gem_vram_driver_dumb_mmap_offset,
.irq_handler= hibmc_drm_interrupt,
 };
 
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 0a381c22de26..6b3430fc5148 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct hibmc_framebuffer {
@@ -59,25 +60,6 @@ struct hibmc_drm_private {
 
 #define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer, fb)
 
-struct hibmc_bo {
-   struct ttm_buffer_object bo;
-   struct ttm_placement placement;
-   struct ttm_bo_kmap_obj kmap;
-   struct drm_gem_object gem;
-   struct ttm_place placements[3];
-   int pin_count;
-};
-
-static inline struct hibmc_bo *hibmc_bo(struct ttm_buffer_object *bo)
-{
-   return container_of(bo, struct hibmc_bo, bo);
-}
-
-static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
-{
-   return container_of(gem, struct hibmc_bo, gem);
-}
-
 void hibmc_set_power_mode(struct hibmc_drm_private *priv,
  unsigned int power_mode);
 void hibmc_set_current_gate(struct hibmc_drm_private *priv,
@@ -97,13 +79,8 @@ hibmc_framebuffer_init(struct drm_device *dev,
 
 int hibmc_mm_init(struct hibmc_drm_private *hibmc);
 void hibmc_mm_fini(struct hibmc_drm_private *hibmc);
-int hibmc_bo_pin(struct hibmc_bo *

[PATCH v3 17/19] drm/vboxvideo: Convert vboxvideo driver to VRAM MM

[Thomas Zimmermann]

The data structure |struct drm_vram_mm| and its helpers replace vboxvideo's
TTM-based memory manager. It's the same implementation; except for the type
names.

v3:
* use drm_gem_vram_mm_funcs
* convert driver to drm_device-based instance
v2:
* implement vbox_mmap() with drm_vram_mm_mmap()

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Hans de Goede 
---
 drivers/gpu/drm/vboxvideo/Kconfig |   1 +
 drivers/gpu/drm/vboxvideo/vbox_drv.c  |  13 +--
 drivers/gpu/drm/vboxvideo/vbox_drv.h  |  15 +--
 drivers/gpu/drm/vboxvideo/vbox_main.c |  13 +--
 drivers/gpu/drm/vboxvideo/vbox_ttm.c  | 136 ++
 5 files changed, 14 insertions(+), 164 deletions(-)

diff --git a/drivers/gpu/drm/vboxvideo/Kconfig 
b/drivers/gpu/drm/vboxvideo/Kconfig
index 96c794a39c56..485b665a9fa4 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -4,6 +4,7 @@ config DRM_VBOXVIDEO
select DRM_KMS_HELPER
select DRM_TTM
select DRM_GEM_VRAM_HELPER
+   select DRM_VRAM_MM_HELPER
select GENERIC_ALLOCATOR
help
  This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 336a8e03e151..02537ab9cc08 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -191,13 +191,7 @@ static struct pci_driver vbox_pci_driver = {
 
 static const struct file_operations vbox_fops = {
.owner = THIS_MODULE,
-   .open = drm_open,
-   .release = drm_release,
-   .unlocked_ioctl = drm_ioctl,
-   .compat_ioctl = drm_compat_ioctl,
-   .mmap = vbox_mmap,
-   .poll = drm_poll,
-   .read = drm_read,
+   DRM_VRAM_MM_FILE_OPERATIONS
 };
 
 static struct drm_driver driver = {
@@ -215,10 +209,7 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
 
-   .gem_free_object_unlocked =
-   drm_gem_vram_driver_gem_free_object_unlocked,
-   .dumb_create = vbox_dumb_create,
-   .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset,
+   DRM_GEM_VRAM_DRIVER,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h 
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index 12e47392b2f9..9028f946bc06 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -20,11 +20,7 @@
 #include 
 #include 
 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
 
 #include "vboxvideo_guest.h"
 #include "vboxvideo_vbe.h"
@@ -78,10 +74,6 @@ struct vbox_private {
 
int fb_mtrr;
 
-   struct {
-   struct ttm_bo_device bdev;
-   } ttm;
-
struct mutex hw_mutex; /* protects modeset and accel/vbva accesses */
struct work_struct hotplug_work;
u32 input_mapping_width;
@@ -169,16 +161,11 @@ int vboxfb_create(struct drm_fb_helper *helper,
  struct drm_fb_helper_surface_size *sizes);
 void vbox_fbdev_fini(struct vbox_private *vbox);
 
-int vbox_dumb_create(struct drm_file *file,
-struct drm_device *dev,
-struct drm_mode_create_dumb *args);
-
 int vbox_mm_init(struct vbox_private *vbox);
 void vbox_mm_fini(struct vbox_private *vbox);
 
 int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
 
 /* vbox_prime.c */
 int vbox_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c 
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index 525e9fd63f4d..18693e2bf72a 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -283,7 +283,8 @@ int vbox_gem_create(struct vbox_private *vbox,
if (size == 0)
return -EINVAL;
 
-   gbo = drm_gem_vram_create(&vbox->ddev, &vbox->ttm.bdev, size, 0, false);
+   gbo = drm_gem_vram_create(&vbox->ddev, &vbox->ddev.vram_mm->bdev,
+ size, 0, false);
if (IS_ERR(gbo)) {
ret = PTR_ERR(gbo);
if (ret != -ERESTARTSYS)
@@ -295,13 +296,3 @@ int vbox_gem_create(struct vbox_private *vbox,
 
return 0;
 }
-
-int vbox_dumb_create(struct drm_file *file,
-struct drm_device *dev, struct drm_mode_create_dumb *args)
-{
-   struct vbox_private *vbox = dev->dev_private;
-
-   return drm_gem_vram_fill_create_dumb(file, dev, &vbox->ttm.bdev, 0,
-   false, args);
-
-}
diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c 
b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
index 0989d656eed6..b82595a9ed0f 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
+++ b/drivers/gpu/d

Re: [PATCH] drm/gma500/cdv: Check vbt config bits when detecting lvds panels

[Hans de Goede]

Hi,

On 22-04-19 19:54, Patrik Jakobsson wrote:

On Sun, Apr 21, 2019 at 8:46 PM Hans de Goede  wrote:


Hi,

On 16-04-19 13:46, Patrik Jakobsson wrote:

Some machines have an lvds child device in vbt even though a panel is
not attached. To make detection more reliable we now also check the lvds
config bits available in the vbt.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Patrik Jakobsson 
Cc: Hans de Goede 
Cc: Ville Syrjälä 


The reporter of https://bugzilla.redhat.com/show_bug.cgi?id=1665766
just got back to me and he confirms that this patch fixes the
false-positive LVDS panel detection on his NAS, without needing
a DMI blacklist.

So it looks like this patch indeed is a better fix then my initial
DMI blacklist approach and from my pov this patch is ready to
go upstream.


Thanks Hans, can I add your review tag?


Erm, then I would need to actually review it first ... done:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
   drivers/gpu/drm/gma500/cdv_intel_lvds.c | 3 +++
   drivers/gpu/drm/gma500/intel_bios.c | 3 +++
   drivers/gpu/drm/gma500/psb_drv.h| 1 +
   3 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..9c8446184b17 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -594,6 +594,9 @@ void cdv_intel_lvds_init(struct drm_device *dev,
   int pipe;
   u8 pin;

+ if (!dev_priv->lvds_enabled_in_vbt)
+ return;
+
   pin = GMBUS_PORT_PANEL;
   if (!lvds_is_present_in_vbt(dev, &pin)) {
   DRM_DEBUG_KMS("LVDS is not present in VBT\n");
diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index 63bde4e86c6a..e019ea271ffc 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -436,6 +436,9 @@ parse_driver_features(struct drm_psb_private *dev_priv,
   if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
   dev_priv->edp.support = 1;

+ dev_priv->lvds_enabled_in_vbt = driver->lvds_config != 0;
+ DRM_DEBUG_KMS("LVDS VBT config bits: 0x%x\n", driver->lvds_config);
+
   /* This bit means to use 96Mhz for DPLL_A or not */
   if (driver->primary_lfp_id)
   dev_priv->dplla_96mhz = true;
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 941b238bdcc9..bc608ddc3bd1 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -537,6 +537,7 @@ struct drm_psb_private {
   int lvds_ssc_freq;
   bool is_lvds_on;
   bool is_mipi_on;
+ bool lvds_enabled_in_vbt;
   u32 mipi_ctrl_display;

   unsigned int core_freq;


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

Re: [Spice-devel] [PATCH] Revert "drm/qxl: drop prime import/export callbacks"

[Daniel Vetter]

On Mon, Apr 29, 2019 at 4:38 PM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > More useful would be some way to signal this self-reimport capability
> > > to userspace somehow.  See DRM_PRIME_CAP_LOCAL patch.
> >
> > Userspace is supposed to test whether import/export works for a
> > specific combo, not blindly assume it does and then keel over. I think
> > we need to fix that, not add more flags - there's lots of reasons why
> > a given pair of devices can't share buffers (e.g. all the contiguous
> > allocations stuff on socs).
>
> Ok.  Lets scratch the DRM_PRIME_CAP_LOCAL idea then and blame userspace
> instead.
>
> > > Right now I have the choice to set DRM_PRIME_CAP_{IMPORT,EXPORT}, in
> > > which case some userspace assumes it can do cross-driver export/import
> > > and trips over that not working.  Or I do not set
> > > DRM_PRIME_CAP_{IMPORT,EXPORT}, which breaks DRI3 ...
> >
> > Yeah that's not an option.
>
> Good.  Can I get an ack for this patch then, as it unbreaks DRI3 with qxl?

Oh sure, acked-by: me. Sorry forgot to supply that ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104345] X-Server hangs with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

--- Comment #14 from bernhardu  ---
This sample happend while just browsing in firefox inside a plasma desktop,
running in amd64 debian buster.


[138335.303379] amdgpu :08:00.0: GPU fault detected: 147 0x0a704402 for
process Xorg pid 1129 thread Xorg:cs0 pid 1161
[138335.303387] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0012014E
[138335.303391] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0E044002
[138335.303396] amdgpu :08:00.0: VM fault (0x02, vmid 7, pasid 32768) at
page 1179982, read from 'TC1' (0x54433100) (68)
[138335.313378] amdgpu :08:00.0: GPU fault detected: 147 0x08904802 for
process kwin_x11 pid 1350 thread kwin_x11:cs0 pid 1568
[138335.313384] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00120712
[138335.313388] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02048002
[138335.313393] amdgpu :08:00.0: VM fault (0x02, vmid 1, pasid 32773) at
page 1181458, read from 'TC0' (0x54433000) (72)
[139983.820484] amdgpu :08:00.0: GPU fault detected: 147 0x4802 for
process Xorg pid 1129 thread Xorg:cs0 pid 1161
[139983.820491] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0800
[139983.820495] amdgpu :08:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0C048002
[139983.820500] amdgpu :08:00.0: VM fault (0x02, vmid 6, pasid 32768) at
page 2048, read from 'TC0' (0x54433000) (72)
[139994.156833] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=14610386, emitted seq=14610389
[139994.156840] [drm] GPU recovery disabled.
[140167.215046] INFO: task kworker/u32:3:15564 blocked for more than 120
seconds.
[140167.215053]   Tainted: G   OE 4.19.0-4-amd64 #1 Debian
4.19.28-2
[140167.215055] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[140167.215058] kworker/u32:3   D0 15564  2 0x8000
[140167.215080] Workqueue: events_unbound commit_work [drm_kms_helper]
[140167.215083] Call Trace:
[140167.215093]  ? __schedule+0x2a2/0x870
[140167.215098]  ? __switch_to_asm+0x40/0x70
[140167.215102]  schedule+0x28/0x80
[140167.215106]  schedule_timeout+0x26d/0x390
[140167.215204]  ? dce110_timing_generator_get_position+0x5b/0x70 [amdgpu]
[140167.215300]  ? dce110_timing_generator_get_crtc_scanoutpos+0x70/0xb0
[amdgpu]
[140167.215305]  dma_fence_default_wait+0x238/0x2a0
[140167.215310]  ? dma_fence_release+0x90/0x90
[140167.215314]  dma_fence_wait_timeout+0xdd/0x100
[140167.215319]  reservation_object_wait_timeout_rcu+0x173/0x280
[140167.215420]  amdgpu_dm_do_flip+0x112/0x340 [amdgpu]
[140167.215523]  amdgpu_dm_atomic_commit_tail+0x750/0xdb0 [amdgpu]
[140167.215528]  ? wait_for_completion_timeout+0x3b/0x1a0
[140167.215531]  ? __switch_to_asm+0x34/0x70
[140167.215535]  ? __switch_to_asm+0x40/0x70
[140167.215538]  ? __switch_to_asm+0x34/0x70
[140167.215541]  ? __switch_to_asm+0x40/0x70
[140167.21]  commit_tail+0x3d/0x70 [drm_kms_helper]
[140167.215562]  process_one_work+0x1a7/0x3a0
[140167.215566]  worker_thread+0x30/0x390
[140167.215571]  ? create_worker+0x1a0/0x1a0
[140167.215573]  kthread+0x112/0x130
[140167.215577]  ? kthread_bind+0x30/0x30
[140167.215581]  ret_from_fork+0x22/0x40
[140241.805748] sysrq: SysRq : Keyboard mode set to system default


What can I do to get this bug forward?

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

Jörn Frenzel  changed:

   What|Removed |Added

 CC||j.fren...@openthinclient.co
   ||m

--- Comment #44 from Jörn Frenzel  ---
Created attachment 144109
  --> https://bugs.freedesktop.org/attachment.cgi?id=144109&action=edit
Oops on debian kernel 4.19.0-0.bpo.4-amd64

Hi,

the issue seems to persist in Debian 9 with kernel 4.19.0-0.bpo.4-amd64. My
hardware:

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: HP
Product Name: HP t530 Thin Client
Version:  

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev 83)
Subsystem: Hewlett-Packard Company Stoney [Radeon R2/R3/R4/R5 Graphics]
[103c:8267]
Kernel modules: amdgpu

Any new ideas on this?

Regards, Jörn

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

[PATCH] backlight: rave-sp: don't touch initial state and register with correct device

[Lucas Stach]

This way the backlight can be referenced through its device node and
enabling/disabling can be managed through the panel driver.

Signed-off-by: Lucas Stach 
---
 drivers/video/backlight/rave-sp-backlight.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/backlight/rave-sp-backlight.c 
b/drivers/video/backlight/rave-sp-backlight.c
index 462f14a1b19d..d296bfcf4396 100644
--- a/drivers/video/backlight/rave-sp-backlight.c
+++ b/drivers/video/backlight/rave-sp-backlight.c
@@ -48,15 +48,13 @@ static int rave_sp_backlight_probe(struct platform_device 
*pdev)
struct device *dev = &pdev->dev;
struct backlight_device *bd;
 
-   bd = devm_backlight_device_register(dev, pdev->name, dev->parent,
+   bd = devm_backlight_device_register(dev, pdev->name, dev,
dev_get_drvdata(dev->parent),
&rave_sp_backlight_ops,
&rave_sp_backlight_props);
if (IS_ERR(bd))
return PTR_ERR(bd);
 
-   backlight_update_status(bd);
-
return 0;
 }
 
-- 
2.20.1

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

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #45 from Michel Dänzer  ---
(In reply to Jörn Frenzel from comment #44)
> the issue seems to persist in Debian 9 with kernel 4.19.0-0.bpo.4-amd64.

The dmesg you attached looks like a different issue, please file your own
report.

-- 
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 v13 16/20] IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr

[Leon Romanovsky]

On Wed, Mar 20, 2019 at 03:51:30PM +0100, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> mlx4_get_umem_mr() uses provided user pointers for vma lookups, which can
> only by done with untagged pointers.
>
> Untag user pointers in this function.
>
> Signed-off-by: Andrey Konovalov 
> ---
>  drivers/infiniband/hw/mlx4/mr.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/mr.c b/drivers/infiniband/hw/mlx4/mr.c
> index 395379a480cb..9a35ed2c6a6f 100644
> --- a/drivers/infiniband/hw/mlx4/mr.c
> +++ b/drivers/infiniband/hw/mlx4/mr.c
> @@ -378,6 +378,7 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata 
> *udata, u64 start,
>* again
>*/
>   if (!ib_access_writable(access_flags)) {
> + unsigned long untagged_start = untagged_addr(start);
>   struct vm_area_struct *vma;
>
>   down_read(¤t->mm->mmap_sem);
> @@ -386,9 +387,9 @@ static struct ib_umem *mlx4_get_umem_mr(struct ib_udata 
> *udata, u64 start,
>* cover the memory, but for now it requires a single vma to
>* entirely cover the MR to support RO mappings.
>*/
> - vma = find_vma(current->mm, start);
> - if (vma && vma->vm_end >= start + length &&
> - vma->vm_start <= start) {
> + vma = find_vma(current->mm, untagged_start);
> + if (vma && vma->vm_end >= untagged_start + length &&
> + vma->vm_start <= untagged_start) {
>   if (vma->vm_flags & VM_WRITE)
>   access_flags |= IB_ACCESS_LOCAL_WRITE;
>   } else {
> --

Thanks,
Reviewed-by: Leon Romanovsky 

Interesting, the followup question is why mlx4 is only one driver in IB which
needs such code in umem_mr. I'll take a look on it.

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

[Bug 110509] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  ---
(In reply to James.Dutton from comment #6)
> 
> I would suggest creating code that actually tries to reset the GPU, instead
> of trying to suspend it while GPU is hung.

That is part of the GPU reset sequence.  We need to attempt to stop the engines
before resetting the GPU.  That is what the suspend code does.  Not all of the
engines are necessarily hung so you need to stop and drain them properly.

-- 
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 v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already signaled.

[Christian König]

I would clean them up further, but that's only moving code around so 
feel free to add my rb to those.


Christian.

Am 29.04.19 um 16:14 schrieb Grodzovsky, Andrey:


Thanks David, with that only patches 5 and 6 are left for the series 
to be reviewed.


Christian, any more comments on those patches ?

Andrey

On 4/27/19 10:56 PM, Zhou, David(ChunMing) wrote:


Sorry, I only can put my Acked-by: Chunming Zhou 
 on patch#3.


I cannot fully judge patch #4, #5, #6.

-David

*From:*amd-gfx  *On Behalf Of 
*Grodzovsky, Andrey

*Sent:* Friday, April 26, 2019 10:09 PM
*To:* Koenig, Christian ; Zhou, 
David(ChunMing) ; 
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; 
e...@anholt.net; etna...@lists.freedesktop.org
*Cc:* Kazlauskas, Nicholas ; Liu, Monk 

*Subject:* Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty 
job already signaled.


Ping (mostly David and Monk).

Andrey

On 4/24/19 3:09 AM, Christian König wrote:

Am 24.04.19 um 05:02 schrieb Zhou, David(ChunMing):

>> - drm_sched_stop(&ring->sched, &job->base);
>> -
>>   /* after all hw jobs are reset, hw fence is
meaningless, so force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>>   }

HW fence are already forced completion, then we can just
disable irq fence process and ignore hw fence signal when we
are trying to do GPU reset, I think. Otherwise which will
make the logic much more complex.

If this situation happens because of long time execution, we
can increase timeout of reset detection.


You are not thinking widely enough, forcing the hw fence to
complete can trigger other to start other activity in the system.

We first need to stop everything and make sure that we don't do
any processing any more and then start with our reset procedure
including forcing all hw fences to complete.

Christian.


-David

*From:*amd-gfx 
 *On Behalf Of
*Grodzovsky, Andrey
*Sent:* Wednesday, April 24, 2019 12:00 AM
*To:* Zhou, David(ChunMing) 
; dri-devel@lists.freedesktop.org
;
amd-...@lists.freedesktop.org
; e...@anholt.net
; etna...@lists.freedesktop.org
;
ckoenig.leichtzumer...@gmail.com

*Cc:* Kazlauskas, Nicholas 
; Liu, Monk
 
*Subject:* Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if
guilty job already signaled.

No, i mean the actual HW fence which signals when the job
finished execution on the HW.

Andrey

On 4/23/19 11:19 AM, Zhou, David(ChunMing) wrote:

do you mean fence timer? why not stop it as well when
stopping sched for the reason of hw reset?

 Original Message 
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if
guilty job already signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)"

,dri-devel@lists.freedesktop.org,amd-...@lists.freedesktop.org,e...@anholt.net,etna...@lists.freedesktop.org,ckoenig.leichtzumer...@gmail.com


CC: "Kazlauskas, Nicholas" ,"Liu, Monk"


On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need
virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if
the job is already
> set to guilty? set it wrongly?
>
>
> -David


It's possible that the job does completes at a later time
then it's
timeout handler started processing so in this patch we
try to protect
against this by rechecking the HW fence after stopping
all SW
schedulers. We do it BEFORE marking guilty on the job's
sched_entity so
at the point we check the guilty flag is not set yet.

Andrey


>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> Also reject TDRs if another one already running.
>>
>> v2:
>> Stop all schedulers across device and entire XGMI hive
before
>> force signaling HW fences.
>> Avoid passing job_signaled to helper fnctions to keep
a

Re: [PATCH][next] drm/amd/display: fix incorrect null check on pointer

[Alex Deucher]

On Fri, Apr 26, 2019 at 5:48 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> Currently an allocation is being made but the allocation failure
> check is being performed on another pointer. Fix this by checking
> the correct pointer. Also use the normal kernel idiom for null
> pointer checks.
>
> Addresses-Coverity: ("Resource leak")
> Fixes: 43e3ac8389ef ("drm/amd/display: Add function to copy DC streams")
> Signed-off-by: Colin Ian King 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> index 6200df3edcd0..96e97d25d639 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> @@ -168,7 +168,7 @@ struct dc_stream_state *dc_copy_stream(const struct 
> dc_stream_state *stream)
> struct dc_stream_state *new_stream;
>
> new_stream = kzalloc(sizeof(struct dc_stream_state), GFP_KERNEL);
> -   if (stream == NULL)
> +   if (!new_stream)
> return NULL;
>
> memcpy(new_stream, stream, sizeof(struct dc_stream_state));
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/19] drm: Add |struct drm_gem_vram_object| and helpers

[Sam Ravnborg]

Hi Thomas.

Some minor things and some bikeshedding too.

One general^Wbikeshedding thing - unint32_t is used in many places.
And then s64 in one place.
Seems like two concepts are mixed.
Maybe be consistent and use u32, s32 everywhere?

I did not read the code carefully enough to understand it.
I cannot give a r-b or a-b - as I feel I need to understand it to do
so.

Sam

On Mon, Apr 29, 2019 at 04:43:23PM +0200, Thomas Zimmermann wrote:
> The type |struct drm_gem_vram_object| implements a GEM object for simple
> framebuffer devices with dedicated video memory. The BO is either located
> in VRAM or system memory.
> 
> The implementation has been created from the respective code in ast,
> bochs and mgag200. These drivers copy their implementation from each
> other; except for the names of several data types. The helpers are
> currently build with TTM, but this is considered an implementation
> detail and may change in future updates.
> 
> v2:
>   * rename to |struct drm_gem_vram_object|
>   * move drm_is_gem_ttm() to a later patch in the series
>   * add drm_gem_vram_kmap_at()
>   * return is_iomem from kmap functions
>   * redefine TTM placement flags for public interface
>   * documentation fixes
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  Documentation/gpu/drm-mm.rst |  12 +
>  drivers/gpu/drm/Kconfig  |  13 +
>  drivers/gpu/drm/Makefile |   4 +
>  drivers/gpu/drm/drm_gem_vram_helper.c| 410 +++
>  drivers/gpu/drm/drm_vram_helper_common.c |   6 +
>  include/drm/drm_gem_vram_helper.h|  92 +
>  6 files changed, 537 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_gem_vram_helper.c
>  create mode 100644 drivers/gpu/drm/drm_vram_helper_common.c
>  create mode 100644 include/drm/drm_gem_vram_helper.h
> 
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index 54a696d961a7..d5327ed608d7 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -380,6 +380,18 @@ GEM CMA Helper Functions Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
> :export:
>  
> +GEM VRAM Helper Functions Reference
> +--
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
> +   :doc: overview
> +
> +.. kernel-doc:: include/drm/drm_gem_vram_helper.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
> +   :export:
> +
>  VMA Offset Manager
>  ==
>  
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 2267e84d5cb4..c0d49a6c09d2 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -160,6 +160,12 @@ config DRM_TTM
> GPU memory types. Will be enabled automatically if a device driver
> uses it.
>  
> +config DRM_VRAM_HELPER
> + tristate
> + depends on DRM && DRM_TTM
> + help
> +   Helpers for VRAM memory management
> +
>  config DRM_GEM_CMA_HELPER
>   bool
>   depends on DRM
> @@ -179,6 +185,13 @@ config DRM_GEM_SHMEM_HELPER
>   help
> Choose this if you need the GEM shmem helper functions
>  
> +config DRM_GEM_VRAM_HELPER
> + bool
> + depends on DRM
> + select DRM_VRAM_HELPER
> + help
> +   Choose this if you need the GEM VRAM helper functions
> +
I cannot remember how select will deal with symbols whos has
a  "depends on".
But if I recall correct then the "depends on" will be ignored
or in best case trigger a warning.
In other words - when we have symbols we select they should not
have a depends on.

What can be done is something like:

symbol foo
bool

symbol bar
depends on foo


symbol foobar
bool "This is what you need - select me"
select foo

So when one chooses "foobar" then we will select "foo" and this will
satisfy bar.

But maybe this rambling is irrelevant - maybe check what we do with
other selectable symbols in DRM.


> +/**
> + * DOC: overview
> + *
> + * This library provides a GEM object that is backed by VRAM. It
> + * can be used for simple framebuffer devices with dedicated memory.
> + */
It is likely only me, but...
I could use a short explanation what is GEM and maybe also VRAM.

VRAM as video RAM, but maybe there is more constraints?
(When I first looked at DRM I wondered what you used Virtual RAM for.
But thats a long time ago so it counts only as a funny story.

> + * Buffer-objects helpers
> + */
> +
> +static void drm_gem_vram_cleanup(struct drm_gem_vram_object *gbo)
> +{
> + /* We got here via ttm_bo_put(), which means that the
> +  * TTM buffer object in 'bo' has already been cleaned
> +  * up; only release the GEM object. */
> + drm_gem_object_release(&gbo->gem);
> +}
> +
> +static void drm_gem_vram_destroy(struct drm_gem_vram_object *gbo)
> +{
> + drm_gem_vram_cleanup(gbo);
> + kfree(gbo);
> +}
> +
> +static void ttm_buffer_object_destroy(struct ttm_buffer_object *bo)
>

[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]

[bugzilla-daemon]

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

--- Comment #11 from segfa...@posteo.de ---
Same here:

HW: Asrock B450M Pro4 + Ryzen 2400g
Kernel: 5.0.9

I'm totally unable to use the gpu.

-- 
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 0/9] PCI: add help pci_dev_id

[Bjorn Helgaas]

On Wed, Apr 24, 2019 at 09:10:21PM +0200, Heiner Kallweit wrote:
> In several places in the kernel we find PCI_DEVID used like this:
> PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper
> for it.
> 
> v2:
> - apply the change to all affected places in the kernel
> 
> Heiner Kallweit (9):
>   PCI: add helper pci_dev_id
>   PCI: use helper pci_dev_id
>   r8169: use new helper pci_dev_id
>   powerpc/powernv/npu: use helper pci_dev_id
>   drm/amdkfd: use helper pci_dev_id
>   iommu/amd: use helper pci_dev_id
>   iommu/vt-d: use helper pci_dev_id
>   stmmac: pci: use helper pci_dev_id
>   platform/chrome: chromeos_laptop: use helper pci_dev_id
> 
>  arch/powerpc/platforms/powernv/npu-dma.c | 14 ++
>  drivers/gpu/drm/amd/amdkfd/kfd_topology.c|  3 +--
>  drivers/iommu/amd_iommu.c|  2 +-
>  drivers/iommu/intel-iommu.c  |  2 +-
>  drivers/iommu/intel_irq_remapping.c  |  2 +-
>  drivers/net/ethernet/realtek/r8169.c |  3 +--
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c |  2 +-
>  drivers/pci/msi.c|  6 +++---
>  drivers/pci/search.c | 10 +++---
>  drivers/platform/chrome/chromeos_laptop.c|  2 +-
>  include/linux/pci.h  |  5 +
>  11 files changed, 24 insertions(+), 27 deletions(-)

Applied with acks/reviewed-by from Benson, Joerg, Christian, Alexey, and
David to pci/misc for v5.2, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/virtio: set seqno for dma-fence

[Chia-I Wu]

This is motivated by having meaningful ftrace events, but it also
fixes use cases where dma_fence_is_later is called, such as in
sync_file_merge.

In other drivers, fence creation and cmdbuf submission normally
happen atomically,

  mutex_lock();
  fence = dma_fence_create(..., ++timeline->seqno);
  submit_cmdbuf();
  mutex_unlock();

and have no such issue.  But in our driver, because most ioctls
queue commands into ctrlq, we do not want to grab a lock.  Instead,
we set seqno to 0 when a fence is created, and update it when the
command is finally queued and the seqno is known.

Signed-off-by: Chia-I Wu 
---
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  1 -
 drivers/gpu/drm/virtio/virtgpu_fence.c | 17 ++---
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 491dec0712b3..90461feeafdb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -102,7 +102,6 @@ struct virtio_gpu_fence {
struct dma_fence f;
struct virtio_gpu_fence_driver *drv;
struct list_head node;
-   uint64_t seq;
 };
 #define to_virtio_fence(x) \
container_of(x, struct virtio_gpu_fence, f)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c 
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 87d1966192f4..72b4f7561432 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -40,16 +40,14 @@ bool virtio_fence_signaled(struct dma_fence *f)
 {
struct virtio_gpu_fence *fence = to_virtio_fence(f);
 
-   if (atomic64_read(&fence->drv->last_seq) >= fence->seq)
+   if (atomic64_read(&fence->drv->last_seq) >= fence->f.seqno)
return true;
return false;
 }
 
 static void virtio_fence_value_str(struct dma_fence *f, char *str, int size)
 {
-   struct virtio_gpu_fence *fence = to_virtio_fence(f);
-
-   snprintf(str, size, "%llu", fence->seq);
+   snprintf(str, size, "%llu", f->seqno);
 }
 
 static void virtio_timeline_value_str(struct dma_fence *f, char *str, int size)
@@ -76,6 +74,11 @@ struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct 
virtio_gpu_device *vgdev)
return fence;
 
fence->drv = drv;
+
+   /* This only partially initializes the fence because the seqno is
+* unknown yet.  The fence must not be used outside of the driver
+* until virtio_gpu_fence_emit is called.
+*/
dma_fence_init(&fence->f, &virtio_fence_ops, &drv->lock, drv->context, 
0);
 
return fence;
@@ -89,13 +92,13 @@ int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
unsigned long irq_flags;
 
spin_lock_irqsave(&drv->lock, irq_flags);
-   fence->seq = ++drv->sync_seq;
+   fence->f.seqno = ++drv->sync_seq;
dma_fence_get(&fence->f);
list_add_tail(&fence->node, &drv->fences);
spin_unlock_irqrestore(&drv->lock, irq_flags);
 
cmd_hdr->flags |= cpu_to_le32(VIRTIO_GPU_FLAG_FENCE);
-   cmd_hdr->fence_id = cpu_to_le64(fence->seq);
+   cmd_hdr->fence_id = cpu_to_le64(fence->f.seqno);
return 0;
 }
 
@@ -109,7 +112,7 @@ void virtio_gpu_fence_event_process(struct 
virtio_gpu_device *vgdev,
spin_lock_irqsave(&drv->lock, irq_flags);
atomic64_set(&vgdev->fence_drv.last_seq, last_seq);
list_for_each_entry_safe(fence, tmp, &drv->fences, node) {
-   if (last_seq < fence->seq)
+   if (last_seq < fence->f.seqno)
continue;
dma_fence_signal_locked(&fence->f);
list_del(&fence->node);
-- 
2.21.0.593.g511ec345e18-goog

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

[PATCH 2/3] drm/virtio: trace drm_fence_emit

[Chia-I Wu]

For most drivers, drm_fence_init is followed by drm_fence_emit
immediately.  But for our driver, they are done separately.  We also
don't know the fence seqno until drm_fence_emit.

Signed-off-by: Chia-I Wu 
---
 drivers/gpu/drm/virtio/virtgpu_fence.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c 
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 72b4f7561432..e22918ca621b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -24,6 +24,7 @@
  */
 
 #include 
+#include 
 #include "virtgpu_drv.h"
 
 static const char *virtio_get_driver_name(struct dma_fence *f)
@@ -97,6 +98,8 @@ int virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
list_add_tail(&fence->node, &drv->fences);
spin_unlock_irqrestore(&drv->lock, irq_flags);
 
+   trace_dma_fence_emit(&fence->f);
+
cmd_hdr->flags |= cpu_to_le32(VIRTIO_GPU_FLAG_FENCE);
cmd_hdr->fence_id = cpu_to_le64(fence->f.seqno);
return 0;
-- 
2.21.0.593.g511ec345e18-goog

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

[PATCH 3/3] drm/virtio: add trace events for commands

[Chia-I Wu]

Trace when commands are queued for both ctrlq and cursorq.  Trace
when responses are received for ctrlq.

Signed-off-by: Chia-I Wu 
---
 drivers/gpu/drm/virtio/Makefile   |  2 +-
 drivers/gpu/drm/virtio/virtgpu_trace.h| 52 +++
 drivers/gpu/drm/virtio/virtgpu_trace_points.c |  5 ++
 drivers/gpu/drm/virtio/virtgpu_vq.c   | 10 
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/virtio/virtgpu_trace.h
 create mode 100644 drivers/gpu/drm/virtio/virtgpu_trace_points.c

diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
index 4e90cc8fa651..42949a17ff70 100644
--- a/drivers/gpu/drm/virtio/Makefile
+++ b/drivers/gpu/drm/virtio/Makefile
@@ -6,6 +6,6 @@
 virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_gem.o \
virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
-   virtgpu_ioctl.o virtgpu_prime.o
+   virtgpu_ioctl.o virtgpu_prime.o virtgpu_trace_points.o
 
 obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
diff --git a/drivers/gpu/drm/virtio/virtgpu_trace.h 
b/drivers/gpu/drm/virtio/virtgpu_trace.h
new file mode 100644
index ..711ecc2bd241
--- /dev/null
+++ b/drivers/gpu/drm/virtio/virtgpu_trace.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#if !defined(_VIRTGPU_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
+#define _VIRTGPU_TRACE_H_
+
+#include 
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM virtio_gpu
+#define TRACE_INCLUDE_FILE virtgpu_trace
+
+DECLARE_EVENT_CLASS(virtio_gpu_cmd,
+   TP_PROTO(struct virtqueue *vq, struct virtio_gpu_ctrl_hdr *hdr),
+   TP_ARGS(vq, hdr),
+   TP_STRUCT__entry(
+__field(int, dev)
+__field(unsigned int, vq)
+__field(const char *, name)
+__field(u32, type)
+__field(u32, flags)
+__field(u64, fence_id)
+__field(u32, ctx_id)
+),
+   TP_fast_assign(
+  __entry->dev = vq->vdev->index;
+  __entry->vq = vq->index;
+  __entry->name = vq->name;
+  __entry->type = le32_to_cpu(hdr->type);
+  __entry->flags = le32_to_cpu(hdr->flags);
+  __entry->fence_id = le64_to_cpu(hdr->fence_id);
+  __entry->ctx_id = le32_to_cpu(hdr->ctx_id);
+  ),
+   TP_printk("vdev=%d vq=%u name=%s type=0x%x flags=0x%x fence_id=%llu 
ctx_id=%u",
+ __entry->dev, __entry->vq, __entry->name,
+ __entry->type, __entry->flags, __entry->fence_id,
+ __entry->ctx_id)
+);
+
+DEFINE_EVENT(virtio_gpu_cmd, virtio_gpu_cmd_queue,
+   TP_PROTO(struct virtqueue *vq, struct virtio_gpu_ctrl_hdr *hdr),
+   TP_ARGS(vq, hdr)
+);
+
+DEFINE_EVENT(virtio_gpu_cmd, virtio_gpu_cmd_response,
+   TP_PROTO(struct virtqueue *vq, struct virtio_gpu_ctrl_hdr *hdr),
+   TP_ARGS(vq, hdr)
+);
+
+#endif
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH ../../drivers/gpu/drm/virtio
+#include 
diff --git a/drivers/gpu/drm/virtio/virtgpu_trace_points.c 
b/drivers/gpu/drm/virtio/virtgpu_trace_points.c
new file mode 100644
index ..1970cb6f24ef
--- /dev/null
+++ b/drivers/gpu/drm/virtio/virtgpu_trace_points.c
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "virtgpu_drv.h"
+
+#define CREATE_TRACE_POINTS
+#include "virtgpu_trace.h"
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index e62fe24b1a2e..2c5eeccb88c0 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -28,6 +28,7 @@
 
 #include 
 #include "virtgpu_drv.h"
+#include "virtgpu_trace.h"
 #include 
 #include 
 #include 
@@ -192,6 +193,9 @@ void virtio_gpu_dequeue_ctrl_func(struct work_struct *work)
 
list_for_each_entry_safe(entry, tmp, &reclaim_list, list) {
resp = (struct virtio_gpu_ctrl_hdr *)entry->resp_buf;
+
+   trace_virtio_gpu_cmd_response(vgdev->ctrlq.vq, resp);
+
if (resp->type != cpu_to_le32(VIRTIO_GPU_RESP_OK_NODATA)) {
if (resp->type >= 
cpu_to_le32(VIRTIO_GPU_RESP_ERR_UNSPEC)) {
struct virtio_gpu_ctrl_hdr *cmd;
@@ -284,6 +288,9 @@ static int virtio_gpu_queue_ctrl_buffer_locked(struct 
virtio_gpu_device *vgdev,
spin_lock(&vgdev->ctrlq.qlock);
goto retry;
} else {
+   trace_virtio_gpu_cmd_queue(vq,
+   (struct virtio_gpu_ctrl_hdr *)vbuf->buf);
+
virtqueue_kick(vq);
}
 
@@ -359,6 +366,9 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device 
*vgdev,
spin_lock(&vgdev->cursorq.qlock);
goto retry;

[PATCH] drm/virtio: allocate fences with GFP_KERNEL

[Chia-I Wu]

It was changed to GFP_ATOMIC in commit ec2f0577c (add & use
virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened
with a spinlock held.  That was no longer true after commit
9fdd90c0f (add virtio_gpu_alloc_fence()).

Signed-off-by: Chia-I Wu 
Cc: Gerd Hoffmann 
Cc: Gustavo Padovan 
Cc: Robert Foss 
---
 drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c 
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index 87d1966192f4..b63ea4797afc 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fence.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fence.c
@@ -71,7 +71,7 @@ struct virtio_gpu_fence *virtio_gpu_fence_alloc(struct 
virtio_gpu_device *vgdev)
 {
struct virtio_gpu_fence_driver *drv = &vgdev->fence_drv;
struct virtio_gpu_fence *fence = kzalloc(sizeof(struct 
virtio_gpu_fence),
-   GFP_ATOMIC);
+   GFP_KERNEL);
if (!fence)
return fence;
 
-- 
2.21.0.593.g511ec345e18-goog

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

Re: [v2 1/3] dt-bindings: display: mediatek: update dsi supported chips

[Rob Herring]

On Tue, Apr 16, 2019 at 01:42:15PM +0800, Jitao Shi wrote:
> Update device tree binding documentation for the dsi for
> Mediatek MT8183 SoCs.
> 
> Signed-off-by: Jitao Shi 
> ---
>  .../devicetree/bindings/display/mediatek/mediatek,dsi.txt   | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index fadf327c7cdf..bd68195458b9 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -26,7 +26,7 @@ The MIPI TX configuration module controls the MIPI D-PHY.
>  
>  Required properties:
>  - compatible: "mediatek,-mipi-tx"
> -  the supported chips are mt2701 and mt8173.
> +  the supported chips are mt2701 , mt8173 and mt8183.

drop the space ^

With that,

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

[Bug 110509] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout

[bugzilla-daemon]

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

--- Comment #8 from james.dut...@gmail.com ---
Thank you for the feedback.
Is there a data sheet somewhere that might help me work out a fix for this.
What I would like is:
1) A way to scan all the engines and detect which ones have hung.
2) A way to intentionally halt an engine and tidy up. So that the modprobe,
rmmod, modprobe scenario works. 
3) data sheet details regarding how to un-hang each engine.
Specifically, in this case the IP block .

Maybe that is not possible, and (I think you are hinting at it), one cannot
reset an individual IP block. So the approach is to suspend the card, and then
do a full reset of the entire card, then resume.

I think a different suspend process would be better.
We have a for_each within the suspend code. The output of that code should not
be a single error code, but instead an array indicating the current state of
each engine (running/hung), the intended state and status of whether the
intention worked or failed. If the loop through the for_each, it could compare
the current state and intended state, and attempt to reach the intended state,
and report an error code for each engine. Then the code to achieve the
transition can been different depending on the current -> intended transition.
i.e. code for running -> suspended, can be different than code for hung ->
suspended. The code already needs to know which engines are enabled/disabled 
(Vega 56 vs Vega 64)

I can hang this IP block  at will. I have 2 games that hang it within
seconds of starting.

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

Re: [PATCH 1/2] dt-bindings: Add CDTech S050WV43-CT5 panel bindings

[Rob Herring]

On Thu, 18 Apr 2019 00:38:44 +0100, Florent TOMASIN wrote:
> Add documentation for S050WV43-CT5 panel
> 
> Signed-off-by: Florent TOMASIN 
> ---
>  .../bindings/display/panel/cdtech,s050wv43-ct5.txt   | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/cdtech,s050wv43-ct5.txt
> 

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

[drm-intel:topic/core-for-CI 16/16] drivers//acpi/processor_driver.c:69:7: error: 'INTEL_FAM6_ICELAKE_MOBILE' undeclared here (not in a function)

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head:   5172ea7b473b47bf94d78cabdce3dc8eb6c4e976
commit: 5172ea7b473b47bf94d78cabdce3dc8eb6c4e976 [16/16] ICL HACK: Disable ACPI 
idle driver
config: ia64-gensparse_defconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5172ea7b473b47bf94d78cabdce3dc8eb6c4e976
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=ia64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   drivers//acpi/processor_driver.c:67:23: error: 'X86_VENDOR_INTEL' undeclared 
here (not in a function); did you mean 'X86_VENDOR_ANY'?
#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
  ^~~~
   drivers//acpi/processor_driver.c:69:2: note: in expansion of macro 'ICPU'
 ICPU(INTEL_FAM6_ICELAKE_MOBILE), /* ICL */
 ^~~~
>> drivers//acpi/processor_driver.c:69:7: error: 'INTEL_FAM6_ICELAKE_MOBILE' 
>> undeclared here (not in a function)
 ICPU(INTEL_FAM6_ICELAKE_MOBILE), /* ICL */
  ^
   drivers//acpi/processor_driver.c:67:44: note: in definition of macro 'ICPU'
#define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
   ^
   drivers//acpi/processor_driver.c: In function '__acpi_processor_start':
   drivers//acpi/processor_driver.c:256:7: error: implicit declaration of 
function 'x86_match_cpu'; did you mean 'on_each_cpu'? 
[-Werror=implicit-function-declaration]
 id = x86_match_cpu(intel_cpu_ids);
  ^
  on_each_cpu
   drivers//acpi/processor_driver.c:256:5: warning: assignment to 'const struct 
x86_cpu_id *' from 'int' makes pointer from integer without a cast 
[-Wint-conversion]
 id = x86_match_cpu(intel_cpu_ids);
^
   cc1: some warnings being treated as errors

vim +/INTEL_FAM6_ICELAKE_MOBILE +69 drivers//acpi/processor_driver.c

66  
  > 67  #define ICPU(model) { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
68  static const struct x86_cpu_id intel_cpu_ids[] = {
  > 69  ICPU(INTEL_FAM6_ICELAKE_MOBILE),/* ICL */
70  {}
71  };
72  MODULE_DEVICE_TABLE(x86cpu, intel_cpu_ids);
73  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110509] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher  ---
(In reply to James.Dutton from comment #8)
> Thank you for the feedback.
> Is there a data sheet somewhere that might help me work out a fix for this.
> What I would like is:
> 1) A way to scan all the engines and detect which ones have hung.

If the gpu scheduler for a queue on a particular engine times out, you can be
pretty sure the engine has hung.  At that point you can check the current busy
status for the block (IP is_idle() callback).

> 2) A way to intentionally halt an engine and tidy up. So that the modprobe,
> rmmod, modprobe scenario works. 

hw_fini() IP callback.

> 3) data sheet details regarding how to un-hang each engine.
> Specifically, in this case the IP block .

Each IP has a soft reset (implemented via the IP soft_reset() callback), but
depending on the hang, in some cases, you may have to do a full GPU reset to
recover.  This is not a hw hang, it's a sw deadlock.  

> 
> Maybe that is not possible, and (I think you are hinting at it), one cannot
> reset an individual IP block. So the approach is to suspend the card, and
> then do a full reset of the entire card, then resume.

All asics support full GPU reset which is implemented via the SOC level
amdgpu_asic_funcs reset() callback.

> 
> I think a different suspend process would be better.
> We have a for_each within the suspend code. The output of that code should
> not be a single error code, but instead an array indicating the current
> state of each engine (running/hung), the intended state and status of
> whether the intention worked or failed. If the loop through the for_each, it
> could compare the current state and intended state, and attempt to reach the
> intended state, and report an error code for each engine. Then the code to
> achieve the transition can been different depending on the current ->
> intended transition.
> i.e. code for running -> suspended, can be different than code for hung ->
> suspended. The code already needs to know which engines are enabled/disabled
> (Vega 56 vs Vega 64)

We don't really care of the suspend fails or not.  See
amdgpu_device_gpu_recover() for the full sequence.

> 
> I can hang this IP block  at will. I have 2 games that hang it within
> seconds of starting.

There was a deadlock in the dm code which has been fixed.  Please try a new
code base.  e.g.,
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-5.2-wip

-- 
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 110472] Graphical Fault (Desktop Freeze) on Specific OpenGL Application

[bugzilla-daemon]

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

--- Comment #1 from gpiza...@javaman.net ---
Bump? Thanks to someone for moving my thread to the correct category, so
hopefully I'll get some sort of response soon :)

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

[PATCH v1 0/2] drm/komeda: Add SMMU support on Komeda driver

[Lowry Li (Arm Technology China)]

Hi,

This serie aims at adding the support for SMMU on Komeda driver.
Also updates the device-tree doc about how to enable SMMU by devicetree.

This patch series depends on:
- https://patchwork.freedesktop.org/series/58710/
- https://patchwork.freedesktop.org/series/59000/
- https://patchwork.freedesktop.org/series/59002/

Thanks,
Lowry

Lowry Li (Arm Technology China) (2):
  drm/komeda: Adds SMMU support
  dt/bindings: drm/komeda: Adds SMMU support for D71 devicetree

 .../devicetree/bindings/display/arm,komeda.txt |  7 
 .../gpu/drm/arm/display/komeda/d71/d71_component.c |  5 +++
 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c   | 49 ++
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 17 
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h|  7 
 .../drm/arm/display/komeda/komeda_framebuffer.c|  2 +
 .../drm/arm/display/komeda/komeda_framebuffer.h|  2 +
 7 files changed, 89 insertions(+)

-- 
1.9.1

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

[PATCH v1 1/2] drm/komeda: Adds SMMU support

[Lowry Li (Arm Technology China)]

Adds iommu_connect and disconnect for SMMU support, and configures
TBU translation once SMMU has been attached to the display device.

Signed-off-by: Lowry Li (Arm Technology China) 
---
 .../gpu/drm/arm/display/komeda/d71/d71_component.c |  5 +++
 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c   | 49 ++
 drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 17 
 drivers/gpu/drm/arm/display/komeda/komeda_dev.h|  7 
 .../drm/arm/display/komeda/komeda_framebuffer.c|  2 +
 .../drm/arm/display/komeda/komeda_framebuffer.h|  2 +
 6 files changed, 82 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 33ca171..9065040 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -215,6 +215,8 @@ static void d71_layer_update(struct komeda_component *c,
malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
 
+   if (kfb->is_va)
+   ctrl |= L_TBU_EN;
malidp_write32_mask(reg, BLK_CONTROL, ctrl_mask, ctrl);
 }
 
@@ -348,6 +350,9 @@ static void d71_wb_layer_update(struct komeda_component *c,
   fb->pitches[i] & 0x);
}
 
+   if (kfb->is_va)
+   ctrl |= LW_TBU_EN;
+
malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 9603de9..45c98a7 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -517,6 +517,53 @@ static void d71_init_fmt_tbl(struct komeda_dev *mdev)
table->n_formats = ARRAY_SIZE(d71_format_caps_table);
 }
 
+static int d71_connect_iommu(struct komeda_dev *mdev)
+{
+   struct d71_dev *d71 = mdev->chip_data;
+   u32 __iomem *reg = d71->gcu_addr;
+   u32 check_bits = (d71->num_pipelines == 2) ?
+GCU_STATUS_TCS0 | GCU_STATUS_TCS1 : GCU_STATUS_TCS0;
+   int i, ret;
+
+   if (!d71->integrates_tbu)
+   return -1;
+
+   malidp_write32_mask(reg, BLK_CONTROL, 0x7, TBU_CONNECT_MODE);
+
+   ret = dp_wait_cond(has_bits(check_bits, malidp_read32(reg, BLK_STATUS)),
+   100, 1000, 1000);
+   if (ret <= 0) {
+   DRM_ERROR("connect to TCU timeout!\n");
+   malidp_write32_mask(reg, BLK_CONTROL, 0x7, INACTIVE_MODE);
+   return -ETIMEDOUT;
+   }
+
+   for (i = 0; i < d71->num_pipelines; i++)
+   malidp_write32_mask(d71->pipes[i]->lpu_addr, LPU_TBU_CONTROL,
+   LPU_TBU_CTRL_TLBPEN, LPU_TBU_CTRL_TLBPEN);
+   return 0;
+}
+
+static int d71_disconnect_iommu(struct komeda_dev *mdev)
+{
+   struct d71_dev *d71 = mdev->chip_data;
+   u32 __iomem *reg = d71->gcu_addr;
+   u32 check_bits = (d71->num_pipelines == 2) ?
+GCU_STATUS_TCS0 | GCU_STATUS_TCS1 : GCU_STATUS_TCS0;
+   int ret;
+
+   malidp_write32_mask(reg, BLK_CONTROL, 0x7, TBU_DISCONNECT_MODE);
+
+   ret = dp_wait_cond(((malidp_read32(reg, BLK_STATUS) & check_bits) == 0),
+   100, 1000, 1000);
+   if (ret <= 0) {
+   DRM_ERROR("disconnect from TCU timeout!\n");
+   malidp_write32_mask(reg, BLK_CONTROL, 0x7, INACTIVE_MODE);
+   }
+
+   return ret > 0 ? 0 : -1;
+}
+
 static struct komeda_dev_funcs d71_chip_funcs = {
.init_format_table = d71_init_fmt_tbl,
.enum_resources = d71_enum_resources,
@@ -527,6 +574,8 @@ static void d71_init_fmt_tbl(struct komeda_dev *mdev)
.on_off_vblank  = d71_on_off_vblank,
.change_opmode  = d71_change_opmode,
.flush  = d71_flush,
+   .connect_iommu  = d71_connect_iommu,
+   .disconnect_iommu = d71_disconnect_iommu,
 };
 
 struct komeda_dev_funcs *
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index e4e5b58..2d97c82 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -251,6 +251,18 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
dev->dma_parms = &mdev->dma_parms;
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
+   mdev->iommu = iommu_get_domain_for_dev(mdev->dev);
+   if (!mdev->iommu)
+   DRM_INFO("continue without IOMMU support!\n");
+
+   if (mdev->iommu && mdev->funcs->connect_iommu) {
+   err = mdev->funcs->connect_iommu(mdev);
+   if (err) {
+   DRM_ERROR("connect iommu failed.\

[PATCH v1 2/2] dt/bindings: drm/komeda: Adds SMMU support for D71 devicetree

[Lowry Li (Arm Technology China)]

Updates the device-tree doc about how to enable SMMU by devicetree.

Signed-off-by: Lowry Li (Arm Technology China) 
---
 Documentation/devicetree/bindings/display/arm,komeda.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/arm,komeda.txt 
b/Documentation/devicetree/bindings/display/arm,komeda.txt
index 02b2265..b12c045 100644
--- a/Documentation/devicetree/bindings/display/arm,komeda.txt
+++ b/Documentation/devicetree/bindings/display/arm,komeda.txt
@@ -11,6 +11,10 @@ Required properties:
   - "pclk": for the APB interface clock
 - #address-cells: Must be 1
 - #size-cells: Must be 0
+- iommus: configure the stream id to IOMMU, Must be configured if want to
+enable iommu in display. for how to configure this node please reference
+devicetree/bindings/iommu/arm,smmu-v3.txt,
+devicetree/bindings/iommu/iommu.txt
 
 Required properties for sub-node: pipeline@nq
 Each device contains one or two pipeline sub-nodes (at least one), each
@@ -44,6 +48,9 @@ Example:
interrupts = <0 168 4>;
clocks = <&dpu_mclk>, <&dpu_aclk>;
clock-names = "mclk", "pclk";
+   iommus = <&smmu 0>, <&smmu 1>, <&smmu 2>, <&smmu 3>,
+   <&smmu 4>, <&smmu 5>, <&smmu 6>, <&smmu 7>,
+   <&smmu 8>, <&smmu 9>;
 
dp0_pipe0: pipeline@0 {
clocks = <&fpgaosc2>, <&dpu_aclk>;
-- 
1.9.1

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