Re: [PATCH v2 1/4] drm/msm: support firmware-name for zap fw (v2)

[Bjorn Andersson]

On Sun 12 Jan 11:53 PST 2020, Rob Clark wrote:

> From: Rob Clark 
> 
> Since zap firmware can be device specific, allow for a firmware-name
> property in the zap node to specify which firmware to load, similarly to
> the scheme used for dsp/wifi/etc.
> 
> v2: only need a single error msg when we can't load from firmware-name
> specified path, and fix comment [Bjorn A.]
> 

Reviewed-by: Bjorn Andersson 

> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30 ++---
>  1 file changed, 27 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 112e8b8a261e..456bb5af1717 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -26,6 +26,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> char *fwname,
>  {
>   struct device *dev = &gpu->pdev->dev;
>   const struct firmware *fw;
> + const char *signed_fwname = NULL;
>   struct device_node *np, *mem_np;
>   struct resource r;
>   phys_addr_t mem_phys;
> @@ -58,8 +59,31 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> char *fwname,
>  
>   mem_phys = r.start;
>  
> - /* Request the MDT file for the firmware */
> - fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> + /*
> +  * Check for a firmware-name property.  This is the new scheme
> +  * to handle firmware that may be signed with device specific
> +  * keys, allowing us to have a different zap fw path for different
> +  * devices.
> +  *
> +  * If the firmware-name property is found, we bypass the
> +  * adreno_request_fw() mechanism, because we don't need to handle
> +  * the /lib/firmware/qcom/* vs /lib/firmware/* case.
> +  *
> +  * If the firmware-name property is not found, for backwards
> +  * compatibility we fall back to the fwname from the gpulist
> +  * table.
> +  */
> + of_property_read_string_index(np, "firmware-name", 0, &signed_fwname);
> + if (signed_fwname) {
> + fwname = signed_fwname;
> + ret = request_firmware_direct(&fw, fwname, gpu->dev->dev);
> + if (ret)
> + fw = ERR_PTR(ret);
> + } else {
> + /* Request the MDT file from the default location: */
> + fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> + }
> +
>   if (IS_ERR(fw)) {
>   DRM_DEV_ERROR(dev, "Unable to load %s\n", fwname);
>   return PTR_ERR(fw);
> @@ -95,7 +119,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> char *fwname,
>* not.  But since we've already gotten through adreno_request_fw()
>* we know which of the two cases it is:
>*/
> - if (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY) {
> + if (signed_fwname || (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY)) 
> {
>   ret = qcom_mdt_load(dev, fw, fwname, pasid,
>   mem_region, mem_phys, mem_size, NULL);
>   } else {
> -- 
> 2.24.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH next] drm/i915: fix build error without ACPI

[Chen Zhou]

If CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=m, compilation complains
with undefined references:

drivers/gpu/drm/i915/display/intel_panel.o: In function 
`intel_backlight_device_register':
intel_panel.c:(.text+0x4dd9): undefined reference to `backlight_device_register'
drivers/gpu/drm/i915/display/intel_panel.o: In function 
`intel_backlight_device_unregister':
intel_panel.c:(.text+0x4e96): undefined reference to 
`backlight_device_unregister'

This patch select BACKLIGHT_CLASS_DEVICE directly.

Reported-by: Hulk Robot 
Signed-off-by: Chen Zhou 
---
 drivers/gpu/drm/i915/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index ba95959..6b69dab 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -16,7 +16,7 @@ config DRM_I915
select IRQ_WORK
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
-   select BACKLIGHT_CLASS_DEVICE if ACPI
+   select BACKLIGHT_CLASS_DEVICE
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
-- 
2.7.4

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

Re: [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Rob Clark]

On Mon, Jan 13, 2020 at 7:37 AM Brian Ho  wrote:
>
> Implements an ioctl to wait until a value at a given iova is greater
> than or equal to a supplied value.
>
> This will initially be used by turnip (open-source Vulkan driver for
> QC in mesa) for occlusion queries where the userspace driver can
> block on a query becoming available before continuing via
> vkGetQueryPoolResults.
>
> Signed-off-by: Brian Ho 
> ---
>  drivers/gpu/drm/msm/msm_drv.c | 63 +--
>  include/uapi/drm/msm_drm.h| 13 
>  2 files changed, 74 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index c84f0a8b3f2c..dcc46874a5a2 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -36,10 +36,11 @@
>   *   MSM_GEM_INFO ioctl.
>   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
>   *   GEM object's debug name
> - * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> + * - 1.5.0 - Add SUBMITQUEUE_QUERY ioctl
> + * - 1.6.0 - Add WAIT_IOVA ioctl
>   */
>  #define MSM_VERSION_MAJOR  1
> -#define MSM_VERSION_MINOR  5
> +#define MSM_VERSION_MINOR  6
>  #define MSM_VERSION_PATCHLEVEL 0
>
>  static const struct drm_mode_config_funcs mode_config_funcs = {
> @@ -952,6 +953,63 @@ static int msm_ioctl_submitqueue_close(struct drm_device 
> *dev, void *data,
> return msm_submitqueue_remove(file->driver_priv, id);
>  }
>
> +static int msm_ioctl_wait_iova(struct drm_device *dev, void *data,
> +   struct drm_file *file)
> +{
> +   struct msm_drm_private *priv = dev->dev_private;
> +   struct drm_gem_object *obj;
> +   struct drm_msm_wait_iova *args = data;
> +   ktime_t timeout = to_ktime(args->timeout);
> +   unsigned long remaining_jiffies = timeout_to_jiffies(&timeout);
> +   struct msm_gpu *gpu = priv->gpu;
> +   void *base_vaddr;
> +   uint64_t *vaddr;
> +   int ret;
> +
> +   if (args->pad)
> +   return -EINVAL;
> +
> +   if (!gpu)
> +   return 0;

hmm, I'm not sure we should return zero in this case.. maybe -ENODEV?

> +
> +   obj = drm_gem_object_lookup(file, args->handle);
> +   if (!obj)
> +   return -ENOENT;
> +
> +   base_vaddr = msm_gem_get_vaddr(obj);
> +   if (IS_ERR(base_vaddr)) {
> +   ret = PTR_ERR(base_vaddr);
> +   goto err_put_gem_object;
> +   }
> +   if (args->offset + sizeof(*vaddr) > obj->size) {
> +   ret = -EINVAL;
> +   goto err_put_vaddr;
> +   }
> +
> +   vaddr = base_vaddr + args->offset;
> +
> +   /* Assumes WC mapping */
> +   ret = wait_event_interruptible_timeout(
> +   gpu->event, *vaddr >= args->value, remaining_jiffies);
> +
> +   if (ret == 0) {
> +   ret = -ETIMEDOUT;
> +   goto err_put_vaddr;
> +   } else if (ret == -ERESTARTSYS) {
> +   goto err_put_vaddr;
> +   }

maybe:

 } else {
   ret = 0;
 }

and then drop the next three lines?

> +
> +   msm_gem_put_vaddr(obj);
> +   drm_gem_object_put_unlocked(obj);
> +   return 0;
> +
> +err_put_vaddr:
> +   msm_gem_put_vaddr(obj);
> +err_put_gem_object:
> +   drm_gem_object_put_unlocked(obj);
> +   return ret;
> +}
> +
>  static const struct drm_ioctl_desc msm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,  
> DRM_RENDER_ALLOW),
> @@ -964,6 +1022,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW,   msm_ioctl_submitqueue_new,   
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close, 
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, 
> DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(MSM_WAIT_IOVA, msm_ioctl_wait_iova, 
> DRM_RENDER_ALLOW),
>  };
>
>  static const struct vm_operations_struct vm_ops = {
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> index 0b85ed6a3710..8477f28a4ee1 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -298,6 +298,17 @@ struct drm_msm_submitqueue_query {
> __u32 pad;
>  };
>
> +/* This ioctl blocks until the u64 value at bo + offset is greater than or
> + * equal to the reference value.
> + */
> +struct drm_msm_wait_iova {
> +   __u32 handle;  /* in, GEM handle */
> +   __u32 pad;
> +   struct drm_msm_timespec timeout;   /* in */
> +   __u64 offset;  /* offset into bo */
> +   __u64 value;   /* reference value */

Maybe we should go ahead and add a __u64 mask;

that would let us wait for 32b values as well, and wait for bits in a bitmask

Other than those minor comments, it looks pretty good to me

BR,
-R

> +};
> +

[PATCH] drm/i915: Fix multiple definition of 'i915_vma_capture_finish'

[Zhang Xiaoxu]

If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there are some
errors like:

drivers/gpu/drm/i915/i915_irq.o:
In function `i915_vma_capture_finish':
./drivers/gpu/drm/i915/i915_gpu_error.h:312:
multiple definition of `i915_vma_capture_finish'
drivers/gpu/drm/i915/i915_drv.o:
./drivers/gpu/drm/i915/i915_gpu_error.h:312: first defined here

So, add 'static inline' on the defineation of the 'i915_vma_capture_finish'

Fixes: d713e3ab93fdc("drm/i915: Correct typo in i915_vma_compress_finish stub")
Reported-by: Hulk Robot 
Signed-off-by: Zhang Xiaoxu 
---
 drivers/gpu/drm/i915/i915_gpu_error.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 1b6dfcb79e14..6bc7e7c901ed 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -307,7 +307,7 @@ i915_vma_capture_prepare(struct intel_gt_coredump *gt)
return NULL;
 }
 
-void i915_vma_capture_finish(struct intel_gt_coredump *gt,
+static inline void i915_vma_capture_finish(struct intel_gt_coredump *gt,
 struct i915_vma_compress *compress)
 {
 }
-- 
2.17.2

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

[PATCH v3 2/3] dt-bindings: panel-simple: Add compatible for Frida FRD350H54004 LCD

[Paul Cercueil]

Add bindings documentation for the Frida 3.5" (320x240 pixels) 24-bit
TFT LCD panel.

v2: Switch documentation from plain text to YAML
v3: Simply add new compatible to panel-simple.yaml file instead of
adding new file

Signed-off-by: Paul Cercueil 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 8fe60ee2531c..4a8064e31793 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -37,6 +37,8 @@ properties:
   - auo,b116xa01
 # BOE NV140FHM-N49 14.0" FHD a-Si FT panel
   - boe,nv140fhmn49
+# Frida FRD350H54004 3.5" QVGA TFT LCD panel
+  - frida,frd350h54004
 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
   - giantplus,gpm940b0
 # Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel
-- 
2.24.1

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

[PATCH 1/2] drm/msm: Add a GPU-wide wait queue

[Brian Ho]

This wait queue is signaled on all IRQs for a given GPU and will be
used as part of the new MSM_WAIT_IOVA ioctl so userspace can sleep
until the value at a given iova reaches a certain condition.

Signed-off-by: Brian Ho 
---
 drivers/gpu/drm/msm/msm_gpu.c | 4 
 drivers/gpu/drm/msm/msm_gpu.h | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index a052364a5d74..d7310c1336e5 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -779,6 +779,8 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 static irqreturn_t irq_handler(int irq, void *data)
 {
struct msm_gpu *gpu = data;
+   wake_up_all(&gpu->event);
+
return gpu->funcs->irq(gpu);
 }
 
@@ -871,6 +873,8 @@ int msm_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
 
spin_lock_init(&gpu->perf_lock);
 
+   init_waitqueue_head(&gpu->event);
+
 
/* Map registers: */
gpu->mmio = msm_ioremap(pdev, config->ioname, name);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index ab8f0f9c9dc8..60562f065dbc 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -104,6 +104,9 @@ struct msm_gpu {
 
struct msm_gem_address_space *aspace;
 
+   /* GPU-wide wait queue that is signaled on all IRQs */
+   wait_queue_head_t event;
+
/* Power Control: */
struct regulator *gpu_reg, *gpu_cx;
struct clk_bulk_data *grp_clks;
-- 
2.25.0.rc1.283.g88dfdc4193-goog

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

[PATCH] drm/i915/dsi: Fix implicit declaration of function 'acpi_dev*' in 'mipi_exec_i2c'

[Zhang Xiaoxu]

If no 'CONFIG_ACPI' configured, shouldn't call 'acpi_device_handle',
'acpi_dev_get_resources' and 'acpi_dev_free_resource_list' in function
'mipi_exec_i2c'.

Fixes: 8cbf89db2941("drm/i915/dsi: Parse the I2C element from the VBT MIPI 
sequence block (v3)")
Reported-by: Hulk Robot 
Signed-off-by: Zhang Xiaoxu 
---
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index 89fb0d90b694..73a25e7ae090 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -384,6 +384,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
return data;
 }
 
+#ifdef CONFIG_ACPI
 static int i2c_adapter_lookup(struct acpi_resource *ares, void *data)
 {
struct i2c_adapter_lookup *lookup = data;
@@ -399,7 +400,6 @@ static int i2c_adapter_lookup(struct acpi_resource *ares, 
void *data)
 
if (lookup->slave_addr != sb->slave_address)
return 1;
-
status = acpi_get_handle(lookup->dev_handle,
 sb->resource_source.string_ptr,
 &adapter_handle);
@@ -412,15 +412,13 @@ static int i2c_adapter_lookup(struct acpi_resource *ares, 
void *data)
 
return 1;
 }
+#endif
 
 static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
 {
struct drm_device *drm_dev = intel_dsi->base.base.dev;
struct device *dev = &drm_dev->pdev->dev;
struct i2c_adapter *adapter;
-   struct acpi_device *acpi_dev;
-   struct list_head resource_list;
-   struct i2c_adapter_lookup lookup;
struct i2c_msg msg;
int ret;
u8 vbt_i2c_bus_num = *(data + 2);
@@ -430,8 +428,13 @@ static const u8 *mipi_exec_i2c(struct intel_dsi 
*intel_dsi, const u8 *data)
u8 *payload_data;
 
if (intel_dsi->i2c_bus_num < 0) {
+#ifdef CONFIG_ACPI
+   struct acpi_device *acpi_dev;
+   struct list_head resource_list;
+   struct i2c_adapter_lookup lookup;
+#endif
intel_dsi->i2c_bus_num = vbt_i2c_bus_num;
-
+#ifdef CONFIG_ACPI
acpi_dev = ACPI_COMPANION(dev);
if (acpi_dev) {
memset(&lookup, 0, sizeof(lookup));
@@ -445,6 +448,7 @@ static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, 
const u8 *data)
   &lookup);
acpi_dev_free_resource_list(&resource_list);
}
+#endif
}
 
adapter = i2c_get_adapter(intel_dsi->i2c_bus_num);
-- 
2.17.2

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

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Rob Clark]

On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse  wrote:
>
> On Mon, Jan 13, 2020 at 10:36:05AM -0500, Brian Ho wrote:
> > Implements an ioctl to wait until a value at a given iova is greater
> > than or equal to a supplied value.
> >
> > This will initially be used by turnip (open-source Vulkan driver for
> > QC in mesa) for occlusion queries where the userspace driver can
> > block on a query becoming available before continuing via
> > vkGetQueryPoolResults.
> >
> > Signed-off-by: Brian Ho 
> > ---
> >  drivers/gpu/drm/msm/msm_drv.c | 63 +--
> >  include/uapi/drm/msm_drm.h| 13 
> >  2 files changed, 74 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index c84f0a8b3f2c..dcc46874a5a2 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -36,10 +36,11 @@
> >   *   MSM_GEM_INFO ioctl.
> >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
> >   *   GEM object's debug name
> > - * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > + * - 1.5.0 - Add SUBMITQUEUE_QUERY ioctl
> > + * - 1.6.0 - Add WAIT_IOVA ioctl
> >   */
> >  #define MSM_VERSION_MAJOR1
> > -#define MSM_VERSION_MINOR5
> > +#define MSM_VERSION_MINOR6
> >  #define MSM_VERSION_PATCHLEVEL   0
> >
> >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > @@ -952,6 +953,63 @@ static int msm_ioctl_submitqueue_close(struct 
> > drm_device *dev, void *data,
> >   return msm_submitqueue_remove(file->driver_priv, id);
> >  }
> >
> > +static int msm_ioctl_wait_iova(struct drm_device *dev, void *data,
> > + struct drm_file *file)
> > +{
> > + struct msm_drm_private *priv = dev->dev_private;
> > + struct drm_gem_object *obj;
> > + struct drm_msm_wait_iova *args = data;
> > + ktime_t timeout = to_ktime(args->timeout);
> > + unsigned long remaining_jiffies = timeout_to_jiffies(&timeout);
> > + struct msm_gpu *gpu = priv->gpu;
> > + void *base_vaddr;
> > + uint64_t *vaddr;
> > + int ret;
> > +
> > + if (args->pad)
> > + return -EINVAL;
> > +
> > + if (!gpu)
> > + return 0;
>
> If the GPU isn't up, it should be an error since this macro is specifically
> designed for just the GPU (though, I suppose the display *COULD* use it to 
> watch
> a memory mapped register or something).
>
> > +
> > + obj = drm_gem_object_lookup(file, args->handle);
> > + if (!obj)
> > + return -ENOENT;
> > +
> > + base_vaddr = msm_gem_get_vaddr(obj);
> > + if (IS_ERR(base_vaddr)) {
> > + ret = PTR_ERR(base_vaddr);
> > + goto err_put_gem_object;
> > + }
> > + if (args->offset + sizeof(*vaddr) > obj->size) {
>
> There is a chance to trigger a u64 overflow here resulting in an arbitrary 
> (ish)
> vaddr two lines below.
>
>
> > + ret = -EINVAL;
> > + goto err_put_vaddr;
> > + }
>
> You can check this before getting the vaddr which would save you a clean up
> step.
>
> > +
> > + vaddr = base_vaddr + args->offset;
> > +
> > + /* Assumes WC mapping */
> > + ret = wait_event_interruptible_timeout(
> > + gpu->event, *vaddr >= args->value, remaining_jiffies);
>
> I feel like a barrier might be needed before checking *vaddr just in case you
> get the interrupt and wake up the queue before the write posts from the
> hardware.
>
> > +
>
> > + if (ret == 0) {
> > + ret = -ETIMEDOUT;
> > + goto err_put_vaddr;
> > + } else if (ret == -ERESTARTSYS) {
> > + goto err_put_vaddr;
> > + }
>
> You don't need either goto here because both paths execute the following 
> cleanup
> steps. I'm also not sure you need to worry about explicitly checking the
> ERESTARTSYS value, I think that this would be sufficient:
>
>  if (ret == 0)
>  ret = -ETIMEDOUT;
>  else if (ret > 0)
>  ret = 0;
>
> > +
>
> Put your err_put_vaddr: label here, but looking up, if you move the bounds 
> check
> before the msm_gem_get_vaddr, I don't think you need a label.
>
> > + msm_gem_put_vaddr(obj);
>
> Put the err_put_gem_object: label here.
>
> > + drm_gem_object_put_unlocked(obj);
> > + return 0;
>
> return ret;
>
> > +
> > +err_put_vaddr:
> > + msm_gem_put_vaddr(obj);
> > +err_put_gem_object:
> > + drm_gem_object_put_unlocked(obj);
> > + return ret;
> > +}
>
> And then these guys aren't needed.
>
> > +
> >  static const struct drm_ioctl_desc msm_ioctls[] = {
> >   DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
> > DRM_RENDER_ALLOW),
> >   DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,  
> > DRM_RENDER_ALLOW),
> > @@ -964,6 +1022,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
> >   DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW,   msm_ioctl_submitqueue_new,   
> > DRM_RENDER_ALLOW),
> >   DRM_IOCTL_DEF_DRV(MSM_

[PATCH v3 3/3] drm/panel: simple: Add support for the Frida FRD350H54004 panel

[Paul Cercueil]

The FRD350H54004 is a simple 3.5" 320x240 24-bit TFT panel, found for
instance inside the Anbernic RG-350 handheld gaming console.

v2: Order alphabetically
v3: Add connector_type, and update timings according to the constraints
listed in the datasheet

Signed-off-by: Paul Cercueil 
---
 drivers/gpu/drm/panel/panel-simple.c | 30 
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac62b5..d6f77bc494c7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1440,6 +1440,33 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct drm_display_mode frida_frd350h54004_mode = {
+   .clock = 6000,
+   .hdisplay = 320,
+   .hsync_start = 320 + 44,
+   .hsync_end = 320 + 44 + 16,
+   .htotal = 320 + 44 + 16 + 20,
+   .vdisplay = 240,
+   .vsync_start = 240 + 2,
+   .vsync_end = 240 + 2 + 6,
+   .vtotal = 240 + 2 + 6 + 2,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc frida_frd350h54004 = {
+   .modes = &frida_frd350h54004_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 77,
+   .height = 64,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+   .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
 static const struct drm_display_mode friendlyarm_hd702e_mode = {
.clock  = 67185,
.hdisplay   = 800,
@@ -3309,6 +3336,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = &foxlink_fl500wvr00_a0t,
+   }, {
+   .compatible = "frida,frd350h54004",
+   .data = &frida_frd350h54004,
}, {
.compatible = "friendlyarm,hd702e",
.data = &friendlyarm_hd702e,
-- 
2.24.1

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

Re: [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Rob Clark]

On Mon, Jan 13, 2020 at 2:55 PM Brian Ho  wrote:
>
> On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote:
> > On Mon, Jan 13, 2020 at 8:25 AM Rob Clark  wrote:
> >
> > > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho  wrote:
> > > >
> > > > Implements an ioctl to wait until a value at a given iova is greater
> > > > than or equal to a supplied value.
> > > >
> > > > This will initially be used by turnip (open-source Vulkan driver for
> > > > QC in mesa) for occlusion queries where the userspace driver can
> > > > block on a query becoming available before continuing via
> > > > vkGetQueryPoolResults.
> > > >
> > > > Signed-off-by: Brian Ho 
> > > > ---
> > > >  drivers/gpu/drm/msm/msm_drv.c | 63 +--
> > > >  include/uapi/drm/msm_drm.h| 13 
> > > >  2 files changed, 74 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/msm_drv.c
> > > b/drivers/gpu/drm/msm/msm_drv.c
> > > > index c84f0a8b3f2c..dcc46874a5a2 100644
> > > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > > @@ -36,10 +36,11 @@
> > > >   *   MSM_GEM_INFO ioctl.
> > > >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to 
> > > > set/get
> > > >   *   GEM object's debug name
> > > > - * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > > > + * - 1.5.0 - Add SUBMITQUEUE_QUERY ioctl
> > > > + * - 1.6.0 - Add WAIT_IOVA ioctl
> > > >   */
> > > >  #define MSM_VERSION_MAJOR  1
> > > > -#define MSM_VERSION_MINOR  5
> > > > +#define MSM_VERSION_MINOR  6
> > > >  #define MSM_VERSION_PATCHLEVEL 0
> > > >
> > > >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > > > @@ -952,6 +953,63 @@ static int msm_ioctl_submitqueue_close(struct
> > > drm_device *dev, void *data,
> > > > return msm_submitqueue_remove(file->driver_priv, id);
> > > >  }
> > > >
> > > > +static int msm_ioctl_wait_iova(struct drm_device *dev, void *data,
> > > > +   struct drm_file *file)
> > > > +{
> > > > +   struct msm_drm_private *priv = dev->dev_private;
> > > > +   struct drm_gem_object *obj;
> > > > +   struct drm_msm_wait_iova *args = data;
> > > > +   ktime_t timeout = to_ktime(args->timeout);
> > > > +   unsigned long remaining_jiffies = timeout_to_jiffies(&timeout);
> > > > +   struct msm_gpu *gpu = priv->gpu;
> > > > +   void *base_vaddr;
> > > > +   uint64_t *vaddr;
> > > > +   int ret;
> > > > +
> > > > +   if (args->pad)
> > > > +   return -EINVAL;
> > > > +
> > > > +   if (!gpu)
> > > > +   return 0;
> > >
> > > hmm, I'm not sure we should return zero in this case.. maybe -ENODEV?
> > >
> > > > +
> > > > +   obj = drm_gem_object_lookup(file, args->handle);
> > > > +   if (!obj)
> > > > +   return -ENOENT;
> > > > +
> > > > +   base_vaddr = msm_gem_get_vaddr(obj);
> > > > +   if (IS_ERR(base_vaddr)) {
> > > > +   ret = PTR_ERR(base_vaddr);
> > > > +   goto err_put_gem_object;
> > > > +   }
> > > > +   if (args->offset + sizeof(*vaddr) > obj->size) {
> > > > +   ret = -EINVAL;
> > > > +   goto err_put_vaddr;
> > > > +   }
> > > > +
> > > > +   vaddr = base_vaddr + args->offset;
> > > > +
> > > > +   /* Assumes WC mapping */
> > > > +   ret = wait_event_interruptible_timeout(
> > > > +   gpu->event, *vaddr >= args->value,
> > > remaining_jiffies);
> > >
> >
> > This needs to do the awkward looking
> >
> >   (int64_t)(*data - value) >= 0
> >
> > to properly handle the wraparound case.
> >
>
> I think this comparison will run into issues if we allow for 64-bit
> reference values. For example, if value is ULLONG_MAX, and *data
> starts at 0 on the first comparison, we'll immediately return.
>
> It's not too much of an issue in fence_completed (msm_fence.c), but
> in this ioctl, *data can grow at an arbitrary rate. Are we concerned
> about this?
>
> > > +
> > > > +   if (ret == 0) {
> > > > +   ret = -ETIMEDOUT;
> > > > +   goto err_put_vaddr;
> > > > +   } else if (ret == -ERESTARTSYS) {
> > > > +   goto err_put_vaddr;
> > > > +   }
> > >
> > > maybe:
> > >
> > >  } else {
> > >ret = 0;
> > >  }
> > >
> > > and then drop the next three lines?
> > >
> > > > +
> > > > +   msm_gem_put_vaddr(obj);
> > > > +   drm_gem_object_put_unlocked(obj);
> > > > +   return 0;
> > > > +
> > > > +err_put_vaddr:
> > > > +   msm_gem_put_vaddr(obj);
> > > > +err_put_gem_object:
> > > > +   drm_gem_object_put_unlocked(obj);
> > > > +   return ret;
> > > > +}
> > > > +
> > > >  static const struct drm_ioctl_desc msm_ioctls[] = {
> > > > DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
> > > DRM_RENDER_ALLOW),
> > > > DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,
> > > DRM_RENDER_ALLOW),
> > > > @@ -964,6 +1022,7 @@ static 

[PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Brian Ho]

Implements an ioctl to wait until a value at a given iova is greater
than or equal to a supplied value.

This will initially be used by turnip (open-source Vulkan driver for
QC in mesa) for occlusion queries where the userspace driver can
block on a query becoming available before continuing via
vkGetQueryPoolResults.

Signed-off-by: Brian Ho 
---
 drivers/gpu/drm/msm/msm_drv.c | 63 +--
 include/uapi/drm/msm_drm.h| 13 
 2 files changed, 74 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c84f0a8b3f2c..dcc46874a5a2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -36,10 +36,11 @@
  *   MSM_GEM_INFO ioctl.
  * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
  *   GEM object's debug name
- * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
+ * - 1.5.0 - Add SUBMITQUEUE_QUERY ioctl
+ * - 1.6.0 - Add WAIT_IOVA ioctl
  */
 #define MSM_VERSION_MAJOR  1
-#define MSM_VERSION_MINOR  5
+#define MSM_VERSION_MINOR  6
 #define MSM_VERSION_PATCHLEVEL 0
 
 static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -952,6 +953,63 @@ static int msm_ioctl_submitqueue_close(struct drm_device 
*dev, void *data,
return msm_submitqueue_remove(file->driver_priv, id);
 }
 
+static int msm_ioctl_wait_iova(struct drm_device *dev, void *data,
+   struct drm_file *file)
+{
+   struct msm_drm_private *priv = dev->dev_private;
+   struct drm_gem_object *obj;
+   struct drm_msm_wait_iova *args = data;
+   ktime_t timeout = to_ktime(args->timeout);
+   unsigned long remaining_jiffies = timeout_to_jiffies(&timeout);
+   struct msm_gpu *gpu = priv->gpu;
+   void *base_vaddr;
+   uint64_t *vaddr;
+   int ret;
+
+   if (args->pad)
+   return -EINVAL;
+
+   if (!gpu)
+   return 0;
+
+   obj = drm_gem_object_lookup(file, args->handle);
+   if (!obj)
+   return -ENOENT;
+
+   base_vaddr = msm_gem_get_vaddr(obj);
+   if (IS_ERR(base_vaddr)) {
+   ret = PTR_ERR(base_vaddr);
+   goto err_put_gem_object;
+   }
+   if (args->offset + sizeof(*vaddr) > obj->size) {
+   ret = -EINVAL;
+   goto err_put_vaddr;
+   }
+
+   vaddr = base_vaddr + args->offset;
+
+   /* Assumes WC mapping */
+   ret = wait_event_interruptible_timeout(
+   gpu->event, *vaddr >= args->value, remaining_jiffies);
+
+   if (ret == 0) {
+   ret = -ETIMEDOUT;
+   goto err_put_vaddr;
+   } else if (ret == -ERESTARTSYS) {
+   goto err_put_vaddr;
+   }
+
+   msm_gem_put_vaddr(obj);
+   drm_gem_object_put_unlocked(obj);
+   return 0;
+
+err_put_vaddr:
+   msm_gem_put_vaddr(obj);
+err_put_gem_object:
+   drm_gem_object_put_unlocked(obj);
+   return ret;
+}
+
 static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,  
DRM_RENDER_ALLOW),
@@ -964,6 +1022,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW,   msm_ioctl_submitqueue_new,   
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(MSM_WAIT_IOVA, msm_ioctl_wait_iova, DRM_RENDER_ALLOW),
 };
 
 static const struct vm_operations_struct vm_ops = {
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 0b85ed6a3710..8477f28a4ee1 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -298,6 +298,17 @@ struct drm_msm_submitqueue_query {
__u32 pad;
 };
 
+/* This ioctl blocks until the u64 value at bo + offset is greater than or
+ * equal to the reference value.
+ */
+struct drm_msm_wait_iova {
+   __u32 handle;  /* in, GEM handle */
+   __u32 pad;
+   struct drm_msm_timespec timeout;   /* in */
+   __u64 offset;  /* offset into bo */
+   __u64 value;   /* reference value */
+};
+
 #define DRM_MSM_GET_PARAM  0x00
 /* placeholder:
 #define DRM_MSM_SET_PARAM  0x01
@@ -315,6 +326,7 @@ struct drm_msm_submitqueue_query {
 #define DRM_MSM_SUBMITQUEUE_NEW0x0A
 #define DRM_MSM_SUBMITQUEUE_CLOSE  0x0B
 #define DRM_MSM_SUBMITQUEUE_QUERY  0x0C
+#define DRM_MSM_WAIT_IOVA  0x0D
 
 #define DRM_IOCTL_MSM_GET_PARAMDRM_IOWR(DRM_COMMAND_BASE + 
DRM_MSM_GET_PARAM, struct drm_msm_param)
 #define DRM_IOCTL_MSM_GEM_NEW  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_MSM_GEM_NEW, struct drm_msm_gem_new)
@@ -327,6 +339,7 @@ struct drm_msm_submitqueue_query {
 #define DRM_IOCTL_MSM_SUBMITQU

Re: [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Brian Ho]

On Mon, Jan 13, 2020 at 09:57:43AM -0800, Kristian Kristensen wrote:
> On Mon, Jan 13, 2020 at 8:25 AM Rob Clark  wrote:
> 
> > On Mon, Jan 13, 2020 at 7:37 AM Brian Ho  wrote:
> > >
> > > Implements an ioctl to wait until a value at a given iova is greater
> > > than or equal to a supplied value.
> > >
> > > This will initially be used by turnip (open-source Vulkan driver for
> > > QC in mesa) for occlusion queries where the userspace driver can
> > > block on a query becoming available before continuing via
> > > vkGetQueryPoolResults.
> > >
> > > Signed-off-by: Brian Ho 
> > > ---
> > >  drivers/gpu/drm/msm/msm_drv.c | 63 +--
> > >  include/uapi/drm/msm_drm.h| 13 
> > >  2 files changed, 74 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_drv.c
> > b/drivers/gpu/drm/msm/msm_drv.c
> > > index c84f0a8b3f2c..dcc46874a5a2 100644
> > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > @@ -36,10 +36,11 @@
> > >   *   MSM_GEM_INFO ioctl.
> > >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
> > >   *   GEM object's debug name
> > > - * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > > + * - 1.5.0 - Add SUBMITQUEUE_QUERY ioctl
> > > + * - 1.6.0 - Add WAIT_IOVA ioctl
> > >   */
> > >  #define MSM_VERSION_MAJOR  1
> > > -#define MSM_VERSION_MINOR  5
> > > +#define MSM_VERSION_MINOR  6
> > >  #define MSM_VERSION_PATCHLEVEL 0
> > >
> > >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > > @@ -952,6 +953,63 @@ static int msm_ioctl_submitqueue_close(struct
> > drm_device *dev, void *data,
> > > return msm_submitqueue_remove(file->driver_priv, id);
> > >  }
> > >
> > > +static int msm_ioctl_wait_iova(struct drm_device *dev, void *data,
> > > +   struct drm_file *file)
> > > +{
> > > +   struct msm_drm_private *priv = dev->dev_private;
> > > +   struct drm_gem_object *obj;
> > > +   struct drm_msm_wait_iova *args = data;
> > > +   ktime_t timeout = to_ktime(args->timeout);
> > > +   unsigned long remaining_jiffies = timeout_to_jiffies(&timeout);
> > > +   struct msm_gpu *gpu = priv->gpu;
> > > +   void *base_vaddr;
> > > +   uint64_t *vaddr;
> > > +   int ret;
> > > +
> > > +   if (args->pad)
> > > +   return -EINVAL;
> > > +
> > > +   if (!gpu)
> > > +   return 0;
> >
> > hmm, I'm not sure we should return zero in this case.. maybe -ENODEV?
> >
> > > +
> > > +   obj = drm_gem_object_lookup(file, args->handle);
> > > +   if (!obj)
> > > +   return -ENOENT;
> > > +
> > > +   base_vaddr = msm_gem_get_vaddr(obj);
> > > +   if (IS_ERR(base_vaddr)) {
> > > +   ret = PTR_ERR(base_vaddr);
> > > +   goto err_put_gem_object;
> > > +   }
> > > +   if (args->offset + sizeof(*vaddr) > obj->size) {
> > > +   ret = -EINVAL;
> > > +   goto err_put_vaddr;
> > > +   }
> > > +
> > > +   vaddr = base_vaddr + args->offset;
> > > +
> > > +   /* Assumes WC mapping */
> > > +   ret = wait_event_interruptible_timeout(
> > > +   gpu->event, *vaddr >= args->value,
> > remaining_jiffies);
> >
> 
> This needs to do the awkward looking
> 
>   (int64_t)(*data - value) >= 0
> 
> to properly handle the wraparound case.
>

I think this comparison will run into issues if we allow for 64-bit
reference values. For example, if value is ULLONG_MAX, and *data
starts at 0 on the first comparison, we'll immediately return.

It's not too much of an issue in fence_completed (msm_fence.c), but
in this ioctl, *data can grow at an arbitrary rate. Are we concerned
about this?

> > +
> > > +   if (ret == 0) {
> > > +   ret = -ETIMEDOUT;
> > > +   goto err_put_vaddr;
> > > +   } else if (ret == -ERESTARTSYS) {
> > > +   goto err_put_vaddr;
> > > +   }
> >
> > maybe:
> >
> >  } else {
> >ret = 0;
> >  }
> >
> > and then drop the next three lines?
> >
> > > +
> > > +   msm_gem_put_vaddr(obj);
> > > +   drm_gem_object_put_unlocked(obj);
> > > +   return 0;
> > > +
> > > +err_put_vaddr:
> > > +   msm_gem_put_vaddr(obj);
> > > +err_put_gem_object:
> > > +   drm_gem_object_put_unlocked(obj);
> > > +   return ret;
> > > +}
> > > +
> > >  static const struct drm_ioctl_desc msm_ioctls[] = {
> > > DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
> > DRM_RENDER_ALLOW),
> > > DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,
> > DRM_RENDER_ALLOW),
> > > @@ -964,6 +1022,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
> > > DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW,
> >  msm_ioctl_submitqueue_new,   DRM_RENDER_ALLOW),
> > > DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE,
> > msm_ioctl_submitqueue_close, DRM_RENDER_ALLOW),
> > > DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY,
> > msm_ioct

[PATCH] drm/i915: convert to new logging macros based on struct intel_engine_cs.

[Wambui Karuga]

This patch extracts the struct drm_i915_private device from struct
intel_engine_cs and converts the printk based logging macros to the
struct drm_based logging macros using the extracted struct.
This transformation was achieved using the following coccinelle script:
@rule1@
identifier fn, T, E;
@@

fn(struct intel_engine_cs *T,...) {
struct drm_i915_private *E = ...;
<+...
(
-DRM_INFO(
+drm_info(&E->drm,
...)
|
-DRM_ERROR(
+drm_err(&E->drm,
...)
|
-DRM_WARN(
+drm_warn(&E->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&E->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&E->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&E->drm,
...)
)
...+>
}

@rule2@
identifier fn, E;
@@

fn(...) {
...
struct intel_engine_cs *E = ...;
+struct drm_i915_private *dev_priv = E->i915;
<+...
(
-DRM_INFO(
+drm_info(&dev_priv->drm,
...)
|
-DRM_ERROR(
+drm_err(&dev_priv->drm,
...)
|
-DRM_WARN(
+drm_warn(&dev_priv->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&dev_priv->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&dev_priv->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&E->drm,
...)
)
...+>
}

@rule3@
identifier fn, E;
@@

fn(struct intel_engine_cs *E,...) {
+struct drm_i915_private *dev_priv = E->i915;
<+...
(
-DRM_INFO(
+drm_info(&dev_priv->drm,
...)
|
-DRM_ERROR(
+drm_err(&dev_priv->drm,
...)
|
-DRM_WARN(
+drm_warn(&dev_priv->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&dev_priv->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&dev_priv->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&dev_priv->drm,
...)
)
...+>
}

Checkpatch warnings were addressed manually.

Signed-off-by: Wambui Karuga 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  3 +-
 drivers/gpu/drm/i915/gt/intel_lrc.c   | 12 ++-
 drivers/gpu/drm/i915/gt/intel_reset.c | 19 ++--
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 33 +++
 drivers/gpu/drm/i915/i915_cmd_parser.c| 88 +++
 5 files changed, 94 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f451ef376548..10b4ed74b416 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -532,6 +532,7 @@ static int pin_ggtt_status_page(struct intel_engine_cs 
*engine,
 
 static int init_status_page(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *dev_priv = engine->i915;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
void *vaddr;
@@ -546,7 +547,7 @@ static int init_status_page(struct intel_engine_cs *engine)
 */
obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
if (IS_ERR(obj)) {
-   DRM_ERROR("Failed to allocate status page\n");
+   drm_err(&dev_priv->drm, "Failed to allocate status page\n");
return PTR_ERR(obj);
}
 
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 9af1b2b493f4..f2a260efb75f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2943,6 +2943,7 @@ typedef u32 *(*wa_bb_func_t)(struct intel_engine_cs 
*engine, u32 *batch);
 
 static int intel_init_workaround_bb(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *dev_priv = engine->i915;
struct i915_ctx_workarounds *wa_ctx = &engine->wa_ctx;
struct i915_wa_ctx_bb *wa_bb[2] = { &wa_ctx->indirect_ctx,
&wa_ctx->per_ctx };
@@ -2978,7 +2979,8 @@ static int intel_init_workaround_bb(struct 
intel_engine_cs *engine)
 
ret = lrc_setup_wa_ctx(engine);
if (ret) {
-   DRM_DEBUG_DRIVER("Failed to setup context WA page: %d\n", ret);
+   drm_dbg(&dev_priv->drm,
+   "Failed to setup context WA page: %d\n", ret);
return ret;
}
 
@@ -3037,10 +3039,12 @@ static void enable_execlists(struct intel_engine_cs 
*engine)
 
 static bool unexpected_starting_state(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *dev_priv = engine->i915;
bool unexpected = false;
 
if (ENGINE_READ_FW(engine, RING_MI_MODE) & STOP_RING) {
-   DRM_DEBUG_DRIVER("STOP_RING still set in RING_MI_MODE\n");
+   drm_dbg(&dev_priv->drm,
+   "STOP_RING still set in RING_MI_MODE\n");
unexpected = true;
}
 
@@ -3976,6 +3980,7 @@ static void rcs_submission_override(struct 
intel_engine_cs *engine)
 
 int intel_execlists_submission_setup(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *dev_priv = engine->i915;
struct intel_engine_execlists * const execlists = &engine->execlists;
struct drm_i915_private *i915 = engine->i915;
struct intel_uncore *uncore = engine->uncore;
@@ -3998,7 +4003,8 @@ int intel_execlists_submission_setup(struct 
intel_engine_cs *engine)
 * because we only expect rare glitches but nothing
 * critical to prevent us from using GPU
 

Re: [PATCH v2 4/4] arm64: dts: sdm845: move gpu zap nodes to per-device dts

[Bjorn Andersson]

On Sun 12 Jan 11:54 PST 2020, Rob Clark wrote:

> From: Rob Clark 
> 
> We want to specify per-device firmware-name, so move the zap node into
> the .dts file for individual boards/devices.  This lets us get rid of
> the /delete-node/ for cheza, which does not use zap.
> 

Reviewed-by: Bjorn Andersson 

> Signed-off-by: Rob Clark 
> ---
> v2: use 'sdm845' for subdir for devices that use test-key signed fw
> 
>  arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi   | 1 -
>  arch/arm64/boot/dts/qcom/sdm845-db845c.dts   | 7 +++
>  arch/arm64/boot/dts/qcom/sdm845-mtp.dts  | 7 +++
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 +-
>  arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 7 +++
>  5 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> index 9a4ff57fc877..2db79c1ecdac 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> @@ -165,7 +165,6 @@ panel_in_edp: endpoint {
>  /delete-node/ &venus_mem;
>  /delete-node/ &cdsp_mem;
>  /delete-node/ &cdsp_pas;
> -/delete-node/ &zap_shader;
>  /delete-node/ &gpu_mem;
>  
>  /* Increase the size from 120 MB to 128 MB */
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts 
> b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> index d100f46791a6..6cd9201ffbbd 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts
> @@ -352,6 +352,13 @@ &gcc {
>  ;
>  };
>  
> +&gpu {
> + zap-shader {
> + memory-region = <&gpu_mem>;
> + firmware-name = "qcom/sdm845/a630_zap.mbn";
> + };
> +};
> +
>  &pm8998_gpio {
>   vol_up_pin_a: vol-up-active {
>   pins = "gpio6";
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index c57548b7b250..09ad37b0dd71 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -360,6 +360,13 @@ &gcc {
>  ;
>  };
>  
> +&gpu {
> + zap-shader {
> + memory-region = <&gpu_mem>;
> + firmware-name = "qcom/sdm845/a630_zap.mbn";
> + };
> +};
> +
>  &i2c10 {
>   status = "okay";
>   clock-frequency = <40>;
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index ddb1f23c936f..601c57cc9b6d 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -2804,7 +2804,7 @@ dsi1_phy: dsi-phy@ae96400 {
>   };
>   };
>  
> - gpu@500 {
> + gpu: gpu@500 {
>   compatible = "qcom,adreno-630.2", "qcom,adreno";
>   #stream-id-cells = <16>;
>  
> @@ -2824,10 +2824,6 @@ gpu@500 {
>  
>   qcom,gmu = <&gmu>;
>  
> - zap_shader: zap-shader {
> - memory-region = <&gpu_mem>;
> - };
> -
>   gpu_opp_table: opp-table {
>   compatible = "operating-points-v2";
>  
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts 
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> index 13dc619687f3..b255be3a4a0a 100644
> --- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -245,6 +245,13 @@ &gcc {
>  ;
>  };
>  
> +&gpu {
> + zap-shader {
> + memory-region = <&gpu_mem>;
> + firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn";
> + };
> +};
> +
>  &i2c1 {
>   status = "okay";
>   clock-frequency = <40>;
> -- 
> 2.24.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm_cflush_sg() loops for over 3ms

[David Laight]

I've been looking at why some RT processes don't get scheduled promptly.
In my test the RT process's affinity ties it to a single cpu (this may not be 
such
a good idea as it seems).

What I've found is that the Intel i915 graphics driver uses the 'events_unbound'
kernel worker thread to periodically execute drm_cflush_sg().
(see https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_cache.c)

I'm guessing this is to ensure that any writes to graphics memory become
visible is a semi-timely manner.

This loop takes about 1us per iteration split fairly evenly between whatever is 
in
for_each_sg_page() and drm_cflush_page().
With a 2560x1440 display the loop count is 3600 (4 bytes/pixel) and the whole
function takes around 3.3ms.

Since the kernel isn't pre-emptive (I though that wasn't much harder than SMP)
nothing else can run on that cpu until the loop finishes.

Adding a cond_resched() to the loop (maybe every 64 iterations) will
allow higher priority processes to run.
But really the code needs to be a lot faster.

I actually suspect that the (I assume IPI based) wbinv_on_all_cpus() would be
a lot faster - especially done by a per-cpu work queue?

I had moderate difficulty getting from the process (kworker/u8:3) to the
name of the worker thread pool, never mind the actual work.
Fortunately it runs so long that some of the output from 'echo t 
>/proc/sysrq-trigger'
still linked the pid (which I knew from ftrace scheduler events (and schedviz))
to the actual work item name.
(Oh, after I'd written a program to tidy up the raw ftrace output so schedviz
didn't barf on a trace that had wrapped.)

Is there anything in /proc (etc) that shows all the work queues and their 
current
work?

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

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

Re: [PATCH] drm/i915: convert to new logging macros based on struct intel_engine_cs.

[Wambui Karuga]

On Mon, 13 Jan 2020, Chris Wilson wrote:


Quoting Wambui Karuga (2020-01-13 11:10:25)

fn(...) {
...
struct intel_engine_cs *E = ...;
+struct drm_i915_private *dev_priv = E->i915;


No new dev_priv.

There should be no reason for drm_dbg here, as the rest of the debug is
behind ENGINE_TRACE and so the vestigial debug should be moved over, or
deleted as not being useful.

The error messages look unhelpful.
Hey Chris, could you please elaborate on the debugs that should be 
removed? These patches are for just converting the current debug 
instances, so removing them might need separate patches.


Thanks,
-wambui



if ((batch_end - cmd) < length) {
-   DRM_DEBUG("CMD: Command length exceeds batch length: 0x%08X 
length=%u batchlen=%td\n",
- *cmd,
- length,
- batch_end - cmd);
+   drm_dbg(&dev_priv->drm,
+   "CMD: Command length exceeds batch length: 0x%08X 
length=%u batchlen=%td\n",


No. This is not driver debug. If anything this should be pr_debug, or
some over user centric channel.
-Chris


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

Re: [Freedreno] [PATCH 1/2] drm/msm: Add a GPU-wide wait queue

[Rob Clark]

On Mon, Jan 13, 2020 at 9:55 AM Jordan Crouse  wrote:
>
> On Mon, Jan 13, 2020 at 10:36:04AM -0500, Brian Ho wrote:
> > This wait queue is signaled on all IRQs for a given GPU and will be
> > used as part of the new MSM_WAIT_IOVA ioctl so userspace can sleep
> > until the value at a given iova reaches a certain condition.
> >
> > Signed-off-by: Brian Ho 
> > ---
> >  drivers/gpu/drm/msm/msm_gpu.c | 4 
> >  drivers/gpu/drm/msm/msm_gpu.h | 3 +++
> >  2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > index a052364a5d74..d7310c1336e5 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > @@ -779,6 +779,8 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct 
> > msm_gem_submit *submit,
> >  static irqreturn_t irq_handler(int irq, void *data)
> >  {
> >   struct msm_gpu *gpu = data;
> > + wake_up_all(&gpu->event);
> > +
>
> I suppose it is intentional to have this happen on *all* interrupts because 
> you
> might be using the CP interrupts for fun and profit and you don't want to 
> plumb
> in callbacks?  I suppose it is okay to do this for all interrupts (including
> errors) but if we're spending a lot of time here we might want to only trigger
> on certain IRQs.

Was just talking to Kristian about GPU hangs.. and I suspect we might
want the ioctl to return an error if there is a gpu reset (so that
userspace can use the robustness uapi to test if the gpu reset was
something it cares about, etc)

Which is as good as a reason as I can think of the wake_up_all() on all irqs..

BR,
-R

>
> >   return gpu->funcs->irq(gpu);
> >  }
> >
> > @@ -871,6 +873,8 @@ int msm_gpu_init(struct drm_device *drm, struct 
> > platform_device *pdev,
> >
> >   spin_lock_init(&gpu->perf_lock);
> >
> > + init_waitqueue_head(&gpu->event);
> > +
> >
> >   /* Map registers: */
> >   gpu->mmio = msm_ioremap(pdev, config->ioname, name);
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> > index ab8f0f9c9dc8..60562f065dbc 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.h
> > +++ b/drivers/gpu/drm/msm/msm_gpu.h
> > @@ -104,6 +104,9 @@ struct msm_gpu {
> >
> >   struct msm_gem_address_space *aspace;
> >
> > + /* GPU-wide wait queue that is signaled on all IRQs */
> > + wait_queue_head_t event;
> > +
> >   /* Power Control: */
> >   struct regulator *gpu_reg, *gpu_cx;
> >   struct clk_bulk_data *grp_clks;
> > --
> > 2.25.0.rc1.283.g88dfdc4193-goog
> >
> > ___
> > Freedreno mailing list
> > freedr...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: convert to new logging macros based on struct intel_engine_cs.

[Wambui Karuga]

On Mon, 13 Jan 2020, Jani Nikula wrote:


On Mon, 13 Jan 2020, Chris Wilson  wrote:

Quoting Wambui Karuga (2020-01-13 11:10:25)

fn(...) {
...
struct intel_engine_cs *E = ...;
+struct drm_i915_private *dev_priv = E->i915;


No new dev_priv.


Wambui, we're gradually converting all dev_priv variable and parameter
names to i915.

Okay, I can change to that - dev_priv seemed more used in the files I 
changed.


Thanks,
wambui

There should be no reason for drm_dbg here, as the rest of the debug is
behind ENGINE_TRACE and so the vestigial debug should be moved over, or
deleted as not being useful.

The error messages look unhelpful.


I don't think you can expect any meaninful improvements on the debug
message contents from Wambui without detailed help at this point.




if ((batch_end - cmd) < length) {
-   DRM_DEBUG("CMD: Command length exceeds batch length: 0x%08X 
length=%u batchlen=%td\n",
- *cmd,
- length,
- batch_end - cmd);
+   drm_dbg(&dev_priv->drm,
+   "CMD: Command length exceeds batch length: 0x%08X 
length=%u batchlen=%td\n",


No. This is not driver debug. If anything this should be pr_debug, or
some over user centric channel.


I'm sorry, I still don't understand your reasoning here.

BR,
Jani.

--
Jani Nikula, Intel Open Source Graphics Center


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

[PATCH 0/2] drm/msm: Add the MSM_WAIT_IOVA ioctl

[Brian Ho]

This patch set implements the MSM_WAIT_IOVA ioctl which lets
userspace sleep until the value at a given iova reaches a certain
condition. This is needed in turnip to implement the
VK_QUERY_RESULT_WAIT_BIT flag for vkGetQueryPoolResults.

First, we add a GPU-wide wait queue that is signaled on all IRQs.
We can then wait on this wait queue inside MSM_WAIT_IOVA until the
condition is met.

The corresponding merge request in mesa can be found at:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3279

Brian Ho (2):
  drm/msm: Add a GPU-wide wait queue
  drm/msm: Add MSM_WAIT_IOVA ioctl

 drivers/gpu/drm/msm/msm_drv.c | 63 +--
 drivers/gpu/drm/msm/msm_gpu.c |  4 +++
 drivers/gpu/drm/msm/msm_gpu.h |  3 ++
 include/uapi/drm/msm_drm.h| 13 
 4 files changed, 81 insertions(+), 2 deletions(-)

-- 
2.25.0.rc1.283.g88dfdc4193-goog

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

Re: [PATCH v2 2/4] drm/msm: allow zapfw to not be specified in gpulist

[Bjorn Andersson]

On Sun 12 Jan 11:53 PST 2020, Rob Clark wrote:

> From: Rob Clark 
> 
> For newer devices we want to require the path to come from the
> firmware-name property in the zap-shader dt node.
> 

Reviewed-by: Bjorn Andersson 

> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 456bb5af1717..c146c3b8f52b 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -79,9 +79,21 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> char *fwname,
>   ret = request_firmware_direct(&fw, fwname, gpu->dev->dev);
>   if (ret)
>   fw = ERR_PTR(ret);
> - } else {
> + } else if (fwname) {
>   /* Request the MDT file from the default location: */
>   fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> + } else {
> + /*
> +  * For new targets, we require the firmware-name property,
> +  * if a zap-shader is required, rather than falling back
> +  * to a firmware name specified in gpulist.
> +  *
> +  * Because the firmware is signed with a (potentially)
> +  * device specific key, having the name come from gpulist
> +  * was a bad idea, and is only provided for backwards
> +  * compatibility for older targets.
> +  */
> + return -ENODEV;
>   }
>  
>   if (IS_ERR(fw)) {
> @@ -170,14 +182,6 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 
> pasid)
>   return -EPROBE_DEFER;
>   }
>  
> - /* Each GPU has a target specific zap shader firmware name to use */
> - if (!adreno_gpu->info->zapfw) {
> - zap_available = false;
> - DRM_DEV_ERROR(&pdev->dev,
> - "Zap shader firmware file not specified for this 
> target\n");
> - return -ENODEV;
> - }
> -
>   return zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw, pasid);
>  }
>  
> -- 
> 2.24.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Frida LCD Co., Ltd.

[Paul Cercueil]

Add an entry for Shenzhen Frida LCD Co., Ltd.

v2: No change
v3: No change

Signed-off-by: Paul Cercueil 
Acked-by: Sam Ravnborg 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 835579edc971..76069bb51ea4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -337,6 +337,8 @@ patternProperties:
 description: Firefly
   "^focaltech,.*":
 description: FocalTech Systems Co.,Ltd
+  "^frida,.*":
+description: Shenzhen Frida LCD Co., Ltd.
   "^friendlyarm,.*":
 description: Guangzhou FriendlyARM Computer Tech Co., Ltd
   "^fsl,.*":
-- 
2.24.1

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

RE: drm_cflush_sg() loops for over 3ms - scheduler not running tasks.

[David Laight]

From: David Laight
> Sent: 13 January 2020 14:35
> 
> I've been looking at why some RT processes don't get scheduled promptly.
> In my test the RT process's affinity ties it to a single cpu (this may not be 
> such
> a good idea as it seems).
> 
> What I've found is that the Intel i915 graphics driver uses the 
> 'events_unbound'
> kernel worker thread to periodically execute drm_cflush_sg().
> (see 
> https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_cache.c)
...
> This loop takes about 1us per iteration split fairly evenly between whatever 
> is in
> for_each_sg_page() and drm_cflush_page().
> With a 2560x1440 display the loop count is 3600 (4 bytes/pixel) and the whole
> function takes around 3.3ms.

Actually not setting the cpu affinity makes no difference.
The process is woken up on the cpu it last ran on and sits 'waiting' until
drm_cflush_sg() finishes - even though the other cpu become idle.
No sign of sched_migrate_task event 'stealing' the process.

Even worse, because 'ticket locks' are used no other user processes can
acquire the same (user) mutex or be woken from cv_wait() until the
process actually runs.

This is a 5.4.0-rc7 kernel.
I think I saw some recent scheduler patches, I can try them until I can't build
with gcc 4.7.3 :-)

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Fix too few arguments to function i915_capture_error_state

[Zhang Xiaoxu]

If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there is an error
when compile the kernel:

drivers/gpu/drm/i915/gt/intel_reset.c:
In function intel_gt_handle_error:
drivers/gpu/drm/i915/gt/intel_reset.c:1233:3:
error: too few arguments to function i915_capture_error_state
   i915_capture_error_state(gt->i915);
   ^~~~
In file included
 from ./drivers/gpu/drm/i915/i915_drv.h:97:0,
 from ./drivers/gpu/drm/i915/display/intel_display_types.h:46,
 from drivers/gpu/drm/i915/gt/intel_reset.c:10:
./drivers/gpu/drm/i915/i915_gpu_error.h:267:20: note: declared here
 static inline void i915_capture_error_state(struct drm_i915_private *dev_priv,

Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capture")
Reported-by: Hulk Robot 
Signed-off-by: Zhang Xiaoxu 
---
 drivers/gpu/drm/i915/i915_gpu_error.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h 
b/drivers/gpu/drm/i915/i915_gpu_error.h
index 1c800448c3ea..1b6dfcb79e14 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -264,9 +264,7 @@ void i915_disable_error_state(struct drm_i915_private 
*i915, int err);
 
 #else
 
-static inline void i915_capture_error_state(struct drm_i915_private *dev_priv,
-   u32 engine_mask,
-   const char *error_msg)
+static inline void i915_capture_error_state(struct drm_i915_private *dev_priv)
 {
 }
 
-- 
2.17.2

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

[PULL] drm-intel-next

[Jani Nikula]

Hi Dave & Daniel -

Last batch for v5.6, slightly delayed I'm afraid.

drm-intel-next-2020-01-14:
Final drm/i915 features for v5.6:
- DP MST fixes (José)
- Fix intel_bw_state memory leak (Pankaj Bharadiya)
- Switch context id allocation to xarray (Tvrtko)
- ICL/EHL/TGL workarounds (Matt Roper, Tvrtko)
- Debugfs for LMEM details (Lukasz Fiedorowicz)
- Prefer platform acronyms over codenames in symbols (Lucas)
- Tiled and port sync mode fixes for fbdev and DP (Manasi)
- DSI panel and backlight enable GPIO fixes (Hans de Goede)
- Relax audio min CDCLK requirements on non-GLK (Kai Vehmanen)
- Plane alignment and dimension check fixes (Imre)
- Fix state checks for PSR (José)
- Remove ICL+ clock gating programming (José)
- Static checker fixes around bool usage (Ma Feng)
- Bring back tests for self-contained headers in i915 (Masahiro Yamada)
- Fix DP MST disable sequence (Ville)
- Start converting i915 to the new drm device based logging macros (Wambui 
Karuga)
- Add DSI VBT I2C sequence execution (Vivek Kasireddy)
- Start using function pointers and ops structs in uc code (Michal)
- Fix PMU names to not use colons or dashes (Tvrtko)
- TGL media decompression support (DK, Imre)
- Split i915_gem_gtt.[ch] to more manageable chunks (Matthew Auld)
- Create dumb buffers in LMEM where available (Ram)
- Extend mmap support for LMEM (Abdiel)
- Selftest updates (Chris)
- Hack bump up CDCLK on TGL to avoid underruns (Stan)
- Use intel_encoder and intel_connector more instead of drm counterparts (Ville)
- Build error fixes (Zhang Xiaoxu)
- Fixes related to GPU and engine initialization/resume (Chris)
- Support for prefaulting discontiguous objects (Abdiel)
- Support discontiguous LMEM object maps (Chris)
- Various GEM and GT improvements and fixes (Chris)
- Merge pinctrl dependencies branch for the DSI GPIO updates (Jani)
- Backmerge drm-next for new logging macros (Jani)

BR,
Jani.

The following changes since commit a566696cf9f27f701cd4a6426d46f112c180059c:

  Merge tag 'drm-misc-next-2020-01-07' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-01-09 10:53:58 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-01-14

for you to fetch changes up to f2221a50494037af98206713155c8d4f2e7bccaa:

  drm/i915: Update DRIVER_DATE to 20200114 (2020-01-14 13:39:38 +0200)


Final drm/i915 features for v5.6:
- DP MST fixes (José)
- Fix intel_bw_state memory leak (Pankaj Bharadiya)
- Switch context id allocation to xarray (Tvrtko)
- ICL/EHL/TGL workarounds (Matt Roper, Tvrtko)
- Debugfs for LMEM details (Lukasz Fiedorowicz)
- Prefer platform acronyms over codenames in symbols (Lucas)
- Tiled and port sync mode fixes for fbdev and DP (Manasi)
- DSI panel and backlight enable GPIO fixes (Hans de Goede)
- Relax audio min CDCLK requirements on non-GLK (Kai Vehmanen)
- Plane alignment and dimension check fixes (Imre)
- Fix state checks for PSR (José)
- Remove ICL+ clock gating programming (José)
- Static checker fixes around bool usage (Ma Feng)
- Bring back tests for self-contained headers in i915 (Masahiro Yamada)
- Fix DP MST disable sequence (Ville)
- Start converting i915 to the new drm device based logging macros (Wambui 
Karuga)
- Add DSI VBT I2C sequence execution (Vivek Kasireddy)
- Start using function pointers and ops structs in uc code (Michal)
- Fix PMU names to not use colons or dashes (Tvrtko)
- TGL media decompression support (DK, Imre)
- Split i915_gem_gtt.[ch] to more manageable chunks (Matthew Auld)
- Create dumb buffers in LMEM where available (Ram)
- Extend mmap support for LMEM (Abdiel)
- Selftest updates (Chris)
- Hack bump up CDCLK on TGL to avoid underruns (Stan)
- Use intel_encoder and intel_connector more instead of drm counterparts (Ville)
- Build error fixes (Zhang Xiaoxu)
- Fixes related to GPU and engine initialization/resume (Chris)
- Support for prefaulting discontiguous objects (Abdiel)
- Support discontiguous LMEM object maps (Chris)
- Various GEM and GT improvements and fixes (Chris)
- Merge pinctrl dependencies branch for the DSI GPIO updates (Jani)
- Backmerge drm-next for new logging macros (Jani)


Abdiel Janulgue (3):
  drm/i915: Introduce remap_io_sg() to prefault discontiguous objects
  drm/i915/gem: Extend mmap support for lmem
  drm/i915/selftests: Extend fault handler selftests to all memory regions

Chen Zhou (1):
  drm/i915/gtt: add missing include file asm/smp.h

Chris Wilson (55):
  drm/i915/gt: Tidy up checking active timelines during retirement
  drm/i915/gt: Flush other retirees inside intel_gt_retire_requests()
  drm/i915: Add spaces before compound GEM_TRACE
  drm/i915/gt: Stop poking at engine->serial at a high level
  drm/i915/gt: Apply sanitiization just before resume
  drm/i915/gt: Ignore incomplete engi

Re: [PATCH 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

[Peter Ujfalusi]

On 27/12/2019 0.24, Rob Herring wrote:
> On Tue, Dec 17, 2019 at 12:15:05PM +0200, Peter Ujfalusi wrote:
>> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  .../display/bridge/toshiba,tc358768.yaml  | 158 ++
>>  1 file changed, 158 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml 
>> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>> new file mode 100644
>> index ..8f96867caca0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
>> @@ -0,0 +1,158 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358768.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Toschiba TC358768/TC358778 Parallel RGB to MIPI DSI bridge
>> +
>> +maintainers:
>> +  - Peter Ujfalusi 
>> +
>> +description: |
>> +  The TC358768/TC358778 is bridge device which converts RGB to DSI.
>> +
>> +properties:
>> +  compatible:
>> +enum:
>> +  - toshiba,tc358768
>> +  - toshiba,tc358778
>> +
>> +  reg:
>> +maxItems: 1
>> +description: base I2C address of the device
>> +
>> +  reset-gpios:
>> +maxItems: 1
>> +description: GPIO connected to active low RESX pin
>> +
>> +  vddc-supply:
>> +maxItems: 1
> 
> Drop this. Not an array. *-supply doesn't need further constraints.

OK.

> 
>> +description: Regulator for 1.2V internal core power.
>> +
>> +  vddmipi-supply:
>> +maxItems: 1
>> +description: Regulator for 1.2V for the MIPI.
>> +
>> +  vddio-supply:
>> +maxItems: 1
>> +description: Regulator for 1.8V - 3.3V IO power.
> 
> Blank line here.

Oops, I'll fix it.

> 
>> +  clocks:
>> +maxItems: 1
>> +
>> +  clock-names:
>> +const: refclk
>> +
>> +  ports:
>> +type: object
>> +
>> +properties:
>> +  "#address-cells":
>> +const: 1
>> +
>> +  "#size-cells":
>> +const: 0
>> +
>> +  port@0:
>> +type: object
>> +additionalProperties: false
>> +
>> +description: |
>> +  Video port for RGB input
>> +
>> +properties:
>> +  reg:
>> +const: 0
>> +
>> +patternProperties:
>> +  endpoint:
>> +type: object
>> +additionalProperties: false
>> +
>> +properties:
>> +  data-lines:
>> +enum: [ 16, 18, 24 ]
>> +
>> +  remote-endpoint: true
>> +
>> +required:
>> +  - reg
>> +
>> +  port@1:
>> +type: object
>> +description: |
>> +  Video port for DSI output (panel or connector).
>> +
>> +properties:
>> +  reg:
>> +const: 1
>> +
>> +patternProperties:
>> +  endpoint:
>> +type: object
>> +additionalProperties: false
>> +
>> +properties:
>> +  remote-endpoint: true
>> +
>> +required:
>> +  - reg
> 
> No additionalProperties on this one?

Correct, I have missed the additionalProperties: false

I'll update the binding documents when I get comments for the driver.

Thank you,
- Péter

> 
>> +
>> +required:
>> +  - "#address-cells"
>> +  - "#size-cells"
>> +  - port@0
>> +  - port@1
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - vddc-supply
>> +  - vddmipi-supply
>> +  - vddio-supply
>> +  - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +i2c1 {
>> +  #address-cells = <1>;
>> +  #size-cells = <0>;
>> +
>> +  dsi_bridge: tc358768@0e {
>> +compatible = "toshiba,tc358768";
>> +reg = <0x0e>;
>> +
>> +clocks = <&tc358768_refclk>;
>> +clock-names = "refclk";
>> +
>> +/* GPIO line is inverted before going to the bridge */
>> +reset-gpios = <&pcf_display_board 0 1 /* GPIO_ACTIVE_LOW */>;
>> +
>> +vddc-supply = <&v1_2d>;
>> +vddmipi-supply = <&v1_2d>;
>> +vddio-supply = <&v3_3d>;
>> +
>> +dsi_bridge_ports: ports {
>> +  #address-cells = <1>;
>> +  #size-cells = <0>;
>> +
>> +  port@0 {
>> +reg = <0>;
>> +rgb_in: endpoint {
>> +  remote-endpoint = <&dpi_out>;
>> +  data-lines = <24>;
>> +};
>> +  };
>> +
>> +  port@1 {
>> +reg = <1>;
>> +dsi_out: endpoint {
>> +  remote-endpoint = <&lcd_in>;
>> +};
>> +  };
>> +};
>> +  };
>> +};
>> +
>> -- 
>> Peter
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>

Texas Instruments Finland Oy, Porkkalankatu 22, 0

Re: [PULL] drm-intel-next

[Chris Wilson]

Quoting Jani Nikula (2020-01-14 11:43:22)
> 
> Hi Dave & Daniel -
> 
> Last batch for v5.6, slightly delayed I'm afraid.

I'd like to close https://gitlab.freedesktop.org/drm/intel/issues/738
for 5.6, otherwise we'll have some more nasty emails from bewildered
users/devs.

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

Re: [PULL] drm-intel-next

[Jani Nikula]

On Tue, 14 Jan 2020, Chris Wilson  wrote:
> Quoting Jani Nikula (2020-01-14 11:43:22)
>> 
>> Hi Dave & Daniel -
>> 
>> Last batch for v5.6, slightly delayed I'm afraid.
>
> I'd like to close https://gitlab.freedesktop.org/drm/intel/issues/738
> for 5.6, otherwise we'll have some more nasty emails from bewildered
> users/devs.
>
> https://patchwork.freedesktop.org/series/71951/

IMO seems small enough to go through drm-intel-next-fixes for v5.6. But
need to close the dinq floodgates already.

BR,
Jani.


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

[PATCH v2] drm/syncobj: Add documentation for timeline syncobj

[Lionel Landwerlin]

We've added a set of new APIs to manipulate syncobjs holding timelines
of dma_fence. This adds a bit of documentation about how this works.

v2: Small language nits (Lionel)

Signed-off-by: Lionel Landwerlin 
Cc: Christian Koenig 
Cc: Jason Ekstrand 
Cc: David(ChunMing) Zhou 
---
 drivers/gpu/drm/drm_syncobj.c | 87 +--
 1 file changed, 74 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 669c93fe2500..42d46414f767 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -43,27 +43,66 @@
  *  - Signal a syncobj (set a trivially signaled fence)
  *  - Wait for a syncobj's fence to appear and be signaled
  *
+ * The syncobj userspace API also provides operations to manipulate a syncobj
+ * in terms of a timeline of struct &dma_fence_chain rather than a single
+ * struct &dma_fence, through the following operations:
+ *
+ *   - Signal a given point on the timeline
+ *   - Wait for a given point to appear and/or be signaled
+ *   - Import and export from/to a given point of a timeline
+ *
  * At it's core, a syncobj is simply a wrapper around a pointer to a struct
  * &dma_fence which may be NULL.
  * When a syncobj is first created, its pointer is either NULL or a pointer
  * to an already signaled fence depending on whether the
  * &DRM_SYNCOBJ_CREATE_SIGNALED flag is passed to
  * &DRM_IOCTL_SYNCOBJ_CREATE.
- * When GPU work which signals a syncobj is enqueued in a DRM driver,
- * the syncobj fence is replaced with a fence which will be signaled by the
- * completion of that work.
- * When GPU work which waits on a syncobj is enqueued in a DRM driver, the
- * driver retrieves syncobj's current fence at the time the work is enqueued
- * waits on that fence before submitting the work to hardware.
- * If the syncobj's fence is NULL, the enqueue operation is expected to fail.
- * All manipulation of the syncobjs's fence happens in terms of the current
- * fence at the time the ioctl is called by userspace regardless of whether
- * that operation is an immediate host-side operation (signal or reset) or
- * or an operation which is enqueued in some driver queue.
- * &DRM_IOCTL_SYNCOBJ_RESET and &DRM_IOCTL_SYNCOBJ_SIGNAL can be used to
- * manipulate a syncobj from the host by resetting its pointer to NULL or
+ *
+ * If the syncobj is considered as a binary (its state is either signaled or
+ * unsignaled) primitive, when GPU work is enqueued in a DRM driver to signal
+ * the syncobj, the syncobj's fence is replaced with a fence which will be
+ * signaled by the completion of that work.
+ * If the syncobj is considered as a timeline primitive, when GPU work is
+ * enqueued in a DRM driver to signal the a given point of the syncobj, a new
+ * struct &dma_fence_chain pointing to the DRM driver's fence and also
+ * pointing to the previous fence that was in the syncobj. The new struct
+ * &dma_fence_chain fence replace the syncobj's fence and will be signaled by
+ * completion of the DRM driver's work and also any work associated with the
+ * fence previously in the syncobj.
+ *
+ * When GPU work which waits on a syncobj is enqueued in a DRM driver, at the
+ * time the work is enqueued, it waits on the syncobj's fence before
+ * submitting the work to hardware. That fence is either :
+ *
+ *- The syncobj's current fence if the syncobj is considered as a binary
+ *  primitive.
+ *- The struct &dma_fence associated with a given point if the syncobj is
+ *  considered as a timeline primitive.
+ *
+ * If the syncobj's fence is NULL or not present in the syncobj's timeline,
+ * the enqueue operation is expected to fail.
+ *
+ * With binary syncobj, all manipulation of the syncobjs's fence happens in
+ * terms of the current fence at the time the ioctl is called by userspace
+ * regardless of whether that operation is an immediate host-side operation
+ * (signal or reset) or or an operation which is enqueued in some driver
+ * queue. &DRM_IOCTL_SYNCOBJ_RESET and &DRM_IOCTL_SYNCOBJ_SIGNAL can be used
+ * to manipulate a syncobj from the host by resetting its pointer to NULL or
  * setting its pointer to a fence which is already signaled.
  *
+ * With a timeline syncobj, all manipulation of the synobj's fence happens in
+ * terms of a u64 value referring to point in the timeline. See
+ * dma_fence_chain_find_seqno() to see how a given point is found in the
+ * timeline.
+ *
+ * Note that applications should be careful to always use timeline set of
+ * ioctl() when dealing with syncobj considered as timeline. Using a binary
+ * set of ioctl() with a syncobj considered as timeline could result incorrect
+ * synchronization. The use of binary syncobj is supported through the
+ * timeline set of ioctl() by using a point value of 0, this will reproduce
+ * the behavior of the binary set of ioctl() (for example replace the
+ * syncobj's fence when signaling).
+ *
  *
  * Host-side wait on syncobjs
 

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

[Ville Syrjälä]

On Mon, Jan 13, 2020 at 04:39:00PM -0800, Manasi Navare wrote:
> Hi Ville,
> 
> So the two major changes you would like to see here are:
> 
>  use version_greate(edid) function 
> and make use of :
> drm_for_each_detailed_block() instead of the for loop.
> But this function does not parse the monitor range yet so
> you are suggesting modifying that dmr helper function as well?

That functions is just the thing that iterates the descriptors, so
can't figure out what you're asking.

> 
> Manasi
> 
> On Fri, Jan 10, 2020 at 03:17:43PM -0800, Manasi Navare wrote:
> > On Thu, Jan 09, 2020 at 03:08:52PM +0200, Ville Syrjälä wrote:
> > > On Tue, Jan 07, 2020 at 04:32:08PM -0800, Manasi Navare wrote:
> > > > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > > > the EDID's detailed descritors to obtain the adaptive sync monitor 
> > > > range.
> > > > Store this info as part fo drm_display_info so it can be used
> > > > across all drivers.
> > > > This part of the code is stripped out of amdgpu's function
> > > > amdgpu_dm_update_freesync_caps() to make it generic and be used
> > > > across all DRM drivers
> > > > 
> > > > v2:
> > > > * Change vmin and vmax to use u8 (Ville)
> > > > * Dont store pixel clock since that is just a max dotclock
> > > > and not related to VRR mode (Manasi)
> > > > 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Harry Wentland 
> > > > Cc: Clinton A Taylor 
> > > > Cc: Nicholas Kazlauskas 
> > > > Signed-off-by: Manasi Navare 
> > > > ---
> > > >  drivers/gpu/drm/drm_edid.c  | 51 +
> > > >  include/drm/drm_connector.h | 22 
> > > >  include/drm/drm_edid.h  |  2 ++
> > > >  3 files changed, 75 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index 99769d6c9f84..52781a0e708b 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct 
> > > > drm_connector *connector,
> > > > }
> > > >  }
> > > >  
> > > > +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> > > > + const struct edid *edid)
> > > > +{
> > > > +   struct drm_display_info *info = &connector->display_info;
> > > > +   const struct detailed_timing *timing;
> > > > +   const struct detailed_non_pixel *data;
> > > > +   const struct detailed_data_monitor_range *range;
> > > 
> > > Needlessly wide scope for everything above.
> > 
> > Okay will move inside the for_each loop ?
> > 
> > > 
> > > > +   int i;
> > > > +
> > > > +   /*
> > > > +* Restrict Adaptive Sync only for dp and edp
> > > > +*/
> > > > +   if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort 
> > > > &&
> > > > +   connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> > > > +   return;
> > > > +
> > > > +   if (edid->version <= 1 && !(edid->version == 1 && 
> > > > edid->revision > 1))
> > > > +   return;
> > > 
> > > if (!version_greater(...))
> > >   return;
> > 
> > You mean simplify the condition or use define a function version_greater() 
> > to check this condition?
> > 
> > > 
> > > > +
> > > > +   for (i = 0; i < 4; i++) {
> > > 
> > > This should probably use for_each_detailed_block()
> > >
> > 
> > 
> > Ok yes will use for_each_detailed_block
> > 
> > Manasi
> > 
> >  
> > > > +   timing  = &edid->detailed_timings[i];
> > > > +   data= &timing->data.other_data;
> > > > +   range   = &data->data.range;
> > > > +   /*
> > > > +* Check if monitor has continuous frequency mode
> > > > +*/
> > > > +   if (data->type != EDID_DETAIL_MONITOR_RANGE)
> > > > +   continue;
> > > > +   /*
> > > > +* Check for flag range limits only. If flag == 1 then
> > > > +* no additional timing information provided.
> > > > +* Default GTF, GTF Secondary curve and CVT are not
> > > > +* supported
> > > > +*/
> > > > +   if (range->flags != 1)
> > > > +   continue;
> > > > +
> > > > +   info->adaptive_sync.min_vfreq = range->min_vfreq;
> > > > +   info->adaptive_sync.max_vfreq = range->max_vfreq;
> > > > +
> > > > +   DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d 
> > > > Hz - %d Hz\n",
> > > > + info->adaptive_sync.min_vfreq,
> > > > + info->adaptive_sync.max_vfreq);
> > > > +   break;
> > > > +   }
> > > > +}
> > > > +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
> > > > +
> > > >  /* A connector has no EDID information, so we've got no EDID to 
> > > > compute quirks from. Reset
> > > >   * all of the values which would have been set from EDID
> > > >   */
> 

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

[Harry Wentland]

Fixing Nick's email.

On 2020-01-10 5:43 p.m., Manasi Navare wrote:
> On Thu, Jan 09, 2020 at 05:24:30PM +0200, Jani Nikula wrote:
>> On Tue, 07 Jan 2020, Manasi Navare  wrote:
>>> Adaptive Sync is a VESA feature so add a DRM core helper to parse
>>> the EDID's detailed descritors to obtain the adaptive sync monitor range.
>>> Store this info as part fo drm_display_info so it can be used
>>> across all drivers.
>>> This part of the code is stripped out of amdgpu's function
>>> amdgpu_dm_update_freesync_caps() to make it generic and be used
>>> across all DRM drivers
>>>
>>> v2:
>>> * Change vmin and vmax to use u8 (Ville)
>>> * Dont store pixel clock since that is just a max dotclock
>>> and not related to VRR mode (Manasi)
>>>
>>> Cc: Ville Syrjälä 
>>> Cc: Harry Wentland 
>>> Cc: Clinton A Taylor 
>>> Cc: Nicholas Kazlauskas 
>>> Signed-off-by: Manasi Navare 
>>> ---
>>>  drivers/gpu/drm/drm_edid.c  | 51 +
>>>  include/drm/drm_connector.h | 22 
>>>  include/drm/drm_edid.h  |  2 ++
>>>  3 files changed, 75 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 99769d6c9f84..52781a0e708b 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector 
>>> *connector,
>>> }
>>>  }
>>>  
>>> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
>>> + const struct edid *edid)
>>> +{
>>> +   struct drm_display_info *info = &connector->display_info;
>>> +   const struct detailed_timing *timing;
>>> +   const struct detailed_non_pixel *data;
>>> +   const struct detailed_data_monitor_range *range;
>>> +   int i;
>>> +
>>> +   /*
>>> +* Restrict Adaptive Sync only for dp and edp
>>> +*/
>>> +   if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
>>> +   connector->connector_type != DRM_MODE_CONNECTOR_eDP)
>>> +   return;
>>> +
>>> +   if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
>>> +   return;
>>> +
>>> +   for (i = 0; i < 4; i++) {
>>> +   timing  = &edid->detailed_timings[i];
>>> +   data= &timing->data.other_data;
>>> +   range   = &data->data.range;
>>> +   /*
>>> +* Check if monitor has continuous frequency mode
>>> +*/
>>> +   if (data->type != EDID_DETAIL_MONITOR_RANGE)
>>> +   continue;
>>> +   /*
>>> +* Check for flag range limits only. If flag == 1 then
>>> +* no additional timing information provided.
>>> +* Default GTF, GTF Secondary curve and CVT are not
>>> +* supported
>>> +*/
>>> +   if (range->flags != 1)
>>> +   continue;
>>> +
>>> +   info->adaptive_sync.min_vfreq = range->min_vfreq;
>>> +   info->adaptive_sync.max_vfreq = range->max_vfreq;
>>> +
>>> +   DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d 
>>> Hz\n",
>>> + info->adaptive_sync.min_vfreq,
>>> + info->adaptive_sync.max_vfreq);
>>> +   break;
>>> +   }
>>> +}
>>> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
>>
>> Why the export? Rather, why is this not static?
>>
> 
> I could make it static but since the way AMDGPU code is written right now they
> would be calling this function explicitly to populate the vmin and vmax in 
> their local
> structs but I can make it static and with some minor refactoring they should 
> be able to
> use thsi infor directly from drm_display_info
> 

Calling this through drm_add_edid_modes should be sufficient for us.
We'll just need to move amdgpu_dm_update_freesync_caps to our get_modes
function.

Dropping the export here seems to be the right thing to do.

Harry

> Manasi
>  
>> BR,
>> Jani.
>>
>>> +
>>>  /* A connector has no EDID information, so we've got no EDID to compute 
>>> quirks from. Reset
>>>   * all of the values which would have been set from EDID
>>>   */
>>> @@ -4901,6 +4949,7 @@ drm_reset_display_info(struct drm_connector 
>>> *connector)
>>> memset(&info->hdmi, 0, sizeof(info->hdmi));
>>>  
>>> info->non_desktop = 0;
>>> +   memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
>>>  }
>>>  
>>>  u32 drm_add_display_info(struct drm_connector *connector, const struct 
>>> edid *edid)
>>> @@ -4916,6 +4965,8 @@ u32 drm_add_display_info(struct drm_connector 
>>> *connector, const struct edid *edi
>>>  
>>> info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>>>  
>>> +   drm_get_adaptive_sync_limits(connector, edid);
>>> +
>>> DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>>>  
>>> if (edid->revision < 3)
>>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>>> index 221910948b37..77df404a2e01 100644
>>> --- a/include/drm/drm_connector.h
>>> +++ b/incl

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

[Jani Nikula]

On Tue, 14 Jan 2020, Harry Wentland  wrote:
> Fixing Nick's email.
>
> On 2020-01-10 5:43 p.m., Manasi Navare wrote:
>> On Thu, Jan 09, 2020 at 05:24:30PM +0200, Jani Nikula wrote:
>>> On Tue, 07 Jan 2020, Manasi Navare  wrote:
 +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
>>>
>>> Why the export? Rather, why is this not static?
>>>
>> 
>> I could make it static but since the way AMDGPU code is written right now 
>> they
>> would be calling this function explicitly to populate the vmin and vmax in 
>> their local
>> structs but I can make it static and with some minor refactoring they should 
>> be able to
>> use thsi infor directly from drm_display_info
>> 
>
> Calling this through drm_add_edid_modes should be sufficient for us.
> We'll just need to move amdgpu_dm_update_freesync_caps to our get_modes
> function.
>
> Dropping the export here seems to be the right thing to do.

Thanks; this should help unify the behaviour across drivers.

BR,
Jani.


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

Re: [PATCH 23/23] drm: Cleanup VBLANK callbacks in struct drm_driver

[Thomas Zimmermann]

Hi

Am 12.01.20 um 23:53 schrieb Daniel Vetter:
> On Fri, Jan 10, 2020 at 10:21:27AM +0100, Thomas Zimmermann wrote:
>> All non-legacy users of VBLANK functions in struct drm_driver have been
>> converted to use the respective interfaces in struct drm_crtc_funcs. The
>> remaining users of VBLANK callbacks in struct drm_driver are legacy drivers
>> with userspace modesetting.
>>
>> There are no users left of get_vblank_timestamp(), so the callback is
>> being removed. The other VBLANK callbacks are being moved to the legacy
>> section at the end of struct drm_driver.
>>
>> Signed-off-by: Thomas Zimmermann 
> 
> I think sprinkling some WARN_ON (in drm_dev_register or wherever) if new
> drivers try to use the legacy hooks would be really nice. Experience says
> someone is going to copypaste this stuff around forever otherwise.

I've been thinking about moving these fields to separate structures, say
struct drm_legacy_device and struct drm_legacy_driver. Those would be
allocated for legacy drivers and KMS drivers would never see them
(except for their forward declaration).

Best regards
Thomas

> 
> Reviewed-by: Daniel Vetter 
> 
>> ---
>>  drivers/gpu/drm/drm_vblank.c |  39 +-
>>  include/drm/drm_drv.h| 101 ++-
>>  2 files changed, 17 insertions(+), 123 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>> index 7cf436a4b908..ceff68474d4d 100644
>> --- a/drivers/gpu/drm/drm_vblank.c
>> +++ b/drivers/gpu/drm/drm_vblank.c
>> @@ -138,10 +138,9 @@ static u32 __get_vblank_counter(struct drm_device *dev, 
>> unsigned int pipe)
>>  
>>  if (crtc->funcs->get_vblank_counter)
>>  return crtc->funcs->get_vblank_counter(crtc);
>> -}
>> -
>> -if (dev->driver->get_vblank_counter)
>> +} else if (dev->driver->get_vblank_counter) {
>>  return dev->driver->get_vblank_counter(dev, pipe);
>> +}
>>  
>>  return drm_vblank_no_hw_counter(dev, pipe);
>>  }
>> @@ -334,8 +333,7 @@ u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
>>  unsigned long flags;
>>  
>>  WARN_ONCE(drm_debug_enabled(DRM_UT_VBL) &&
>> -  !crtc->funcs->get_vblank_timestamp &&
>> -  !dev->driver->get_vblank_timestamp,
>> +  !crtc->funcs->get_vblank_timestamp,
>>"This function requires support for accurate vblank 
>> timestamps.");
>>  
>>  spin_lock_irqsave(&dev->vblank_time_lock, flags);
>> @@ -357,13 +355,11 @@ static void __disable_vblank(struct drm_device *dev, 
>> unsigned int pipe)
>>  if (WARN_ON(!crtc))
>>  return;
>>  
>> -if (crtc->funcs->disable_vblank) {
>> +if (crtc->funcs->disable_vblank)
>>  crtc->funcs->disable_vblank(crtc);
>> -return;
>> -}
>> +} else {
>> +dev->driver->disable_vblank(dev, pipe);
>>  }
>> -
>> -dev->driver->disable_vblank(dev, pipe);
>>  }
>>  
>>  /*
>> @@ -791,9 +787,6 @@ drm_get_last_vbltimestamp(struct drm_device *dev, 
>> unsigned int pipe,
>>  
>>  ret = crtc->funcs->get_vblank_timestamp(crtc, &max_error,
>>  tvblank, in_vblank_irq);
>> -} else if (dev->driver->get_vblank_timestamp && (max_error > 0)) {
>> -ret = dev->driver->get_vblank_timestamp(dev, pipe, &max_error,
>> -tvblank, in_vblank_irq);
>>  }
>>  
>>  /* GPU high precision timestamp query unsupported or failed.
>> @@ -1016,9 +1009,11 @@ static int __enable_vblank(struct drm_device *dev, 
>> unsigned int pipe)
>>  
>>  if (crtc->funcs->enable_vblank)
>>  return crtc->funcs->enable_vblank(crtc);
>> +} else if (dev->driver->enable_vblank) {
>> +return dev->driver->enable_vblank(dev, pipe);
>>  }
>>  
>> -return dev->driver->enable_vblank(dev, pipe);
>> +return -EINVAL;
>>  }
>>  
>>  static int drm_vblank_enable(struct drm_device *dev, unsigned int pipe)
>> @@ -1109,13 +1104,10 @@ static bool __vblank_disable_immediate(struct 
>> drm_device *dev, unsigned int pipe
>>  return false;
>>  
>>  crtc = drm_crtc_from_index(dev, pipe);
>> -if (crtc && crtc->funcs->get_vblank_timestamp)
>> -return true;
>> -
>> -if (dev->driver->get_vblank_timestamp)
>> -return true;
>> +if (!crtc || !crtc->funcs->get_vblank_timestamp)
>> +return false;
>>  
>> -return false;
>> +return true;
>>  }
>>  
>>  static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
>> @@ -1798,7 +1790,6 @@ static void drm_handle_vblank_events(struct drm_device 
>> *dev, unsigned int pipe)
>>  struct drm_pending_vblank_event *e, *t;
>>  ktime_t now;
>>  u64 seq;
>> -bool high_prec;
>>  
>>  assert_spin_locked(&dev->event_lock);
>>  
>> @@ -1818,10 +1809,8 

Re: [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

[Jani Nikula]

On Mon, 06 Jan 2020, Kai-Heng Feng  wrote:
> Hi Jani,
>
>> On Dec 24, 2019, at 16:42, Kai-Heng Feng  wrote:
>> 
>> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
>> becomes useless and never responds to cable hotplugging:
>> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
>> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on 
>> port D
>> 
>> Seems like the lspcon chip on the system in question only gets powered
>> after the cable is plugged.
>> 
>> So let's call lspcon_init() dynamically to properly initialize the
>> lspcon chip and make HDMI port work.
>
> Do you have any further suggestion for this patch?

Sorry for taking so long. Comments inline.

>
> Kai-Heng
>
>> 
>> Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
>> Signed-off-by: Kai-Heng Feng 
>> ---
>> v3:
>> - Make sure it's handled under long HPD case.
>> 
>> v2: 
>> - Move lspcon_init() inside of intel_dp_hpd_pulse().
>> 
>> drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index fe31bbfd6c62..a72c9c041c60 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -6573,6 +6573,7 @@ enum irqreturn
>> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>> {
>>  struct intel_dp *intel_dp = &intel_dig_port->dp;
>> +struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> 
>>  if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
>>  /*
>> @@ -6593,7 +6594,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
>> *intel_dig_port, bool long_hpd)
>>long_hpd ? "long" : "short");
>> 
>>  if (long_hpd) {
>> -intel_dp->reset_link_params = true;
>> +if (intel_dig_port->base.type == INTEL_OUTPUT_DDI &&
>> +HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
>> +lspcon_init(intel_dig_port);
>> +else
>> +intel_dp->reset_link_params = true;
>> +

Hmm, I think this will try to init lspcon on ports that do not have
lspcon. Also, why wouldn't we reset the params?

I think this boils down to just adding the following lines:

if (intel_bios_is_lspcon_present(dev_priv, intel_dig_port->base.port) &&
!intel_dig_port->lspcon.active)
lspcon_init(intel_dig_port);


Ville?

BR,
Jani.

>>  return IRQ_NONE;
>>  }
>> 
>> -- 
>> 2.17.1
>> 
>

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

Re: [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

[Jani Nikula]

On Tue, 14 Jan 2020, Wambui Karuga  wrote:
> Converts the printk based logging macros in i915/display/intel_audio.c
> to the struct drm_device based logging macros.

Couple of comments inline.

BR,
Jani.


> This transformation was achieved using the following coccinelle script
> that matches the existence of the struct drm_i915_private device:
>
> @rule1@
> identifier fn, T;
> @@
>
> fn(struct drm_i915_private *T,...) {
> <+...
> (
> -DRM_INFO(
> +drm_info(&T->drm,
> ...)
> |
> -DRM_ERROR(
> +drm_err(&T->drm,
> ...)
> |
> -DRM_WARN(
> +drm_warn(&T->drm,
> ...)
> |
> -DRM_DEBUG(
> +drm_dbg(&T->drm,
> ...)
> |
> -DRM_DEBUG_DRIVER(
> +drm_dbg(&T->drm,
> ...)
> |
> -DRM_DEBUG_KMS(
> +drm_dbg_kms(&T->drm,
> ...)
> )
> ...+>
> }
>
> @rule2@
> identifier fn, T;
> @@
>
> fn(...) {
> ...
> struct drm_i915_private *T = ...;
> <+...
> (
> -DRM_INFO(
> +drm_info(&T->drm,
> ...)
> |
> -DRM_ERROR(
> +drm_err(&T->drm,
> ...)
> |
> -DRM_WARN(
> +drm_warn(&T->drm,
> ...)
> |
> -DRM_DEBUG(
> +drm_dbg(&T->drm,
> ...)
> |
> -DRM_DEBUG_KMS(
> +drm_dbg_kms(&T->drm,
> ...)
> |
> -DRM_DEBUG_DRIVER(
> +drm_dbg(&T->drm,
> ...)
> )
> ...+>
> }
>
> Checkpatch warnings were manually fixed.
>
> Signed-off-by: Wambui Karuga 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 71 --
>  1 file changed, 40 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index e406719a6716..57208440bf6d 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -315,7 +315,7 @@ static void g4x_audio_codec_disable(struct intel_encoder 
> *encoder,
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   u32 eldv, tmp;
>  
> - DRM_DEBUG_KMS("Disable audio codec\n");
> + drm_dbg_kms(&dev_priv->drm, "Disable audio codec\n");
>  
>   tmp = I915_READ(G4X_AUD_VID_DID);
>   if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
> @@ -340,7 +340,8 @@ static void g4x_audio_codec_enable(struct intel_encoder 
> *encoder,
>   u32 tmp;
>   int len, i;
>  
> - DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", drm_eld_size(eld));
> + drm_dbg_kms(&dev_priv->drm, "Enable audio codec, %u bytes ELD\n",
> + drm_eld_size(eld));
>  
>   tmp = I915_READ(G4X_AUD_VID_DID);
>   if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
> @@ -360,7 +361,7 @@ static void g4x_audio_codec_enable(struct intel_encoder 
> *encoder,
>   I915_WRITE(G4X_AUD_CNTL_ST, tmp);
>  
>   len = min(drm_eld_size(eld) / 4, len);
> - DRM_DEBUG_DRIVER("ELD size %d\n", len);
> + drm_dbg(&dev_priv->drm, "ELD size %d\n", len);

Please convert this to drm_dbg_kms() while at it.

>   for (i = 0; i < len; i++)
>   I915_WRITE(G4X_HDMIW_HDMIEDID, *((const u32 *)eld + i));
>  
> @@ -384,9 +385,10 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
>   rate = acomp ? acomp->aud_sample_rate[port] : 0;
>   nm = audio_config_dp_get_n_m(crtc_state, rate);
>   if (nm)
> - DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
> + drm_dbg_kms(&dev_priv->drm, "using Maud %u, Naud %u\n", nm->m,
> + nm->n);
>   else
> - DRM_DEBUG_KMS("using automatic Maud, Naud\n");
> + drm_dbg_kms(&dev_priv->drm, "using automatic Maud, Naud\n");
>  
>   tmp = I915_READ(HSW_AUD_CFG(cpu_transcoder));
>   tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> @@ -437,13 +439,13 @@ hsw_hdmi_audio_config_update(struct intel_encoder 
> *encoder,
>  
>   n = audio_config_hdmi_get_n(crtc_state, rate);
>   if (n != 0) {
> - DRM_DEBUG_KMS("using N %d\n", n);
> + drm_dbg_kms(&dev_priv->drm, "using N %d\n", n);
>  
>   tmp &= ~AUD_CONFIG_N_MASK;
>   tmp |= AUD_CONFIG_N(n);
>   tmp |= AUD_CONFIG_N_PROG_ENABLE;
>   } else {
> - DRM_DEBUG_KMS("using automatic N\n");
> + drm_dbg_kms(&dev_priv->drm, "using automatic N\n");
>   }
>  
>   I915_WRITE(HSW_AUD_CFG(cpu_transcoder), tmp);
> @@ -476,8 +478,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
> *encoder,
>   enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
>   u32 tmp;
>  
> - DRM_DEBUG_KMS("Disable audio codec on transcoder %s\n",
> -   transcoder_name(cpu_transcoder));
> + drm_dbg_kms(&dev_priv->drm, "Disable audio codec on transcoder %s\n",
> + transcoder_name(cpu_transcoder));
>  
>   mutex_lock(&dev_priv->av_mutex);
>  
> @@ -511,8 +513,9 @@ static void hsw_audio_codec_enable(struct intel_encoder 
> *encoder,
>   u32 tmp;
>   int len, i;
>  
> - DRM_DEBUG_KMS("Enable audio codec on transcoder %s, %u bytes ELD\n",
> -   transcoder_name(cpu_transcoder), drm_eld_size(eld));
> + drm_dbg_kms(&dev_priv->drm,
> +  

Re: [PATCH 2/5] drm/i915/audio: convert to new drm logging macros.

[Jani Nikula]

On Tue, 14 Jan 2020, Jani Nikula  wrote:
> On Tue, 14 Jan 2020, Wambui Karuga  wrote:
>> Converts the printk based logging macros in i915/display/intel_audio.c
>> to the struct drm_device based logging macros.
>
> Couple of comments inline.

PS. This is

Reviewed-by: Jani Nikula 

and I'm fine with the requested changes being applied as separate
patches as long as they happen.


>
> BR,
> Jani.
>
>
>> This transformation was achieved using the following coccinelle script
>> that matches the existence of the struct drm_i915_private device:
>>
>> @rule1@
>> identifier fn, T;
>> @@
>>
>> fn(struct drm_i915_private *T,...) {
>> <+...
>> (
>> -DRM_INFO(
>> +drm_info(&T->drm,
>> ...)
>> |
>> -DRM_ERROR(
>> +drm_err(&T->drm,
>> ...)
>> |
>> -DRM_WARN(
>> +drm_warn(&T->drm,
>> ...)
>> |
>> -DRM_DEBUG(
>> +drm_dbg(&T->drm,
>> ...)
>> |
>> -DRM_DEBUG_DRIVER(
>> +drm_dbg(&T->drm,
>> ...)
>> |
>> -DRM_DEBUG_KMS(
>> +drm_dbg_kms(&T->drm,
>> ...)
>> )
>> ...+>
>> }
>>
>> @rule2@
>> identifier fn, T;
>> @@
>>
>> fn(...) {
>> ...
>> struct drm_i915_private *T = ...;
>> <+...
>> (
>> -DRM_INFO(
>> +drm_info(&T->drm,
>> ...)
>> |
>> -DRM_ERROR(
>> +drm_err(&T->drm,
>> ...)
>> |
>> -DRM_WARN(
>> +drm_warn(&T->drm,
>> ...)
>> |
>> -DRM_DEBUG(
>> +drm_dbg(&T->drm,
>> ...)
>> |
>> -DRM_DEBUG_KMS(
>> +drm_dbg_kms(&T->drm,
>> ...)
>> |
>> -DRM_DEBUG_DRIVER(
>> +drm_dbg(&T->drm,
>> ...)
>> )
>> ...+>
>> }
>>
>> Checkpatch warnings were manually fixed.
>>
>> Signed-off-by: Wambui Karuga 
>> ---
>>  drivers/gpu/drm/i915/display/intel_audio.c | 71 --
>>  1 file changed, 40 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
>> b/drivers/gpu/drm/i915/display/intel_audio.c
>> index e406719a6716..57208440bf6d 100644
>> --- a/drivers/gpu/drm/i915/display/intel_audio.c
>> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
>> @@ -315,7 +315,7 @@ static void g4x_audio_codec_disable(struct intel_encoder 
>> *encoder,
>>  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>>  u32 eldv, tmp;
>>  
>> -DRM_DEBUG_KMS("Disable audio codec\n");
>> +drm_dbg_kms(&dev_priv->drm, "Disable audio codec\n");
>>  
>>  tmp = I915_READ(G4X_AUD_VID_DID);
>>  if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
>> @@ -340,7 +340,8 @@ static void g4x_audio_codec_enable(struct intel_encoder 
>> *encoder,
>>  u32 tmp;
>>  int len, i;
>>  
>> -DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", drm_eld_size(eld));
>> +drm_dbg_kms(&dev_priv->drm, "Enable audio codec, %u bytes ELD\n",
>> +drm_eld_size(eld));
>>  
>>  tmp = I915_READ(G4X_AUD_VID_DID);
>>  if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
>> @@ -360,7 +361,7 @@ static void g4x_audio_codec_enable(struct intel_encoder 
>> *encoder,
>>  I915_WRITE(G4X_AUD_CNTL_ST, tmp);
>>  
>>  len = min(drm_eld_size(eld) / 4, len);
>> -DRM_DEBUG_DRIVER("ELD size %d\n", len);
>> +drm_dbg(&dev_priv->drm, "ELD size %d\n", len);
>
> Please convert this to drm_dbg_kms() while at it.
>
>>  for (i = 0; i < len; i++)
>>  I915_WRITE(G4X_HDMIW_HDMIEDID, *((const u32 *)eld + i));
>>  
>> @@ -384,9 +385,10 @@ hsw_dp_audio_config_update(struct intel_encoder 
>> *encoder,
>>  rate = acomp ? acomp->aud_sample_rate[port] : 0;
>>  nm = audio_config_dp_get_n_m(crtc_state, rate);
>>  if (nm)
>> -DRM_DEBUG_KMS("using Maud %u, Naud %u\n", nm->m, nm->n);
>> +drm_dbg_kms(&dev_priv->drm, "using Maud %u, Naud %u\n", nm->m,
>> +nm->n);
>>  else
>> -DRM_DEBUG_KMS("using automatic Maud, Naud\n");
>> +drm_dbg_kms(&dev_priv->drm, "using automatic Maud, Naud\n");
>>  
>>  tmp = I915_READ(HSW_AUD_CFG(cpu_transcoder));
>>  tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
>> @@ -437,13 +439,13 @@ hsw_hdmi_audio_config_update(struct intel_encoder 
>> *encoder,
>>  
>>  n = audio_config_hdmi_get_n(crtc_state, rate);
>>  if (n != 0) {
>> -DRM_DEBUG_KMS("using N %d\n", n);
>> +drm_dbg_kms(&dev_priv->drm, "using N %d\n", n);
>>  
>>  tmp &= ~AUD_CONFIG_N_MASK;
>>  tmp |= AUD_CONFIG_N(n);
>>  tmp |= AUD_CONFIG_N_PROG_ENABLE;
>>  } else {
>> -DRM_DEBUG_KMS("using automatic N\n");
>> +drm_dbg_kms(&dev_priv->drm, "using automatic N\n");
>>  }
>>  
>>  I915_WRITE(HSW_AUD_CFG(cpu_transcoder), tmp);
>> @@ -476,8 +478,8 @@ static void hsw_audio_codec_disable(struct intel_encoder 
>> *encoder,
>>  enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
>>  u32 tmp;
>>  
>> -DRM_DEBUG_KMS("Disable audio codec on transcoder %s\n",
>> -  transcoder_name(cpu_transcoder));
>> +drm_dbg_kms(&dev_priv->drm, "Disable audio codec on transcoder %s\n",
>> +transcoder_name(cpu_transcoder));
>>  
>>  mutex_lock(&dev_priv->av_mutex);
>>  
>> @@ -511,8 +513,9 

Re: [PATCH v2] drm/syncobj: Add documentation for timeline syncobj

[Christian König]

Am 14.01.20 um 13:19 schrieb Lionel Landwerlin:

We've added a set of new APIs to manipulate syncobjs holding timelines
of dma_fence. This adds a bit of documentation about how this works.

v2: Small language nits (Lionel)

Signed-off-by: Lionel Landwerlin 
Cc: Christian Koenig 
Cc: Jason Ekstrand 
Cc: David(ChunMing) Zhou 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/drm_syncobj.c | 87 +--
  1 file changed, 74 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 669c93fe2500..42d46414f767 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -43,27 +43,66 @@
   *  - Signal a syncobj (set a trivially signaled fence)
   *  - Wait for a syncobj's fence to appear and be signaled
   *
+ * The syncobj userspace API also provides operations to manipulate a syncobj
+ * in terms of a timeline of struct &dma_fence_chain rather than a single
+ * struct &dma_fence, through the following operations:
+ *
+ *   - Signal a given point on the timeline
+ *   - Wait for a given point to appear and/or be signaled
+ *   - Import and export from/to a given point of a timeline
+ *
   * At it's core, a syncobj is simply a wrapper around a pointer to a struct
   * &dma_fence which may be NULL.
   * When a syncobj is first created, its pointer is either NULL or a pointer
   * to an already signaled fence depending on whether the
   * &DRM_SYNCOBJ_CREATE_SIGNALED flag is passed to
   * &DRM_IOCTL_SYNCOBJ_CREATE.
- * When GPU work which signals a syncobj is enqueued in a DRM driver,
- * the syncobj fence is replaced with a fence which will be signaled by the
- * completion of that work.
- * When GPU work which waits on a syncobj is enqueued in a DRM driver, the
- * driver retrieves syncobj's current fence at the time the work is enqueued
- * waits on that fence before submitting the work to hardware.
- * If the syncobj's fence is NULL, the enqueue operation is expected to fail.
- * All manipulation of the syncobjs's fence happens in terms of the current
- * fence at the time the ioctl is called by userspace regardless of whether
- * that operation is an immediate host-side operation (signal or reset) or
- * or an operation which is enqueued in some driver queue.
- * &DRM_IOCTL_SYNCOBJ_RESET and &DRM_IOCTL_SYNCOBJ_SIGNAL can be used to
- * manipulate a syncobj from the host by resetting its pointer to NULL or
+ *
+ * If the syncobj is considered as a binary (its state is either signaled or
+ * unsignaled) primitive, when GPU work is enqueued in a DRM driver to signal
+ * the syncobj, the syncobj's fence is replaced with a fence which will be
+ * signaled by the completion of that work.
+ * If the syncobj is considered as a timeline primitive, when GPU work is
+ * enqueued in a DRM driver to signal the a given point of the syncobj, a new
+ * struct &dma_fence_chain pointing to the DRM driver's fence and also
+ * pointing to the previous fence that was in the syncobj. The new struct
+ * &dma_fence_chain fence replace the syncobj's fence and will be signaled by
+ * completion of the DRM driver's work and also any work associated with the
+ * fence previously in the syncobj.
+ *
+ * When GPU work which waits on a syncobj is enqueued in a DRM driver, at the
+ * time the work is enqueued, it waits on the syncobj's fence before
+ * submitting the work to hardware. That fence is either :
+ *
+ *- The syncobj's current fence if the syncobj is considered as a binary
+ *  primitive.
+ *- The struct &dma_fence associated with a given point if the syncobj is
+ *  considered as a timeline primitive.
+ *
+ * If the syncobj's fence is NULL or not present in the syncobj's timeline,
+ * the enqueue operation is expected to fail.
+ *
+ * With binary syncobj, all manipulation of the syncobjs's fence happens in
+ * terms of the current fence at the time the ioctl is called by userspace
+ * regardless of whether that operation is an immediate host-side operation
+ * (signal or reset) or or an operation which is enqueued in some driver
+ * queue. &DRM_IOCTL_SYNCOBJ_RESET and &DRM_IOCTL_SYNCOBJ_SIGNAL can be used
+ * to manipulate a syncobj from the host by resetting its pointer to NULL or
   * setting its pointer to a fence which is already signaled.
   *
+ * With a timeline syncobj, all manipulation of the synobj's fence happens in
+ * terms of a u64 value referring to point in the timeline. See
+ * dma_fence_chain_find_seqno() to see how a given point is found in the
+ * timeline.
+ *
+ * Note that applications should be careful to always use timeline set of
+ * ioctl() when dealing with syncobj considered as timeline. Using a binary
+ * set of ioctl() with a syncobj considered as timeline could result incorrect
+ * synchronization. The use of binary syncobj is supported through the
+ * timeline set of ioctl() by using a point value of 0, this will reproduce
+ * the behavior of the binary set of ioctl() (for 

Re: [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed

[Ville Syrjälä]

On Tue, Jan 14, 2020 at 04:11:40PM +0200, Jani Nikula wrote:
> On Mon, 06 Jan 2020, Kai-Heng Feng  wrote:
> > Hi Jani,
> >
> >> On Dec 24, 2019, at 16:42, Kai-Heng Feng  
> >> wrote:
> >> 
> >> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> >> becomes useless and never responds to cable hotplugging:
> >> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> >> [3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on 
> >> port D
> >> 
> >> Seems like the lspcon chip on the system in question only gets powered
> >> after the cable is plugged.
> >> 
> >> So let's call lspcon_init() dynamically to properly initialize the
> >> lspcon chip and make HDMI port work.
> >
> > Do you have any further suggestion for this patch?
> 
> Sorry for taking so long. Comments inline.
> 
> >
> > Kai-Heng
> >
> >> 
> >> Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
> >> Signed-off-by: Kai-Heng Feng 
> >> ---
> >> v3:
> >> - Make sure it's handled under long HPD case.
> >> 
> >> v2: 
> >> - Move lspcon_init() inside of intel_dp_hpd_pulse().
> >> 
> >> drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index fe31bbfd6c62..a72c9c041c60 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -6573,6 +6573,7 @@ enum irqreturn
> >> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool 
> >> long_hpd)
> >> {
> >>struct intel_dp *intel_dp = &intel_dig_port->dp;
> >> +  struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >> 
> >>if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> >>/*
> >> @@ -6593,7 +6594,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> >> *intel_dig_port, bool long_hpd)
> >>  long_hpd ? "long" : "short");
> >> 
> >>if (long_hpd) {
> >> -  intel_dp->reset_link_params = true;
> >> +  if (intel_dig_port->base.type == INTEL_OUTPUT_DDI &&
> >> +  HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
> >> +  lspcon_init(intel_dig_port);
> >> +  else
> >> +  intel_dp->reset_link_params = true;
> >> +
> 
> Hmm, I think this will try to init lspcon on ports that do not have
> lspcon. Also, why wouldn't we reset the params?
> 
> I think this boils down to just adding the following lines:
> 
>   if (intel_bios_is_lspcon_present(dev_priv, intel_dig_port->base.port) &&
> !intel_dig_port->lspcon.active)
>   lspcon_init(intel_dig_port);
> 
> 
> Ville?

This won't work right. Eg. intel_infoframe_init() assumes that lspcon
init happens during driver load. We should probably change that to just
trust the VBT and simply move the lspcon probe (if we even need one)
into dp_detect() instead of sprinkling it around in several places.

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

Re: [PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs

[Yannick FERTRE]

Thanks for the patch.

Tested-by: Yannick Fertré 

BR
Yannick Fertré


On 1/10/20 10:21 AM, Thomas Zimmermann wrote:

The new callback get_scanout_position() reads the current location of
the scanout process. The operation is currentyl located in struct
drm_driver, but really belongs to the CRTC. Drivers will be converted
in separate patches.

Signed-off-by: Thomas Zimmermann 

---
 drivers/gpu/drm/drm_vblank.c | 24 
 include/drm/drm_drv.h|  7 +---
 include/drm/drm_modeset_helper_vtables.h | 47 
 3 files changed, 65 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 1659b13b178c..c12f0b333e14 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -590,7 +591,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
  * Implements calculation of exact vblank timestamps from given 
drm_display_mode
  * timings and current video scanout position of a CRTC. This can be directly
  * used as the &drm_driver.get_vblank_timestamp implementation of a kms driver
- * if &drm_driver.get_scanout_position is implemented.
+ * if &drm_crtc_helper_funcs.get_scanout_position is implemented.
  *
  * The current implementation only handles standard video modes. For double 
scan
  * and interlaced modes the driver is supposed to adjust the hardware mode
@@ -632,8 +633,9 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
}

/* Scanout position query not supported? Should not happen. */
-   if (!dev->driver->get_scanout_position) {
-   DRM_ERROR("Called from driver w/o get_scanout_position()!?\n");
+   if (!dev->driver->get_scanout_position ||
+   !crtc->helper_private->get_scanout_position) {
+   DRM_ERROR("Called from CRTC w/o get_scanout_position()!?\n");
return false;
}

@@ -664,11 +666,17 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
 * Get vertical and horizontal scanout position vpos, hpos,
 * and bounding timestamps stime, etime, pre/post query.
 */
-   vbl_status = dev->driver->get_scanout_position(dev, pipe,
-  in_vblank_irq,
-  &vpos, &hpos,
-  &stime, &etime,
-  mode);
+   if (crtc->helper_private->get_scanout_position) {
+   vbl_status =
+   crtc->helper_private->get_scanout_position(
+   crtc, in_vblank_irq, &vpos, &hpos,
+   &stime, &etime, mode);
+   } else {
+   vbl_status =
+   dev->driver->get_scanout_position(
+   dev, pipe, in_vblank_irq, &vpos,
+   &hpos, &stime, &etime, mode);
+   }

/* Return as no-op if scanout query unsupported or failed. */
if (!vbl_status) {
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index cf13470810a5..d0049e5786fc 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -362,11 +362,8 @@ struct drm_driver {
 * True on success, false if a reliable scanout position counter could
 * not be read out.
 *
-* FIXME:
-*
-* Since this is a helper to implement @get_vblank_timestamp, we should
-* move it to &struct drm_crtc_helper_funcs, like all the other
-* helper-internal hooks.
+* This is deprecated and should not be used by new drivers.
+* Use &drm_crtc_helper_funcs.get_scanout_position instead.
 */
bool (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
  bool in_vblank_irq, int *vpos, int *hpos,
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index 5a87f1bd7a3f..e398512bfd5f 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -450,6 +450,53 @@ struct drm_crtc_helper_funcs {
 */
void (*atomic_disable)(struct drm_crtc *crtc,
   struct drm_crtc_state *old_crtc_state);
+
+   /**
+* @get_scanout_position:
+*
+* Called by vblank timestamping code.
+*
+* Returns the current display scanout position from a CRTC and an
+* optional accurate ktime_get() timestamp of when the position was
+* measured. Note that this is a 

Re: [PATCH 09/23] drm: Remove struct drm_driver.get_scanout_position()

[Yannick FERTRE]

Thanks for the patch.

Tested-by: Yannick Fertré 

BR
Yannick Fertré


On 1/10/20 10:21 AM, Thomas Zimmermann wrote:

All users of struct drm_driver.get_scanout_position() have been
covnerted to the respective CRTC helper function. Remove the callback
from struct drm_driver.

Signed-off-by: Thomas Zimmermann 

---
 drivers/gpu/drm/drm_vblank.c | 13 ++---
 include/drm/drm_drv.h| 52 
 2 files changed, 2 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index c12f0b333e14..b84065911d69 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -633,8 +633,7 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
}

/* Scanout position query not supported? Should not happen. */
-   if (!dev->driver->get_scanout_position ||
-   !crtc->helper_private->get_scanout_position) {
+   if (!crtc->helper_private->get_scanout_position) {
DRM_ERROR("Called from CRTC w/o get_scanout_position()!?\n");
return false;
}
@@ -666,17 +665,9 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
 * Get vertical and horizontal scanout position vpos, hpos,
 * and bounding timestamps stime, etime, pre/post query.
 */
-   if (crtc->helper_private->get_scanout_position) {
-   vbl_status =
-   crtc->helper_private->get_scanout_position(
+   vbl_status = crtc->helper_private->get_scanout_position(
crtc, in_vblank_irq, &vpos, &hpos,
&stime, &etime, mode);
-   } else {
-   vbl_status =
-   dev->driver->get_scanout_position(
-   dev, pipe, in_vblank_irq, &vpos,
-   &hpos, &stime, &etime, mode);
-   }

/* Return as no-op if scanout query unsupported or failed. */
if (!vbl_status) {
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d0049e5786fc..b704e252f3b2 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -318,58 +318,6 @@ struct drm_driver {
 */
void (*disable_vblank) (struct drm_device *dev, unsigned int pipe);

-   /**
-* @get_scanout_position:
-*
-* Called by vblank timestamping code.
-*
-* Returns the current display scanout position from a crtc, and an
-* optional accurate ktime_get() timestamp of when position was
-* measured. Note that this is a helper callback which is only used if a
-* driver uses drm_calc_vbltimestamp_from_scanoutpos() for the
-* @get_vblank_timestamp callback.
-*
-* Parameters:
-*
-* dev:
-* DRM device.
-* pipe:
-* Id of the crtc to query.
-* in_vblank_irq:
-* True when called from drm_crtc_handle_vblank().  Some drivers
-* need to apply some workarounds for gpu-specific vblank irq quirks
-* if flag is set.
-* vpos:
-* Target location for current vertical scanout position.
-* hpos:
-* Target location for current horizontal scanout position.
-* stime:
-* Target location for timestamp taken immediately before
-* scanout position query. Can be NULL to skip timestamp.
-* etime:
-* Target location for timestamp taken immediately after
-* scanout position query. Can be NULL to skip timestamp.
-* mode:
-* Current display timings.
-*
-* Returns vpos as a positive number while in active scanout area.
-* Returns vpos as a negative number inside vblank, counting the number
-* of scanlines to go until end of vblank, e.g., -1 means "one scanline
-* until start of active scanout / end of vblank."
-*
-* Returns:
-*
-* True on success, false if a reliable scanout position counter could
-* not be read out.
-*
-* This is deprecated and should not be used by new drivers.
-* Use &drm_crtc_helper_funcs.get_scanout_position instead.
-*/
-   bool (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
- bool in_vblank_irq, int *vpos, int *hpos,
- ktime_t *stime, ktime_t *etime,
- const struct drm_display_mode *mode);
-
/**
 * @get_vblank_timestamp:
 *


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

Re: [PATCH 08/23] drm/stm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

[Yannick FERTRE]

Thanks for the patch.

Tested-by: Yannick Fertré 

BR
Yannick Fertré


On 1/10/20 10:21 AM, Thomas Zimmermann wrote:

The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm
over.

Signed-off-by: Thomas Zimmermann 

---
 drivers/gpu/drm/stm/drv.c  |  1 -
 drivers/gpu/drm/stm/ltdc.c | 65 --
 drivers/gpu/drm/stm/ltdc.h |  5 ---
 3 files changed, 34 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 5a9f9aca8bc2..486985604109 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -72,7 +72,6 @@ static struct drm_driver drv_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .get_scanout_position = ltdc_crtc_scanoutpos,
.get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
 };

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index c2815e8ae1da..8b6d1a2252e3 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -636,38 +636,13 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
}
 }

-static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
-   .mode_valid = ltdc_crtc_mode_valid,
-   .mode_fixup = ltdc_crtc_mode_fixup,
-   .mode_set_nofb = ltdc_crtc_mode_set_nofb,
-   .atomic_flush = ltdc_crtc_atomic_flush,
-   .atomic_enable = ltdc_crtc_atomic_enable,
-   .atomic_disable = ltdc_crtc_atomic_disable,
-};
-
-static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
-{
-   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
-
-   DRM_DEBUG_DRIVER("\n");
-   reg_set(ldev->regs, LTDC_IER, IER_LIE);
-
-   return 0;
-}
-
-static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
-{
-   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
-
-   DRM_DEBUG_DRIVER("\n");
-   reg_clear(ldev->regs, LTDC_IER, IER_LIE);
-}
-
-bool ltdc_crtc_scanoutpos(struct drm_device *ddev, unsigned int pipe,
- bool in_vblank_irq, int *vpos, int *hpos,
- ktime_t *stime, ktime_t *etime,
- const struct drm_display_mode *mode)
+static bool ltdc_crtc_get_scanout_position(struct drm_crtc *crtc,
+  bool in_vblank_irq,
+  int *vpos, int *hpos,
+  ktime_t *stime, ktime_t *etime,
+  const struct drm_display_mode *mode)
 {
+   struct drm_device *ddev = crtc->dev;
struct ltdc_device *ldev = ddev->dev_private;
int line, vactive_start, vactive_end, vtotal;

@@ -710,6 +685,34 @@ bool ltdc_crtc_scanoutpos(struct drm_device *ddev, 
unsigned int pipe,
return true;
 }

+static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
+   .mode_valid = ltdc_crtc_mode_valid,
+   .mode_fixup = ltdc_crtc_mode_fixup,
+   .mode_set_nofb = ltdc_crtc_mode_set_nofb,
+   .atomic_flush = ltdc_crtc_atomic_flush,
+   .atomic_enable = ltdc_crtc_atomic_enable,
+   .atomic_disable = ltdc_crtc_atomic_disable,
+   .get_scanout_position = ltdc_crtc_get_scanout_position,
+};
+
+static int ltdc_crtc_enable_vblank(struct drm_crtc *crtc)
+{
+   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+
+   DRM_DEBUG_DRIVER("\n");
+   reg_set(ldev->regs, LTDC_IER, IER_LIE);
+
+   return 0;
+}
+
+static void ltdc_crtc_disable_vblank(struct drm_crtc *crtc)
+{
+   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
+
+   DRM_DEBUG_DRIVER("\n");
+   reg_clear(ldev->regs, LTDC_IER, IER_LIE);
+}
+
 static const struct drm_crtc_funcs ltdc_crtc_funcs = {
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index a1ad0ae3b006..c5467d74e707 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -39,11 +39,6 @@ struct ltdc_device {
struct drm_atomic_state *suspend_state;
 };

-bool ltdc_crtc_scanoutpos(struct drm_device *dev, unsigned int pipe,
- bool in_vblank_irq, int *vpos, int *hpos,
- ktime_t *stime, ktime_t *etime,
- const struct drm_display_mode *mode);
-
 int ltdc_load(struct drm_device *ddev);
 void ltdc_unload(struct drm_device *ddev);
 void ltdc_suspend(struct drm_device *ddev);


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

Re: [PATCH 23/23] drm: Cleanup VBLANK callbacks in struct drm_driver

[Yannick FERTRE]

Thanks for the patch.

Tested-by: Yannick Fertré 

BR
Yannick Fertré


On 1/10/20 10:21 AM, Thomas Zimmermann wrote:

All non-legacy users of VBLANK functions in struct drm_driver have been
converted to use the respective interfaces in struct drm_crtc_funcs. The
remaining users of VBLANK callbacks in struct drm_driver are legacy drivers
with userspace modesetting.

There are no users left of get_vblank_timestamp(), so the callback is
being removed. The other VBLANK callbacks are being moved to the legacy
section at the end of struct drm_driver.

Signed-off-by: Thomas Zimmermann 

---
 drivers/gpu/drm/drm_vblank.c |  39 +-
 include/drm/drm_drv.h| 101 ++-
 2 files changed, 17 insertions(+), 123 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7cf436a4b908..ceff68474d4d 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -138,10 +138,9 @@ static u32 __get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)

if (crtc->funcs->get_vblank_counter)
return crtc->funcs->get_vblank_counter(crtc);
-   }
-
-   if (dev->driver->get_vblank_counter)
+   } else if (dev->driver->get_vblank_counter) {
return dev->driver->get_vblank_counter(dev, pipe);
+   }

return drm_vblank_no_hw_counter(dev, pipe);
 }
@@ -334,8 +333,7 @@ u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
unsigned long flags;

WARN_ONCE(drm_debug_enabled(DRM_UT_VBL) &&
- !crtc->funcs->get_vblank_timestamp &&
- !dev->driver->get_vblank_timestamp,
+ !crtc->funcs->get_vblank_timestamp,
  "This function requires support for accurate vblank 
timestamps.");

spin_lock_irqsave(&dev->vblank_time_lock, flags);
@@ -357,13 +355,11 @@ static void __disable_vblank(struct drm_device *dev, 
unsigned int pipe)
if (WARN_ON(!crtc))
return;

-   if (crtc->funcs->disable_vblank) {
+   if (crtc->funcs->disable_vblank)
crtc->funcs->disable_vblank(crtc);
-   return;
-   }
+   } else {
+   dev->driver->disable_vblank(dev, pipe);
}
-
-   dev->driver->disable_vblank(dev, pipe);
 }

 /*
@@ -791,9 +787,6 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned 
int pipe,

ret = crtc->funcs->get_vblank_timestamp(crtc, &max_error,
tvblank, in_vblank_irq);
-   } else if (dev->driver->get_vblank_timestamp && (max_error > 0)) {
-   ret = dev->driver->get_vblank_timestamp(dev, pipe, &max_error,
-   tvblank, in_vblank_irq);
}

/* GPU high precision timestamp query unsupported or failed.
@@ -1016,9 +1009,11 @@ static int __enable_vblank(struct drm_device *dev, 
unsigned int pipe)

if (crtc->funcs->enable_vblank)
return crtc->funcs->enable_vblank(crtc);
+   } else if (dev->driver->enable_vblank) {
+   return dev->driver->enable_vblank(dev, pipe);
}

-   return dev->driver->enable_vblank(dev, pipe);
+   return -EINVAL;
 }

 static int drm_vblank_enable(struct drm_device *dev, unsigned int pipe)
@@ -1109,13 +1104,10 @@ static bool __vblank_disable_immediate(struct 
drm_device *dev, unsigned int pipe
return false;

crtc = drm_crtc_from_index(dev, pipe);
-   if (crtc && crtc->funcs->get_vblank_timestamp)
-   return true;
-
-   if (dev->driver->get_vblank_timestamp)
-   return true;
+   if (!crtc || !crtc->funcs->get_vblank_timestamp)
+   return false;

-   return false;
+   return true;
 }

 static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
@@ -1798,7 +1790,6 @@ static void drm_handle_vblank_events(struct drm_device 
*dev, unsigned int pipe)
struct drm_pending_vblank_event *e, *t;
ktime_t now;
u64 seq;
-   bool high_prec;

assert_spin_locked(&dev->event_lock);

@@ -1818,10 +1809,8 @@ static void drm_handle_vblank_events(struct drm_device 
*dev, unsigned int pipe)
send_vblank_event(dev, e, seq, now);
}

-   high_prec = crtc->funcs->get_vblank_timestamp ||
-   dev->driver->get_vblank_timestamp;
-
-   trace_drm_vblank_event(pipe, seq, now, high_prec);
+   trace_drm_vblank_event(pipe, seq, now,
+  crtc->funcs->get_vblank_timestamp != NULL);
 }

 /**
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index b704e252f3b2..e290b3aca6eb 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -268,104 +268,6 @@ struct drm_driver {
 */
   

Re: [PATCH 19/23] drm/stm: Convert to CRTC VBLANK callbacks

[Yannick FERTRE]

Thanks for the patch.

Tested-by: Yannick Fertré 

BR
Yannick Fertré


On 1/10/20 10:21 AM, Thomas Zimmermann wrote:

VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert stm over.

Signed-off-by: Thomas Zimmermann 

---
 drivers/gpu/drm/stm/drv.c  | 1 -
 drivers/gpu/drm/stm/ltdc.c | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 486985604109..ea9fcbdc68b3 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -72,7 +72,6 @@ static struct drm_driver drv_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
-   .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
 };

 static int drv_load(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 8b6d1a2252e3..4fe9b033de1b 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -722,6 +722,7 @@ static const struct drm_crtc_funcs ltdc_crtc_funcs = {
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.enable_vblank = ltdc_crtc_enable_vblank,
.disable_vblank = ltdc_crtc_disable_vblank,
+   .get_vblank_timestamp = drm_crtc_calc_vbltimestamp_from_scanoutpos,
.gamma_set = drm_atomic_helper_legacy_gamma_set,
 };



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

Re: [PATCH v3 4/7] drm/panfrost: Add support for multiple regulators

[Mark Brown]

On Tue, Jan 14, 2020 at 03:15:59PM +0800, Nicolas Boichat wrote:

>  - I couldn't find a way to detect the number of regulators in the
>device tree, if we wanted to refuse to probe the device if there
>are too many regulators, which might be required for safety, see
>the thread on v2 [1].

You'd need to enumerate all the properties of the device and look
for things matching *-supply.

Reviewed-by: Mark Brown 


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

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

[Jordan Crouse]

On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote:
> On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse  wrote:
> >
> > On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote:
> > > This
> > >
> > > 1) Enables core DRM syncobj support.
> > > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> > >
> > > Just like the wait fence fd, this does inline waits. Using the
> > > scheduler would be nice but I believe it is out of scope for
> > > this work.
> > >
> > > Support for timeline syncobjs is implemented and the interface
> > > is ready for it, but I'm not enabling it yet until there is
> > > some code for turnip to use it.
> > >
> > > The reset is mostly in there because in the presence of waiting
> > > and signalling the same semaphores, resetting them after
> > > signalling can become very annoying.
> > >
> > > Signed-off-by: Bas Nieuwenhuizen 
> > > ---
> > >
> > > Userspace code in
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2769
> > >
> > >  drivers/gpu/drm/msm/msm_drv.c|   6 +-
> > >  drivers/gpu/drm/msm/msm_gem_submit.c | 241 ++-
> > >  include/uapi/drm/msm_drm.h   |  22 ++-
> > >  3 files changed, 265 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > > index c84f0a8b3f2c..ca36d6b21d8f 100644
> > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > @@ -37,9 +37,10 @@
> > >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
> > >   *   GEM object's debug name
> > >   * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > > + * - 1.6.0 - Syncobj support
> > >   */
> > >  #define MSM_VERSION_MAJOR1
> > > -#define MSM_VERSION_MINOR5
> > > +#define MSM_VERSION_MINOR6
> > >  #define MSM_VERSION_PATCHLEVEL   0
> > >
> > >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > > @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> > >   .driver_features= DRIVER_GEM |
> > >   DRIVER_RENDER |
> > >   DRIVER_ATOMIC |
> > > - DRIVER_MODESET,
> > > + DRIVER_MODESET|
> >
> > A space before the | would be preferred.
> 
> Done.
> >
> > > + DRIVER_SYNCOBJ,
> > >   .open   = msm_open,
> > >   .postclose   = msm_postclose,
> > >   .lastclose  = drm_fb_helper_lastclose,
> > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > index be5327af16fa..9085229f88e0 100644
> > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > @@ -8,7 +8,9 @@
> > >  #include 
> > >  #include 
> > >
> > > +#include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "msm_drv.h"
> > >  #include "msm_gpu.h"
> > > @@ -394,6 +396,196 @@ static void submit_cleanup(struct msm_gem_submit 
> > > *submit)
> > >   ww_acquire_fini(&submit->ticket);
> > >  }
> > >
> > > +
> > > +struct msm_submit_post_dep {
> > > + struct drm_syncobj *syncobj;
> > > + uint64_t point;
> > > + struct dma_fence_chain *chain;
> > > +};
> > > +
> > > +static int msm_wait_deps(struct drm_device *dev,
> > > + struct drm_file *file,
> > > + uint64_t in_syncobjs_addr,
> > > + uint32_t nr_in_syncobjs,
> > > + struct msm_ringbuffer *ring,
> > > + struct drm_syncobj ***syncobjs)
> > > +{
> > > + struct drm_msm_gem_submit_syncobj *syncobj_descs;
> > > + int ret = 0;
> > > + uint32_t i, j;
> > > +
> > > + syncobj_descs = kmalloc_array(nr_in_syncobjs, 
> > > sizeof(*syncobj_descs),
> > > +   GFP_KERNEL);
> > > + if (!syncobj_descs)
> > > + return -ENOMEM;
> > > +
> > We would want to watch out here for fuzzers and malicious actors that try to
> > force an enormous memory allocation. It seems like we should be able to
> > iteratively read each fences in the loop and skip this memory allocation.
> >
> > > + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs), GFP_KERNEL);
> > > + if (!syncobjs) {
> > > + ret = -ENOMEM;
> > > + goto out_syncobjs;
> > > + }
> >
> > Alas no good way to skip this one. But it seems that syncobjs should only
> > contain descriptors with MSM_SUBMIT_SYNCOBJ_RESET set. I'm not very familiar
> > with how fences work so I'm not sure how common this path is. Would the same
> > fuzzer or malicious actor be able to double the destruction by forcing a 
> > large
> > allocation that doesn't even end up getting used?
> 
> In real usecases I expect MSM_SUBMIT_SYNCOBJ_RESET to be set for 50%+
> of the entries and the number of entries to be < 10.
> 
> I can certainly start doing a copy_from_use

Re: [PATCH] drm/msm: Fix error about comments within a comment block

[Jordan Crouse]

On Mon, Jan 13, 2020 at 02:04:46PM -0800, Douglas Anderson wrote:
> My compiler yells:
>   .../drivers/gpu/drm/msm/adreno/adreno_gpu.c:69:27:
>   error: '/*' within block comment [-Werror,-Wcomment]
> 
> Let's fix.

grumble something about the road being paved with good intentions

Reviewed-by: Jordan Crouse 

> Fixes: 6a0dea02c2c4 ("drm/msm: support firmware-name for zap fw (v2)")
> Signed-off-by: Douglas Anderson 
> ---
> 
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index c146c3b8f52b..7fd29829b2fa 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -67,7 +67,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> char *fwname,
>*
>* If the firmware-name property is found, we bypass the
>* adreno_request_fw() mechanism, because we don't need to handle
> -  * the /lib/firmware/qcom/* vs /lib/firmware/* case.
> +  * the /lib/firmware/qcom/... vs /lib/firmware/... case.
>*
>* If the firmware-name property is not found, for backwards
>* compatibility we fall back to the fwname from the gpulist
> -- 
> 2.25.0.rc1.283.g88dfdc4193-goog
> 

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

[PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Sean Paul]

From: Sean Paul 

This patch uses a ring_buffer to keep a "flight recorder" (name credit Weston)
of DRM logs for a specified set of debug categories. The user writes a
bitmask of debug categories to the "trace_mask" node and can read log
messages from the "trace" node.

These nodes currently exist in debugfs under the dri directory. I
intended on exposing all of this through tracefs originally, but the
tracefs entry points are not exposed, so there's no way to create
tracefs files from drivers at the moment. I think it would be a
worthwhile endeavour, but one requiring more time and conversation to
ensure the drm traces fit somewhere sensible.

Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Pekka Paalanen 
Cc: Rob Clark 
Cc: Steven Rostedt 
Cc: Thomas Zimmermann 
Cc: Ville Syrjälä 
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
 #v1
Link: 
https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html #v2
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191212203301.142437-1-s...@poorly.run
 #v3

Changes in v2:
- Went with a completely different approach:
https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html

Changes in v3:
- Changed commit message to be a bit less RFC-y
- Make class_drm_category_log an actual trace class

Changes in v4:
- Instead of [ab]using trace events and the system trace buffer, use our
  own ringbuffer
---
---
 Documentation/gpu/drm-uapi.rst |   9 +
 drivers/gpu/drm/Kconfig|   1 +
 drivers/gpu/drm/Makefile   |   2 +-
 drivers/gpu/drm/drm_drv.c  |   3 +
 drivers/gpu/drm/drm_print.c|  80 +--
 drivers/gpu/drm/drm_trace.c| 376 +
 include/drm/drm_print.h|  39 
 7 files changed, 487 insertions(+), 23 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_trace.c

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..089eb6fd3e94 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -312,6 +312,15 @@ Debugfs Support
 .. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
:export:
 
+DRM Tracing
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_trace.c
+   :doc: DRM Tracing
+
+.. kernel-doc:: drivers/gpu/drm/drm_trace.c
+   :internal:
+
 Sysfs Support
 =
 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d0aa6cff2e02..9d8077e87afe 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -14,6 +14,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+   select RING_BUFFER
select SYNC_FILE
help
  Kernel-level support for the Direct Rendering Infrastructure (DRI)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6493088a0fdd..88b4674934e6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -29,7 +29,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_PCI) += drm_pci.o
-drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o drm_trace.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 
 drm_vram_helper-y := drm_gem_vram_helper.o \
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7c18a980cd4b..98260b9f8004 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1114,6 +1114,7 @@ static const struct file_operations drm_stub_fops = {
 static void drm_core_exit(void)
 {
unregister_chrdev(DRM_MAJOR, "drm");
+   drm_trace_cleanup();
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
idr_destroy(&drm_minors_idr);
@@ -1135,6 +1136,8 @@ static int __init drm_core_init(void)
 
drm_debugfs_root = debugfs_create_dir("dri", NULL);
 
+   WARN_ON(drm_trace_init(drm_debugfs_root));
+
ret = register_chrdev(DRM_MAJOR, "drm", &drm_stub_fops);
if (ret < 0)
goto error;
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 111b932cf2a9..0ac1867937bf 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -262,21 +262,37 @@ void drm_dev_dbg(const struct device *dev, enum 
drm_debug_category category,
struct va_format vaf;
va_list args;
 
-   if (!drm_debug_enabled(category))
-   return;
-
-   va_start(args, format);
-   vaf.fmt = format;
-   vaf.va = &args;
-
-   if (dev)
-   dev_printk(KERN_DEBUG, dev, "[" DRM_NAME ":%ps] %pV",
-  __builtin_return_address(0), &vaf);
-   else
-   printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
-  __builtin_return_address(0), &vaf);
+   if (drm_debug_enabled(category)) {
+   va_start(args, format);
+  

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Jordan Crouse]

On Tue, Jan 14, 2020 at 08:52:43AM -0800, Rob Clark wrote:
> On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse  wrote:
> >
> > On Mon, Jan 13, 2020 at 10:36:05AM -0500, Brian Ho wrote:
> > > +
> > > + vaddr = base_vaddr + args->offset;
> > > +
> > > + /* Assumes WC mapping */
> > > + ret = wait_event_interruptible_timeout(
> > > + gpu->event, *vaddr >= args->value, 
> > > remaining_jiffies);
> >
> > I feel like a barrier might be needed before checking *vaddr just in case 
> > you
> > get the interrupt and wake up the queue before the write posts from the
> > hardware.
> >
> 
> if the gpu is doing posted (or cached) writes, I don't think there is
> even a CPU side barrier primitive that could wait for that?  I think
> we rely on the GPU not interrupting the CPU until the write is posted

Once the GPU puts the write on the bus then it is up to the whims of the CPU
architecture. If the writes are being done out of order you run a chance of
firing the interrupt and making it all the way to your handler before the writes
catch up.

Since you are scheduling and doing a bunch of things in between you probably
don't need to worry but if you start missing events and you don't know why then
this could be why. A rmb() would give you piece of mind at the cost of being
Yet Another Barrier (TM).

Jordan

> BR,
> -R
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

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

[pull] drm/msm: msm-next for 5.6

[Rob Clark]

Hi Dave,

This time around:

+ sc7180 display + DSI support
+ a618 (sc7180) support
+ more UBWC (bandwidth compression) support
+ various cleanups to handle devices that use vs don't
  use zap fw, etc
+ usual random cleanups and fixes


The following changes since commit fd6988496e79a6a4bdb514a4655d2920209eb85d:

  Linux 5.5-rc4 (2019-12-29 15:29:16 -0800)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2020-01-14

for you to fetch changes up to 5f9935f514d66ddba868e587d9e976a567232547:

  drm/msm: Fix error about comments within a comment block (2020-01-13
16:06:00 -0800)


Brian Masney (4):
  dt-bindings: drm/msm/gpu: document second interconnect
  drm/msm/gpu: add support for ocmem interconnect path
  drm/msm/a3xx: set interconnect bandwidth vote
  drm/msm/a4xx: set interconnect bandwidth vote

Douglas Anderson (1):
  drm/msm: Fix error about comments within a comment block

Drew Davenport (6):
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL checks
  drm/msm/dpu: Remove unnecessary NULL check
  drm/msm/dpu: Remove unreachable code
  drm/msm/dpu: Remove unnecessary NULL checks

Fabio Estevam (1):
  drm/msm/adreno: Do not print error on "qcom, gpu-pwrlevels" absence

Fritz Koenig (2):
  drm/msm/dpu: Add UBWC support for RGB formats
  drm/msm/dpu: Allow UBWC on NV12

Harigovindan P (2):
  drm/msm: add DSI support for sc7180
  drm/msm: update LANE_CTRL register value from default value

John Stultz (1):
  drm: msm: Quiet down plane errors in atomic_check

Kalyan Thota (4):
  dt-bindings: msm:disp: add sc7180 DPU variant
  msm:disp:dpu1: add support for display for SC7180 target
  msm:disp:dpu1: setup display datapath for SC7180 target
  msm:disp:dpu1: add mixer selection for display topology

Nathan Chancellor (1):
  drm: msm: mdp4: Adjust indentation in mdp4_dsi_encoder_enable

Rob Clark (7):
  drm/msm/dpu: ignore NULL clocks
  drm/msm/a6xx: restore previous freq on resume
  drm/msm/adreno: fix zap vs no-zap handling
  drm/msm/dsi: split clk rate setting and enable
  drm/msm: support firmware-name for zap fw (v2)
  drm/msm: allow zapfw to not be specified in gpulist
  dt-bindings: drm/msm/gpu: Document firmware-name

Sharat Masetty (3):
  drm: msm: Add 618 gpu to the adreno gpu list
  drm: msm: a6xx: Add support for A618
  drm: msm: a6xx: Dump GBIF registers, debugbus in gpu state

Shubhashree Dhar (3):
  msm: disp: dpu1: add support to access hw irqs regs depending on revision
  msm:disp:dpu1: add scaler support on SC7180 display
  msm:disp:dpu1: Fix core clk rate in display driver

Stephan Gerhold (1):
  drm/msm/dsi: Delay drm_panel_enable() until dsi_mgr_bridge_enable()

Stephen Boyd (1):
  drm/msm/dpu: Mark various data tables as const

Wambui Karuga (1):
  drm/msm: use BUG_ON macro for debugging.

zhengbin (4):
  drm/msm/hdmi: Remove unneeded semicolon
  drm/msm/mdp5: Remove unneeded semicolon
  drm/msm/dpu: Remove unneeded semicolon in dpu_plane.c
  drm/msm/dpu: Remove unneeded semicolon in dpu_encoder.c

 .../devicetree/bindings/display/msm/dpu.txt|   4 +-
 .../devicetree/bindings/display/msm/gpu.txt|   9 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |   8 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c  |   8 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  |  11 +-
 drivers/gpu/drm/msm/adreno/a6xx.xml.h  |  52 -
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  |  32 ++-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h  |   3 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  81 ++-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   9 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c|  52 -
 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h|  16 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c |  11 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  66 --
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|  17 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  15 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 186 +++-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  73 ++-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  73 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c|  18 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 241 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  38 ++--
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h  |   4 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c |  92 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  26 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c  |  22 +-
 drivers/gpu/d

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

[Kristian Høgsberg]

On Tue, Jan 14, 2020 at 8:41 AM Rob Clark  wrote:
>
> On Tue, Jan 14, 2020 at 7:58 AM Jordan Crouse  wrote:
> >
> > On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote:
> > > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse  
> > > wrote:
> > > >
> > > > On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote:
> > > > > This
> > > > >
> > > > > 1) Enables core DRM syncobj support.
> > > > > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> > > > >
> > > > > Just like the wait fence fd, this does inline waits. Using the
> > > > > scheduler would be nice but I believe it is out of scope for
> > > > > this work.
> > > > >
> > > > > Support for timeline syncobjs is implemented and the interface
> > > > > is ready for it, but I'm not enabling it yet until there is
> > > > > some code for turnip to use it.
> > > > >
> > > > > The reset is mostly in there because in the presence of waiting
> > > > > and signalling the same semaphores, resetting them after
> > > > > signalling can become very annoying.
> > > > >
> > > > > Signed-off-by: Bas Nieuwenhuizen 
> > > > > ---
> > > > >
> > > > > Userspace code in
> > > > >
> > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2769
> > > > >
> > > > >  drivers/gpu/drm/msm/msm_drv.c|   6 +-
> > > > >  drivers/gpu/drm/msm/msm_gem_submit.c | 241 
> > > > > ++-
> > > > >  include/uapi/drm/msm_drm.h   |  22 ++-
> > > > >  3 files changed, 265 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_drv.c 
> > > > > b/drivers/gpu/drm/msm/msm_drv.c
> > > > > index c84f0a8b3f2c..ca36d6b21d8f 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > > > @@ -37,9 +37,10 @@
> > > > >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to 
> > > > > set/get
> > > > >   *   GEM object's debug name
> > > > >   * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > > > > + * - 1.6.0 - Syncobj support
> > > > >   */
> > > > >  #define MSM_VERSION_MAJOR1
> > > > > -#define MSM_VERSION_MINOR5
> > > > > +#define MSM_VERSION_MINOR6
> > > > >  #define MSM_VERSION_PATCHLEVEL   0
> > > > >
> > > > >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > > > > @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> > > > >   .driver_features= DRIVER_GEM |
> > > > >   DRIVER_RENDER |
> > > > >   DRIVER_ATOMIC |
> > > > > - DRIVER_MODESET,
> > > > > + DRIVER_MODESET|
> > > >
> > > > A space before the | would be preferred.
> > >
> > > Done.
> > > >
> > > > > + DRIVER_SYNCOBJ,
> > > > >   .open   = msm_open,
> > > > >   .postclose   = msm_postclose,
> > > > >   .lastclose  = drm_fb_helper_lastclose,
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > index be5327af16fa..9085229f88e0 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > @@ -8,7 +8,9 @@
> > > > >  #include 
> > > > >  #include 
> > > > >
> > > > > +#include 
> > > > >  #include 
> > > > > +#include 
> > > > >
> > > > >  #include "msm_drv.h"
> > > > >  #include "msm_gpu.h"
> > > > > @@ -394,6 +396,196 @@ static void submit_cleanup(struct 
> > > > > msm_gem_submit *submit)
> > > > >   ww_acquire_fini(&submit->ticket);
> > > > >  }
> > > > >
> > > > > +
> > > > > +struct msm_submit_post_dep {
> > > > > + struct drm_syncobj *syncobj;
> > > > > + uint64_t point;
> > > > > + struct dma_fence_chain *chain;
> > > > > +};
> > > > > +
> > > > > +static int msm_wait_deps(struct drm_device *dev,
> > > > > + struct drm_file *file,
> > > > > + uint64_t in_syncobjs_addr,
> > > > > + uint32_t nr_in_syncobjs,
> > > > > + struct msm_ringbuffer *ring,
> > > > > + struct drm_syncobj ***syncobjs)
> > > > > +{
> > > > > + struct drm_msm_gem_submit_syncobj *syncobj_descs;
> > > > > + int ret = 0;
> > > > > + uint32_t i, j;
> > > > > +
> > > > > + syncobj_descs = kmalloc_array(nr_in_syncobjs, 
> > > > > sizeof(*syncobj_descs),
> > > > > +   GFP_KERNEL);
> > > > > + if (!syncobj_descs)
> > > > > + return -ENOMEM;
> > > > > +
> > > > We would want to watch out here for fuzzers and malicious actors that 
> > > > try to
> > > > force an enormous memory allocation. It seems like we should be able to
> > > > iteratively read each fences in the loop and skip this memory 
> > > > allocation.
> > > >
> > > > > + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs), 
> > > > > GFP_KERNEL);
> > > > > + if (!syncobjs) {
> > > > > + 

Re: [PATCH v4] drm/trace: Buffer DRM logs in a ringbuffer accessible via debugfs

[Steven Rostedt]

On Tue, 14 Jan 2020 12:21:43 -0500
Sean Paul  wrote:

> From: Sean Paul 
> 
> This patch uses a ring_buffer to keep a "flight recorder" (name credit Weston)
> of DRM logs for a specified set of debug categories. The user writes a
> bitmask of debug categories to the "trace_mask" node and can read log
> messages from the "trace" node.
> 
> These nodes currently exist in debugfs under the dri directory. I
> intended on exposing all of this through tracefs originally, but the
> tracefs entry points are not exposed, so there's no way to create
> tracefs files from drivers at the moment. I think it would be a
> worthwhile endeavour, but one requiring more time and conversation to
> ensure the drm traces fit somewhere sensible.

You may want to rebase these on my tree that renames ring_buffer to
trace_buffer. For more information, read this thread:

  https://lore.kernel.org/r/20191213153553.GE20583@krava

My tree is currently being tested and when it finishes contingent on no
errors found, I'll be pushing it to linux-next.

 
https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git/commit/?h=ftrace/core&id=13292494379f92f532de71b31a54018336adc589

-- Steve


> 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Pekka Paalanen 
> Cc: Rob Clark 
> Cc: Steven Rostedt 
> Cc: Thomas Zimmermann 
> Cc: Ville Syrjälä 
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
>  #v1
> Link: 
> https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html #v2
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191212203301.142437-1-s...@poorly.run
>  #v3
> 
> Changes in v2:
> - Went with a completely different approach:
> https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html
> 
> Changes in v3:
> - Changed commit message to be a bit less RFC-y
> - Make class_drm_category_log an actual trace class
> 
> Changes in v4:
> - Instead of [ab]using trace events and the system trace buffer, use our
>   own ringbuffer
> ---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH] drm/msm: Add syncobj support.

[Jordan Crouse]

On Tue, Jan 14, 2020 at 08:41:05AM -0800, Rob Clark wrote:
> On Tue, Jan 14, 2020 at 7:58 AM Jordan Crouse  wrote:
> >
> > On Tue, Jan 14, 2020 at 01:40:11AM +0100, Bas Nieuwenhuizen wrote:
> > > On Tue, Jan 14, 2020 at 12:41 AM Jordan Crouse  
> > > wrote:
> > > >
> > > > On Mon, Jan 13, 2020 at 09:25:57PM +0100, Bas Nieuwenhuizen wrote:
> > > > > This
> > > > >
> > > > > 1) Enables core DRM syncobj support.
> > > > > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> > > > >
> > > > > Just like the wait fence fd, this does inline waits. Using the
> > > > > scheduler would be nice but I believe it is out of scope for
> > > > > this work.
> > > > >
> > > > > Support for timeline syncobjs is implemented and the interface
> > > > > is ready for it, but I'm not enabling it yet until there is
> > > > > some code for turnip to use it.
> > > > >
> > > > > The reset is mostly in there because in the presence of waiting
> > > > > and signalling the same semaphores, resetting them after
> > > > > signalling can become very annoying.
> > > > >
> > > > > Signed-off-by: Bas Nieuwenhuizen 
> > > > > ---
> > > > >
> > > > > Userspace code in
> > > > >
> > > > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2769
> > > > >
> > > > >  drivers/gpu/drm/msm/msm_drv.c|   6 +-
> > > > >  drivers/gpu/drm/msm/msm_gem_submit.c | 241 
> > > > > ++-
> > > > >  include/uapi/drm/msm_drm.h   |  22 ++-
> > > > >  3 files changed, 265 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_drv.c 
> > > > > b/drivers/gpu/drm/msm/msm_drv.c
> > > > > index c84f0a8b3f2c..ca36d6b21d8f 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_drv.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > > > > @@ -37,9 +37,10 @@
> > > > >   * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to 
> > > > > set/get
> > > > >   *   GEM object's debug name
> > > > >   * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
> > > > > + * - 1.6.0 - Syncobj support
> > > > >   */
> > > > >  #define MSM_VERSION_MAJOR1
> > > > > -#define MSM_VERSION_MINOR5
> > > > > +#define MSM_VERSION_MINOR6
> > > > >  #define MSM_VERSION_PATCHLEVEL   0
> > > > >
> > > > >  static const struct drm_mode_config_funcs mode_config_funcs = {
> > > > > @@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
> > > > >   .driver_features= DRIVER_GEM |
> > > > >   DRIVER_RENDER |
> > > > >   DRIVER_ATOMIC |
> > > > > - DRIVER_MODESET,
> > > > > + DRIVER_MODESET|
> > > >
> > > > A space before the | would be preferred.
> > >
> > > Done.
> > > >
> > > > > + DRIVER_SYNCOBJ,
> > > > >   .open   = msm_open,
> > > > >   .postclose   = msm_postclose,
> > > > >   .lastclose  = drm_fb_helper_lastclose,
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > index be5327af16fa..9085229f88e0 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > @@ -8,7 +8,9 @@
> > > > >  #include 
> > > > >  #include 
> > > > >
> > > > > +#include 
> > > > >  #include 
> > > > > +#include 
> > > > >
> > > > >  #include "msm_drv.h"
> > > > >  #include "msm_gpu.h"
> > > > > @@ -394,6 +396,196 @@ static void submit_cleanup(struct 
> > > > > msm_gem_submit *submit)
> > > > >   ww_acquire_fini(&submit->ticket);
> > > > >  }
> > > > >
> > > > > +
> > > > > +struct msm_submit_post_dep {
> > > > > + struct drm_syncobj *syncobj;
> > > > > + uint64_t point;
> > > > > + struct dma_fence_chain *chain;
> > > > > +};
> > > > > +
> > > > > +static int msm_wait_deps(struct drm_device *dev,
> > > > > + struct drm_file *file,
> > > > > + uint64_t in_syncobjs_addr,
> > > > > + uint32_t nr_in_syncobjs,
> > > > > + struct msm_ringbuffer *ring,
> > > > > + struct drm_syncobj ***syncobjs)
> > > > > +{
> > > > > + struct drm_msm_gem_submit_syncobj *syncobj_descs;
> > > > > + int ret = 0;
> > > > > + uint32_t i, j;
> > > > > +
> > > > > + syncobj_descs = kmalloc_array(nr_in_syncobjs, 
> > > > > sizeof(*syncobj_descs),
> > > > > +   GFP_KERNEL);
> > > > > + if (!syncobj_descs)
> > > > > + return -ENOMEM;
> > > > > +
> > > > We would want to watch out here for fuzzers and malicious actors that 
> > > > try to
> > > > force an enormous memory allocation. It seems like we should be able to
> > > > iteratively read each fences in the loop and skip this memory 
> > > > allocation.
> > > >
> > > > > + *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs), 
> > > > > GFP_KERNEL);
> > > > > + if (!syncobjs) {
> > > > >

Re: [Freedreno] [PATCH 2/2] drm/msm: Add MSM_WAIT_IOVA ioctl

[Jordan Crouse]

On Tue, Jan 14, 2020 at 09:30:00AM -0800, Kristian Kristensen wrote:
> On Tue, Jan 14, 2020 at 9:23 AM Jordan Crouse  wrote:
> >
> > On Tue, Jan 14, 2020 at 08:52:43AM -0800, Rob Clark wrote:
> > > On Mon, Jan 13, 2020 at 9:51 AM Jordan Crouse  
> > > wrote:
> > > >
> > > > On Mon, Jan 13, 2020 at 10:36:05AM -0500, Brian Ho wrote:
> > > > > +
> > > > > + vaddr = base_vaddr + args->offset;
> > > > > +
> > > > > + /* Assumes WC mapping */
> > > > > + ret = wait_event_interruptible_timeout(
> > > > > + gpu->event, *vaddr >= args->value, 
> > > > > remaining_jiffies);
> > > >
> > > > I feel like a barrier might be needed before checking *vaddr just in 
> > > > case you
> > > > get the interrupt and wake up the queue before the write posts from the
> > > > hardware.
> > > >
> > >
> > > if the gpu is doing posted (or cached) writes, I don't think there is
> > > even a CPU side barrier primitive that could wait for that?  I think
> > > we rely on the GPU not interrupting the CPU until the write is posted
> >
> > Once the GPU puts the write on the bus then it is up to the whims of the CPU
> > architecture. If the writes are being done out of order you run a chance of
> > firing the interrupt and making it all the way to your handler before the 
> > writes
> > catch up.
> >
> > Since you are scheduling and doing a bunch of things in between you probably
> > don't need to worry but if you start missing events and you don't know why 
> > then
> > this could be why. A rmb() would give you piece of mind at the cost of being
> > Yet Another Barrier (TM).
> 
> Doesn't the fence case do the same thing without a barrier?

We get a free __iormb() and dma_rmb() from every gpu_read() so I think that
is enough to catch everything up when the interrupt handler reads the status
register and in most cases we don't check the fence until after that. I'm not
sure that covers all the possible error cases.  Maybe something to look into?

Also that field is marked as volatile in the struct, but I'm not sure that does
anything useful.

Jordan

> > > BR,
> > > -R
> > > ___
> > > Freedreno mailing list
> > > freedr...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/freedreno
> >
> > --
> > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > a Linux Foundation Collaborative Project
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

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

Re: [PATCH v2] drm/dp_mst: clear time slots for ports invalid

[Lyude Paul]

Pushed, thanks!

On Mon, 2020-01-06 at 18:21 +0800, Wayne Lin wrote:
> [Why]
> When change the connection status in a MST topology, mst device
> which detect the event will send out CONNECTION_STATUS_NOTIFY messgae.
> 
> e.g. src-mst-mst-sst => src-mst (unplug) mst-sst
> 
> Currently, under the above case of unplugging device, ports which have
> been allocated payloads and are no longer in the topology still occupy
> time slots and recorded in proposed_vcpi[] of topology manager.
> 
> If we don't clean up the proposed_vcpi[], when code flow goes to try to
> update payload table by calling drm_dp_update_payload_part1(), we will
> fail at checking port validation due to there are ports with proposed
> time slots but no longer in the mst topology. As the result of that, we
> will also stop updating the DPCD payload table of down stream port.
> 
> [How]
> While handling the CONNECTION_STATUS_NOTIFY message, add a detection to
> see if the event indicates that a device is unplugged to an output port.
> If the detection is true, then iterrate over all proposed_vcpi[] to
> see whether a port of the proposed_vcpi[] is still in the topology or
> not. If the port is invalid, set its num_slots to 0.
> 
> Thereafter, when try to update payload table by calling
> drm_dp_update_payload_part1(), we can successfully update the DPCD
> payload table of down stream port and clear the proposed_vcpi[] to NULL.
> 
> Changes since v1:(https://patchwork.kernel.org/patch/11275801/)
> * Invert the conditional to reduce the indenting
> 
> Reviewed-by: Lyude Paul 
> Signed-off-by: Wayne Lin 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 25 -
>  1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 6e10f6235009..e37cd6ec6e36 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2321,7 +2321,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
> *mstb,
>  {
>   struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
>   struct drm_dp_mst_port *port;
> - int old_ddps, ret;
> + int old_ddps, old_input, ret, i;
>   u8 new_pdt;
>   bool dowork = false, create_connector = false;
>  
> @@ -2352,6 +2352,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
> *mstb,
>   }
>  
>   old_ddps = port->ddps;
> + old_input = port->input;
>   port->input = conn_stat->input_port;
>   port->mcs = conn_stat->message_capability_status;
>   port->ldps = conn_stat->legacy_device_plug_status;
> @@ -2376,6 +2377,28 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
> *mstb,
>   dowork = false;
>   }
>  
> + if (!old_input && old_ddps != port->ddps && !port->ddps) {
> + for (i = 0; i < mgr->max_payloads; i++) {
> + struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
> + struct drm_dp_mst_port *port_validated;
> +
> + if (!vcpi)
> + continue;
> +
> + port_validated =
> + container_of(vcpi, struct drm_dp_mst_port,
> vcpi);
> + port_validated =
> + drm_dp_mst_topology_get_port_validated(mgr,
> port_validated);
> + if (!port_validated) {
> + mutex_lock(&mgr->payload_lock);
> + vcpi->num_slots = 0;
> + mutex_unlock(&mgr->payload_lock);
> + } else {
> + drm_dp_mst_topology_put_port(port_validated);
> + }
> + }
> + }
> +
>   if (port->connector)
>   drm_modeset_unlock(&mgr->base.lock);
>   else if (create_connector)
-- 
Cheers,
Lyude Paul

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

[Bug 206141] VCE UVD ring test failed -110

[bugzilla-daemon]

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

Thong Thai (thong.t...@amd.com) changed:

   What|Removed |Added

 CC||thong.t...@amd.com

--- Comment #5 from Thong Thai (thong.t...@amd.com) ---
Hi Janpieter,

I was unsuccessful in trying to recreate your issue. 
- Running Linux stable, 5.4.10, verified the IB tests are running
- Same video card, same VBIOS, same firmware
- Tried with/without a display connected
- Tried with/with rocm-dkms

Trying to see if I'm missing anything else, what motherboard / CPU are using?
and do you have any special kernal parameters you're using?

---

[4.702561] [drm] initializing kernel modesetting (FIJI 0x1002:0x7300
0x1002:0x0B36 0xCA).
[4.702569] [drm] register mmio base: 0xFCF0
[4.702569] [drm] register mmio size: 262144
[4.702577] [drm] add ip block number 0 
[4.702578] [drm] add ip block number 1 
[4.702578] [drm] add ip block number 2 
[4.702579] [drm] add ip block number 3 
[4.702580] [drm] add ip block number 4 
[4.702580] [drm] add ip block number 5 
[4.702581] [drm] add ip block number 6 
[4.702582] [drm] add ip block number 7 
[4.702582] [drm] add ip block number 8 
[4.702758] amdgpu :07:00.0: No more image in the PCI ROM
[4.702777] ATOM BIOS: 113-C8820200-107
[4.702789] [drm] UVD is enabled in physical mode
[4.702789] [drm] VCE enabled in physical mode
[4.702811] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment
size is 9-bit
[4.702818] amdgpu :07:00.0: VRAM: 4096M 0x00F4 -
0x00F4 (4096M used)
[4.702819] amdgpu :07:00.0: GART: 1024M 0x00FF -
0x00FF3FFF
[4.702823] [drm] Detected VRAM RAM=4096M, BAR=256M
[4.702824] [drm] RAM width 512bits HBM
[4.702876] [TTM] Zone  kernel: Available graphics memory: 8201336 KiB
[4.702877] [TTM] Zone   dma32: Available graphics memory: 2097152 KiB
[4.702877] [TTM] Initializing pool allocator
[4.702880] [TTM] Initializing DMA pool allocator
[4.702907] [drm] amdgpu: 4096M of VRAM memory ready
[4.702909] [drm] amdgpu: 4096M of GTT memory ready.
[4.702925] [drm] GART: num cpu pages 262144, num gpu pages 262144
[4.702988] [drm] PCIE GART of 1024M enabled (table at 0x00F4001D5000).
[4.743132] [drm] Chained IB support enabled!
[4.764245] amdgpu: [powerplay] hwmgr_sw_init smu backed is fiji_smu
[4.768880] [drm] Found UVD firmware Version: 1.91 Family ID: 12
[4.768885] [drm] UVD ENC is disabled
[4.772092] [drm] Found VCE firmware Version: 55.2 Binary ID: 3
[4.837386] [drm] dce110_link_encoder_construct: Failed to get
encoder_cap_info from VBIOS with error code 4!
[4.848088] [drm] Display Core initialized with v3.2.48!
[4.848823] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[4.848824] [drm] Driver supports precise vblank timestamp query.
[4.874937] [drm] UVD initialized successfully.
[4.974949] [drm] VCE initialized successfully.
[4.976370] [drm] Cannot find any crtc or sizes
[4.978116] [drm] Initialized amdgpu 3.35.0 20150101 for :07:00.0 on
minor 0

-- 
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 206141] VCE UVD ring test failed -110

[bugzilla-daemon]

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

--- Comment #6 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 286813
  --> https://bugzilla.kernel.org/attachment.cgi?id=286813&action=edit
Kernel. Config

Hi Thong,
I use efibootmgr, so no kernel arguments on bootloader, but there are a few in
config (attached here) 
Hope it helps!
Also, I ordered another R9 nano, to rule out the possibility of hardware
failure. It will be available in a few days. I'll keep you updated

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

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

[John Hubbard]

On 1/9/20 2:07 PM, John Hubbard wrote:
> On 1/7/20 2:45 PM, John Hubbard wrote:
>> Hi,
>>
>> The "track FOLL_PIN pages" would have been the very next patch, but it is
>> not included here because I'm still debugging a bug report from Leon.
>> Let's get all of the prerequisite work (it's been reviewed) into the tree
>> so that future reviews are easier. It's clear that any fixes that are
>> required to the tracking patch, won't affect these patches here.
>>
>> This implements an API naming change (put_user_page*() -->
>> unpin_user_page*()), and also adds FOLL_PIN page support, up to
>> *but not including* actually tracking FOLL_PIN pages. It extends
>> the FOLL_PIN support to a few select subsystems. More subsystems will
>> be added in follow up work.
>>
> 
> Hi Andrew and all,
> 
> To clarify: I'm hoping that this series can go into 5.6.
> 
> Meanwhile, I'm working on tracking down and solving the problem that Leon
> reported, in the "track FOLL_PIN pages" patch, and that patch is not part of
> this series.
> 

Hi Andrew and all,

Any thoughts on this?

As for the not-included-yet tracking patch, my local testing still suggests the
need to allow for larger refcounts of huge pages (in other words, I can write a 
test
to pin huge pages many times, and overflow with the same backtrace that Leon has
reported).

The second struct page (I recall Jan suggested) can hold those, so I'm going to 
proceed
with that approach, while waiting to see if Leon has any more test data for me.

Again, I think this series is worth getting out of the way, in the meantime.


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

Re: [PATCH 1/2] drm/dp_mst: Add a function to determine the mst end device

[Lyude Paul]

This patch series looks awesome so far, thank you for the great work! This
patch looks great, I think we should just squash it into the next patch though
since we don't use this function until then.

On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote:
> [Why]
> For later usage convenience, add the function
> drm_dp_mst_is_dp_mst_end_device() to decide whether a peer device
> connected to a DFP is mst end device. Which also indicates if the peer
> device is capable of handling message or not.
> 
> Signed-off-by: Wayne Lin 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index eebf325d7f48..8f54b241db08 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1918,6 +1918,22 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port
> *port,
>   return parent_lct + 1;
>  }
>  
> +static bool drm_dp_mst_is_dp_mst_end_device(u8 pdt, bool mcs)
> +{
> + switch (pdt) {
> + case DP_PEER_DEVICE_DP_LEGACY_CONV:
> + case DP_PEER_DEVICE_SST_SINK:
> + return true;
> + case DP_PEER_DEVICE_MST_BRANCHING:
> + /* For sst branch device */
> + if (!mcs)
> + return true;
> +
> + return false;
> + }
> + return true;
> +}
> +
>  static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt)
>  {
>   struct drm_dp_mst_topology_mgr *mgr = port->mgr;
-- 
Cheers,
Lyude Paul

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

Re: [PATCH 2/2] drm/dp_mst: Handle SST-only branch device case

[Lyude Paul]

On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote:
> [Why]
> While handling LINK_ADDRESS reply, current code expects a peer device
> can handle sideband message once the peer device type is reported as
> DP_PEER_DEVICE_MST_BRANCHING. However, when the connected device is
> a SST branch case, it can't handle the sideband message(MST_CAP=0 in
> DPCD 00021h).
> 
> Current code will try to send LINK_ADDRESS to SST branch device and end
> up with message timeout and monitor can't display normally. As the
> result of that, we should take SST branch device into account.
> 
> [How]
> According to DP 1.4 spec, we can use Peer_Device_Type as
> DP_PEER_DEVICE_MST_BRANCHING and Message_Capability_Status as 0 to
> indicate peer device as a SST-only branch device.
> 
> Fix following:
> - Take SST-only branch device case into account in
> drm_dp_port_set_pdt() and add a new parameter 'new_mcs'. Take sst branch
> device case as the same case as DP_PEER_DEVICE_DP_LEGACY_CONV and
> DP_PEER_DEVICE_SST_SINK. All original handling logics remain.
> - Take SST-only branch device case into account in
> drm_dp_mst_port_add_connector().
> - Fix some parts in drm_dp_mst_handle_link_address_port() to have SST
> branch device case into consideration.
> - Fix the arguments of drm_dp_port_set_pdt() in
> drm_dp_mst_handle_conn_stat().
> - Have SST branch device also report
> connector_status_connected when the ddps is true
> in drm_dp_mst_detect_port()
> - Fix the arguments of drm_dp_port_set_pdt() in
> drm_dp_delayed_destroy_port()
> 
> Fixes: c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more
> locking")
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Cc: Lyude Paul 
> Signed-off-by: Wayne Lin 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 131 +-
>  1 file changed, 68 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 8f54b241db08..4395d5cc0645 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1934,73 +1934,74 @@ static bool drm_dp_mst_is_dp_mst_end_device(u8 pdt,
> bool mcs)
>   return true;
>  }
>  
> -static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt)
> +static int
> +drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt,
> + bool new_mcs)
>  {
>   struct drm_dp_mst_topology_mgr *mgr = port->mgr;
>   struct drm_dp_mst_branch *mstb;
>   u8 rad[8], lct;
>   int ret = 0;
>  
> - if (port->pdt == new_pdt)
> + if (port->pdt == new_pdt && port->mcs == new_mcs)
>   return 0;
>  
>   /* Teardown the old pdt, if there is one */
> - switch (port->pdt) {
> - case DP_PEER_DEVICE_DP_LEGACY_CONV:
> - case DP_PEER_DEVICE_SST_SINK:
> - /*
> -  * If the new PDT would also have an i2c bus, don't bother
> -  * with reregistering it
> -  */
> - if (new_pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
> - new_pdt == DP_PEER_DEVICE_SST_SINK) {
> - port->pdt = new_pdt;
> - return 0;
> - }
> + if (port->pdt != DP_PEER_DEVICE_NONE) {
> + if (drm_dp_mst_is_dp_mst_end_device(port->pdt, port->mcs)) {
> + /*
> +  * If the new PDT would also have an i2c bus,
> +  * don't bother with reregistering it
> +  */
> + if (new_pdt != DP_PEER_DEVICE_NONE &&
> + drm_dp_mst_is_dp_mst_end_device(new_pdt, new_mcs))
> {
> + port->pdt = new_pdt;
> + port->mcs = new_mcs;
> + return 0;
> + }
>  
> - /* remove i2c over sideband */
> - drm_dp_mst_unregister_i2c_bus(&port->aux);
> - break;
> - case DP_PEER_DEVICE_MST_BRANCHING:
> - mutex_lock(&mgr->lock);
> - drm_dp_mst_topology_put_mstb(port->mstb);
> - port->mstb = NULL;
> - mutex_unlock(&mgr->lock);
> - break;
> + /* remove i2c over sideband */
> + drm_dp_mst_unregister_i2c_bus(&port->aux);
> + } else {
> + mutex_lock(&mgr->lock);
> + drm_dp_mst_topology_put_mstb(port->mstb);
> + port->mstb = NULL;
> + mutex_unlock(&mgr->lock);
> + }
>   }
>  
>   port->pdt = new_pdt;
> - switch (port->pdt) {
> - case DP_PEER_DEVICE_DP_LEGACY_CONV:
> - case DP_PEER_DEVICE_SST_SINK:
> - /* add i2c over sideband */
> - ret = drm_dp_mst_register_i2c_bus(&port->aux);
> - break;
> + port->mcs = new_mcs;
>  
> - case DP_PEER_DEVICE_MST_BRANCHING:
> - lct = drm_dp_calculate_rad(port, rad);
> - m

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

[Linus Torvalds]

Dave, Alex,
 there's an odd bugreport on bugzilla, where Artem is seeing an odd
early-boot failure.

That one almost certainly has nothing to do with you guys, but see the
later odd (and apparently unrelated) report about some AMD graphics
firmware issue and a black screen.

 Linus

On Tue, Jan 14, 2020 at 1:17 PM  wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=206175
>
> --- Comment #9 from Matt Yates (m...@fast-mail.org) ---
> My BIOS vendor is "Insyde Corp.".  There is a TPM module.  When I disabled it,
> it caused my EFI boot entry to disappear, so I couldn't test it.
>
> However, I think we may have two separate problems.  I switched back from
> Fedora to Debian Testing, and the Debian installer upgraded the kernel from 
> 5.3
> to 5.4 series prior to the first boot.  The 5.4 kernel booted up on first 
> boot.
>  I could see boot messages scrolling, but the screen went to a black while
> trying to load lightdm because I did not have the "firmware-amd-graphics"
> package installed required for graphics.  After installing the amd graphics
> package, the 5.4 kernel freezes as before (right at the start of the boot
> process).  The 5.3 kernel boots as normal, and graphics work.
>
> The "firmware-amd-graphics" package (version 20190717-2) was the only thing I
> changed, so I guess the problem must be some sort of conflict with the amd
> graphics firmware and the 5.4 kernel.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 0/2] Security mitigation for Intel Gen7 and Gen7.5

[Akeem G Abodunrin]

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Summary of Vulnerability

Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via local access

Products affected:
--
Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics.

Mitigation Summary
--
This patch provides mitigation for Gen7 and Gen7.5 hardware only.
Patch for Gen9 devices have been provided and merged to Linux mainline,
and backported to stable kernels.
Note that Gen8 is not impacted due to a previously implemented
workaround.

The mitigation involves submitting a custom EU kernel prior to every
context restore, in order to forcibly clear down residual EU and URB
resources.

This is currently an RFC while more analysis is performed on the
performance implications.

Note on Address Space Isolation (Full PPGTT)


Isolation of EU kernel assets should be considered complementary to the
existing support for address space isolation (aka Full PPGTT), since
without address space isolation there is minimal value in preventing
leakage between EU contexts. Full PPGTT has long been supported on Gen
Gfx devices since Gen8, and protection against EU residual leakage is a
welcome addition for these newer platforms.

By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only
as a hardware development feature for anticipated Gen8 productization.
Support was never intended for, or provided to the Linux kernels for
these platforms. Recent work (still ongoing) to the mainline kernel is
retroactively providing this support, but due to the level of complexity
it is not practical to attempt to backport this to earlier stable
kernels. Since without Full PPGTT, EU residuals protection has
questionable benefit, *there are no plans to provide stable kernel
backports for this patch series.*

Mika Kuoppala (1):
  drm/i915: Add mechanism to submit a context WA on ring submission

Prathap Kumar Valsan (1):
  drm/i915/gen7: Clear all EU/L3 residual contexts

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c| 514 ++
 drivers/gpu/drm/i915/gt/gen7_renderclear.h|  15 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 103 +++-
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 6 files changed, 649 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h

-- 
2.20.1

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

[RFC PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

[Akeem G Abodunrin]

From: Prathap Kumar Valsan 

On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Akeem G Abodunrin 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c| 514 ++
 drivers/gpu/drm/i915/gt/gen7_renderclear.h|  15 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   3 +-
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 6 files changed, 551 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b8c5f8934dbd..e5386871f015 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -75,6 +75,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+   gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
new file mode 100644
index ..3e9fc2c05fbb
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -0,0 +1,514 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gen7_renderclear.h"
+#include "i915_drv.h"
+#include "i915_utils.h"
+#include "intel_gpu_commands.h"
+
+#define MAX_URB_ENTRIES 64
+#define STATE_SIZE (4 * 1024)
+
+/* Media CB Kernel for gen7 devices */
+static const u32 cb7_kernel[][4] = {
+   { 0x0001, 0x26020128, 0x0024, 0x },
+   { 0x0040, 0x20280c21, 0x0028, 0x0001 },
+   { 0x0110, 0x2c20, 0x002c, 0x },
+   { 0x00010220, 0x34001c00, 0x1400, 0x002c },
+   { 0x0061, 0x20600061, 0x, 0x },
+   { 0x0008, 0x20601c85, 0x0e00, 0x000c },
+   { 0x0005, 0x20601ca5, 0x0060, 0x0001 },
+   { 0x0008, 0x20641c85, 0x0e00, 0x000d },
+   { 0x0005, 0x20641ca5, 0x0064, 0x0003 },
+   { 0x0041, 0x207424a5, 0x0064, 0x0034 },
+   { 0x0040, 0x206014a5, 0x0060, 0x0074 },
+   { 0x0008, 0x20681c85, 0x0e00, 0x0008 },
+   { 0x0005, 0x20681ca5, 0x0068, 0x000f },
+   { 0x0041, 0x20701ca5, 0x0060, 0x0010 },
+   { 0x0040, 0x206814a5, 0x0068, 0x0070 },
+   { 0x0061, 0x20a00061, 0x, 0x },
+   { 0x0005, 0x206c1c85, 0x0e00, 0x0007 },
+   { 0x0041, 0x206c1ca5, 0x006c, 0x0004 },
+   { 0x0061, 0x20800021, 0x008d, 0x },
+   { 0x0001, 0x20800021, 0x006c, 0x },
+   { 0x0001, 0x20840021, 0x0068, 0x },
+   { 0x0001, 0x20880061, 0x, 0x0003 },
+   { 0x0005, 0x208c0d21, 0x0086, 0x },
+   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x02190001 },
+   { 0x0040, 0x20a01ca5, 0x00a0, 0x0001 },
+   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x040a8001 },
+   { 0x0240, 0x20281c21, 0x0028, 0x },
+   { 0x00010220, 0x34001c00, 0x1400, 0xfffc },
+   { 0x0001, 0x26020128, 0x0024, 0x },
+   { 0x0001, 0x22e4, 0x, 0x },
+   { 0x0001, 0x220801ec, 0x, 0x007f007f },
+   { 0x0061, 0x20400021, 0x008d, 0x },
+   { 0x0061, 0x2fe00021, 0x008d, 0x },
+   { 0x0021, 0x20400121, 0x00450020, 0x },
+   { 0x0001, 0x20480061, 0x, 0x000f000f },
+   { 0x0005, 0x204c0d21, 0x0046, 0xffef },
+   { 0x0081, 0x20600061, 0x, 0x },
+   { 0x0081, 0x20800061, 0x, 0x },
+   { 0x0081, 0x20a00061, 0x, 0x },
+   { 0x0081, 0x20c00061, 0x, 0x },
+   { 0x0081, 0x20e00061, 0x, 0x },
+   { 0x0081, 0x2161, 0x, 0x },
+   { 0x0081, 0x21200061, 0x, 0x },
+   { 0x0081, 0x21400061, 0x, 0x },
+   { 0x05600032, 0x20001fa0, 0x008d0040, 0x120a8000 },
+   { 0x0040, 0x20402d21, 0x0020, 0x00100010 },
+   { 0x05600032, 0x20001fa0, 0x008d0040, 0x120a8000 },
+   { 0x0240, 0x22083d8c, 0x0208, 0x },
+   { 0x0081, 0xa109, 0x0602, 0x },
+   { 0x0040, 0x22001c84, 0x0

[RFC PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission

[Akeem G Abodunrin]

From: Mika Kuoppala 

This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Akeem G Abodunrin 
Cc: Kumar Valsan Prathap 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
---
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 102 +-
 1 file changed, 99 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index bc44fe8e5ffa..204c450b7c42 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1384,7 +1384,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
 }
 
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
 {
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1459,7 +1461,7 @@ static inline int mi_set_context(struct i915_request *rq, 
u32 flags)
 
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
-   *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+   *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
 * w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
 * WaMiSetContext_Hang:snb,ivb,vlv
@@ -1574,13 +1576,51 @@ static int switch_mm(struct i915_request *rq, struct 
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
 }
 
+static int clear_residuals(struct i915_request *rq)
+{
+   struct intel_engine_cs *engine = rq->engine;
+   int ret;
+
+   GEM_BUG_ON(!engine->kernel_context->state);
+
+   ret = switch_mm(rq, vm_alias(engine->kernel_context));
+   if (ret)
+   return ret;
+
+   ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+   if (ret)
+   return ret;
+
+   ret = engine->emit_bb_start(rq,
+   engine->wa_ctx.vma->node.start, 0,
+   0);
+   if (ret)
+   return ret;
+
+   ret = engine->emit_flush(rq, EMIT_FLUSH);
+   if (ret)
+   return ret;
+
+   /* Always invalidate before the next switch_mm() */
+   return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
 static int switch_context(struct i915_request *rq)
 {
+   struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
int ret;
 
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
 
+   if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+   ret = clear_residuals(rq);
+   if (ret)
+   return ret;
+   }
+
ret = switch_mm(rq, vm_alias(ce));
if (ret)
return ret;
@@ -1600,7 +1640,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
 
-   ret = mi_set_context(rq, flags);
+   ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1792,6 +1832,8 @@ static void ring_release(struct intel_engine_cs *engine)
 
intel_engine_cleanup_common(engine);
 
+   i915_vma_unpin_and_release(&engine->wa_ctx.vma, 0);
+
intel_ring_unpin(engine->legacy.ring);
intel_ring_put(engine->legacy.ring);
 
@@ -1939,6 +1981,52 @@ static void setup_vecs(struct intel_engine_cs *engine)
engine->emit_fini_breadcrumb = gen7_xcs_emit_breadcrumb;
 }
 
+static int gen7_ctx_switch_bb_setup(struct intel_engine_cs * const engine,
+   struct i915_vma * const vma)
+{
+   return 0;
+}
+
+static int gen7_ctx_switch_bb_init(struct intel_engine_cs *engine)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int size;
+   int err;
+
+   size = gen7_ctx_switch_bb_setup(engine, NULL /* probe size */);
+   if (size <= 0)
+   return size;
+
+   size = ALIGN(size, PAGE_SIZE);
+   obj = i915_gem_object_create_internal(engine->i915, size);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   vma = i915_vma_instance(obj, engine->gt->vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_obj;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_HIGH);
+   if (err)
+   goto err_obj;
+
+   err = gen7_ctx_switch_bb_setup(engine, vma);
+   if (err)
+   goto err_unpin;
+
+   engine->wa_ctx.vma = vma;
+   return 0;
+
+err_unpin:
+   

Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

[Alex Deucher]

On Tue, Jan 14, 2020 at 4:41 PM Linus Torvalds
 wrote:
>
> Dave, Alex,
>  there's an odd bugreport on bugzilla, where Artem is seeing an odd
> early-boot failure.
>
> That one almost certainly has nothing to do with you guys, but see the
> later odd (and apparently unrelated) report about some AMD graphics
> firmware issue and a black screen.

Odd.  I have a similar picasso based raven laptop and it is working
fine with F31 and the latest 5.4.8 kernel.  I think the firmware is a
red herring as the driver won't load without it so if you don't have
it installed, the driver won't be running in the first place.  I'll
follow up in the bug report and ask him to file a new bug about the
amdgpu issue to avoid cluttering up the current report.

Alex

>
>  Linus
>
> On Tue, Jan 14, 2020 at 1:17 PM  wrote:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=206175
> >
> > --- Comment #9 from Matt Yates (m...@fast-mail.org) ---
> > My BIOS vendor is "Insyde Corp.".  There is a TPM module.  When I disabled 
> > it,
> > it caused my EFI boot entry to disappear, so I couldn't test it.
> >
> > However, I think we may have two separate problems.  I switched back from
> > Fedora to Debian Testing, and the Debian installer upgraded the kernel from 
> > 5.3
> > to 5.4 series prior to the first boot.  The 5.4 kernel booted up on first 
> > boot.
> >  I could see boot messages scrolling, but the screen went to a black while
> > trying to load lightdm because I did not have the "firmware-amd-graphics"
> > package installed required for graphics.  After installing the amd graphics
> > package, the 5.4 kernel freezes as before (right at the start of the boot
> > process).  The 5.3 kernel boots as normal, and graphics work.
> >
> > The "firmware-amd-graphics" package (version 20190717-2) was the only thing 
> > I
> > changed, so I guess the problem must be some sort of conflict with the amd
> > graphics firmware and the 5.4 kernel.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
> ___
> 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: [RFC PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

[Chris Wilson]

Quoting Akeem G Abodunrin (2020-01-14 14:51:36)
> From: Prathap Kumar Valsan 
> 
> On gen7 and gen7.5 devices, there could be leftover data residuals in
> EU/L3 from the retiring context. This patch introduces workaround to clear
> that residual contexts, by submitting a batch buffer with dedicated HW
> context to the GPU with ring allocation for each context switching.
> 
> Signed-off-by: Mika Kuoppala 
> Signed-off-by: Prathap Kumar Valsan 
> Signed-off-by: Akeem G Abodunrin 
> Cc: Chris Wilson 
> Cc: Balestrieri Francesco 
> Cc: Bloomfield Jon 
> Cc: Dutt Sudeep 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/gt/gen7_renderclear.c| 514 ++
>  drivers/gpu/drm/i915/gt/gen7_renderclear.h|  15 +
>  drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
>  .../gpu/drm/i915/gt/intel_ring_submission.c   |   3 +-
>  drivers/gpu/drm/i915/i915_utils.h |   5 +
>  6 files changed, 551 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
>  create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b8c5f8934dbd..e5386871f015 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -75,6 +75,7 @@ gt-y += \
> gt/debugfs_gt.o \
> gt/debugfs_gt_pm.o \
> gt/gen6_ppgtt.o \
> +   gt/gen7_renderclear.o \
> gt/gen8_ppgtt.o \
> gt/intel_breadcrumbs.o \
> gt/intel_context.o \
> diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
> b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> new file mode 100644
> index ..3e9fc2c05fbb
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> @@ -0,0 +1,514 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include "gen7_renderclear.h"
> +#include "i915_drv.h"
> +#include "i915_utils.h"
> +#include "intel_gpu_commands.h"
> +
> +#define MAX_URB_ENTRIES 64
> +#define STATE_SIZE (4 * 1024)
> +
> +/* Media CB Kernel for gen7 devices */
> +static const u32 cb7_kernel[][4] = {
> +   { 0x0001, 0x26020128, 0x0024, 0x },
> +   { 0x0040, 0x20280c21, 0x0028, 0x0001 },
> +   { 0x0110, 0x2c20, 0x002c, 0x },
> +   { 0x00010220, 0x34001c00, 0x1400, 0x002c },
> +   { 0x0061, 0x20600061, 0x, 0x },
> +   { 0x0008, 0x20601c85, 0x0e00, 0x000c },
> +   { 0x0005, 0x20601ca5, 0x0060, 0x0001 },
> +   { 0x0008, 0x20641c85, 0x0e00, 0x000d },
> +   { 0x0005, 0x20641ca5, 0x0064, 0x0003 },
> +   { 0x0041, 0x207424a5, 0x0064, 0x0034 },
> +   { 0x0040, 0x206014a5, 0x0060, 0x0074 },
> +   { 0x0008, 0x20681c85, 0x0e00, 0x0008 },
> +   { 0x0005, 0x20681ca5, 0x0068, 0x000f },
> +   { 0x0041, 0x20701ca5, 0x0060, 0x0010 },
> +   { 0x0040, 0x206814a5, 0x0068, 0x0070 },
> +   { 0x0061, 0x20a00061, 0x, 0x },
> +   { 0x0005, 0x206c1c85, 0x0e00, 0x0007 },
> +   { 0x0041, 0x206c1ca5, 0x006c, 0x0004 },
> +   { 0x0061, 0x20800021, 0x008d, 0x },
> +   { 0x0001, 0x20800021, 0x006c, 0x },
> +   { 0x0001, 0x20840021, 0x0068, 0x },
> +   { 0x0001, 0x20880061, 0x, 0x0003 },
> +   { 0x0005, 0x208c0d21, 0x0086, 0x },
> +   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x02190001 },
> +   { 0x0040, 0x20a01ca5, 0x00a0, 0x0001 },
> +   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x040a8001 },
> +   { 0x0240, 0x20281c21, 0x0028, 0x },
> +   { 0x00010220, 0x34001c00, 0x1400, 0xfffc },
> +   { 0x0001, 0x26020128, 0x0024, 0x },
> +   { 0x0001, 0x22e4, 0x, 0x },
> +   { 0x0001, 0x220801ec, 0x, 0x007f007f },
> +   { 0x0061, 0x20400021, 0x008d, 0x },
> +   { 0x0061, 0x2fe00021, 0x008d, 0x },
> +   { 0x0021, 0x20400121, 0x00450020, 0x },
> +   { 0x0001, 0x20480061, 0x, 0x000f000f },
> +   { 0x0005, 0x204c0d21, 0x0046, 0xffef },
> +   { 0x0081, 0x20600061, 0x, 0x },
> +   { 0x0081, 0x20800061, 0x, 0x },
> +   { 0x0081, 0x20a00061, 0x, 0x },
> +   { 0x0081, 0x20c00061, 0x, 0x },
> +   { 0x0081, 0x20e00061, 0x, 0x },
> +   { 0x0081, 0x2161, 0x, 0x },
> +   { 0x0081, 0x21200061, 0x, 0x },
> +   { 0x0081, 0x21400061, 0x, 0x },
> +   { 0x05600032, 0x20001fa0, 0x008d0040, 0x120a8000 },
> +   { 0x0040, 0

Re: [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN

[Andrew Morton]

On Tue, 14 Jan 2020 12:15:08 -0800 John Hubbard  wrote:

> > 
> > Hi Andrew and all,
> > 
> > To clarify: I'm hoping that this series can go into 5.6.
> > 
> > Meanwhile, I'm working on tracking down and solving the problem that Leon
> > reported, in the "track FOLL_PIN pages" patch, and that patch is not part of
> > this series.
> > 
> 
> Hi Andrew and all,
> 
> Any thoughts on this?

5.6 is late.  But it was in -mm before (briefly) and appears to be
mature and well-reviewed.

I'll toss it in there and shall push it into -next hopefully today. 
Let's decide 2-3 weeks hence.

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

Re: [PATCH 09/10] drm/vkms: plane_state->fb iff plane_state->crtc

[Rodrigo Siqueira]

On 12/13, Daniel Vetter wrote:
> Checking both is one too much, so wrap a WARN_ON around it to stope
> the copypasta.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 5fc8f85aaf3d..6d31265a2ab7 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -117,7 +117,7 @@ static int vkms_plane_atomic_check(struct drm_plane 
> *plane,
>   bool can_position = false;
>   int ret;
>  
> - if (!state->fb | !state->crtc)
> + if (!state->fb || WARN_ON(!state->crtc))
>   return 0;
>  
>   crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> -- 
> 2.24.0
>

Hi,

Sorry, the delay in taking a look at this patch.

I tried to find the whole series for getting the context related to this
patch, but I could not find it in my mailbox. Could you shed some light
here? Why check fb and crtc is too much? How the WARN_ON fix the issue?

Best Regards

Ps.: in the commit message: "stope" -> "stop"

-- 
Rodrigo Siqueira
Software Engineer, Advanced Micro Devices (AMD)
https://siqueira.tech


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

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

[Manasi Navare]

On Tue, Jan 14, 2020 at 03:07:56PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 13, 2020 at 04:39:00PM -0800, Manasi Navare wrote:
> > Hi Ville,
> > 
> > So the two major changes you would like to see here are:
> > 
> >  use version_greate(edid) function 
> > and make use of :
> > drm_for_each_detailed_block() instead of the for loop.
> > But this function does not parse the monitor range yet so
> > you are suggesting modifying that dmr helper function as well?
> 
> That functions is just the thing that iterates the descriptors, so
> can't figure out what you're asking.

My question was on your review comment below where you asked me to use
for_each_detailed_block(), were you referring to using the existing 
drm_for_each_detailed_block
or just defining a new iterator for looping through 4 detailed blocks to get the
monitor range?

Manasi

> 
> > 
> > Manasi
> > 
> > On Fri, Jan 10, 2020 at 03:17:43PM -0800, Manasi Navare wrote:
> > > On Thu, Jan 09, 2020 at 03:08:52PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Jan 07, 2020 at 04:32:08PM -0800, Manasi Navare wrote:
> > > > > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > > > > the EDID's detailed descritors to obtain the adaptive sync monitor 
> > > > > range.
> > > > > Store this info as part fo drm_display_info so it can be used
> > > > > across all drivers.
> > > > > This part of the code is stripped out of amdgpu's function
> > > > > amdgpu_dm_update_freesync_caps() to make it generic and be used
> > > > > across all DRM drivers
> > > > > 
> > > > > v2:
> > > > > * Change vmin and vmax to use u8 (Ville)
> > > > > * Dont store pixel clock since that is just a max dotclock
> > > > > and not related to VRR mode (Manasi)
> > > > > 
> > > > > Cc: Ville Syrjälä 
> > > > > Cc: Harry Wentland 
> > > > > Cc: Clinton A Taylor 
> > > > > Cc: Nicholas Kazlauskas 
> > > > > Signed-off-by: Manasi Navare 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_edid.c  | 51 
> > > > > +
> > > > >  include/drm/drm_connector.h | 22 
> > > > >  include/drm/drm_edid.h  |  2 ++
> > > > >  3 files changed, 75 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > > index 99769d6c9f84..52781a0e708b 100644
> > > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > > @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct 
> > > > > drm_connector *connector,
> > > > >   }
> > > > >  }
> > > > >  
> > > > > +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> > > > > +   const struct edid *edid)
> > > > > +{
> > > > > + struct drm_display_info *info = &connector->display_info;
> > > > > + const struct detailed_timing *timing;
> > > > > + const struct detailed_non_pixel *data;
> > > > > + const struct detailed_data_monitor_range *range;
> > > > 
> > > > Needlessly wide scope for everything above.
> > > 
> > > Okay will move inside the for_each loop ?
> > > 
> > > > 
> > > > > + int i;
> > > > > +
> > > > > + /*
> > > > > +  * Restrict Adaptive Sync only for dp and edp
> > > > > +  */
> > > > > + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort 
> > > > > &&
> > > > > + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> > > > > + return;
> > > > > +
> > > > > + if (edid->version <= 1 && !(edid->version == 1 && 
> > > > > edid->revision > 1))
> > > > > + return;
> > > > 
> > > > if (!version_greater(...))
> > > > return;
> > > 
> > > You mean simplify the condition or use define a function 
> > > version_greater() to check this condition?
> > > 
> > > > 
> > > > > +
> > > > > + for (i = 0; i < 4; i++) {
> > > > 
> > > > This should probably use for_each_detailed_block()
> > > >
> > > 
> > > 
> > > Ok yes will use for_each_detailed_block
> > > 
> > > Manasi
> > > 
> > >  
> > > > > + timing  = &edid->detailed_timings[i];
> > > > > + data= &timing->data.other_data;
> > > > > + range   = &data->data.range;
> > > > > + /*
> > > > > +  * Check if monitor has continuous frequency mode
> > > > > +  */
> > > > > + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> > > > > + continue;
> > > > > + /*
> > > > > +  * Check for flag range limits only. If flag == 1 then
> > > > > +  * no additional timing information provided.
> > > > > +  * Default GTF, GTF Secondary curve and CVT are not
> > > > > +  * supported
> > > > > +  */
> > > > > + if (range->flags != 1)
> > > > > + continue;
> > > > > +
> > > > > + info->adaptive_sync.min_vfreq = range->min_vfreq;
> > > > > + info->adaptive_sync.max_vfreq = range->max_vfreq;
> > > > > +
> > > > > + DRM_D

Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits

[Manasi Navare]

On Tue, Jan 14, 2020 at 08:31:22AM -0500, Harry Wentland wrote:
> Fixing Nick's email.
> 
> On 2020-01-10 5:43 p.m., Manasi Navare wrote:
> > On Thu, Jan 09, 2020 at 05:24:30PM +0200, Jani Nikula wrote:
> >> On Tue, 07 Jan 2020, Manasi Navare  wrote:
> >>> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> >>> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> >>> Store this info as part fo drm_display_info so it can be used
> >>> across all drivers.
> >>> This part of the code is stripped out of amdgpu's function
> >>> amdgpu_dm_update_freesync_caps() to make it generic and be used
> >>> across all DRM drivers
> >>>
> >>> v2:
> >>> * Change vmin and vmax to use u8 (Ville)
> >>> * Dont store pixel clock since that is just a max dotclock
> >>> and not related to VRR mode (Manasi)
> >>>
> >>> Cc: Ville Syrjälä 
> >>> Cc: Harry Wentland 
> >>> Cc: Clinton A Taylor 
> >>> Cc: Nicholas Kazlauskas 
> >>> Signed-off-by: Manasi Navare 
> >>> ---
> >>>  drivers/gpu/drm/drm_edid.c  | 51 +
> >>>  include/drm/drm_connector.h | 22 
> >>>  include/drm/drm_edid.h  |  2 ++
> >>>  3 files changed, 75 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >>> index 99769d6c9f84..52781a0e708b 100644
> >>> --- a/drivers/gpu/drm/drm_edid.c
> >>> +++ b/drivers/gpu/drm/drm_edid.c
> >>> @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector 
> >>> *connector,
> >>>   }
> >>>  }
> >>>  
> >>> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> >>> +   const struct edid *edid)
> >>> +{
> >>> + struct drm_display_info *info = &connector->display_info;
> >>> + const struct detailed_timing *timing;
> >>> + const struct detailed_non_pixel *data;
> >>> + const struct detailed_data_monitor_range *range;
> >>> + int i;
> >>> +
> >>> + /*
> >>> +  * Restrict Adaptive Sync only for dp and edp
> >>> +  */
> >>> + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> >>> + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> >>> + return;
> >>> +
> >>> + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> >>> + return;
> >>> +
> >>> + for (i = 0; i < 4; i++) {
> >>> + timing  = &edid->detailed_timings[i];
> >>> + data= &timing->data.other_data;
> >>> + range   = &data->data.range;
> >>> + /*
> >>> +  * Check if monitor has continuous frequency mode
> >>> +  */
> >>> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> >>> + continue;
> >>> + /*
> >>> +  * Check for flag range limits only. If flag == 1 then
> >>> +  * no additional timing information provided.
> >>> +  * Default GTF, GTF Secondary curve and CVT are not
> >>> +  * supported
> >>> +  */
> >>> + if (range->flags != 1)
> >>> + continue;
> >>> +
> >>> + info->adaptive_sync.min_vfreq = range->min_vfreq;
> >>> + info->adaptive_sync.max_vfreq = range->max_vfreq;
> >>> +
> >>> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d 
> >>> Hz\n",
> >>> +   info->adaptive_sync.min_vfreq,
> >>> +   info->adaptive_sync.max_vfreq);
> >>> + break;
> >>> + }
> >>> +}
> >>> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
> >>
> >> Why the export? Rather, why is this not static?
> >>
> > 
> > I could make it static but since the way AMDGPU code is written right now 
> > they
> > would be calling this function explicitly to populate the vmin and vmax in 
> > their local
> > structs but I can make it static and with some minor refactoring they 
> > should be able to
> > use thsi infor directly from drm_display_info
> > 
> 
> Calling this through drm_add_edid_modes should be sufficient for us.
> We'll just need to move amdgpu_dm_update_freesync_caps to our get_modes
> function.

Thanks Harry, Would you or Nick make these changes as follow up changes after 
this patch lands?
Since it might be easier for you to figure out where to accomodate the changes 
in amdgpu.

Manasi


> 
> Dropping the export here seems to be the right thing to do.
> 
> Harry
> 
> > Manasi
> >  
> >> BR,
> >> Jani.
> >>
> >>> +
> >>>  /* A connector has no EDID information, so we've got no EDID to compute 
> >>> quirks from. Reset
> >>>   * all of the values which would have been set from EDID
> >>>   */
> >>> @@ -4901,6 +4949,7 @@ drm_reset_display_info(struct drm_connector 
> >>> *connector)
> >>>   memset(&info->hdmi, 0, sizeof(info->hdmi));
> >>>  
> >>>   info->non_desktop = 0;
> >>> + memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
> >>>  }
> >>>  
> >>>  u32 drm_add_display_info(struct drm_connector *connector, const struct 
> >>> edid *edid)
> >>> @@ -4916,6 +4965,8 @@ u32 drm_add_display_info(struct drm_connector 
> >>> *connector,

[RFC PATCH v2 1/2] drm/i915: Add mechanism to submit a context WA on ring submission

[Akeem G Abodunrin]

From: Mika Kuoppala 

This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Akeem G Abodunrin 
Cc: Kumar Valsan Prathap 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
---
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 102 +-
 1 file changed, 99 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index bc44fe8e5ffa..204c450b7c42 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1384,7 +1384,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
 }
 
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
 {
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1459,7 +1461,7 @@ static inline int mi_set_context(struct i915_request *rq, 
u32 flags)
 
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
-   *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+   *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
 * w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
 * WaMiSetContext_Hang:snb,ivb,vlv
@@ -1574,13 +1576,51 @@ static int switch_mm(struct i915_request *rq, struct 
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
 }
 
+static int clear_residuals(struct i915_request *rq)
+{
+   struct intel_engine_cs *engine = rq->engine;
+   int ret;
+
+   GEM_BUG_ON(!engine->kernel_context->state);
+
+   ret = switch_mm(rq, vm_alias(engine->kernel_context));
+   if (ret)
+   return ret;
+
+   ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+   if (ret)
+   return ret;
+
+   ret = engine->emit_bb_start(rq,
+   engine->wa_ctx.vma->node.start, 0,
+   0);
+   if (ret)
+   return ret;
+
+   ret = engine->emit_flush(rq, EMIT_FLUSH);
+   if (ret)
+   return ret;
+
+   /* Always invalidate before the next switch_mm() */
+   return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
 static int switch_context(struct i915_request *rq)
 {
+   struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
int ret;
 
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
 
+   if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+   ret = clear_residuals(rq);
+   if (ret)
+   return ret;
+   }
+
ret = switch_mm(rq, vm_alias(ce));
if (ret)
return ret;
@@ -1600,7 +1640,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
 
-   ret = mi_set_context(rq, flags);
+   ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1792,6 +1832,8 @@ static void ring_release(struct intel_engine_cs *engine)
 
intel_engine_cleanup_common(engine);
 
+   i915_vma_unpin_and_release(&engine->wa_ctx.vma, 0);
+
intel_ring_unpin(engine->legacy.ring);
intel_ring_put(engine->legacy.ring);
 
@@ -1939,6 +1981,52 @@ static void setup_vecs(struct intel_engine_cs *engine)
engine->emit_fini_breadcrumb = gen7_xcs_emit_breadcrumb;
 }
 
+static int gen7_ctx_switch_bb_setup(struct intel_engine_cs * const engine,
+   struct i915_vma * const vma)
+{
+   return 0;
+}
+
+static int gen7_ctx_switch_bb_init(struct intel_engine_cs *engine)
+{
+   struct drm_i915_gem_object *obj;
+   struct i915_vma *vma;
+   int size;
+   int err;
+
+   size = gen7_ctx_switch_bb_setup(engine, NULL /* probe size */);
+   if (size <= 0)
+   return size;
+
+   size = ALIGN(size, PAGE_SIZE);
+   obj = i915_gem_object_create_internal(engine->i915, size);
+   if (IS_ERR(obj))
+   return PTR_ERR(obj);
+
+   vma = i915_vma_instance(obj, engine->gt->vm, NULL);
+   if (IS_ERR(vma)) {
+   err = PTR_ERR(vma);
+   goto err_obj;
+   }
+
+   err = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_HIGH);
+   if (err)
+   goto err_obj;
+
+   err = gen7_ctx_switch_bb_setup(engine, vma);
+   if (err)
+   goto err_unpin;
+
+   engine->wa_ctx.vma = vma;
+   return 0;
+
+err_unpin:
+   

[RFC PATCH v2 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

[Akeem G Abodunrin]

From: Prathap Kumar Valsan 

On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.

V2: Addressed comments about unused code, code formatting, and include
additional debug code

Signed-off-by: Mika Kuoppala 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Akeem G Abodunrin 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c| 515 ++
 drivers/gpu/drm/i915/gt/gen7_renderclear.h|  16 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   3 +-
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 6 files changed, 553 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b8c5f8934dbd..e5386871f015 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -75,6 +75,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+   gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
new file mode 100644
index ..6fe2a6fcbddd
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -0,0 +1,515 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gen7_renderclear.h"
+#include "i915_drv.h"
+#include "i915_utils.h"
+#include "intel_gpu_commands.h"
+
+#define MAX_URB_ENTRIES 64
+#define STATE_SIZE (4 * 1024)
+#define GT3_INLINE_DATA_DELAYS 0x1E00
+
+/* Media CB Kernel for gen7 devices */
+static const u32 cb7_kernel[][4] = {
+   { 0x0001, 0x26020128, 0x0024, 0x },
+   { 0x0040, 0x20280c21, 0x0028, 0x0001 },
+   { 0x0110, 0x2c20, 0x002c, 0x },
+   { 0x00010220, 0x34001c00, 0x1400, 0x002c },
+   { 0x0061, 0x20600061, 0x, 0x },
+   { 0x0008, 0x20601c85, 0x0e00, 0x000c },
+   { 0x0005, 0x20601ca5, 0x0060, 0x0001 },
+   { 0x0008, 0x20641c85, 0x0e00, 0x000d },
+   { 0x0005, 0x20641ca5, 0x0064, 0x0003 },
+   { 0x0041, 0x207424a5, 0x0064, 0x0034 },
+   { 0x0040, 0x206014a5, 0x0060, 0x0074 },
+   { 0x0008, 0x20681c85, 0x0e00, 0x0008 },
+   { 0x0005, 0x20681ca5, 0x0068, 0x000f },
+   { 0x0041, 0x20701ca5, 0x0060, 0x0010 },
+   { 0x0040, 0x206814a5, 0x0068, 0x0070 },
+   { 0x0061, 0x20a00061, 0x, 0x },
+   { 0x0005, 0x206c1c85, 0x0e00, 0x0007 },
+   { 0x0041, 0x206c1ca5, 0x006c, 0x0004 },
+   { 0x0061, 0x20800021, 0x008d, 0x },
+   { 0x0001, 0x20800021, 0x006c, 0x },
+   { 0x0001, 0x20840021, 0x0068, 0x },
+   { 0x0001, 0x20880061, 0x, 0x0003 },
+   { 0x0005, 0x208c0d21, 0x0086, 0x },
+   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x02190001 },
+   { 0x0040, 0x20a01ca5, 0x00a0, 0x0001 },
+   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x040a8001 },
+   { 0x0240, 0x20281c21, 0x0028, 0x },
+   { 0x00010220, 0x34001c00, 0x1400, 0xfffc },
+   { 0x0001, 0x26020128, 0x0024, 0x },
+   { 0x0001, 0x22e4, 0x, 0x },
+   { 0x0001, 0x220801ec, 0x, 0x007f007f },
+   { 0x0061, 0x20400021, 0x008d, 0x },
+   { 0x0061, 0x2fe00021, 0x008d, 0x },
+   { 0x0021, 0x20400121, 0x00450020, 0x },
+   { 0x0001, 0x20480061, 0x, 0x000f000f },
+   { 0x0005, 0x204c0d21, 0x0046, 0xffef },
+   { 0x0081, 0x20600061, 0x, 0x },
+   { 0x0081, 0x20800061, 0x, 0x },
+   { 0x0081, 0x20a00061, 0x, 0x },
+   { 0x0081, 0x20c00061, 0x, 0x },
+   { 0x0081, 0x20e00061, 0x, 0x },
+   { 0x0081, 0x2161, 0x, 0x },
+   { 0x0081, 0x21200061, 0x, 0x },
+   { 0x0081, 0x21400061, 0x, 0x },
+   { 0x05600032, 0x20001fa0, 0x008d0040, 0x120a8000 },
+   { 0x0040, 0x20402d21, 0x0020, 0x00100010 },
+   { 0x05600032, 0x20001fa0, 0x008d0040, 0x120a8000 },
+   { 0x0240, 0x2208

[RFC PATCH v2 0/2] Security mitigation for Intel Gen7 HWs

[Akeem G Abodunrin]

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Summary of Vulnerability

Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via local access

Products affected:
--
Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics.

Mitigation Summary
--
This patch provides mitigation for Gen7 and Gen7.5 hardware only.
Patch for Gen9 devices have been provided and merged to Linux mainline,
and backported to stable kernels.
Note that Gen8 is not impacted due to a previously implemented
workaround.

The mitigation involves submitting a custom EU kernel prior to every
context restore, in order to forcibly clear down residual EU and URB
resources.

This is currently an RFC while more analysis is performed on the
performance implications.

Note on Address Space Isolation (Full PPGTT)


Isolation of EU kernel assets should be considered complementary to the
existing support for address space isolation (aka Full PPGTT), since
without address space isolation there is minimal value in preventing
leakage between EU contexts. Full PPGTT has long been supported on Gen
Gfx devices since Gen8, and protection against EU residual leakage is a
welcome addition for these newer platforms.

By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only
as a hardware development feature for anticipated Gen8 productization.
Support was never intended for, or provided to the Linux kernels for
these platforms. Recent work (still ongoing) to the mainline kernel is
retroactively providing this support, but due to the level of complexity
it is not practical to attempt to backport this to earlier stable
kernels. Since without Full PPGTT, EU residuals protection has
questionable benefit, *there are no plans to provide stable kernel
backports for this patch series.*

V2: Addressed comments about unused code, code formatting, and include
additional debug code

Mika Kuoppala (1):
  drm/i915: Add mechanism to submit a context WA on ring submission

Prathap Kumar Valsan (1):
  drm/i915/gen7: Clear all EU/L3 residual contexts

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c| 515 ++
 drivers/gpu/drm/i915/gt/gen7_renderclear.h|  16 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 103 +++-
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 6 files changed, 651 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h

-- 
2.20.1

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

Re: [PATCH 09/10] drm/vkms: plane_state->fb iff plane_state->crtc

[Sam Ravnborg]

Hi Rodrigo.

On Tue, Jan 14, 2020 at 06:50:13PM -0500, Rodrigo Siqueira wrote:
> On 12/13, Daniel Vetter wrote:
> > Checking both is one too much, so wrap a WARN_ON around it to stope
> > the copypasta.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Rodrigo Siqueira 
> > Cc: Haneen Mohammed 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/vkms/vkms_plane.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
> > b/drivers/gpu/drm/vkms/vkms_plane.c
> > index 5fc8f85aaf3d..6d31265a2ab7 100644
> > --- a/drivers/gpu/drm/vkms/vkms_plane.c
> > +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> > @@ -117,7 +117,7 @@ static int vkms_plane_atomic_check(struct drm_plane 
> > *plane,
> > bool can_position = false;
> > int ret;
> >  
> > -   if (!state->fb | !state->crtc)
> > +   if (!state->fb || WARN_ON(!state->crtc))
> > return 0;
> >  
> > crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> > -- 
> > 2.24.0
> >
> 
> Hi,
> 
> Sorry, the delay in taking a look at this patch.
> 
> I tried to find the whole series for getting the context related to this
> patch, but I could not find it in my mailbox. Could you shed some light
> here? Why check fb and crtc is too much? How the WARN_ON fix the issue?

You can find some background in the first patch:
https://lists.freedesktop.org/archives/dri-devel/2019-December/248981.html

Hope this sched enough light on the topic.

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

RE: [PATCH 1/2] drm/dp_mst: Add a function to determine the mst end device

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, January 15, 2020 5:16 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry 
> Subject: Re: [PATCH 1/2] drm/dp_mst: Add a function to determine the mst end
> device
> 
> This patch series looks awesome so far, thank you for the great work! This
> patch looks great, I think we should just squash it into the next patch though
> since we don't use this function until then.
> 
Thanks for your time.
I will squash it in the new version.

> On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote:
> > [Why]
> > For later usage convenience, add the function
> > drm_dp_mst_is_dp_mst_end_device() to decide whether a peer device
> > connected to a DFP is mst end device. Which also indicates if the peer
> > device is capable of handling message or not.
> >
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index eebf325d7f48..8f54b241db08 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1918,6 +1918,22 @@ static u8 drm_dp_calculate_rad(struct
> > drm_dp_mst_port *port,
> > return parent_lct + 1;
> >  }
> >
> > +static bool drm_dp_mst_is_dp_mst_end_device(u8 pdt, bool mcs) {
> > +   switch (pdt) {
> > +   case DP_PEER_DEVICE_DP_LEGACY_CONV:
> > +   case DP_PEER_DEVICE_SST_SINK:
> > +   return true;
> > +   case DP_PEER_DEVICE_MST_BRANCHING:
> > +   /* For sst branch device */
> > +   if (!mcs)
> > +   return true;
> > +
> > +   return false;
> > +   }
> > +   return true;
> > +}
> > +
> >  static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8
> > new_pdt)  {
> > struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> --
> Cheers,
>   Lyude Paul
--
Best regards,
Wayne Lin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/2] drm/dp_mst: Handle SST-only branch device case

[Lin, Wayne]

[AMD Public Use]



> -Original Message-
> From: Lyude Paul 
> Sent: Wednesday, January 15, 2020 5:19 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry ; Ville Syrjälä
> ; Wentland, Harry 
> Subject: Re: [PATCH 2/2] drm/dp_mst: Handle SST-only branch device case
> 
> On Wed, 2020-01-08 at 16:44 +0800, Wayne Lin wrote:
> > [Why]
> > While handling LINK_ADDRESS reply, current code expects a peer device
> > can handle sideband message once the peer device type is reported as
> > DP_PEER_DEVICE_MST_BRANCHING. However, when the connected device
> is a
> > SST branch case, it can't handle the sideband message(MST_CAP=0 in
> > DPCD 00021h).
> >
> > Current code will try to send LINK_ADDRESS to SST branch device and
> > end up with message timeout and monitor can't display normally. As the
> > result of that, we should take SST branch device into account.
> >
> > [How]
> > According to DP 1.4 spec, we can use Peer_Device_Type as
> > DP_PEER_DEVICE_MST_BRANCHING and Message_Capability_Status as 0 to
> > indicate peer device as a SST-only branch device.
> >
> > Fix following:
> > - Take SST-only branch device case into account in
> > drm_dp_port_set_pdt() and add a new parameter 'new_mcs'. Take sst
> > branch device case as the same case as
> DP_PEER_DEVICE_DP_LEGACY_CONV
> > and DP_PEER_DEVICE_SST_SINK. All original handling logics remain.
> > - Take SST-only branch device case into account in
> > drm_dp_mst_port_add_connector().
> > - Fix some parts in drm_dp_mst_handle_link_address_port() to have SST
> > branch device case into consideration.
> > - Fix the arguments of drm_dp_port_set_pdt() in
> > drm_dp_mst_handle_conn_stat().
> > - Have SST branch device also report
> > connector_status_connected when the ddps is true in
> > drm_dp_mst_detect_port()
> > - Fix the arguments of drm_dp_port_set_pdt() in
> > drm_dp_delayed_destroy_port()
> >
> > Fixes: c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add
> > more
> > locking")
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Cc: Lyude Paul 
> > Signed-off-by: Wayne Lin 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 131
> > +-
> >  1 file changed, 68 insertions(+), 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 8f54b241db08..4395d5cc0645 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1934,73 +1934,74 @@ static bool
> drm_dp_mst_is_dp_mst_end_device(u8
> > pdt, bool mcs)
> > return true;
> >  }
> >
> > -static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8
> > new_pdt)
> > +static int
> > +drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt,
> > +   bool new_mcs)
> >  {
> > struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> > struct drm_dp_mst_branch *mstb;
> > u8 rad[8], lct;
> > int ret = 0;
> >
> > -   if (port->pdt == new_pdt)
> > +   if (port->pdt == new_pdt && port->mcs == new_mcs)
> > return 0;
> >
> > /* Teardown the old pdt, if there is one */
> > -   switch (port->pdt) {
> > -   case DP_PEER_DEVICE_DP_LEGACY_CONV:
> > -   case DP_PEER_DEVICE_SST_SINK:
> > -   /*
> > -* If the new PDT would also have an i2c bus, don't bother
> > -* with reregistering it
> > -*/
> > -   if (new_pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
> > -   new_pdt == DP_PEER_DEVICE_SST_SINK) {
> > -   port->pdt = new_pdt;
> > -   return 0;
> > -   }
> > +   if (port->pdt != DP_PEER_DEVICE_NONE) {
> > +   if (drm_dp_mst_is_dp_mst_end_device(port->pdt, port->mcs)) {
> > +   /*
> > +* If the new PDT would also have an i2c bus,
> > +* don't bother with reregistering it
> > +*/
> > +   if (new_pdt != DP_PEER_DEVICE_NONE &&
> > +   drm_dp_mst_is_dp_mst_end_device(new_pdt, new_mcs))
> > {
> > +   port->pdt = new_pdt;
> > +   port->mcs = new_mcs;
> > +   return 0;
> > +   }
> >
> > -   /* remove i2c over sideband */
> > -   drm_dp_mst_unregister_i2c_bus(&port->aux);
> > -   break;
> > -   case DP_PEER_DEVICE_MST_BRANCHING:
> > -   mutex_lock(&mgr->lock);
> > -   drm_dp_mst_topology_put_mstb(port->mstb);
> > -   port->mstb = NULL;
> > -   mutex_unlock(&mgr->lock);
> > -   break;
> > +   /* remove i2c over sideband */
> > +   drm_dp_mst_unregister_i2c_bus(&port->aux);
> > +   } else {
> > +   mutex_lock(&mgr->lock);
> > +   drm_dp_mst_topology_put_mstb(port->mstb);
> > +   port->mstb = NULL;
> 

[[Intel-gfx] [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915

[Pankaj Bharadiya]

Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.

Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we know
what device the warnings originate from. Knowing the device specific
information in the backtrace would be helpful in development all
around.

This patch series aims to convert calls of WARN(), WARN_ON(),
WARN_ONCE() and WARN_ON_ONCE() in i916 driver to use the drm
device-specific variants automatically wherever struct device pointer
is available.

To do this, this patch series -
  - introduces new struct drm_device based WARN* macros
  - automatically converts WARN* with device specific dev_WARN*
variants using coccinelle semantic patch scripts.

The goal is to convert all the calls of WARN* with drm_WARN* in i915,
but there are still cases where device pointer is not readily
available in some functions (or I missed them somehow) using WARN*
hence some manual churning is needed. Handle such remaining cases
separately later.

changes since v1:
  - Address Jani's review comments
- Fix typo in comment of patch 0001
- Get rid of helper functions
- Split patches by directory 

Changes since RFC at [1]
  - Introduce drm_WARN* macros and use them as suggested by Sam and Jani
  - Get rid of extra local variables

[1] https://patchwork.freedesktop.org/series/71668/


Pankaj Bharadiya (10):
  drm/print: introduce new struct drm_device based WARN* macros
  drm/i915/display: Make WARN* drm specific where drm_device ptr is available
  drm/i915/display: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/display: Make WARN* drm specific where encoder ptr is available
  drm/i915/gem: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/gt: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available
  drm/i915: Make WARN* drm specific where drm_priv ptr is available
  drm/i915: Make WARN* drm specific where uncore or stream ptr is available

 drivers/gpu/drm/i915/display/icl_dsi.c|  14 +-
 drivers/gpu/drm/i915/display/intel_atomic.c   |   6 +-
 drivers/gpu/drm/i915/display/intel_audio.c|  19 +-
 drivers/gpu/drm/i915/display/intel_bios.c |  10 +-
 drivers/gpu/drm/i915/display/intel_bw.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c|  81 ---
 drivers/gpu/drm/i915/display/intel_color.c|   4 +-
 .../gpu/drm/i915/display/intel_combo_phy.c|   2 +-
 .../gpu/drm/i915/display/intel_connector.c|   3 +-
 drivers/gpu/drm/i915/display/intel_crt.c  |  10 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  | 100 
 drivers/gpu/drm/i915/display/intel_display.c  | 228 ++
 .../drm/i915/display/intel_display_power.c| 169 +++--
 drivers/gpu/drm/i915/display/intel_dp.c   | 123 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  10 +-
 drivers/gpu/drm/i915/display/intel_dpio_phy.c |   3 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  37 +--
 drivers/gpu/drm/i915/display/intel_dsb.c  |   6 +-
 .../i915/display/intel_dsi_dcs_backlight.c|   2 +-
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  |   5 +-
 drivers/gpu/drm/i915/display/intel_fbc.c  |  23 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|  13 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|   3 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  21 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  71 +++---
 drivers/gpu/drm/i915/display/intel_hotplug.c  |   7 +-
 .../gpu/drm/i915/display/intel_lpe_audio.c|   2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |   7 +-
 drivers/gpu/drm/i915/display/intel_opregion.c |   7 +-
 drivers/gpu/drm/i915/display/intel_overlay.c  |  14 +-
 drivers/gpu/drm/i915/display/intel_panel.c|  19 +-
 drivers/gpu/drm/i915/display/intel_pipe_crc.c |   7 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  32 +--
 drivers/gpu/drm/i915/display/intel_sdvo.c |  14 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |   5 +-
 drivers/gpu/drm/i915/display/intel_tc.c   |  18 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c |   2 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  15 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   8 +-
 drivers/gpu/drm/i915/gt/intel_engine_user.c   |   3 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   6 +-
 drivers/gpu/drm/i915/gt/intel_mocs.c  |   4 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   2 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   7 +-
 drivers/gpu/drm/

[[Intel-gfx] [PATCH v2 01/10] drm/print: introduce new struct drm_device based WARN* macros

[Pankaj Bharadiya]

Add new struct drm_device based WARN* macros. These are modeled after
the core kernel device based WARN* macros. These would be preferred
over the regular WARN* macros, where possible.

These macros include device information in the backtrace, so we know
what device the warnings originate from.

Knowing the device specific information in the backtrace would be
helpful in development all around.

Signed-off-by: Pankaj Bharadiya 
---
 include/drm/drm_print.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 8f99d389792d..894a0b9437e2 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -553,4 +553,33 @@ void __drm_err(const char *format, ...);
 #define DRM_DEBUG_PRIME_RATELIMITED(fmt, ...)  \
DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
 
+/*
+ * struct drm_device based WARNs
+ *
+ * drm_WARN*() acts like WARN*(), but with the key difference of
+ * using device specific information so that we know from which device
+ * warning is originating from.
+ *
+ * Prefer drm_device based drm_WARN* over regular WARN*
+ */
+
+/* Helper for struct drm_device based WARNs */
+#define drm_WARN(drm, condition, format, arg...)   \
+   WARN(condition, "%s %s: " format,   \
+   dev_driver_string((drm)->dev),  \
+   dev_name((drm)->dev), ## arg)
+
+#define drm_WARN_ONCE(drm, condition, format, arg...)  \
+   WARN_ONCE(condition, "%s %s: " format,  \
+   dev_driver_string((drm)->dev),  \
+   dev_name((drm)->dev), ## arg)
+
+#define drm_WARN_ON(drm, x)\
+   drm_WARN((drm), (x), "%s",  \
+"drm_WARN_ON(" __stringify(x) ")")
+
+#define drm_WARN_ON_ONCE(drm, x)   \
+   drm_WARN_ONCE((drm), (x), "%s", \
+ "drm_WARN_ON_ONCE(" __stringify(x) ")")
+
 #endif /* DRM_PRINT_H_ */
-- 
2.23.0

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

[[Intel-gfx] [PATCH v2 01/10] drm/print: introduce new struct drm_device based WARN* macros

[Pankaj Bharadiya]

Add new struct drm_device based WARN* macros. These are modeled after
the core kernel device based WARN* macros. These would be preferred
over the regular WARN* macros, where possible.

These macros include device information in the backtrace, so we know
what device the warnings originate from.

Knowing the device specific information in the backtrace would be
helpful in development all around.

Signed-off-by: Pankaj Bharadiya 
---
 include/drm/drm_print.h | 29 +
 1 file changed, 29 insertions(+)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 8f99d389792d..894a0b9437e2 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -553,4 +553,33 @@ void __drm_err(const char *format, ...);
 #define DRM_DEBUG_PRIME_RATELIMITED(fmt, ...)  \
DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
 
+/*
+ * struct drm_device based WARNs
+ *
+ * drm_WARN*() acts like WARN*(), but with the key difference of
+ * using device specific information so that we know from which device
+ * warning is originating from.
+ *
+ * Prefer drm_device based drm_WARN* over regular WARN*
+ */
+
+/* Helper for struct drm_device based WARNs */
+#define drm_WARN(drm, condition, format, arg...)   \
+   WARN(condition, "%s %s: " format,   \
+   dev_driver_string((drm)->dev),  \
+   dev_name((drm)->dev), ## arg)
+
+#define drm_WARN_ONCE(drm, condition, format, arg...)  \
+   WARN_ONCE(condition, "%s %s: " format,  \
+   dev_driver_string((drm)->dev),  \
+   dev_name((drm)->dev), ## arg)
+
+#define drm_WARN_ON(drm, x)\
+   drm_WARN((drm), (x), "%s",  \
+"drm_WARN_ON(" __stringify(x) ")")
+
+#define drm_WARN_ON_ONCE(drm, x)   \
+   drm_WARN_ONCE((drm), (x), "%s", \
+ "drm_WARN_ON_ONCE(" __stringify(x) ")")
+
 #endif /* DRM_PRINT_H_ */
-- 
2.23.0

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

[[Intel-gfx] [PATCH v2 00/10] drm: Introduce struct drm_device based WARN* and use them in i915

[Pankaj Bharadiya]

Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.

Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we know
what device the warnings originate from. Knowing the device specific
information in the backtrace would be helpful in development all
around.

This patch series aims to convert calls of WARN(), WARN_ON(),
WARN_ONCE() and WARN_ON_ONCE() in i916 driver to use the drm
device-specific variants automatically wherever struct device pointer
is available.

To do this, this patch series -
  - introduces new struct drm_device based WARN* macros
  - automatically converts WARN* with device specific dev_WARN*
variants using coccinelle semantic patch scripts.

The goal is to convert all the calls of WARN* with drm_WARN* in i915,
but there are still cases where device pointer is not readily
available in some functions (or I missed them somehow) using WARN*
hence some manual churning is needed. Handle such remaining cases
separately later.

changes since v1:
  - Address Jani's review comments
- Fix typo in comment of patch 0001
- Get rid of helper functions
- Split patches by directory 

Changes since RFC at [1]
  - Introduce drm_WARN* macros and use them as suggested by Sam and Jani
  - Get rid of extra local variables

[1] https://patchwork.freedesktop.org/series/71668/


Pankaj Bharadiya (10):
  drm/print: introduce new struct drm_device based WARN* macros
  drm/i915/display: Make WARN* drm specific where drm_device ptr is available
  drm/i915/display: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/display: Make WARN* drm specific where encoder ptr is available
  drm/i915/gem: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/gt: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available
  drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available
  drm/i915: Make WARN* drm specific where drm_priv ptr is available
  drm/i915: Make WARN* drm specific where uncore or stream ptr is available

 drivers/gpu/drm/i915/display/icl_dsi.c|  14 +-
 drivers/gpu/drm/i915/display/intel_atomic.c   |   6 +-
 drivers/gpu/drm/i915/display/intel_audio.c|  19 +-
 drivers/gpu/drm/i915/display/intel_bios.c |  10 +-
 drivers/gpu/drm/i915/display/intel_bw.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_cdclk.c|  81 ---
 drivers/gpu/drm/i915/display/intel_color.c|   4 +-
 .../gpu/drm/i915/display/intel_combo_phy.c|   2 +-
 .../gpu/drm/i915/display/intel_connector.c|   3 +-
 drivers/gpu/drm/i915/display/intel_crt.c  |  10 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  | 100 
 drivers/gpu/drm/i915/display/intel_display.c  | 228 ++
 .../drm/i915/display/intel_display_power.c| 169 +++--
 drivers/gpu/drm/i915/display/intel_dp.c   | 123 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c   |  10 +-
 drivers/gpu/drm/i915/display/intel_dpio_phy.c |   3 +-
 drivers/gpu/drm/i915/display/intel_dpll_mgr.c |  37 +--
 drivers/gpu/drm/i915/display/intel_dsb.c  |   6 +-
 .../i915/display/intel_dsi_dcs_backlight.c|   2 +-
 drivers/gpu/drm/i915/display/intel_dsi_vbt.c  |   5 +-
 drivers/gpu/drm/i915/display/intel_fbc.c  |  23 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|  13 +-
 drivers/gpu/drm/i915/display/intel_gmbus.c|   3 +-
 drivers/gpu/drm/i915/display/intel_hdcp.c |  21 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c |  71 +++---
 drivers/gpu/drm/i915/display/intel_hotplug.c  |   7 +-
 .../gpu/drm/i915/display/intel_lpe_audio.c|   2 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |   7 +-
 drivers/gpu/drm/i915/display/intel_opregion.c |   7 +-
 drivers/gpu/drm/i915/display/intel_overlay.c  |  14 +-
 drivers/gpu/drm/i915/display/intel_panel.c|  19 +-
 drivers/gpu/drm/i915/display/intel_pipe_crc.c |   7 +-
 drivers/gpu/drm/i915/display/intel_psr.c  |  32 +--
 drivers/gpu/drm/i915/display/intel_sdvo.c |  14 +-
 drivers/gpu/drm/i915/display/intel_sprite.c   |   5 +-
 drivers/gpu/drm/i915/display/intel_tc.c   |  18 +-
 drivers/gpu/drm/i915/display/intel_vdsc.c |   2 +-
 drivers/gpu/drm/i915/display/vlv_dsi.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c|   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c  |  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  15 +-
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   8 +-
 drivers/gpu/drm/i915/gt/intel_engine_user.c   |   3 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   6 +-
 drivers/gpu/drm/i915/gt/intel_mocs.c  |   4 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   2 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   7 +-
 drivers/gpu/drm/

[[Intel-gfx] [PATCH v2 02/10] drm/i915/display: Make WARN* drm specific where drm_device ptr is available

[Pankaj Bharadiya]

Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}

@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 02/10] drm/i915/display: Make WARN* drm specific where drm_device ptr is available

[Pankaj Bharadiya]

Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}

@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 04/10] drm/i915/display: Make WARN* drm specific where encoder ptr is available

[Pankaj Bharadiya]

Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where intel_encoder struct pointer is available.

The conversion was done automatically with below coccinelle semantic
patch.

@@
identifier func, T;
@@
func(...) {
...
struct intel_encoder *T = ...;
<...
(
-WARN(
+drm_WARN(T->base.dev,
...)
|
-WARN_ON(
+drm_WARN_ON(T->base.dev,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T->base.dev,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T->base.dev,
...)
)
...>

}

@@
identifier func, T;
@@
func(struct intel_encoder *T,...) {
<...
(
-WARN(
+drm_WARN(T->base.dev,
...)
|
-WARN_ON(
+drm_WARN_ON(T->base.dev,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T->base.dev,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T->base.dev,
...)
)
...>

}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 03/10] drm/i915/display: Make WARN* drm specific where drm_priv ptr is available

[Pankaj Bharadiya]

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 05/10] drm/i915/gem: Make WARN* drm specific where drm_priv ptr is available

[Pankaj Bharadiya]

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 10/10] drm/i915: Make WARN* drm specific where uncore or stream ptr is available

[Pankaj Bharadiya]

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where intel_uncore/i915_perf_stream  struct
pointer is readily available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@@
identifier func, T;
@@
func(...) {
...
struct intel_uncore *T = ...;
<...
(
-WARN(
+drm_WARN(&T->i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->i915->drm,
...)
)
...>

}

@@
identifier func, T;
@@
func(struct intel_uncore *T,...) {
<...
(
-WARN(
+drm_WARN(&T->i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->i915->drm,
...)
)
...>

}

@@
identifier func, T;
@@
func(struct i915_perf_stream *T,...) {
+struct drm_i915_private *i915 = T->perf->i915;
<+...
(
-WARN(
+drm_WARN(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>

}

command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file 

[[Intel-gfx] [PATCH v2 07/10] drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available

[Pankaj Bharadiya]

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 08/10] drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available

[Pankaj Bharadiya]

Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@@
identifier func, T;
@@
func(struct intel_vgpu *T,...) {
+struct drm_i915_private *i915 = T->gvt->dev_priv;
<+...
(
-WARN(
+drm_WARN(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>

}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 06/10] drm/i915/gt: Make WARN* drm specific where drm_priv ptr is available

[Pankaj Bharadiya]

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: spatch --sp-file 

[[Intel-gfx] [PATCH v2 09/10] drm/i915: Make WARN* drm specific where drm_priv ptr is available

[Pankaj Bharadiya]

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \

nouveau-next 5.6

[Ben Skeggs]

Hey Dave,

It's a little late in the -next cycle, but final firmware images from
NVIDIA appear to be ready now, so I've spent the last few days
testing/tidying up this code to get it ready to upstream - finally.

Brief overview (more info in commit messages):

- Rewrite of the ACR (formerly "secure boot") code, both to support
Turing, support multiple FW revisions, and to make life easier when
having to debug HW/FW bring-up in the future
- Support for TU10x graphics engine, TU11x not available yet as FW isn't ready
- Proper page 'kind' mappings for Turing
- 10-bit LUT support
- GP10B (Tegra) fixes
- Misc other fixes

Thanks,
Ben.

The following changes since commit 688486a49cf500a193dfe15be9eb5aa468887769:

  Merge tag 'amd-drm-next-5.6-2020-01-10-dp-mst-dsc' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-01-13
17:14:34 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.6

for you to fetch changes up to afa3b96b058d87c2c44d1c83dadb2ba6998d03ce:

  drm/nouveau/gr/tu10x: initial support (2020-01-15 10:50:30 +1000)


Ben Skeggs (77):
  drm/nouveau/gr/gk208-gm10x: regenerate built-in firmware
  drm/nouveau/core: fix missing newline in fw loader error message
  drm/nouveau/fault/tu102: define nvkm_fault_func.pin
  drm/nouveau/gr/gf100-: remove dtor
  drm/nouveau/gr/gk20a,gm200-: add terminators to method lists read from fw
  drm/nouveau/gr/gv100-: modify gr init to match newer version of RM
  drm/nouveau/disp/dp: fix typo when determining failsafe link configuration
  drm/nouveau/fault/gv100-: fix memory leak on module unload
  drm/nouveau/flcn: move fetching of configuration until first use
  drm/nouveau/flcn: fetch PRI address from TOP if not provided by
constructor
  drm/nouveau/flcn: export existing funcs
  drm/nouveau/core: output fw size in debug messages
  drm/nouveau/core: add a macro to better handle multiple firmware versions
  drm/nouveau/core: add representation of generic binary objects
  drm/nouveau/core: define ACR subdev
  drm/nouveau/acr: add stub implementation for all GPUs currently
supported by SECBOOT
  drm/nouveau/acr: add loaders for currently available LS firmware images
  drm/nouveau/gsp: select implementation based on available firmware
  drm/nouveau/gsp: initialise SW state for falcon from constructor
  drm/nouveau/pmu/gp10b: split from gm20b implementation
  drm/nouveau/pmu: select implementation based on available firmware
  drm/nouveau/pmu: initialise SW state for falcon from constructor
  drm/nouveau/gr/gf100-: use nvkm_blob structure for fecs/gpccs fw
  drm/nouveau/gr/gk20a,gm200-: use nvkm_firmware_load_blob for sw init
  drm/nouveau/gr/gf100-: drop fuc_ prefix on sw init
  drm/nouveau/gr/gf100-: move fecs/gpccs ucode into their substructures
  drm/nouveau/gr/gp108: split from gp107
  drm/nouveau/gr/gf100-: select implementation based on available FW
  drm/nouveau/gr/gf100-: initialise SW state for falcon from constructor
  drm/nouveau/sec2/gp108: split from gp102 implementation
  drm/nouveau/sec2: select implementation based on available firmware
  drm/nouveau/sec2: initialise SW state for falcon from constructor
  drm/nouveau/sec2: use falcon funcs
  drm/nouveau/sec2: move interrupt handler to hw-specific module
  drm/nouveau/nvdec: select implementation based on available fw
  drm/nouveau/nvdec: initialise SW state for falcon from constructor
  drm/nouveau/nvdec/gm107: rename from gp102 implementation
  drm/nouveau/nvdec/gm107-: add missing engine instances
  drm/nouveau/nvenc: add a stub implementation for the GPUs where
it should be supported
  drm/nouveau/flcn: specify FBIF offset from subdev
  drm/nouveau/flcn: move bind_context WAR out of common code
  drm/nouveau/flcn: specify EMEM address from subdev
  drm/nouveau/flcn: specify debug/production register offset from subdev
  drm/nouveau/flcn: specify queue register offsets from subdev
  drm/nouveau/flcn: reset sec2/gsp falcons harder
  drm/nouveau/flcn: add printk macros
  drm/nouveau/flcn: split msgqueue into multiple pieces
  drm/nouveau/flcn/qmgr: explicitly create queue manager from subdevs
  drm/nouveau/flcn/cmdq: explicitly create command queue(s) from subdevs
  drm/nouveau/flcn/msgq: explicitly create message queue from subdevs
  drm/nouveau/flcn/qmgr: move sequence tracking from nvkm_msgqueue
to nvkm_falcon_qmgr
  drm/nouveau/flcn/qmgr: allow arbtrary priv + return code for callbacks
  drm/nouveau/flcn/qmgr: support syncronous command submission
from common code
  drm/nouveau/flcn/qmgr: rename remaining nvkm_msgqueue bits to
nvkm_falcon_qmgr
  drm/nouveau/flcn/cmdq: split the condition for queue readiness
vs pmu acr readiness
  drm/nouveau/flcn/cmdq: cmd_queue_push can't fa

Re: [PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs

[Thomas Zimmermann]

Hi

Am 14.01.20 um 16:31 schrieb Yannick FERTRE:
> Thanks for the patch.
> 
> Tested-by: Yannick Fertré  

Thanks for testing all these patches.

Best regards
Thomas

> 
> BR
> Yannick Fertré
> 
> 
> On 1/10/20 10:21 AM, Thomas Zimmermann wrote:
>> The new callback get_scanout_position() reads the current location of
>> the scanout process. The operation is currentyl located in struct
>> drm_driver, but really belongs to the CRTC. Drivers will be converted
>> in separate patches.
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>  drivers/gpu/drm/drm_vblank.c | 24 
>>  include/drm/drm_drv.h|  7 +---
>>  include/drm/drm_modeset_helper_vtables.h | 47 
>>  3 files changed, 65 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>> index 1659b13b178c..c12f0b333e14 100644
>> --- a/drivers/gpu/drm/drm_vblank.c
>> +++ b/drivers/gpu/drm/drm_vblank.c
>> @@ -30,6 +30,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -590,7 +591,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants);
>>   * Implements calculation of exact vblank timestamps from given 
>> drm_display_mode
>>   * timings and current video scanout position of a CRTC. This can be 
>> directly
>>   * used as the &drm_driver.get_vblank_timestamp implementation of a kms 
>> driver
>> - * if &drm_driver.get_scanout_position is implemented.
>> + * if &drm_crtc_helper_funcs.get_scanout_position is implemented.
>>   *
>>   * The current implementation only handles standard video modes. For double 
>> scan
>>   * and interlaced modes the driver is supposed to adjust the hardware mode
>> @@ -632,8 +633,9 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
>> drm_device *dev,
>>  }
>>  
>>  /* Scanout position query not supported? Should not happen. */
>> -if (!dev->driver->get_scanout_position) {
>> -DRM_ERROR("Called from driver w/o get_scanout_position()!?\n");
>> +if (!dev->driver->get_scanout_position ||
>> +!crtc->helper_private->get_scanout_position) {
>> +DRM_ERROR("Called from CRTC w/o get_scanout_position()!?\n");
>>  return false;
>>  }
>>  
>> @@ -664,11 +666,17 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
>> drm_device *dev,
>>   * Get vertical and horizontal scanout position vpos, hpos,
>>   * and bounding timestamps stime, etime, pre/post query.
>>   */
>> -vbl_status = dev->driver->get_scanout_position(dev, pipe,
>> -   in_vblank_irq,
>> -   &vpos, &hpos,
>> -   &stime, &etime,
>> -   mode);
>> +if (crtc->helper_private->get_scanout_position) {
>> +vbl_status =
>> +crtc->helper_private->get_scanout_position(
>> +crtc, in_vblank_irq, &vpos, &hpos,
>> +&stime, &etime, mode);
>> +} else {
>> +vbl_status =
>> +dev->driver->get_scanout_position(
>> +dev, pipe, in_vblank_irq, &vpos,
>> +&hpos, &stime, &etime, mode);
>> +}
>>  
>>  /* Return as no-op if scanout query unsupported or failed. */
>>  if (!vbl_status) {
>> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>> index cf13470810a5..d0049e5786fc 100644
>> --- a/include/drm/drm_drv.h
>> +++ b/include/drm/drm_drv.h
>> @@ -362,11 +362,8 @@ struct drm_driver {
>>   * True on success, false if a reliable scanout position counter could
>>   * not be read out.
>>   *
>> - * FIXME:
>> - *
>> - * Since this is a helper to implement @get_vblank_timestamp, we should
>> - * move it to &struct drm_crtc_helper_funcs, like all the other
>> - * helper-internal hooks.
>> + * This is deprecated and should not be used by new drivers.
>> + * Use &drm_crtc_helper_funcs.get_scanout_position instead.
>>   */
>>  bool (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
>>bool in_vblank_irq, int *vpos, int *hpos,
>> diff --git a/include/drm/drm_modeset_helper_vtables.h 
>> b/include/drm/drm_modeset_helper_vtables.h
>> index 5a87f1bd7a3f..e398512bfd5f 100644
>> --- a/include/drm/drm_modeset_helper_vtables.h
>> +++ b/include/drm/drm_modeset_helper_vtables.h
>> @@ -450,6 +450,53 @@ struct drm_crtc_helper_funcs {
>>   */
>>  void (*atomic_disable)(struct drm_crtc *crtc,
>> struct drm_crtc_state *old_crtc_state);
>> +
>> +/**
>> + * @get_scanout_position:
>> + *
>> +