Re: [PATCH] devfreq: Register devfreq as a cooling device

[Steven Price]

On 04/03/2021 12:50, Daniel Lezcano wrote:

Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.

There are no so many and actually it makes more sense to register the
devfreq device when adding it.

Consequently, every devfreq becomes a cooling device like cpufreq is.

Having a devfreq being registered as a cooling device can not mitigate
a thermal zone if it is not bound to this one. Thus, the current
configurations are not impacted by this change.

Signed-off-by: Daniel Lezcano 
---
  drivers/devfreq/devfreq.c   |  8 
  drivers/gpu/drm/lima/lima_devfreq.c | 13 -
  drivers/gpu/drm/lima/lima_devfreq.h |  2 --
  drivers/gpu/drm/msm/msm_gpu.c   | 11 ---
  drivers/gpu/drm/msm/msm_gpu.h   |  2 --
  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
  include/linux/devfreq.h |  3 +++
  7 files changed, 11 insertions(+), 41 deletions(-)


[...]

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..2cb6300de1f1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -3,7 +3,6 @@
  
  #include 

  #include 
-#include 
  #include 
  #include 
  
@@ -90,7 +89,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)

struct device *dev = &pfdev->pdev->dev;
struct devfreq *devfreq;
struct opp_table *opp_table;
-   struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
  
  	opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,

@@ -139,12 +137,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
}
pfdevfreq->devfreq = devfreq;
  
-	cooling = devfreq_cooling_em_register(devfreq, NULL);

-   if (IS_ERR(cooling))
-   DRM_DEV_INFO(dev, "Failed to register cooling device\n");
-   else
-   pfdevfreq->cooling = cooling;
-
return 0;
  
  err_fini:

@@ -156,11 +148,6 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
  {
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
  
-	if (pfdevfreq->cooling) {

-   devfreq_cooling_unregister(pfdevfreq->cooling);
-   pfdevfreq->cooling = NULL;
-   }
-
if (pfdevfreq->opp_of_table_added) {
dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
pfdevfreq->opp_of_table_added = false;


You've removed all references to pfdevfreq->cooling, so please also 
remove the member from struct panfrost_devfreq (as already done with 
lima and msm).


Thanks,

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

Re: [PATCH] drm/uapi: document kernel capabilities

[Pekka Paalanen]

On Thu,  4 Mar 2021 23:10:57 +0100
Simon Ser  wrote:

> Document all of the DRM_CAP_* defines.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Pekka Paalanen 
> ---
>  include/uapi/drm/drm.h | 100 +++--
>  1 file changed, 96 insertions(+), 4 deletions(-)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 0827037c5484..4ef07f505725 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -625,30 +625,122 @@ struct drm_gem_open {
>   __u64 size;
>  };
>  
> +/**
> + * DRM_CAP_DUMB_BUFFER
> + *
> + * If set to 1, the driver supports creating dumb buffers via the
> + * &DRM_IOCTL_MODE_CREATE_DUMB ioctl.
> + */
>  #define DRM_CAP_DUMB_BUFFER  0x1
> +/**
> + * DRM_CAP_VBLANK_HIGH_CRTC
> + *
> + * If set to 1, the kernel supports specifying a CRTC index in the high bits 
> of
> + * &drm_wait_vblank_request.type.
> + */
>  #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
> +/**
> + * DRM_CAP_DUMB_PREFERRED_DEPTH
> + *
> + * The preferred depth (in bits) for dumb buffers.

Hi,

this is literally depth, not bits per pixel, right?

> + */
>  #define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
> +/**
> + * DRM_CAP_DUMB_PREFER_SHADOW
> + *
> + * If set to 1, the driver prefers userspace to render to a shadow buffer
> + * instead of directly rendering to a dumb buffer.

Maybe add something like:

For best speed, userspace should do streaming ordered memory copies
into the dumb buffer and never read from it.

Isn't that correct?

> + */
>  #define DRM_CAP_DUMB_PREFER_SHADOW   0x4
> +/**
> + * DRM_CAP_PRIME
> + *
> + * Bitfield of supported PRIME sharing capabilities. See 
> &DRM_PRIME_CAP_IMPORT
> + * and &DRM_PRIME_CAP_EXPORT.
> + */
>  #define DRM_CAP_PRIME0x5
> +/**
> + * DRM_PRIME_CAP_IMPORT
> + *
> + * If this bit is set in &DRM_CAP_PRIME, the driver supports importing PRIME
> + * buffers.

What are PRIME buffers?

> + */
>  #define  DRM_PRIME_CAP_IMPORT0x1
> +/**
> + * DRM_PRIME_CAP_EXPORT
> + *
> + * If this bit is set in &DRM_CAP_PRIME, the driver supports exporting PRIME
> + * buffers.

What's the export API? HandleToFD()?

> + */
>  #define  DRM_PRIME_CAP_EXPORT0x2
> +/**
> + * DRM_CAP_TIMESTAMP_MONOTONIC
> + *
> + * If set to 0, the kernel will report timestamps with the realtime clock in
> + * struct drm_event_vblank. If set to 1, the kernel will report timestamps 
> with
> + * the monotonic clock.

I think it would be more explicit to say CLOCK_REALTIME and
CLOCK_MONOTONIC, because there are things like CLOCK_MONOTONIC_RAW
which is different. Mention clock_gettime()?

> + */
>  #define DRM_CAP_TIMESTAMP_MONOTONIC  0x6
> +/**
> + * DRM_CAP_ASYNC_PAGE_FLIP
> + *
> + * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC.

Does this apply equally to both legacy and atomic KMS API?

> + */
>  #define DRM_CAP_ASYNC_PAGE_FLIP  0x7
> -/*
> - * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid 
> widthxheight
> - * combination for the hardware cursor. The intention is that a hardware
> - * agnostic userspace can query a cursor plane size to use.
> +/**
> + * DRM_CAP_CURSOR_WIDTH
> + *
> + * The ``CURSOR_WIDTH`` and ``CURSOR_HEIGHT`` capabilities return a valid
> + * width x height combination for the hardware cursor. The intention is that 
> a
> + * hardware agnostic userspace can query a cursor plane size to use.
>   *
>   * Note that the cross-driver contract is to merely return a valid size;
>   * drivers are free to attach another meaning on top, eg. i915 returns the
>   * maximum plane size.
>   */
>  #define DRM_CAP_CURSOR_WIDTH 0x8
> +/**
> + * DRM_CAP_CURSOR_HEIGHT
> + *
> + * See &DRM_CAP_CURSOR_WIDTH.
> + */
>  #define DRM_CAP_CURSOR_HEIGHT0x9
> +/**
> + * DRM_CAP_ADDFB2_MODIFIERS
> + *
> + * If set to 1, the driver supports supplying modifiers in the
> + * &DRM_IOCTL_MODE_ADDFB2 ioctl.
> + */
>  #define DRM_CAP_ADDFB2_MODIFIERS 0x10
> +/**
> + * DRM_CAP_PAGE_FLIP_TARGET
> + *
> + * If set to 1, the driver supports the &DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 
> and
> + * &DRM_MODE_PAGE_FLIP_TARGET_RELATIVE flags in
> + * &drm_mode_crtc_page_flip_target.flags for the &DRM_IOCTL_MODE_PAGE_FLIP
> + * ioctl.
> + */
>  #define DRM_CAP_PAGE_FLIP_TARGET 0x11
> +/**
> + * DRM_CAP_CRTC_IN_VBLANK_EVENT
> + *
> + * If set to 1, the kernel supports reporting the CRTC ID in
> + * &drm_event_vblank.crtc_id.

Does this not apply also to the pageflip / atomic completion event?

> + */
>  #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
> +/**
> + * DRM_CAP_SYNCOBJ
> + *
> + * If set to 1, the driver supports sync objects. See
> + * Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
> + */
>  #define DRM_CAP_SYNCOBJ  0x13
> +/**
> + * DRM_CAP_SYNCOBJ_TIMELINE
> + *
> + * If set to 1, the driver supports timeline operations on sync objects. See
> + * Documentation/gpu/drm-mm.rst, section "DRM Sync Objects".
> + */
>  #def

[patch 2/7] drm/vmgfx: Replace kmap_atomic()

[Thomas Gleixner]

From: Thomas Gleixner 

There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().

Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.

Remove the NULL pointer check for the map. These functions return a valid
address for valid pages and the return was bogus anyway as it would have
left preemption and pagefaults disabled.

Signed-off-by: Thomas Gleixner 
Cc: VMware Graphics 
Cc: Roland Scheidegger 
Cc: Zack Rusin 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c |   30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -375,12 +375,12 @@ static int vmw_bo_cpu_blit_line(struct v
copy_size = min_t(u32, copy_size, PAGE_SIZE - src_page_offset);
 
if (unmap_src) {
-   kunmap_atomic(d->src_addr);
+   kunmap_local(d->src_addr);
d->src_addr = NULL;
}
 
if (unmap_dst) {
-   kunmap_atomic(d->dst_addr);
+   kunmap_local(d->dst_addr);
d->dst_addr = NULL;
}
 
@@ -388,12 +388,8 @@ static int vmw_bo_cpu_blit_line(struct v
if (WARN_ON_ONCE(dst_page >= d->dst_num_pages))
return -EINVAL;
 
-   d->dst_addr =
-   kmap_atomic_prot(d->dst_pages[dst_page],
-d->dst_prot);
-   if (!d->dst_addr)
-   return -ENOMEM;
-
+   d->dst_addr = 
kmap_local_page_prot(d->dst_pages[dst_page],
+  d->dst_prot);
d->mapped_dst = dst_page;
}
 
@@ -401,12 +397,8 @@ static int vmw_bo_cpu_blit_line(struct v
if (WARN_ON_ONCE(src_page >= d->src_num_pages))
return -EINVAL;
 
-   d->src_addr =
-   kmap_atomic_prot(d->src_pages[src_page],
-d->src_prot);
-   if (!d->src_addr)
-   return -ENOMEM;
-
+   d->src_addr = 
kmap_local_page_prot(d->src_pages[src_page],
+  d->src_prot);
d->mapped_src = src_page;
}
diff->do_cpy(diff, d->dst_addr + dst_page_offset,
@@ -436,8 +428,10 @@ static int vmw_bo_cpu_blit_line(struct v
  *
  * Performs a CPU blit from one buffer object to another avoiding a full
  * bo vmap which may exhaust- or fragment vmalloc space.
- * On supported architectures (x86), we're using kmap_atomic which avoids
- * cross-processor TLB- and cache flushes and may, on non-HIGHMEM systems
+ *
+ * On supported architectures (x86), we're using kmap_local_prot() which
+ * avoids cross-processor TLB- and cache flushes. kmap_local_prot() will
+ * either map a highmem page with the proper pgprot on HIGHMEM=y systems or
  * reference already set-up mappings.
  *
  * Neither of the buffer objects may be placed in PCI memory
@@ -500,9 +494,9 @@ int vmw_bo_cpu_blit(struct ttm_buffer_ob
}
 out:
if (d.src_addr)
-   kunmap_atomic(d.src_addr);
+   kunmap_local(d.src_addr);
if (d.dst_addr)
-   kunmap_atomic(d.dst_addr);
+   kunmap_local(d.dst_addr);
 
return ret;
 }


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

Re: cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver

[Joerg Roedel]

On Mon, Mar 01, 2021 at 09:42:40AM +0100, Christoph Hellwig wrote:
> Diffstat:
>  arch/powerpc/include/asm/fsl_pamu_stash.h   |   12 
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c |2 
>  drivers/iommu/amd/iommu.c   |   23 
>  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |   85 ---
>  drivers/iommu/arm/arm-smmu/arm-smmu.c   |  122 +---
>  drivers/iommu/dma-iommu.c   |8 
>  drivers/iommu/fsl_pamu.c|  264 --
>  drivers/iommu/fsl_pamu.h|   10 
>  drivers/iommu/fsl_pamu_domain.c |  694 
> ++--
>  drivers/iommu/fsl_pamu_domain.h |   46 -
>  drivers/iommu/intel/iommu.c |   55 --
>  drivers/iommu/iommu.c   |   75 ---
>  drivers/soc/fsl/qbman/qman_portal.c |   56 --
>  drivers/vfio/vfio_iommu_type1.c |   31 -
>  drivers/vhost/vdpa.c|   10 
>  include/linux/iommu.h   |   81 ---
>  16 files changed, 214 insertions(+), 1360 deletions(-)

Nice cleanup, thanks. The fsl_pamu driver and interface has always been
a little bit of an alien compared to other IOMMU drivers. I am inclined
to merge this after -rc3 is out, given some reviews. Can you also please
add changelogs to the last three patches?

Thanks,

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

[patch 0/7] drm, highmem: Cleanup io/kmap_atomic*() usage

[Thomas Gleixner]

None of the DRM usage sites of temporary mappings requires the side
effects of io/kmap_atomic(), i.e. preemption and pagefault disable.

Replace them with the io/kmap_local() variants, simplify the
copy_to/from_user() error handling and remove the atomic variants.

Thanks,

tglx
---
 Documentation/driver-api/io-mapping.rst |   22 +++---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c  |7 +--
 drivers/gpu/drm/i915/i915_gem.c |   40 ++-
 drivers/gpu/drm/i915/selftests/i915_gem.c   |4 -
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c   |8 +--
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/fbmem.h |8 +--
 drivers/gpu/drm/qxl/qxl_image.c |   18 
 drivers/gpu/drm/qxl/qxl_ioctl.c |   27 ++--
 drivers/gpu/drm/qxl/qxl_object.c|   12 ++---
 drivers/gpu/drm/qxl/qxl_object.h|4 -
 drivers/gpu/drm/qxl/qxl_release.c   |4 -
 drivers/gpu/drm/ttm/ttm_bo_util.c   |   20 +
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c|   30 +-
 include/linux/highmem-internal.h|   14 --
 include/linux/io-mapping.h  |   42 
 15 files changed, 93 insertions(+), 167 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch 5/7] drm/nouveau/device: Replace io_mapping_map_atomic_wc()

[Thomas Gleixner]

From: Thomas Gleixner 

Neither fbmem_peek() nor fbmem_poke() require to disable pagefaults and
preemption as a side effect of io_mapping_map_atomic_wc().

Use io_mapping_map_local_wc() instead.

Signed-off-by: Thomas Gleixner 
Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/fbmem.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/fbmem.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/fbmem.h
@@ -60,19 +60,19 @@ fbmem_fini(struct io_mapping *fb)
 static inline u32
 fbmem_peek(struct io_mapping *fb, u32 off)
 {
-   u8 __iomem *p = io_mapping_map_atomic_wc(fb, off & PAGE_MASK);
+   u8 __iomem *p = io_mapping_map_local_wc(fb, off & PAGE_MASK);
u32 val = ioread32(p + (off & ~PAGE_MASK));
-   io_mapping_unmap_atomic(p);
+   io_mapping_unmap_local(p);
return val;
 }
 
 static inline void
 fbmem_poke(struct io_mapping *fb, u32 off, u32 val)
 {
-   u8 __iomem *p = io_mapping_map_atomic_wc(fb, off & PAGE_MASK);
+   u8 __iomem *p = io_mapping_map_local_wc(fb, off & PAGE_MASK);
iowrite32(val, p + (off & ~PAGE_MASK));
wmb();
-   io_mapping_unmap_atomic(p);
+   io_mapping_unmap_local(p);
 }
 
 static inline bool


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

Re: [PATCH] devfreq: Register devfreq as a cooling device

[Daniel Lezcano]

On 04/03/2021 16:06, Chanwoo Choi wrote:
> Hi Daniel,
> 
> As Lukasz's comment, actually some devfreq devices like memory bus
> might not affect the thermal critically. In the mainline,
> there are four types devfreq as following:
> 1. GPU
> 2. UFS Storage
> 3. DMC (Memory Controller)
> 4. Memory bus like AMBA AXI
> 
> I think that you can specify this devfreq device will be used
> for cooling device by editing the devfreq_dev_profile structure.

Thanks for the suggestion, it makes sense.

I will do the change following your example below.

  -- Daniel

> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index bf3047896e41..77966a17d03f 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -935,6 +935,13 @@ struct devfreq *devfreq_add_device(struct device *dev,
> 
>     mutex_unlock(&devfreq_list_lock);
> 
> +   if (devfreq->profile->is_cooling_device) {
> +   devfreq->cdev = devfreq_cooling_em_register(devfreq, NULL);
> +   if (IS_ERR(devfreq->cdev))
> +   dev_info(dev,
> +   "Failed to register devfreq cooling
> device\n");
> +   }
> +
>     return devfreq;
> 
>  err_init:
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 26ea0850be9b..26dc69f1047b 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -103,6 +103,7 @@ struct devfreq_dev_profile {
>     unsigned long initial_freq;
>     unsigned int polling_ms;
>     enum devfreq_timer timer;
> +   bool is_cooling_device;
> 
>     int (*target)(struct device *dev, unsigned long *freq, u32 flags);
>     int (*get_dev_status)(struct device *dev,
> 



-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: Fix typo issue

[zuoqilin1]

From: zuoqilin 

Change 'frequncy' to 'frequency'.

Signed-off-by: zuoqilin 
---
 drivers/video/fbdev/aty/atyfb_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/aty/atyfb_base.c 
b/drivers/video/fbdev/aty/atyfb_base.c
index e946903a..83b76d3 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3390,7 +3390,7 @@ static int init_from_bios(struct atyfb_par *par)
 
PRINTKI("Mach64 BIOS is located at %x, mapped at %x.\n", 
rom_addr, bios_base);
 
-   /* check for frequncy table */
+   /* check for frequency table */
bios_ptr = (u8*)bios_base;
rom_table_offset = (u16)(bios_ptr[0x48] | (bios_ptr[0x49] << 
8));
freq_table_offset = bios_ptr[rom_table_offset + 16] | 
(bios_ptr[rom_table_offset + 17] << 8);
-- 
1.9.1


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

[patch 3/7] highmem: Remove kmap_atomic_prot()

[Thomas Gleixner]

From: Thomas Gleixner 

No more users.

Signed-off-by: Thomas Gleixner 
Cc: Andrew Morton 
Cc: linux...@kvack.org
---
 include/linux/highmem-internal.h |   14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

--- a/include/linux/highmem-internal.h
+++ b/include/linux/highmem-internal.h
@@ -88,16 +88,11 @@ static inline void __kunmap_local(void *
kunmap_local_indexed(vaddr);
 }
 
-static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
+static inline void *kmap_atomic(struct page *page)
 {
preempt_disable();
pagefault_disable();
-   return __kmap_local_page_prot(page, prot);
-}
-
-static inline void *kmap_atomic(struct page *page)
-{
-   return kmap_atomic_prot(page, kmap_prot);
+   return __kmap_local_page_prot(page, kmap_prot);
 }
 
 static inline void *kmap_atomic_pfn(unsigned long pfn)
@@ -184,11 +179,6 @@ static inline void *kmap_atomic(struct p
return page_address(page);
 }
 
-static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
-{
-   return kmap_atomic(page);
-}
-
 static inline void *kmap_atomic_pfn(unsigned long pfn)
 {
return kmap_atomic(pfn_to_page(pfn));

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

[patch 7/7] io-mapping: Remove io_mapping_map_atomic_wc()

[Thomas Gleixner]

From: Thomas Gleixner 

No more users. Get rid of it and remove the traces in documentation.

Signed-off-by: Thomas Gleixner 
Cc: Andrew Morton 
Cc: linux...@kvack.org
---
 Documentation/driver-api/io-mapping.rst |   22 +---
 include/linux/io-mapping.h  |   42 +---
 2 files changed, 9 insertions(+), 55 deletions(-)

--- a/Documentation/driver-api/io-mapping.rst
+++ b/Documentation/driver-api/io-mapping.rst
@@ -21,19 +21,15 @@ mappable, while 'size' indicates how lar
 enable. Both are in bytes.
 
 This _wc variant provides a mapping which may only be used with
-io_mapping_map_atomic_wc(), io_mapping_map_local_wc() or
-io_mapping_map_wc().
+io_mapping_map_local_wc() or io_mapping_map_wc().
 
 With this mapping object, individual pages can be mapped either temporarily
 or long term, depending on the requirements. Of course, temporary maps are
-more efficient. They come in two flavours::
+more efficient.
 
void *io_mapping_map_local_wc(struct io_mapping *mapping,
  unsigned long offset)
 
-   void *io_mapping_map_atomic_wc(struct io_mapping *mapping,
-  unsigned long offset)
-
 'offset' is the offset within the defined mapping region.  Accessing
 addresses beyond the region specified in the creation function yields
 undefined results. Using an offset which is not page aligned yields an
@@ -50,9 +46,6 @@ io_mapping_map_local_wc() has a side eff
 migration to make the mapping code work. No caller can rely on this side
 effect.
 
-io_mapping_map_atomic_wc() has the side effect of disabling preemption and
-pagefaults. Don't use in new code. Use io_mapping_map_local_wc() instead.
-
 Nested mappings need to be undone in reverse order because the mapping
 code uses a stack for keeping track of them::
 
@@ -65,11 +58,10 @@ Nested mappings need to be undone in rev
 The mappings are released with::
 
void io_mapping_unmap_local(void *vaddr)
-   void io_mapping_unmap_atomic(void *vaddr)
 
-'vaddr' must be the value returned by the last io_mapping_map_local_wc() or
-io_mapping_map_atomic_wc() call. This unmaps the specified mapping and
-undoes the side effects of the mapping functions.
+'vaddr' must be the value returned by the last io_mapping_map_local_wc()
+call. This unmaps the specified mapping and undoes eventual side effects of
+the mapping function.
 
 If you need to sleep while holding a mapping, you can use the regular
 variant, although this may be significantly slower::
@@ -77,8 +69,8 @@ If you need to sleep while holding a map
void *io_mapping_map_wc(struct io_mapping *mapping,
unsigned long offset)
 
-This works like io_mapping_map_atomic/local_wc() except it has no side
-effects and the pointer is globaly visible.
+This works like io_mapping_map_local_wc() except it has no side effects and
+the pointer is globaly visible.
 
 The mappings are released with::
 
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -60,28 +60,7 @@ io_mapping_fini(struct io_mapping *mappi
iomap_free(mapping->base, mapping->size);
 }
 
-/* Atomic map/unmap */
-static inline void __iomem *
-io_mapping_map_atomic_wc(struct io_mapping *mapping,
-unsigned long offset)
-{
-   resource_size_t phys_addr;
-
-   BUG_ON(offset >= mapping->size);
-   phys_addr = mapping->base + offset;
-   preempt_disable();
-   pagefault_disable();
-   return __iomap_local_pfn_prot(PHYS_PFN(phys_addr), mapping->prot);
-}
-
-static inline void
-io_mapping_unmap_atomic(void __iomem *vaddr)
-{
-   kunmap_local_indexed((void __force *)vaddr);
-   pagefault_enable();
-   preempt_enable();
-}
-
+/* Temporary mappings which are only valid in the current context */
 static inline void __iomem *
 io_mapping_map_local_wc(struct io_mapping *mapping, unsigned long offset)
 {
@@ -163,24 +142,7 @@ io_mapping_unmap(void __iomem *vaddr)
 {
 }
 
-/* Atomic map/unmap */
-static inline void __iomem *
-io_mapping_map_atomic_wc(struct io_mapping *mapping,
-unsigned long offset)
-{
-   preempt_disable();
-   pagefault_disable();
-   return io_mapping_map_wc(mapping, offset, PAGE_SIZE);
-}
-
-static inline void
-io_mapping_unmap_atomic(void __iomem *vaddr)
-{
-   io_mapping_unmap(vaddr);
-   pagefault_enable();
-   preempt_enable();
-}
-
+/* Temporary mappings which are only valid in the current context */
 static inline void __iomem *
 io_mapping_map_local_wc(struct io_mapping *mapping, unsigned long offset)
 {

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

[PATCH] devfreq: Register devfreq as a cooling device

[Daniel Lezcano]

Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.

There are no so many and actually it makes more sense to register the
devfreq device when adding it.

Consequently, every devfreq becomes a cooling device like cpufreq is.

Having a devfreq being registered as a cooling device can not mitigate
a thermal zone if it is not bound to this one. Thus, the current
configurations are not impacted by this change.

Signed-off-by: Daniel Lezcano 
---
 drivers/devfreq/devfreq.c   |  8 
 drivers/gpu/drm/lima/lima_devfreq.c | 13 -
 drivers/gpu/drm/lima/lima_devfreq.h |  2 --
 drivers/gpu/drm/msm/msm_gpu.c   | 11 ---
 drivers/gpu/drm/msm/msm_gpu.h   |  2 --
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
 include/linux/devfreq.h |  3 +++
 7 files changed, 11 insertions(+), 41 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index b6d63f02d293..19149b31b000 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "governor.h"
 
@@ -935,6 +937,10 @@ struct devfreq *devfreq_add_device(struct device *dev,
 
mutex_unlock(&devfreq_list_lock);
 
+   devfreq->cdev = devfreq_cooling_em_register(devfreq, NULL);
+   if (IS_ERR(devfreq->cdev))
+   dev_info(dev, "Failed to register devfreq cooling device\n");
+
return devfreq;
 
 err_init:
@@ -960,6 +966,8 @@ int devfreq_remove_device(struct devfreq *devfreq)
if (!devfreq)
return -EINVAL;
 
+   thermal_cooling_device_unregister(devfreq->cdev);
+
if (devfreq->governor) {
devfreq->governor->event_handler(devfreq,
 DEVFREQ_GOV_STOP, NULL);
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c 
b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..a696eff1642c 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -7,7 +7,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -90,11 +89,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
 {
struct lima_devfreq *devfreq = &ldev->devfreq;
 
-   if (devfreq->cooling) {
-   devfreq_cooling_unregister(devfreq->cooling);
-   devfreq->cooling = NULL;
-   }
-
if (devfreq->devfreq) {
devm_devfreq_remove_device(ldev->dev, devfreq->devfreq);
devfreq->devfreq = NULL;
@@ -110,7 +104,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
 
 int lima_devfreq_init(struct lima_device *ldev)
 {
-   struct thermal_cooling_device *cooling;
struct device *dev = ldev->dev;
struct opp_table *opp_table;
struct devfreq *devfreq;
@@ -173,12 +166,6 @@ int lima_devfreq_init(struct lima_device *ldev)
 
ldevfreq->devfreq = devfreq;
 
-   cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
-   if (IS_ERR(cooling))
-   dev_info(dev, "Failed to register cooling device\n");
-   else
-   ldevfreq->cooling = cooling;
-
return 0;
 
 err_fini:
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h 
b/drivers/gpu/drm/lima/lima_devfreq.h
index 2d9b3008ce77..c43a2069e5d3 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -9,7 +9,6 @@
 
 struct devfreq;
 struct opp_table;
-struct thermal_cooling_device;
 
 struct lima_device;
 
@@ -17,7 +16,6 @@ struct lima_devfreq {
struct devfreq *devfreq;
struct opp_table *clkname_opp_table;
struct opp_table *regulators_opp_table;
-   struct thermal_cooling_device *cooling;
 
ktime_t busy_time;
ktime_t idle_time;
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ab7c167b0623..d7f80ebfe9df 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -112,14 +111,6 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
}
 
devfreq_suspend_device(gpu->devfreq.devfreq);
-
-   gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
-   gpu->devfreq.devfreq);
-   if (IS_ERR(gpu->cooling)) {
-   DRM_DEV_ERROR(&gpu->pdev->dev,
-   "Couldn't register GPU cooling device\n");
-   gpu->cooling = NULL;
-   }
 }
 
 static int enable_pwrrail(struct msm_gpu *gpu)
@@ -1056,6 +1047,4 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
if (gpu->worker) {
kthread_destroy_worker(gpu->worker);
}
-
-   devfreq_cooling_unregister(gpu->cooling)

[patch 1/7] drm/ttm: Replace kmap_atomic() usage

[Thomas Gleixner]

From: Thomas Gleixner 

There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().

Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.

Remove the NULL pointer check for the map. These functions return a valid
address for valid pages and the return was bogus anyway as it would have
left preemption and pagefaults disabled.

Signed-off-by: Thomas Gleixner 
Cc: Christian Koenig 
Cc: Huang Rui 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/ttm/ttm_bo_util.c |   20 
 1 file changed, 12 insertions(+), 8 deletions(-)

--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -181,13 +181,15 @@ static int ttm_copy_io_ttm_page(struct t
return -ENOMEM;
 
src = (void *)((unsigned long)src + (page << PAGE_SHIFT));
-   dst = kmap_atomic_prot(d, prot);
-   if (!dst)
-   return -ENOMEM;
+   /*
+* Ensure that a highmem page is mapped with the correct
+* pgprot. For non highmem the mapping is already there.
+*/
+   dst = kmap_local_page_prot(d, prot);
 
memcpy_fromio(dst, src, PAGE_SIZE);
 
-   kunmap_atomic(dst);
+   kunmap_local(dst);
 
return 0;
 }
@@ -203,13 +205,15 @@ static int ttm_copy_ttm_io_page(struct t
return -ENOMEM;
 
dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));
-   src = kmap_atomic_prot(s, prot);
-   if (!src)
-   return -ENOMEM;
+   /*
+* Ensure that a highmem page is mapped with the correct
+* pgprot. For non highmem the mapping is already there.
+*/
+   src = kmap_local_page_prot(s, prot);
 
memcpy_toio(dst, src, PAGE_SIZE);
 
-   kunmap_atomic(src);
+   kunmap_local(src);
 
return 0;
 }


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

[PATCH] gpu: drm: swsmu: fix error return code of smu_v11_0_set_allowed_mask()

[Jia-Ju Bai]

When bitmap_empty() or feature->feature_num triggers an error, 
no error return code of smu_v11_0_set_allowed_mask() is assigned.
To fix this bug, ret is assigned with -EINVAL as error return code.

Reported-by: TOTE Robot 
Signed-off-by: Jia-Ju Bai 
---
 drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
index 90585461a56e..82731a932308 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
@@ -747,8 +747,10 @@ int smu_v11_0_set_allowed_mask(struct smu_context *smu)
int ret = 0;
uint32_t feature_mask[2];
 
-   if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) || 
feature->feature_num < 64)
+   if (bitmap_empty(feature->allowed, SMU_FEATURE_MAX) || 
feature->feature_num < 64) {
+   ret = -EINVAL;
goto failed;
+   }
 
bitmap_copy((unsigned long *)feature_mask, feature->allowed, 64);
 
-- 
2.17.1

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

Re: [PATCH] devfreq: Register devfreq as a cooling device

[Daniel Lezcano]

Hi Lukasz,

thanks for commenting this patch,

On 04/03/2021 14:47, Lukasz Luba wrote:
> Hi Daniel,
> 
> On 3/4/21 12:50 PM, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling device.
>>
>> There are no so many and actually it makes more sense to register the
>> devfreq device when adding it.
>>
>> Consequently, every devfreq becomes a cooling device like cpufreq is.
>>
>> Having a devfreq being registered as a cooling device can not mitigate
>> a thermal zone if it is not bound to this one. Thus, the current
>> configurations are not impacted by this change.
> 
> There are also different type of devices, which register into devfreq
> framework like NoC buses, UFS/eMMC, jpeg and video accelerators, ISP,
> etc.
> In some platforms there are plenty of those devices and they all would
> occupy memory due to private freq_table in devfreq_cooling, function:
> devfreq_cooling_gen_tables().
> 
> IIRC in OdroidXU4 there are ~20 devfreq devs for NoC buses.

I'm curious, do you have a pointer to such kernels having all those
devfreq ?

> It's true that they will not affect thermal zones, but unnecessarily,
> they all will show up in the /sys/class/thermal/ as
> thermal-devfreq-X
>
>
> IMO the devfreq shouldn't be tight with devfreq cooling thermal.

The energy model is tied with a cooling device initialization.

So if we want to do power limitation, the energy model must be
initialized with the device, thus the cooling device also.

That is the reason why I'm ending up with this change. Chanwoo
suggestion makes sense and that will allow to move the initialization to
devfreq which is more sane but it does not solve the initial problem
with the energy model.




-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch 6/7] drm/i915: Replace io_mapping_map_atomic_wc()

[Thomas Gleixner]

From: Thomas Gleixner 

None of these mapping requires the side effect of disabling pagefaults and
preemption.

Use io_mapping_map_local_wc() instead, and clean up gtt_user_read() and
gtt_user_write() to use a plain copy_from_user() as the local maps are not
disabling pagefaults.

Signed-off-by: Thomas Gleixner 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Chris Wilson 
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |7 +---
 drivers/gpu/drm/i915/i915_gem.c|   40 -
 drivers/gpu/drm/i915/selftests/i915_gem.c  |4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |8 ++---
 4 files changed, 22 insertions(+), 37 deletions(-)

--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1080,7 +1080,7 @@ static void reloc_cache_reset(struct rel
struct i915_ggtt *ggtt = cache_to_ggtt(cache);
 
intel_gt_flush_ggtt_writes(ggtt->vm.gt);
-   io_mapping_unmap_atomic((void __iomem *)vaddr);
+   io_mapping_unmap_local((void __iomem *)vaddr);
 
if (drm_mm_node_allocated(&cache->node)) {
ggtt->vm.clear_range(&ggtt->vm,
@@ -1146,7 +1146,7 @@ static void *reloc_iomap(struct drm_i915
 
if (cache->vaddr) {
intel_gt_flush_ggtt_writes(ggtt->vm.gt);
-   io_mapping_unmap_atomic((void __force __iomem *) 
unmask_page(cache->vaddr));
+   io_mapping_unmap_local((void __force __iomem *) 
unmask_page(cache->vaddr));
} else {
struct i915_vma *vma;
int err;
@@ -1194,8 +1194,7 @@ static void *reloc_iomap(struct drm_i915
offset += page << PAGE_SHIFT;
}
 
-   vaddr = (void __force *)io_mapping_map_atomic_wc(&ggtt->iomap,
-offset);
+   vaddr = (void __force *)io_mapping_map_local_wc(&ggtt->iomap, offset);
cache->page = page;
cache->vaddr = (unsigned long)vaddr;
 
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -253,22 +253,15 @@ gtt_user_read(struct io_mapping *mapping
  char __user *user_data, int length)
 {
void __iomem *vaddr;
-   unsigned long unwritten;
+   bool fail = false;
 
/* We can use the cpu mem copy function because this is X86. */
-   vaddr = io_mapping_map_atomic_wc(mapping, base);
-   unwritten = __copy_to_user_inatomic(user_data,
-   (void __force *)vaddr + offset,
-   length);
-   io_mapping_unmap_atomic(vaddr);
-   if (unwritten) {
-   vaddr = io_mapping_map_wc(mapping, base, PAGE_SIZE);
-   unwritten = copy_to_user(user_data,
-(void __force *)vaddr + offset,
-length);
-   io_mapping_unmap(vaddr);
-   }
-   return unwritten;
+   vaddr = io_mapping_map_local_wc(mapping, base);
+   if (copy_to_user(user_data, (void __force *)vaddr + offset, length))
+   fail = true;
+   io_mapping_unmap_local(vaddr);
+
+   return fail;
 }
 
 static int
@@ -437,21 +430,14 @@ ggtt_write(struct io_mapping *mapping,
   char __user *user_data, int length)
 {
void __iomem *vaddr;
-   unsigned long unwritten;
+   bool fail = false;
 
/* We can use the cpu mem copy function because this is X86. */
-   vaddr = io_mapping_map_atomic_wc(mapping, base);
-   unwritten = __copy_from_user_inatomic_nocache((void __force *)vaddr + 
offset,
- user_data, length);
-   io_mapping_unmap_atomic(vaddr);
-   if (unwritten) {
-   vaddr = io_mapping_map_wc(mapping, base, PAGE_SIZE);
-   unwritten = copy_from_user((void __force *)vaddr + offset,
-  user_data, length);
-   io_mapping_unmap(vaddr);
-   }
-
-   return unwritten;
+   vaddr = io_mapping_map_local_wc(mapping, base);
+   if (copy_from_user((void __force *)vaddr + offset, user_data, length))
+   fail = true;
+   io_mapping_unmap_local(vaddr);
+   return fail;
 }
 
 /**
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -58,12 +58,12 @@ static void trash_stolen(struct drm_i915
 
ggtt->vm.insert_page(&ggtt->vm, dma, slot, I915_CACHE_NONE, 0);
 
-   s = io_mapping_map_atomic_wc(&ggtt->iomap, slot);
+   s = io_mapping_map_local_wc(&ggtt->iomap, slot);
for (x = 0; x < PAGE_SIZE / sizeof(u32); x++) {
prng = next_pseudo_random32(prng);
io

[patch 4/7] drm/qxl: Replace io_mapping_map_atomic_wc()

[Thomas Gleixner]

From: Thomas Gleixner 

None of these mapping requires the side effect of disabling pagefaults and
preemption.

Use io_mapping_map_local_wc() instead, rename the related functions
accordingly and clean up qxl_process_single_command() to use a plain
copy_from_user() as the local maps are not disabling pagefaults.

Signed-off-by: Thomas Gleixner 
Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: Daniel Vetter 
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/qxl/qxl_image.c   |   18 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c   |   27 +--
 drivers/gpu/drm/qxl/qxl_object.c  |   12 ++--
 drivers/gpu/drm/qxl/qxl_object.h  |4 ++--
 drivers/gpu/drm/qxl/qxl_release.c |4 ++--
 5 files changed, 32 insertions(+), 33 deletions(-)

--- a/drivers/gpu/drm/qxl/qxl_image.c
+++ b/drivers/gpu/drm/qxl/qxl_image.c
@@ -124,12 +124,12 @@ qxl_image_init_helper(struct qxl_device
  wrong (check the bitmaps are sent correctly
  first) */
 
-   ptr = qxl_bo_kmap_atomic_page(qdev, chunk_bo, 0);
+   ptr = qxl_bo_kmap_local_page(qdev, chunk_bo, 0);
chunk = ptr;
chunk->data_size = height * chunk_stride;
chunk->prev_chunk = 0;
chunk->next_chunk = 0;
-   qxl_bo_kunmap_atomic_page(qdev, chunk_bo, ptr);
+   qxl_bo_kunmap_local_page(qdev, chunk_bo, ptr);
 
{
void *k_data, *i_data;
@@ -143,7 +143,7 @@ qxl_image_init_helper(struct qxl_device
i_data = (void *)data;
 
while (remain > 0) {
-   ptr = qxl_bo_kmap_atomic_page(qdev, chunk_bo, 
page << PAGE_SHIFT);
+   ptr = qxl_bo_kmap_local_page(qdev, chunk_bo, 
page << PAGE_SHIFT);
 
if (page == 0) {
chunk = ptr;
@@ -157,7 +157,7 @@ qxl_image_init_helper(struct qxl_device
 
memcpy(k_data, i_data, size);
 
-   qxl_bo_kunmap_atomic_page(qdev, chunk_bo, ptr);
+   qxl_bo_kunmap_local_page(qdev, chunk_bo, ptr);
i_data += size;
remain -= size;
page++;
@@ -175,10 +175,10 @@ qxl_image_init_helper(struct qxl_device
page_offset = 
offset_in_page(out_offset);
size = min((int)(PAGE_SIZE - 
page_offset), remain);
 
-   ptr = qxl_bo_kmap_atomic_page(qdev, 
chunk_bo, page_base);
+   ptr = qxl_bo_kmap_local_page(qdev, 
chunk_bo, page_base);
k_data = ptr + page_offset;
memcpy(k_data, i_data, size);
-   qxl_bo_kunmap_atomic_page(qdev, 
chunk_bo, ptr);
+   qxl_bo_kunmap_local_page(qdev, 
chunk_bo, ptr);
remain -= size;
i_data += size;
out_offset += size;
@@ -189,7 +189,7 @@ qxl_image_init_helper(struct qxl_device
qxl_bo_kunmap(chunk_bo);
 
image_bo = dimage->bo;
-   ptr = qxl_bo_kmap_atomic_page(qdev, image_bo, 0);
+   ptr = qxl_bo_kmap_local_page(qdev, image_bo, 0);
image = ptr;
 
image->descriptor.id = 0;
@@ -212,7 +212,7 @@ qxl_image_init_helper(struct qxl_device
break;
default:
DRM_ERROR("unsupported image bit depth\n");
-   qxl_bo_kunmap_atomic_page(qdev, image_bo, ptr);
+   qxl_bo_kunmap_local_page(qdev, image_bo, ptr);
return -EINVAL;
}
image->u.bitmap.flags = QXL_BITMAP_TOP_DOWN;
@@ -222,7 +222,7 @@ qxl_image_init_helper(struct qxl_device
image->u.bitmap.palette = 0;
image->u.bitmap.data = qxl_bo_physical_address(qdev, chunk_bo, 0);
 
-   qxl_bo_kunmap_atomic_page(qdev, image_bo, ptr);
+   qxl_bo_kunmap_local_page(qdev, image_bo, ptr);
 
return 0;
 }
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -89,11 +89,11 @@ apply_reloc(struct qxl_device *qdev, str
 {
void *reloc_page;
 
-   reloc_page = qxl_bo_kmap_atomic_page(qdev, info->dst_bo, 
info->dst_offset & PAGE_MASK);
+   reloc_page = qxl_bo_kmap_local_page(qdev, info->dst_bo, 
info->dst_offset & PAGE_MASK);
*(uint64_t *)(reloc_page + (info->dst_offset & ~PAGE_MASK)) = 
qxl_bo_physical_address(qdev,

  info->src_bo,

  info->src_o

Re: [PATCH] devfreq: Register devfreq as a cooling device

[Daniel Lezcano]

On 05/03/2021 09:12, Steven Price wrote:
> On 04/03/2021 12:50, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling device.
>>
>> There are no so many and actually it makes more sense to register the
>> devfreq device when adding it.
>>
>> Consequently, every devfreq becomes a cooling device like cpufreq is.
>>
>> Having a devfreq being registered as a cooling device can not mitigate
>> a thermal zone if it is not bound to this one. Thus, the current
>> configurations are not impacted by this change.
>>
>> Signed-off-by: Daniel Lezcano 
>> ---

[ ... ]

>>   if (pfdevfreq->opp_of_table_added) {
>>   dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
>>   pfdevfreq->opp_of_table_added = false;
> 
> You've removed all references to pfdevfreq->cooling, so please also
> remove the member from struct panfrost_devfreq (as already done with
> lima and msm).

Sure, thanks for spotting this.


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/2] dt-bindings: display: bridge: Add Chipone ICN6211 bindings

[Robert Foss]

Hey Jagan,

This looks good to me, feel free to add my r-b.

Reviewed-by: Robert Foss 

On Thu, 4 Mar 2021 at 10:21, Jagan Teki  wrote:
>
> ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone.
>
> It has a flexible configuration of MIPI DSI signal input and
> produces RGB565, RGB666, RGB888 output format.
>
> Add dt-bingings for it.
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v4:
> - fixed Laurent comments
> - added regulators
> - replace reset with EN
> - fixed warnings pointed by Robert
> Changes for v3:
> - updated to new dt-bindings style
>
>  .../display/bridge/chipone,icn6211.yaml   | 99 +++
>  MAINTAINERS   |  5 +
>  2 files changed, 104 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml 
> b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> new file mode 100644
> index ..62c3bd4cb28d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge
> +
> +maintainers:
> +  - Jagan Teki 
> +
> +description: |
> +  ICN6211 is MIPI-DSI to RGB Converter bridge from chipone.
> +
> +  It has a flexible configuration of MIPI DSI signal input and
> +  produce RGB565, RGB666, RGB888 output format.
> +
> +properties:
> +  compatible:
> +enum:
> +  - chipone,icn6211
> +
> +  reg:
> +maxItems: 1
> +description: virtual channel number of a DSI peripheral
> +
> +  enable-gpios:
> +description: Bridge EN pin, chip is reset when EN is low.
> +
> +  vdd1-supply:
> +description: A 1.8V/2.5V/3.3V supply that power the MIPI RX.
> +
> +  vdd2-supply:
> +description: A 1.8V/2.5V/3.3V supply that power the PLL.
> +
> +  vdd3-supply:
> +description: A 1.8V/2.5V/3.3V supply that power the RGB output.
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port for MIPI DSI input
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Video port for MIPI DPI output (panel or connector).
> +
> +required:
> +  - port@0
> +  - port@1
> +
> +required:
> +  - compatible
> +  - reg
> +  - enable-gpios
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +dsi {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  bridge@0 {
> +compatible = "chipone,icn6211";
> +reg = <0>;
> +enable-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> +reg = <0>;
> +
> +bridge_in_dsi: endpoint {
> +  remote-endpoint = <&dsi_out_bridge>;
> +};
> +  };
> +
> +  port@1 {
> +reg = <1>;
> +
> +bridge_out_panel: endpoint {
> +  remote-endpoint = <&panel_out_bridge>;
> +};
> +  };
> +};
> +  };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9d241b832aae..065cbdc889d3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5529,6 +5529,11 @@ S:   Maintained
>  F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
>  F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
>
> +DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTER BRIDGE
> +M: Jagan Teki 
> +S: Maintained
> +F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> +
>  DRM DRIVER FOR FARADAY TVE200 TV ENCODER
>  M: Linus Walleij 
>  S: Maintained
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridge

[Robert Foss]

Hey Jagan,

This patch also looks good to me.

Reviewed-by: Robert Foss 

On Thu, 4 Mar 2021 at 10:22, Jagan Teki  wrote:
>
> ICN6211 is MIPI-DSI to RGB Converter bridge from Chipone.
>
> It has a flexible configuration of MIPI DSI signal input and
> produce RGB565, RGB666, RGB888 output format.
>
> Add bridge driver for it.
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v4:
> - added regulators
> - replace reset with EN
> - fixed warnings pointed by Robert
> Changes for v3:
> - updated the driver to inline with new drm bridge style
>
>  MAINTAINERS  |   1 +
>  drivers/gpu/drm/bridge/Kconfig   |  13 +
>  drivers/gpu/drm/bridge/Makefile  |   1 +
>  drivers/gpu/drm/bridge/chipone-icn6211.c | 293 +++
>  4 files changed, 308 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/chipone-icn6211.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 065cbdc889d3..9c59402e51bc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5533,6 +5533,7 @@ DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB 
> CONVERTER BRIDGE
>  M: Jagan Teki 
>  S: Maintained
>  F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
> +F: drivers/gpu/drm/bridge/chipone-icn6211.c
>
>  DRM DRIVER FOR FARADAY TVE200 TV ENCODER
>  M: Linus Walleij 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e4110d6ca7b3..330ee70ed746 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -27,6 +27,19 @@ config DRM_CDNS_DSI
>   Support Cadence DPI to DSI bridge. This is an internal
>   bridge and is meant to be directly embedded in a SoC.
>
> +config DRM_CHIPONE_ICN6211
> +   tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
> +   depends on OF
> +   select DRM_MIPI_DSI
> +   select DRM_PANEL_BRIDGE
> +   help
> + ICN6211 is MIPI-DSI/RGB Converter bridge from chipone.
> +
> + It has a flexible configuration of MIPI DSI signal input
> + and produce RGB565, RGB666, RGB888 output format.
> +
> + If in doubt, say "N".
> +
>  config DRM_CHRONTEL_CH7033
> tristate "Chrontel CH7033 Video Encoder"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 86e7acc76f8d..3eb84b638988 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> +obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
>  obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>  obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
>  obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c 
> b/drivers/gpu/drm/bridge/chipone-icn6211.c
> new file mode 100644
> index ..a6151db95586
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
> @@ -0,0 +1,293 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Amarula Solutions(India)
> + * Author: Jagan Teki 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define HACTIVE_LI 0x20
> +#define VACTIVE_LI 0x21
> +#define VACTIVE_HACTIVE_HI 0x22
> +#define HFP_LI 0x23
> +#define HSYNC_LI   0x24
> +#define HBP_LI 0x25
> +#define HFP_HSW_HBP_HI 0x26
> +#define VFP0x27
> +#define VSYNC  0x28
> +#define VBP0x29
> +
> +struct chipone {
> +   struct device *dev;
> +   struct drm_bridge bridge;
> +   struct drm_bridge *panel_bridge;
> +   struct gpio_desc *enable_gpio;
> +   struct regulator *vdd1;
> +   struct regulator *vdd2;
> +   struct regulator *vdd3;
> +};
> +
> +static inline struct chipone *bridge_to_chipone(struct drm_bridge *bridge)
> +{
> +   return container_of(bridge, struct chipone, bridge);
> +}
> +
> +static struct drm_display_mode *bridge_to_mode(struct drm_bridge *bridge)
> +{
> +   return &bridge->encoder->crtc->state->adjusted_mode;
> +}
> +
> +static inline int chipone_dsi_write(struct chipone *icn,  const void *seq,
> +   size_t len)
> +{
> +   struct mipi_dsi_device *dsi = to_mipi_dsi_device(icn->dev);
> +
> +   return mipi_dsi_generic_write(dsi, seq, len);
> +}
> +
> +#define ICN6211_DSI(icn, seq...)   \
> +   {   \
> +   const u8 d[] = { seq }; \
> +   chipone_dsi_write(icn, d, ARRAY_SIZE(d));   \
> +   }
> +
> +static void chipone_enable(struct drm_bridge *bridge)
> +{
> +   struct chipone *icn = bridge_to_chipone(bridge);
> +   struct drm_display

Re: [PATCH] qxl: Fix uninitialised struct field head.surface_id

[Gerd Hoffmann]

On Thu, Mar 04, 2021 at 09:49:28AM +, Colin King wrote:
> From: Colin Ian King 
> 
> The surface_id struct field in head is not being initialized and
> static analysis warns that this is being passed through to
> dev->monitors_config->heads[i] on an assignment. Clear up this
> warning by initializing it to zero.
> 
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: a6d3c4d79822 ("qxl: hook monitors_config updates into crtc, not 
> encoder.")
> Signed-off-by: Colin Ian King 

Pushed to drm-misc-fixes.

thanks,
  Gerd

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

[PATCH RESEND][next] drm/i915/gem: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a return statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index c2dba1cd9532..2a14a5c94a8a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -60,6 +60,7 @@ static void try_to_writeback(struct drm_i915_gem_object *obj,
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
i915_gem_object_truncate(obj);
+   return;
case __I915_MADV_PURGED:
return;
}
-- 
2.27.0

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

[PATCH RESEND][next] drm/nouveau/clk: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
index 83067763c0ec..e1d31c62f9ec 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c
@@ -313,6 +313,7 @@ nv50_clk_read(struct nvkm_clk *base, enum nv_clk_src src)
default:
break;
}
+   break;
default:
break;
}
-- 
2.27.0

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

[PATCH RESEND][next] drm/nouveau: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple
of warnings by explicitly adding a couple of break statements instead
of letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c| 1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 2375711877cf..62903c3b368d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -443,6 +443,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain, 
bool contig)
break;
case TTM_PL_TT:
error |= !(domain & NOUVEAU_GEM_DOMAIN_GART);
+   break;
default:
break;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 61e6d7412505..eb844cdcaec2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -157,6 +157,7 @@ nouveau_conn_atomic_set_property(struct drm_connector 
*connector,
default:
break;
}
+   break;
case DRM_MODE_SCALE_FULLSCREEN:
case DRM_MODE_SCALE_CENTER:
case DRM_MODE_SCALE_ASPECT:
-- 
2.27.0

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

[PATCH RESEND][next] drm/nouveau/therm: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
index 2b031d4eaeb6..684aff7437ee 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c
@@ -41,6 +41,7 @@ pwm_info(struct nvkm_therm *therm, int line)
default:
break;
}
+   break;
default:
break;
}
-- 
2.27.0

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

Re: [PATCH v8 1/5] drm: Add a sharable drm page-pool implementation

[Christian König]

Am 05.03.21 um 00:20 schrieb John Stultz:

This adds a shrinker controlled page pool, extracted
out of the ttm_pool logic, and abstracted out a bit
so it can be used by other non-ttm drivers.


In general please keep the kernel doc which is in TTMs pool.



Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v8:
* Completely rewritten from scratch, using only the
   ttm_pool logic so it can be dual licensed.
---
  drivers/gpu/drm/Kconfig |   4 +
  drivers/gpu/drm/Makefile|   2 +
  drivers/gpu/drm/page_pool.c | 214 
  include/drm/page_pool.h |  65 +++
  4 files changed, 285 insertions(+)
  create mode 100644 drivers/gpu/drm/page_pool.c
  create mode 100644 include/drm/page_pool.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e392a90ca687..7cbcecb8f7df 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -177,6 +177,10 @@ config DRM_DP_CEC
  Note: not all adapters support this feature, and even for those
  that do support this they often do not hook up the CEC pin.
  
+config DRM_PAGE_POOL

+   bool
+   depends on DRM
+
  config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 926adef289db..2dc7b2fe3fe5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -39,6 +39,8 @@ obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
  drm_ttm_helper-y := drm_gem_ttm_helper.o
  obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
  
+drm-$(CONFIG_DRM_PAGE_POOL) += page_pool.o

+
  drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o drm_dp_helper.o \
drm_dsc.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/page_pool.c b/drivers/gpu/drm/page_pool.c
new file mode 100644
index ..a60b954cfe0f
--- /dev/null
+++ b/drivers/gpu/drm/page_pool.c
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Sharable page pool implementation
+ *
+ * Extracted from drivers/gpu/drm/ttm/ttm_pool.c
+ * Copyright 2020 Advanced Micro Devices, Inc.
+ * Copyright 2021 Linaro Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Christian König, John Stultz
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static unsigned long page_pool_size;
+
+MODULE_PARM_DESC(page_pool_size, "Number of pages in the WC/UC/DMA pool");
+module_param(page_pool_size, ulong, 0644);
+
+static atomic_long_t allocated_pages;
+
+static struct mutex shrinker_lock;
+static struct list_head shrinker_list;
+static struct shrinker mm_shrinker;
+
+void drm_page_pool_set_max(unsigned long max)


This function and a whole bunch of other can be static.

And in general I'm not sure if we really need wrappers for functionality 
like this, e.g. it is only used once during startup IIRC.



+{
+   if (!page_pool_size)
+   page_pool_size = max;
+}
+
+unsigned long drm_page_pool_get_max(void)
+{
+   return page_pool_size;
+}
+
+unsigned long drm_page_pool_get_total(void)
+{
+   return atomic_long_read(&allocated_pages);
+}
+
+unsigned long drm_page_pool_get_size(struct drm_page_pool *pool)
+{
+   unsigned long size;
+
+   spin_lock(&pool->lock);
+   size = pool->page_count;
+   spin_unlock(&pool->lock);
+   return size;
+}
+
+/* Give pages into a specific pool */
+void drm_page_pool_add(struct drm_page_pool *pool, struct page *p)
+{
+   unsigned int i, num_pages = 1 << pool->order;
+
+   for (i = 0; i <

Re: [Freedreno] [PATCH 16/17] iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFG

[Will Deacon]

On Thu, Mar 04, 2021 at 03:11:08PM -0800, Rob Clark wrote:
> On Thu, Mar 4, 2021 at 7:48 AM Robin Murphy  wrote:
> >
> > On 2021-03-01 08:42, Christoph Hellwig wrote:
> > > Signed-off-by: Christoph Hellwig 
> >
> > Moreso than the previous patch, where the feature is at least relatively
> > generic (note that there's a bunch of in-flight development around
> > DOMAIN_ATTR_NESTING), I'm really not convinced that it's beneficial to
> > bloat the generic iommu_ops structure with private driver-specific
> > interfaces. The attribute interface is a great compromise for these
> > kinds of things, and you can easily add type-checked wrappers around it
> > for external callers (maybe even make the actual attributes internal
> > between the IOMMU core and drivers) if that's your concern.
> 
> I suppose if this is *just* for the GPU we could move it into 
> adreno_smmu_priv..
> 
> But one thing I'm not sure about is whether
> IO_PGTABLE_QUIRK_ARM_OUTER_WBWA is something that other devices
> *should* be using as well, but just haven't gotten around to yet.

The intention is certainly that this would be a place to collate per-domain
pgtable quirks, so I'd prefer not to tie that to the GPU.

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

Re: [PATCH 1/3] drm/bridge: ti-sn65dsi86: Simplify refclk handling

[Robert Foss]

Hey Douglas,

Thanks for submitting this cleanup, it looks good to me.

Reviewed-by: Robert Foss 


On Fri, 5 Mar 2021 at 00:53, Douglas Anderson  wrote:
>
> The clock framework makes it simple to deal with an optional clock.
> You can call clk_get_optional() and if the clock isn't specified it'll
> just return NULL without complaint. It's valid to pass NULL to
> enable/disable/prepare/unprepare. Let's make use of this to simplify
> things a tiny bit.
>
> NOTE: this makes things look a tad bit asymmetric now since we check
> for NULL before clk_prepare_enable() but not for
> clk_disable_unprepare(). This seemed OK to me. We already have to
> check for NULL in the enable case anyway so why not avoid the extra
> call?

I think this is fine. Since the refclk != NULL check in
ti_sn_bridge_set_refclk_freq is in order to determine other behaviour,
the asymmetry is required.

>
> Signed-off-by: Douglas Anderson 
> ---
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index f27306c51e4d..942019842ff4 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -1261,14 +1261,9 @@ static int ti_sn_bridge_probe(struct i2c_client 
> *client,
> return ret;
> }
>
> -   pdata->refclk = devm_clk_get(pdata->dev, "refclk");
> -   if (IS_ERR(pdata->refclk)) {
> -   ret = PTR_ERR(pdata->refclk);
> -   if (ret == -EPROBE_DEFER)
> -   return ret;
> -   DRM_DEBUG_KMS("refclk not found\n");
> -   pdata->refclk = NULL;
> -   }
> +   pdata->refclk = devm_clk_get_optional(pdata->dev, "refclk");
> +   if (IS_ERR(pdata->refclk))
> +   return PTR_ERR(pdata->refclk);
>
> ret = ti_sn_bridge_parse_dsi_host(pdata);
> if (ret)
> --
> 2.30.1.766.gb4fecdf3b7-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/bridge: ti-sn65dsi86: Move code in prep for EDID read fix

[Robert Foss]

Hey Douglas,

Thanks for splitting this out into its own patch.

Reviewed-by: Robert Foss 

On Fri, 5 Mar 2021 at 00:53, Douglas Anderson  wrote:
>
> This patch is _only_ code motion to prepare for the patch
> ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if
> refclk") and make it easier to understand.
>
> Signed-off-by: Douglas Anderson 
> ---
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 196 +-
>  1 file changed, 98 insertions(+), 98 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 942019842ff4..491c9c4f32d1 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -345,6 +345,104 @@ static int ti_sn_bridge_parse_regulators(struct 
> ti_sn_bridge *pdata)
>pdata->supplies);
>  }
>
> +static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata)
> +{
> +   u32 bit_rate_khz, clk_freq_khz;
> +   struct drm_display_mode *mode =
> +   &pdata->bridge.encoder->crtc->state->adjusted_mode;
> +
> +   bit_rate_khz = mode->clock *
> +   mipi_dsi_pixel_format_to_bpp(pdata->dsi->format);
> +   clk_freq_khz = bit_rate_khz / (pdata->dsi->lanes * 2);
> +
> +   return clk_freq_khz;
> +}
> +
> +/* clk frequencies supported by bridge in Hz in case derived from REFCLK pin 
> */
> +static const u32 ti_sn_bridge_refclk_lut[] = {
> +   1200,
> +   1920,
> +   2600,
> +   2700,
> +   3840,
> +};
> +
> +/* clk frequencies supported by bridge in Hz in case derived from DACP/N pin 
> */
> +static const u32 ti_sn_bridge_dsiclk_lut[] = {
> +   46800,
> +   38400,
> +   41600,
> +   48600,
> +   46080,
> +};
> +
> +static void ti_sn_bridge_set_refclk_freq(struct ti_sn_bridge *pdata)
> +{
> +   int i;
> +   u32 refclk_rate;
> +   const u32 *refclk_lut;
> +   size_t refclk_lut_size;
> +
> +   if (pdata->refclk) {
> +   refclk_rate = clk_get_rate(pdata->refclk);
> +   refclk_lut = ti_sn_bridge_refclk_lut;
> +   refclk_lut_size = ARRAY_SIZE(ti_sn_bridge_refclk_lut);
> +   clk_prepare_enable(pdata->refclk);
> +   } else {
> +   refclk_rate = ti_sn_bridge_get_dsi_freq(pdata) * 1000;
> +   refclk_lut = ti_sn_bridge_dsiclk_lut;
> +   refclk_lut_size = ARRAY_SIZE(ti_sn_bridge_dsiclk_lut);
> +   }
> +
> +   /* for i equals to refclk_lut_size means default frequency */
> +   for (i = 0; i < refclk_lut_size; i++)
> +   if (refclk_lut[i] == refclk_rate)
> +   break;
> +
> +   regmap_update_bits(pdata->regmap, SN_DPPLL_SRC_REG, REFCLK_FREQ_MASK,
> +  REFCLK_FREQ(i));
> +}
> +
> +static void ti_sn_bridge_post_disable(struct drm_bridge *bridge)
> +{
> +   struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> +   clk_disable_unprepare(pdata->refclk);
> +
> +   pm_runtime_put_sync(pdata->dev);
> +}
> +
> +static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> +   struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> +   pm_runtime_get_sync(pdata->dev);
> +
> +   /* configure bridge ref_clk */
> +   ti_sn_bridge_set_refclk_freq(pdata);
> +
> +   /*
> +* HPD on this bridge chip is a bit useless.  This is an eDP bridge
> +* so the HPD is an internal signal that's only there to signal that
> +* the panel is done powering up.  ...but the bridge chip debounces
> +* this signal by between 100 ms and 400 ms (depending on process,
> +* voltage, and temperate--I measured it at about 200 ms).  One
> +* particular panel asserted HPD 84 ms after it was powered on meaning
> +* that we saw HPD 284 ms after power on.  ...but the same panel said
> +* that instead of looking at HPD you could just hardcode a delay of
> +* 200 ms.  We'll assume that the panel driver will have the hardcoded
> +* delay in its prepare and always disable HPD.
> +*
> +* If HPD somehow makes sense on some future panel we'll have to
> +* change this to be conditional on someone specifying that HPD should
> +* be used.
> +*/
> +   regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, HPD_DISABLE,
> +  HPD_DISABLE);
> +
> +   drm_panel_prepare(pdata->panel);
> +}
> +
>  static int ti_sn_bridge_attach(struct drm_bridge *bridge,
>enum drm_bridge_attach_flags flags)
>  {
> @@ -443,64 +541,6 @@ static void ti_sn_bridge_disable(struct drm_bridge 
> *bridge)
> drm_panel_unprepare(pdata->panel);
>  }
>
> -static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata)
> -{
> -   u32 bit_rate_khz, clk_freq_khz;
> -   struct drm_display_mod

Re: [PATCH 0/2] Fix purging buffers in the shmem helpers

[Steven Price]

On 23/02/2021 15:51, Neil Roberts wrote:

These two patches fix a problem with the madvise purging code for the
shmem helpers where the mmaping for a purged buffer wouldn't get
invalidated correctly. This presumably ends up as a security hole
where the mapping can be accessed from user-space to read and write
random pages from other buffers. This is currently affecting Panfrost.
The second patch is a v2 from a patch that was sent standalone.

There is a WIP IGT test for Panfrost which demonstrates the bug here:

https://gitlab.freedesktop.org/nroberts/igt-gpu-tools/-/commits/panfrost-purgemap/

Neil Roberts (2):
   drm/shmem-helper: Check for purged buffers in fault handler
   drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff

  drivers/gpu/drm/drm_gem_shmem_helper.c | 25 ++---
  1 file changed, 18 insertions(+), 7 deletions(-)



Pushed to drm-misc-fixes

Thanks,

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

Re: [PATCH 1/3] drm/msm: Fix speed-bin support not to access outside valid memory

[Srinivas Kandagatla]

On 27/02/2021 00:26, Douglas Anderson wrote:

When running the latest kernel on an sc7180 with KASAN I got this
splat:
   BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644
   Read of size 4 at addr ff8088f36100 by task kworker/7:1/58
   CPU: 7 PID: 58 Comm: kworker/7:1 Not tainted 5.11.0+ #3
   Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
   Workqueue: events deferred_probe_work_func
   Call trace:
dump_backtrace+0x0/0x3a8
show_stack+0x24/0x30
dump_stack+0x174/0x1e0
print_address_description+0x70/0x2e4
kasan_report+0x178/0x1bc
__asan_report_load4_noabort+0x44/0x50
a6xx_gpu_init+0x618/0x644
adreno_bind+0x26c/0x438

This is because the speed bin is defined like this:
   gpu_speed_bin: gpu_speed_bin@1d2 {
 reg = <0x1d2 0x2>;
 bits = <5 8>;
   };

As you can see the "length" is 2 bytes. That means that the nvmem
subsystem allocates only 2 bytes. The GPU code, however, was casting
the pointer allocated by nvmem to a (u32 *) and dereferencing. That's
not so good.

Let's fix this to just use the nvmem_cell_read_u16() accessor function
which simplifies things and also gets rid of the splat.

Let's also put an explicit conversion from little endian in place just
to make things clear. The nvmem subsystem today is assuming little
endian and this makes it clear. Specifically, the way the above sc7180
cell is interpreted:

NVMEM:
  ++++++
  | .. | 0x1d3  | 0x1d2  | .. | 0x000  |
  ++++++
   ^   ^
  msb lsb

You can see that the least significant data is at the lower address
which is little endian.

NOTE: someone who is truly paying attention might wonder about me
picking the "u16" version of this accessor instead of the "u8" (since
the value is 8 bits big) or the u32 version (just for fun). At the
moment you need to pick the accessor that exactly matches the length
the cell was specified as in the device tree. Hopefully future
patches to the nvmem subsystem will fix this.

Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
Signed-off-by: Douglas Anderson 
---

  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
  1 file changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..0e2024defd79 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1350,35 +1350,20 @@ static int a6xx_set_supported_hw(struct device *dev, 
struct a6xx_gpu *a6xx_gpu,
u32 revn)
  {
struct opp_table *opp_table;
-   struct nvmem_cell *cell;
u32 supp_hw = UINT_MAX;
-   void *buf;
-
-   cell = nvmem_cell_get(dev, "speed_bin");
-   /*
-* -ENOENT means that the platform doesn't support speedbin which is
-* fine
-*/
-   if (PTR_ERR(cell) == -ENOENT)
-   return 0;
-   else if (IS_ERR(cell)) {
-   DRM_DEV_ERROR(dev,
-   "failed to read speed-bin. Some OPPs may not be 
supported by hardware");
-   goto done;
-   }
+   u16 speedbin;
+   int ret;
  
-	buf = nvmem_cell_read(cell, NULL);


I think the issue here is not passing len pointer which should return 
how many bytes the cell is!


Then from there we can decide to do le16_to_cpu or le32_to_cpu or not!
This will also future proof the code to handle speed_bins of different 
sizes!


--srini


-   if (IS_ERR(buf)) {
-   nvmem_cell_put(cell);



+   ret = nvmem_cell_read_u16(dev, "speed_bin", &speedbin);
+   if (ret) {
DRM_DEV_ERROR(dev,
-   "failed to read speed-bin. Some OPPs may not be 
supported by hardware");
+ "failed to read speed-bin (%d). Some OPPs may not be 
supported by hardware",
+ ret);
goto done;
}
+   speedbin = le16_to_cpu(speedbin);
  
-	supp_hw = fuse_to_supp_hw(dev, revn, *((u32 *) buf));

-
-   kfree(buf);
-   nvmem_cell_put(cell);
+   supp_hw = fuse_to_supp_hw(dev, revn, speedbin);
  
  done:

opp_table = dev_pm_opp_set_supported_hw(dev, &supp_hw, 1);


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

Re: [PATCH v8 2/5] drm: ttm_pool: Rework ttm_pool to use drm_page_pool

[Christian König]

Am 05.03.21 um 00:20 schrieb John Stultz:

This patch reworks the ttm_pool logic to utilize the recently
added drm_page_pool code.

This adds drm_page_pool structures to the ttm_pool_type
structures, and then removes all the ttm_pool_type shrinker
logic (as its handled in the drm_page_pool shrinker).

NOTE: There is one mismatch in the interfaces I'm not totally
happy with. The ttm_pool tracks all of its pooled pages across
a number of different pools, and tries to keep this size under
the specified page_pool_size value. With the drm_page_pool,
there may other users, however there is still one global
shrinker list of pools. So we can't easily reduce the ttm
pool under the ttm specified size without potentially doing
a lot of shrinking to other non-ttm pools. So either we can:
   1) Try to split it so each user of drm_page_pools manages its
  own pool shrinking.
   2) Push the max value into the drm_page_pool, and have it
  manage shrinking to fit under that global max. Then share
  those size/max values out so the ttm_pool debug output
  can have more context.

I've taken the second path in this patch set, but wanted to call
it out so folks could look closely.


That's perfectly fine with me. A global approach for the different page 
pool types is desired anyway as far as I can see.




Thoughts would be greatly appreciated here!

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v7:
* Major refactoring to use drm_page_pools inside the
   ttm_pool_type structure. This allows us to use container_of to
   get the needed context to free a page. This also means less
   code is changed overall.
v8:
* Reworked to use the new cleanly rewritten drm_page_pool logic
---
  drivers/gpu/drm/Kconfig|   1 +
  drivers/gpu/drm/ttm/ttm_pool.c | 156 ++---
  include/drm/ttm/ttm_pool.h |   6 +-
  3 files changed, 31 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7cbcecb8f7df..a6cbdb63f6c7 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -184,6 +184,7 @@ config DRM_PAGE_POOL
  config DRM_TTM
tristate
depends on DRM && MMU
+   select DRM_PAGE_POOL
help
  GPU memory management subsystem for devices with multiple
  GPU memory types. Will be enabled automatically if a device driver
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 6e27cb1bf48b..f74ea801d7ab 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -39,6 +39,7 @@
  #include 
  #endif
  
+#include 

  #include 
  #include 
  #include 
@@ -68,8 +69,6 @@ static struct ttm_pool_type 
global_dma32_write_combined[MAX_ORDER];
  static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
  
  static struct mutex shrinker_lock;

-static struct list_head shrinker_list;
-static struct shrinker mm_shrinker;
  
  /* Allocate pages of size 1 << order with the given gfp_flags */

  static struct page *ttm_pool_alloc_page(struct ttm_pool *pool, gfp_t 
gfp_flags,
@@ -125,8 +124,9 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool 
*pool, gfp_t gfp_flags,
  }
  
  /* Reset the caching and pages of size 1 << order */

-static void ttm_pool_free_page(struct ttm_pool *pool, enum ttm_caching caching,
-  unsigned int order, struct page *p)
+static unsigned long ttm_pool_free_page(struct ttm_pool *pool,
+   enum ttm_caching caching,
+   unsigned int order, struct page *p)
  {
unsigned long attr = DMA_ATTR_FORCE_CONTIGUOUS;
struct ttm_pool_dma *dma;
@@ -142,7 +142,7 @@ static void ttm_pool_free_page(struct ttm_pool *pool, enum 
ttm_caching caching,
  
  	if (!pool || !pool->use_dma_alloc) {

__free_pages(p, order);
-   return;
+   return 1UL << order;
}
  
  	if (order)

@@ -153,6 +153,16 @@ static void ttm_pool_free_page(struct ttm_pool *pool, enum 
ttm_caching caching,
dma_free_attrs(pool->dev, (1UL << order) * PAGE_SIZE, vaddr, dma->addr,
   attr);
kfree(dma);
+   return 1UL << order;


The returned value is always the same. So you wrapper can do this and we 
don't really need to change the function here.



+}
+
+static unsigned long ttm_subpool_free_page(struct drm_page_pool *subpool,
+  struct page *p)


Better call this ttm_pool_free_callback.


+{
+   struct ttm_pool_type *pt;
+
+   pt = container_of(subpool, struct ttm_pool_type, subpool);
+ 

Re: [PATCH v8 3/5] dma-buf: heaps: Add deferred-free-helper library code

[Christian König]

Am 05.03.21 um 00:20 schrieb John Stultz:

This patch provides infrastructure for deferring buffer frees.

This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/free path,
and pushed off to a kthread.


In general that's a nice idea, but to be honest this implementation 
looks broken and rather inefficient.


You should probably rather integrate that into the DRM pool core 
functionality which is currently clearing all freed pages anyway.


I would also use a work item per pool instead of a kthread, that would 
help with data locality.


Regards,
Christian.



As not all heaps will find this useful, its implemented as
a optional helper library that heaps can utilize.

Cc: Daniel Vetter 
Cc: Christian Koenig 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Chris Goldsworthy 
Cc: Laura Abbott 
Cc: Brian Starkey 
Cc: Hridya Valsaraju 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Daniel Mentz 
Cc: Ørjan Eide 
Cc: Robin Murphy 
Cc: Ezequiel Garcia 
Cc: Simon Ser 
Cc: James Jones 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
   to a spinlock as Reported-by: kernel test robot 
* Cleanup API to use a reason enum for clarity and add some documentation
   comments as suggested by Suren Baghdasaryan.
v3:
* Minor tweaks so it can be built as a module
* A few small fixups suggested by Daniel Mentz
v4:
* Tweak from Daniel Mentz to make sure the shrinker
   count/freed values are tracked in pages not bytes
v5:
* Fix up page count tracking as suggested by Suren Baghdasaryan
v7:
* Rework accounting to use nr_pages rather then size, as suggested
   by Suren Baghdasaryan
---
  drivers/dma-buf/heaps/Kconfig|   3 +
  drivers/dma-buf/heaps/Makefile   |   1 +
  drivers/dma-buf/heaps/deferred-free-helper.c | 138 +++
  drivers/dma-buf/heaps/deferred-free-helper.h |  55 
  4 files changed, 197 insertions(+)
  create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
  create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..f7aef8bc7119 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,3 +1,6 @@
+config DMABUF_HEAPS_DEFERRED_FREE
+   tristate
+
  config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..4e7839875615 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
  # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_DEFERRED_FREE) += deferred-free-helper.o
  obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
  obj-$(CONFIG_DMABUF_HEAPS_CMA)+= cma_heap.o
diff --git a/drivers/dma-buf/heaps/deferred-free-helper.c 
b/drivers/dma-buf/heaps/deferred-free-helper.c
new file mode 100644
index ..e19c8b68dfeb
--- /dev/null
+++ b/drivers/dma-buf/heaps/deferred-free-helper.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Deferred dmabuf freeing helper
+ *
+ * Copyright (C) 2020 Linaro, Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "deferred-free-helper.h"
+
+static LIST_HEAD(free_list);
+static size_t list_nr_pages;
+wait_queue_head_t freelist_waitqueue;
+struct task_struct *freelist_task;
+static DEFINE_SPINLOCK(free_list_lock);
+
+void deferred_free(struct deferred_freelist_item *item,
+  void (*free)(struct deferred_freelist_item*,
+   enum df_reason),
+  size_t nr_pages)
+{
+   unsigned long flags;
+
+   INIT_LIST_HEAD(&item->list);
+   item->nr_pages = nr_pages;
+   item->free = free;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   list_add(&item->list, &free_list);
+   list_nr_pages += nr_pages;
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   wake_up(&freelist_waitqueue);
+}
+EXPORT_SYMBOL_GPL(deferred_free);
+
+static size_t free_one_item(enum df_reason reason)
+{
+   unsigned long flags;
+   size_t nr_pages;
+   struct deferred_freelist_item *item;
+
+   spin_lock_irqsave(&free_list_lock, flags);
+   if (list_empty(&free_list)) {
+   spin_unlock_irqrestore(&free_list_lock, flags);
+   return 0;
+   }
+   item = list_first_entry(&free_list, struct deferred_freelist_item, 
list);
+   list_del(&item->list);
+   nr_pages = item->nr_pages;
+   list_nr_pages -= nr_pages;
+   spin_unlock_irqrestore(&free_list_lock, flags);
+
+   item->free(

[PATCH] dma-buf: Fix confusion of dynamic dma-buf vs dynamic attachment

[Chris Wilson]

Commit c545781e1c55 ("dma-buf: doc polish for pin/unpin") disagrees with
the introduction of dynamism in commit: bb42df4662a4 ("dma-buf: add
dynamic DMA-buf handling v15") resulting in warning spew on
importing dma-buf. Silence the warning from the latter by only pinning
the attachment if the attachment rather than the dmabuf is to be
dynamic.

Fixes: bb42df4662a4 ("dma-buf: add dynamic DMA-buf handling v15")
Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Christian König 
Cc:  # v5.7+
---
 drivers/dma-buf/dma-buf.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..09f5ae458515 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -758,8 +758,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
 
-   if (dma_buf_is_dynamic(attach->dmabuf)) {
-   dma_resv_lock(attach->dmabuf->resv, NULL);
+   if (dma_buf_attachment_is_dynamic(attach)) {
+   dma_resv_lock(dmabuf->resv, NULL);
ret = dma_buf_pin(attach);
if (ret)
goto err_unlock;
@@ -772,8 +772,9 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_unlock(attach->dmabuf->resv);
+   if (dma_buf_attachment_is_dynamic(attach))
+   dma_resv_unlock(dmabuf->resv);
+
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
-- 
2.20.1

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

Re: [PATCH] dma-buf: Fix confusion of dynamic dma-buf vs dynamic attachment

[Christian König]

Am 05.03.21 um 11:51 schrieb Chris Wilson:

Commit c545781e1c55 ("dma-buf: doc polish for pin/unpin") disagrees with
the introduction of dynamism in commit: bb42df4662a4 ("dma-buf: add
dynamic DMA-buf handling v15") resulting in warning spew on
importing dma-buf. Silence the warning from the latter by only pinning
the attachment if the attachment rather than the dmabuf is to be
dynamic.


NAK, this is intentionally like this. You need to pin the DMA-buf if it 
is dynamic and the attachment isn't.


Otherwise the DMA-buf would be able to move even when it has an 
attachment which can't handle that.


We should rather fix the documentation if that is wrong on this point.

Regards,
Christian.



Fixes: bb42df4662a4 ("dma-buf: add dynamic DMA-buf handling v15")
Fixes: c545781e1c55 ("dma-buf: doc polish for pin/unpin")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Christian König 
Cc:  # v5.7+
---
  drivers/dma-buf/dma-buf.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383e..09f5ae458515 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -758,8 +758,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
  
-		if (dma_buf_is_dynamic(attach->dmabuf)) {

-   dma_resv_lock(attach->dmabuf->resv, NULL);
+   if (dma_buf_attachment_is_dynamic(attach)) {
+   dma_resv_lock(dmabuf->resv, NULL);
ret = dma_buf_pin(attach);
if (ret)
goto err_unlock;
@@ -772,8 +772,9 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_unlock(attach->dmabuf->resv);
+   if (dma_buf_attachment_is_dynamic(attach))
+   dma_resv_unlock(dmabuf->resv);
+
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}


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

[PATCH i-g-t 0/2] panfrost: Test accessing a purged buffer via mmap

[Neil Roberts]

This adds a test for Panfrost to make sure that accessing a buffer
that has been madvised and then purged causes a bus fault. It is
intended to test the fix provided by this series:

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

The series has now been merged into drm-misc-fixes (thanks!)

In order to trigger the purge, the test just tries to allocate a bunch
of buffers until one of them causes the original buffer to be purged.
During the review of the kernel patch series, Daniel Vetter suggested
it would be better to use debugfs or vm_drop_caches file from proc.
However, I noticed that there are other tests that use the same method
as in this series (eg, igt_vc4_trigger_purge). Seeing as there is
already a precedent for IGT tests to do this, I wonder if we could
leave that as a later change for someone who is more active in
Panfrost development.

Neil Roberts (2):
  lib/panfrost: Add a utility to madvise a buffer
  tests/panfrost: Add a test for accessing a purged buffer

 lib/igt_panfrost.c|  12 
 lib/igt_panfrost.h|   1 +
 tests/meson.build |   1 +
 tests/panfrost_purgemap.c | 146 ++
 4 files changed, 160 insertions(+)
 create mode 100644 tests/panfrost_purgemap.c

-- 
2.29.2

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

[PATCH i-g-t 1/2] lib/panfrost: Add a utility to madvise a buffer

[Neil Roberts]

Signed-off-by: Neil Roberts 
---
 lib/igt_panfrost.c | 12 
 lib/igt_panfrost.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/lib/igt_panfrost.c b/lib/igt_panfrost.c
index 8b0c2b77..ffce66a2 100644
--- a/lib/igt_panfrost.c
+++ b/lib/igt_panfrost.c
@@ -127,6 +127,18 @@ void igt_panfrost_bo_mmap(int fd, struct panfrost_bo *bo)
 igt_assert(bo->map);
 }
 
+bool igt_panfrost_bo_madvise(int fd, struct panfrost_bo *bo, uint32_t madv)
+{
+struct drm_panfrost_madvise madvise = {
+.handle = bo->handle,
+.madv = madv,
+};
+
+do_ioctl(fd, DRM_IOCTL_PANFROST_MADVISE, &madvise);
+
+return madvise.retained;
+}
+
 struct panfrost_submit *igt_panfrost_trivial_job(int fd, bool do_crash, int 
width, int height, uint32_t color)
 {
 struct panfrost_submit *submit;
diff --git a/lib/igt_panfrost.h b/lib/igt_panfrost.h
index cc7998dc..df326a6c 100644
--- a/lib/igt_panfrost.h
+++ b/lib/igt_panfrost.h
@@ -56,5 +56,6 @@ uint32_t igt_panfrost_get_param(int fd, int param);
 void *igt_panfrost_mmap_bo(int fd, uint32_t handle, uint32_t size, unsigned 
prot);
 
 void igt_panfrost_bo_mmap(int fd, struct panfrost_bo *bo);
+bool igt_panfrost_bo_madvise(int fd, struct panfrost_bo *bo, uint32_t madv);
 
 #endif /* IGT_PANFROST_H */
-- 
2.29.2

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

[PATCH i-g-t 2/2] tests/panfrost: Add a test for accessing a purged buffer

[Neil Roberts]

The test creates a buffer, sets it as DONTNEED via madvise, tries to
trigger a purge of buffers and then accesses the buffer via a user-space
mapping. This should generate a bus error, but due to a bug in the
kernel driver it fails to invalidate the mapping when the buffer is
purged.

Signed-off-by: Neil Roberts 
---
 tests/meson.build |   1 +
 tests/panfrost_purgemap.c | 146 ++
 2 files changed, 147 insertions(+)
 create mode 100644 tests/panfrost_purgemap.c

diff --git a/tests/meson.build b/tests/meson.build
index 825e0183..af24427a 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -82,6 +82,7 @@ test_progs = [
'panfrost_get_param',
'panfrost_gem_new',
'panfrost_prime',
+   'panfrost_purgemap',
'panfrost_submit',
'prime_busy',
'prime_mmap',
diff --git a/tests/panfrost_purgemap.c b/tests/panfrost_purgemap.c
new file mode 100644
index ..096fb95a
--- /dev/null
+++ b/tests/panfrost_purgemap.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright © 2021 Igalia
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "igt_panfrost.h"
+#include "igt_syncobj.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "panfrost-job.h"
+#include "panfrost_drm.h"
+
+IGT_TEST_DESCRIPTION("Checks that accessing an mmapping of a buffer that has "
+"been purged causes a bus fault signal.");
+
+#define BUF_SIZE (32 * 1024 * 1024)
+
+struct buf_link {
+   struct panfrost_bo *bo;
+   struct buf_link *next;
+};
+
+static jmp_buf jmp;
+
+__noreturn static void sigtrap(int sig)
+{
+   siglongjmp(jmp, sig);
+}
+
+static void
+try_writing_to_mmap(uint8_t *ptr)
+{
+   sighandler_t old_sigsegv, old_sigbus;
+
+   old_sigsegv = signal(SIGSEGV, sigtrap);
+   old_sigbus = signal(SIGBUS, sigtrap);
+
+   switch (sigsetjmp(jmp, SIGBUS | SIGSEGV)) {
+   case SIGBUS:
+   break;
+   case 0:
+   *ptr = 0;
+   default:
+   igt_assert(!"reached");
+   break;
+   }
+
+   signal(SIGBUS, old_sigsegv);
+   signal(SIGSEGV, old_sigbus);
+}
+
+static void
+trigger_purge(int fd, struct panfrost_bo *madv_bo)
+{
+   struct buf_link *buf_list = NULL, *next, *buf;
+   bool retained;
+
+   /* Try to trigger a purge by allocating buffers until the main
+* buffer is no longer retained. This should probably be
+* replaced with a more reliable way to do this such as a
+* debugfs trigger.
+*/
+
+   while (true) {
+   /* Mark the buffer as purgeable */
+   retained = igt_panfrost_bo_madvise(fd,
+  madv_bo,
+  PANFROST_MADV_DONTNEED);
+   igt_assert(retained);
+
+   buf = malloc(sizeof(*buf));
+   buf->bo = igt_panfrost_gem_new(fd, BUF_SIZE);
+   buf->next = buf_list;
+   buf_list = buf;
+
+   /* Check if that caused the buffer to be purged */
+   retained = igt_panfrost_bo_madvise(fd,
+  madv_bo,
+  PANFROST_MADV_WILLNEED);
+
+   if (!retained)
+   break;
+   }
+
+   /* Free all the temporary buffers that we created */
+   for (buf = buf_list; buf; buf = next) {
+   next = buf->next;
+   igt_panfrost_free_bo(fd, buf->bo);
+   free(buf);
+   }
+}
+
+igt_simple_main
+{
+   int fd;
+   struct panfrost_bo *bo;
+
+   fd = drm_open_driver(DRIVER_PANFROST);
+
+   bo = igt_panfrost_gem_new(fd, BUF_SIZE);
+
+   igt_panfrost_bo_mmap(fd, bo);
+
+   /* Writ

[PATCH 1/2] drm/sched: select new rq even if there is only one v3

[Christian König]

This is necessary when changing priorities of an entity.

v2: test the sched_list instead of num_sched.
v3: set the sched_list to NULL when there is only one entry

Signed-off-by: Christian König 
---
 drivers/gpu/drm/scheduler/sched_entity.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index 92d965b629c6..f0790e9471d1 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -453,7 +453,7 @@ void drm_sched_entity_select_rq(struct drm_sched_entity 
*entity)
struct drm_gpu_scheduler *sched;
struct drm_sched_rq *rq;
 
-   if (spsc_queue_count(&entity->job_queue) || entity->num_sched_list <= 1)
+   if (spsc_queue_count(&entity->job_queue) || !entity->sched_list)
return;
 
fence = READ_ONCE(entity->last_scheduled);
@@ -467,8 +467,10 @@ void drm_sched_entity_select_rq(struct drm_sched_entity 
*entity)
drm_sched_rq_remove_entity(entity->rq, entity);
entity->rq = rq;
}
-
spin_unlock(&entity->rq_lock);
+
+   if (entity->num_sched_list == 1)
+   entity->sched_list = NULL;
 }
 
 /**
-- 
2.25.1

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

[PATCH 2/2] drm/amdgpu: load balance VCN3 decode as well v8

[Christian König]

Add VCN3 IB parsing to figure out to which instance we can send the
stream for decode.

v2: remove VCN instance limit as well, fix amdgpu_cs_find_mapping,
check supported formats instead of unsupported.
v3: fix typo and error handling
v4: make sure the message BO is CPU accessible
v5: fix addr calculation once more
v6: only check message buffers
v7: fix constant and use defines
v8: fix create msg calculation

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 132 +-
 1 file changed, 130 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index b33f513fd2ac..77932003b4c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -50,6 +50,9 @@
 #define VCN_INSTANCES_SIENNA_CICHLID   2
 #define DEC_SW_RING_ENABLEDFALSE
 
+#define RDECODE_MSG_CREATE 0x
+#define RDECODE_MESSAGE_CREATE 0x0001
+
 static int amdgpu_ih_clientid_vcns[] = {
SOC15_IH_CLIENTID_VCN,
SOC15_IH_CLIENTID_VCN1
@@ -208,8 +211,6 @@ static int vcn_v3_0_sw_init(void *handle)
} else {
ring->doorbell_index = 
(adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 8 * i;
}
-   if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 0)
-   ring->no_scheduler = true;
sprintf(ring->name, "vcn_dec_%d", i);
r = amdgpu_ring_init(adev, ring, 512, &adev->vcn.inst[i].irq, 0,
 AMDGPU_RING_PRIO_DEFAULT,
@@ -1825,6 +1826,132 @@ static const struct amdgpu_ring_funcs 
vcn_v3_0_dec_sw_ring_vm_funcs = {
.emit_reg_write_reg_wait = amdgpu_ring_emit_reg_write_reg_wait_helper,
 };
 
+static int vcn_v3_0_limit_sched(struct amdgpu_cs_parser *p)
+{
+   struct drm_gpu_scheduler **scheds;
+
+   /* The create msg must be in the first IB submitted */
+   if (atomic_read(&p->entity->fence_seq))
+   return -EINVAL;
+
+   scheds = p->adev->gpu_sched[AMDGPU_HW_IP_VCN_DEC]
+   [AMDGPU_RING_PRIO_DEFAULT].sched;
+   drm_sched_entity_modify_sched(p->entity, scheds, 1);
+   return 0;
+}
+
+static int vcn_v3_0_dec_msg(struct amdgpu_cs_parser *p, uint64_t addr)
+{
+   struct ttm_operation_ctx ctx = { false, false };
+   struct amdgpu_bo_va_mapping *map;
+   uint32_t *msg, num_buffers;
+   struct amdgpu_bo *bo;
+   uint64_t start, end;
+   unsigned int i;
+   void * ptr;
+   int r;
+
+   addr &= AMDGPU_GMC_HOLE_MASK;
+   r = amdgpu_cs_find_mapping(p, addr, &bo, &map);
+   if (r) {
+   DRM_ERROR("Can't find BO for addr 0x%08Lx\n", addr);
+   return r;
+   }
+
+   start = map->start * AMDGPU_GPU_PAGE_SIZE;
+   end = (map->last + 1) * AMDGPU_GPU_PAGE_SIZE;
+   if (addr & 0x7) {
+   DRM_ERROR("VCN messages must be 8 byte aligned!\n");
+   return -EINVAL;
+   }
+
+   bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
+   amdgpu_bo_placement_from_domain(bo, bo->allowed_domains);
+   r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+   if (r) {
+   DRM_ERROR("Failed validating the VCN message BO (%d)!\n", r);
+   return r;
+   }
+
+   r = amdgpu_bo_kmap(bo, &ptr);
+   if (r) {
+   DRM_ERROR("Failed mapping the VCN message (%d)!\n", r);
+   return r;
+   }
+
+   msg = ptr + addr - start;
+
+   /* Check length */
+   if (msg[1] > end - addr) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   if (msg[3] != RDECODE_MSG_CREATE)
+   goto out;
+
+   num_buffers = msg[2];
+   for (i = 0, msg = &msg[6]; i < num_buffers; ++i, msg += 4) {
+   uint32_t offset, size, *create;
+
+   if (msg[0] != RDECODE_MESSAGE_CREATE)
+   continue;
+
+   offset = msg[1];
+   size = msg[2];
+
+   if (offset + size > end) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   create = ptr + addr + offset - start;
+
+   /* H246, HEVC and VP9 can run on any instance */
+   if (create[0] == 0x7 || create[0] == 0x10 || create[0] == 0x11)
+   continue;
+
+   r = vcn_v3_0_limit_sched(p);
+   if (r)
+   goto out;
+   }
+
+out:
+   amdgpu_bo_kunmap(bo);
+   return r;
+}
+
+static int vcn_v3_0_ring_patch_cs_in_place(struct amdgpu_cs_parser *p,
+  uint32_t ib_idx)
+{
+   struct amdgpu_ring *ring = to_amdgpu_ring(p->entity->rq->sched);
+   struct amdgpu_ib *ib = &p->job->ibs[ib_idx];
+   uint32_

[PATCH v5 2/2] drm/bridge: anx7688: Add ANX7688 bridge driver support

[Dafna Hirschfeld]

From: Enric Balletbo i Serra 

This driver adds support for the ANX7688 HDMI to DP converter block of the
ANX7688 device.

For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count are reported by the bridge via
2 registers and, as far as we know, only chips that have a firmware
version greater than 0.85 support these two registers.

Signed-off-by: Nicolas Boichat 
Signed-off-by: Hsin-Yi Wang 
[The driver is OF only so should depends on CONFIG_OF]
Reported-by: kbuild test robot 
Signed-off-by: Enric Balletbo i Serra 
[convert the driver to be a i2c driver]
Signed-off-by: Dafna Hirschfeld 
---
 drivers/gpu/drm/bridge/analogix/Kconfig   |  11 ++
 drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
 .../drm/bridge/analogix/analogix-anx7688.c| 186 ++
 3 files changed, 198 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c

diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 024ea2a570e7..323327aabc38 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -11,6 +11,17 @@ config DRM_ANALOGIX_ANX6345
  ANX6345 transforms the LVTTL RGB output of an
  application processor to eDP or DisplayPort.
 
+config DRM_ANALOGIX_ANX7688
+   tristate "Analogix ANX7688 bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   help
+ ANX7688 is an ultra-low power 4K Ultra-HD (4096x2160p60)
+ mobile HD transmitter designed for portable
+ devices. The ANX7688 converts HDMI 2.0 to
+ DisplayPort 1.3 Ultra-HD.
+
 config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
b/drivers/gpu/drm/bridge/analogix/Makefile
index 44da392bb9f9..8f2272b8b732 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -2,5 +2,6 @@
 analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
new file mode 100644
index ..85a4b1a23035
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2020 Google LLC
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register addresses */
+#define ANX7688_VENDOR_ID_REG  0x00
+#define ANX7688_DEVICE_ID_REG  0x02
+
+#define ANX7688_FW_VERSION_REG 0x80
+
+#define ANX7688_DP_BANDWIDTH_REG   0x85
+#define ANX7688_DP_LANE_COUNT_REG  0x86
+
+#define ANX7688_VENDOR_ID  0x1f29
+#define ANX7688_DEVICE_ID  0x7688
+
+/* First supported firmware version (0.85) */
+#define ANX7688_MINIMUM_FW_VERSION 0x0085
+
+static const struct regmap_config anx7688_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+struct anx7688 {
+   struct i2c_client *client;
+   struct regmap *regmap;
+   struct drm_bridge bridge;
+   bool filter;
+};
+
+static inline struct anx7688 *
+bridge_to_anx7688(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct anx7688, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+   struct anx7688 *anx = bridge_to_anx7688(bridge);
+   int totalbw, requiredbw;
+   u8 dpbw, lanecount;
+   u8 regs[2];
+   int ret;
+
+   if (!anx->filter)
+   return true;
+
+   /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+   ret = regmap_bulk_read(anx->regmap, ANX7688_DP_BANDWIDTH_REG, regs, 2);
+   if (ret < 0) {
+   DRM_ERROR("Failed to read bandwidth/lane count\n");
+   return false;
+   }
+   dpbw = regs[0];
+   lanecount = regs[1];
+
+   /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+   if (dpbw > 0x19 || lanecount > 2) {
+   DRM_ERROR("Invalid bandwidth/lane count (%02x/%d)\n", dpbw,
+ lanecount);
+   return false;
+   }
+
+   /* Compute available bandwidth (kHz) */
+   totalbw = dpbw * lanecount * 27 * 8 / 10;
+
+   /* Required bandwidth (8 bpc, kHz) */
+   requiredbw

[PATCH v5 0/2] Add support for ANX7688

[Dafna Hirschfeld]

ANX7688 is a typec port controller that also converts HDMI to DP.
ANX7688 is found on Acer Chromebook R13 (elm) and on Pine64 PinePhone.

On Acer Chromebook R13, the device is powered-up and controller by the
Embedded Controller. Therefore the dt-bindings requires
only the 'compatible' and 'reg' properties.

In v4 of this set, the device was added as an 'mfd' device
and an additional 'bridge' device for the HDMI-DP conversion, see [1].
In this version we add the device as a typec controller.

[1] https://lkml.org/lkml/2020/3/18/64

Changes from v4:
Send the device as a typec controller instead of mfd.
The bridge driver should therefore convert from a platform
driver to an i2c driver.

Dafna Hirschfeld (1):
  dt-bindings: usb: add analogix,anx7688.yaml

Enric Balletbo i Serra (1):
  drm/bridge: anx7688: Add ANX7688 bridge driver support

 .../bindings/usb/analogix,anx7688.yaml| 177 +
 drivers/gpu/drm/bridge/analogix/Kconfig   |  11 ++
 drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
 .../drm/bridge/analogix/analogix-anx7688.c| 186 ++
 4 files changed, 375 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c

-- 
2.17.1

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

[PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml

[Dafna Hirschfeld]

ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
DisplayPort 1.3 Ultra-HDi (4096x2160p60).
The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer
along with the DisplayPort Alternate Mode signaling over USB Type-C.
Additionally, an on-chip microcontroller (OCM) is available to manage the
signal switching, Channel Configuration (CC) detection, USB Power
Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other
functions as defined in the USB TypeC and USB Power Delivery
specifications.

ANX7688 is found on Acer Chromebook R13 (elm) and on
Pine64 PinePhone.

Signed-off-by: Dafna Hirschfeld 
---
 .../bindings/usb/analogix,anx7688.yaml| 177 ++
 1 file changed, 177 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/analogix,anx7688.yaml

diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml 
b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
new file mode 100644
index ..6c4dd6b4b28b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion
+
+maintainers:
+  - Nicolas Boichat 
+  - Enric Balletbo i Serra 
+
+description: |
+  ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
+  DisplayPort 1.3 Ultra-HDi (4096x2160p60).
+  The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer 
along with
+  the DisplayPort Alternate Mode signaling over USB Type-C. Additionally,
+  an on-chip microcontroller (OCM) is available to manage the signal switching,
+  Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor
+  Defined Message (VDM) protocol support and other functions as defined in the
+  USB TypeC and USB Power Delivery specifications.
+
+
+properties:
+  compatible:
+const: analogix,anx7688
+
+  reg:
+maxItems: 1
+
+  avdd33-supply:
+description: 3.3V Analog core supply voltage.
+
+  dvdd18-supply:
+description: 1.8V Digital I/O supply voltage.
+
+  avdd18-supply:
+description: 1.8V Analog core power supply voltage.
+
+  avdd10-supply:
+description: 1.0V Analog core power supply voltage.
+
+  dvdd10-supply:
+description: 1.0V Digital core supply voltage.
+
+  hdmi5v-supply:
+description: 5V power supply for the HDMI.
+
+  hdmi_vt-supply:
+description: Termination voltage for HDMI input.
+
+  clocks:
+description: The input clock specifier.
+maxItems: 1
+
+  clock-names:
+items:
+  - const: xtal
+
+  hpd-gpios:
+description: |
+  In USB Type-C applications, DP_HPD has no use. In standard DisplayPort
+  applications, DP_HPD is used as DP hot-plug.
+maxItems: 1
+
+  enable-gpios:
+description: Chip power down control. No internal pull-down or pull-up 
resistor.
+maxItems: 1
+
+  reset-gpios:
+description: Reset input signal. Active low.
+maxItems: 1
+
+  vbus-det-gpios:
+description: |
+  An input gpio for VBUS detection and high voltage detection,
+  external resistance divide VBUS voltage to 1/8.
+maxItems: 1
+
+  interrupts:
+description: |
+  The interrupt notifies 4 possible events - TCPC ALERT int, PD int, DP 
int, HDMI int.
+maxItems: 1
+
+  cabledet-gpios:
+description: An output gpio, indicates by the device that a cable is 
plugged.
+maxItems: 1
+
+  vbus-ctrl-gpios:
+description:
+  External VBUS power path. Enable VBUS source and disable VBUS sink or 
vice versa.
+maxItems: 1
+
+  vconn-en1-gpios:
+description: Controls the VCONN switch on the CC1 pin.
+maxItems: 1
+
+  vconn-en2-gpios:
+description: Controls the VCONN switch on the CC2 pin.
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for HDMI input.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: USB port for the USB3 input.
+
+  port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description: USB Type-c connector, see connector/usb-connector.yaml.
+
+required:
+  - port@0
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+anx7688: anx7688@2c {
+compatible = "analogix,anx7688";
+reg = <0x2c>;
+avdd33-supply = <®_dcdc1>;
+dvdd18-supply = <®_ldo_io1>;
+avdd18-supply = <®_ldo_io1>;
+avdd10-supply = <®_anx1v0>;
+dvdd10-supply = <®_anx1v0>;
+hd

[PATCH 1/3] drm/amdgpu: introduce struct amdgpu_bo_user

[Nirmoy Das]

Implement a new struct amdgpu_bo_user as subclass of
struct amdgpu_bo and a function to created amdgpu_bo_user
bo with a flag to identify the owner.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 44 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  9 +
 include/uapi/drm/amdgpu_drm.h  |  2 +
 3 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 745393472564..f21679f38383 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -699,6 +699,50 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
return r;
 }
 
+/**
+ * amdgpu_bo_create_user - create an &amdgpu_bo_user buffer object
+ * @adev: amdgpu device object
+ * @bp: parameters to be used for the buffer object
+ * @ubo_ptr: pointer to the buffer object pointer
+ *
+ * Create a BO to be used by user application;
+ *
+ * Returns:
+ * 0 for success or a negative error code on failure.
+ */
+
+int amdgpu_bo_create_user(struct amdgpu_device *adev,
+struct amdgpu_bo_param *bp,
+struct amdgpu_bo_user **ubo_ptr)
+{
+   struct amdgpu_bo *bo_ptr;
+   u64 flags = bp->flags;
+   int r;
+
+   bp->flags = bp->flags & ~AMDGPU_GEM_CREATE_SHADOW;
+   bp->flags = bp->flags | AMDGPU_GEM_CREATE_USER;
+   bp->bo_ptr_size = sizeof(struct amdgpu_bo);
+   r = amdgpu_bo_do_create(adev, bp, &bo_ptr);
+   if (r)
+   return r;
+
+   *ubo_ptr = (struct amdgpu_bo_user *)bo_ptr;
+   if ((flags & AMDGPU_GEM_CREATE_SHADOW) && !(adev->flags & AMD_IS_APU)) {
+   if (!bp->resv)
+   WARN_ON(dma_resv_lock((*ubo_ptr)->bo.tbo.base.resv,
+   NULL));
+
+   r = amdgpu_bo_create_shadow(adev, bp->size, bo_ptr);
+
+   if (!bp->resv)
+   dma_resv_unlock((*ubo_ptr)->bo.tbo.base.resv);
+
+   if (r)
+   ttm_bo_put(&(*ubo_ptr)->bo.tbo);
+   }
+
+   return r;
+}
 /**
  * amdgpu_bo_validate - validate an &amdgpu_bo buffer object
  * @bo: pointer to the buffer object
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 848dc0a017dd..332e269c3fd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -114,6 +114,12 @@ struct amdgpu_bo {
struct kgd_mem  *kfd_bo;
 };
 
+struct amdgpu_bo_user {
+   struct amdgpu_bobo;
+   u64 tiling_flags;
+
+};
+
 static inline struct amdgpu_bo *ttm_to_amdgpu_bo(struct ttm_buffer_object *tbo)
 {
return container_of(tbo, struct amdgpu_bo, tbo);
@@ -257,6 +263,9 @@ int amdgpu_bo_create_kernel(struct amdgpu_device *adev,
 int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev,
   uint64_t offset, uint64_t size, uint32_t domain,
   struct amdgpu_bo **bo_ptr, void **cpu_addr);
+int amdgpu_bo_create_user(struct amdgpu_device *adev,
+struct amdgpu_bo_param *bp,
+struct amdgpu_bo_user **ubo_ptr);
 void amdgpu_bo_free_kernel(struct amdgpu_bo **bo, u64 *gpu_addr,
   void **cpu_addr);
 int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr);
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 8b832f7458f2..9b9a4ac6f00f 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -141,6 +141,8 @@ extern "C" {
  * accessing it with various hw blocks
  */
 #define AMDGPU_GEM_CREATE_ENCRYPTED(1 << 10)
+/* Flag that indicates the BO is created for userspace */
+#define AMDGPU_GEM_CREATE_USER (1 << 11)
 
 struct drm_amdgpu_gem_create_in  {
/** the requested memory size */
-- 
2.30.1

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

[PATCH 3/3] drm/amdgpu: use tiling_flags of struct amdgpu_bo_user

[Nirmoy Das]

This flag is only needed for BOs created by amdgpu_gem_object_create(),
so we can remove tiling_flags from the base class.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 -
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index f21679f38383..c19cb6863966 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1190,12 +1190,19 @@ int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
 int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 tiling_flags)
 {
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   struct amdgpu_bo_user *ubo;
+
+   if (!(bo->flags & AMDGPU_GEM_CREATE_USER)) {
+   DRM_ERROR("can not set tiling_flags for a non-amdgpu_bo_user 
type BO\n");
+   return -EINVAL;
+   }
 
if (adev->family <= AMDGPU_FAMILY_CZ &&
AMDGPU_TILING_GET(tiling_flags, TILE_SPLIT) > 6)
return -EINVAL;
 
-   bo->tiling_flags = tiling_flags;
+   ubo = container_of((bo), struct amdgpu_bo_user, bo);
+   ubo->tiling_flags = tiling_flags;
return 0;
 }
 
@@ -1209,10 +1216,18 @@ int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, 
u64 tiling_flags)
  */
 void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, u64 *tiling_flags)
 {
+   struct amdgpu_bo_user *ubo;
+
+   if (!(bo->flags & AMDGPU_GEM_CREATE_USER)) {
+   DRM_ERROR("can not get tiling_flags for a non-amdgpu_bo_user 
type BO\n");
+   return;
+   }
+
dma_resv_assert_held(bo->tbo.base.resv);
+   ubo = container_of((bo), struct amdgpu_bo_user, bo);
 
if (tiling_flags)
-   *tiling_flags = bo->tiling_flags;
+   *tiling_flags = ubo->tiling_flags;
 }
 
 /**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 332e269c3fd1..7164c0799534 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -91,7 +91,6 @@ struct amdgpu_bo {
struct ttm_bo_kmap_obj  kmap;
u64 flags;
unsignedpin_count;
-   u64 tiling_flags;
u64 metadata_flags;
void*metadata;
u32 metadata_size;
-- 
2.30.1

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

[PATCH 2/3] drm/amdgpu: use amdgpu_bo_create_user() for gem object

[Nirmoy Das]

GEM objects encapsulate amdgpu_bo for userspace applications.
Now that we have a new amdgpu_bo_user subclass for that purpose,
let's use that instead.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 8e9b8a6e6ef0..9d2b55eb31c2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -54,6 +54,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, 
unsigned long size,
 struct drm_gem_object **obj)
 {
struct amdgpu_bo *bo;
+   struct amdgpu_bo_user *ubo;
struct amdgpu_bo_param bp;
int r;
 
@@ -68,7 +69,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, 
unsigned long size,
 retry:
bp.flags = flags;
bp.domain = initial_domain;
-   r = amdgpu_bo_create(adev, &bp, &bo);
+   r = amdgpu_bo_create_user(adev, &bp, &ubo);
if (r) {
if (r != -ERESTARTSYS) {
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) {
@@ -85,6 +86,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, 
unsigned long size,
}
return r;
}
+   bo = &ubo->bo;
*obj = &bo->tbo.base;
 
return 0;
-- 
2.30.1

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

Re: [PATCH 1/3] drm/amdgpu: introduce struct amdgpu_bo_user

[Christian König]

Am 05.03.21 um 13:56 schrieb Nirmoy Das:

Implement a new struct amdgpu_bo_user as subclass of
struct amdgpu_bo and a function to created amdgpu_bo_user
bo with a flag to identify the owner.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 44 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  9 +
  include/uapi/drm/amdgpu_drm.h  |  2 +
  3 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 745393472564..f21679f38383 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -699,6 +699,50 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
return r;
  }
  
+/**

+ * amdgpu_bo_create_user - create an &amdgpu_bo_user buffer object
+ * @adev: amdgpu device object
+ * @bp: parameters to be used for the buffer object
+ * @ubo_ptr: pointer to the buffer object pointer
+ *
+ * Create a BO to be used by user application;
+ *
+ * Returns:
+ * 0 for success or a negative error code on failure.
+ */
+
+int amdgpu_bo_create_user(struct amdgpu_device *adev,
+struct amdgpu_bo_param *bp,
+struct amdgpu_bo_user **ubo_ptr)
+{
+   struct amdgpu_bo *bo_ptr;
+   u64 flags = bp->flags;
+   int r;
+
+   bp->flags = bp->flags & ~AMDGPU_GEM_CREATE_SHADOW;
+   bp->flags = bp->flags | AMDGPU_GEM_CREATE_USER;
+   bp->bo_ptr_size = sizeof(struct amdgpu_bo);
+   r = amdgpu_bo_do_create(adev, bp, &bo_ptr);
+   if (r)
+   return r;
+
+   *ubo_ptr = (struct amdgpu_bo_user *)bo_ptr;
+   if ((flags & AMDGPU_GEM_CREATE_SHADOW) && !(adev->flags & AMD_IS_APU)) {
+   if (!bp->resv)
+   WARN_ON(dma_resv_lock((*ubo_ptr)->bo.tbo.base.resv,
+   NULL));
+
+   r = amdgpu_bo_create_shadow(adev, bp->size, bo_ptr);
+
+   if (!bp->resv)
+   dma_resv_unlock((*ubo_ptr)->bo.tbo.base.resv);
+
+   if (r)
+   ttm_bo_put(&(*ubo_ptr)->bo.tbo);
+   }


The shadows handling is specific for VM BOs and not necessary for BOs 
which are used by userspace.


Regards,
Christian.


+
+   return r;
+}
  /**
   * amdgpu_bo_validate - validate an &amdgpu_bo buffer object
   * @bo: pointer to the buffer object
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 848dc0a017dd..332e269c3fd1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -114,6 +114,12 @@ struct amdgpu_bo {
struct kgd_mem  *kfd_bo;
  };
  
+struct amdgpu_bo_user {

+   struct amdgpu_bobo;
+   u64 tiling_flags;
+
+};
+
  static inline struct amdgpu_bo *ttm_to_amdgpu_bo(struct ttm_buffer_object 
*tbo)
  {
return container_of(tbo, struct amdgpu_bo, tbo);
@@ -257,6 +263,9 @@ int amdgpu_bo_create_kernel(struct amdgpu_device *adev,
  int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev,
   uint64_t offset, uint64_t size, uint32_t domain,
   struct amdgpu_bo **bo_ptr, void **cpu_addr);
+int amdgpu_bo_create_user(struct amdgpu_device *adev,
+struct amdgpu_bo_param *bp,
+struct amdgpu_bo_user **ubo_ptr);
  void amdgpu_bo_free_kernel(struct amdgpu_bo **bo, u64 *gpu_addr,
   void **cpu_addr);
  int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr);
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 8b832f7458f2..9b9a4ac6f00f 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -141,6 +141,8 @@ extern "C" {
   * accessing it with various hw blocks
   */
  #define AMDGPU_GEM_CREATE_ENCRYPTED   (1 << 10)
+/* Flag that indicates the BO is created for userspace */
+#define AMDGPU_GEM_CREATE_USER (1 << 11)
  
  struct drm_amdgpu_gem_create_in  {

/** the requested memory size */


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

Re: [PATCH 3/3] drm/amdgpu: use tiling_flags of struct amdgpu_bo_user

[Christian König]

Am 05.03.21 um 13:56 schrieb Nirmoy Das:

This flag is only needed for BOs created by amdgpu_gem_object_create(),
so we can remove tiling_flags from the base class.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 -
  2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index f21679f38383..c19cb6863966 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1190,12 +1190,19 @@ int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
  int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 tiling_flags)
  {
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   struct amdgpu_bo_user *ubo;
+
+   if (!(bo->flags & AMDGPU_GEM_CREATE_USER)) {


You don't need the AMDGPU_GEM_CREATE_USER flag, just test TTMs BO type.


+   DRM_ERROR("can not set tiling_flags for a non-amdgpu_bo_user type 
BO\n");
+   return -EINVAL;
+   }
  
  	if (adev->family <= AMDGPU_FAMILY_CZ &&

AMDGPU_TILING_GET(tiling_flags, TILE_SPLIT) > 6)
return -EINVAL;
  
-	bo->tiling_flags = tiling_flags;

+   ubo = container_of((bo), struct amdgpu_bo_user, bo);
+   ubo->tiling_flags = tiling_flags;
return 0;
  }
  
@@ -1209,10 +1216,18 @@ int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 tiling_flags)

   */
  void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, u64 *tiling_flags)
  {
+   struct amdgpu_bo_user *ubo;
+
+   if (!(bo->flags & AMDGPU_GEM_CREATE_USER)) {
+   DRM_ERROR("can not get tiling_flags for a non-amdgpu_bo_user type 
BO\n");
+   return;
+   }
+
dma_resv_assert_held(bo->tbo.base.resv);
+   ubo = container_of((bo), struct amdgpu_bo_user, bo);
  
  	if (tiling_flags)

-   *tiling_flags = bo->tiling_flags;
+   *tiling_flags = ubo->tiling_flags;
  }
  
  /**

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 332e269c3fd1..7164c0799534 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -91,7 +91,6 @@ struct amdgpu_bo {
struct ttm_bo_kmap_obj  kmap;
u64 flags;
unsignedpin_count;
-   u64 tiling_flags;
u64 metadata_flags;
void*metadata;
u32 metadata_size;


BTW: The metadata can be moved to the user BOs as well!

Thanks,
Christian.

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

Re: [PATCH 3/3] drm/amdgpu: use tiling_flags of struct amdgpu_bo_user

[Nirmoy]

On 3/5/21 2:08 PM, Christian König wrote:

Am 05.03.21 um 13:56 schrieb Nirmoy Das:

This flag is only needed for BOs created by amdgpu_gem_object_create(),
so we can remove tiling_flags from the base class.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 19 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 -
  2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

index f21679f38383..c19cb6863966 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1190,12 +1190,19 @@ int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
  int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 tiling_flags)
  {
  struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+    struct amdgpu_bo_user *ubo;
+
+    if (!(bo->flags & AMDGPU_GEM_CREATE_USER)) {


You don't need the AMDGPU_GEM_CREATE_USER flag, just test TTMs BO type.



Okay I will remove AMDGPU_GEM_CREATE_USER flag completely.




+    DRM_ERROR("can not set tiling_flags for a non-amdgpu_bo_user 
type BO\n");

+    return -EINVAL;
+    }
    if (adev->family <= AMDGPU_FAMILY_CZ &&
  AMDGPU_TILING_GET(tiling_flags, TILE_SPLIT) > 6)
  return -EINVAL;
  -    bo->tiling_flags = tiling_flags;
+    ubo = container_of((bo), struct amdgpu_bo_user, bo);
+    ubo->tiling_flags = tiling_flags;
  return 0;
  }
  @@ -1209,10 +1216,18 @@ int amdgpu_bo_set_tiling_flags(struct 
amdgpu_bo *bo, u64 tiling_flags)

   */
  void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, u64 
*tiling_flags)

  {
+    struct amdgpu_bo_user *ubo;
+
+    if (!(bo->flags & AMDGPU_GEM_CREATE_USER)) {
+    DRM_ERROR("can not get tiling_flags for a non-amdgpu_bo_user 
type BO\n");

+    return;
+    }
+
  dma_resv_assert_held(bo->tbo.base.resv);
+    ubo = container_of((bo), struct amdgpu_bo_user, bo);
    if (tiling_flags)
-    *tiling_flags = bo->tiling_flags;
+    *tiling_flags = ubo->tiling_flags;
  }
    /**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h

index 332e269c3fd1..7164c0799534 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -91,7 +91,6 @@ struct amdgpu_bo {
  struct ttm_bo_kmap_obj    kmap;
  u64    flags;
  unsigned    pin_count;
-    u64    tiling_flags;
  u64    metadata_flags;
  void    *metadata;
  u32    metadata_size;


BTW: The metadata can be moved to the user BOs as well!



I resend with metadata members moved to the user BO.


Thanks,

Nirmoy



Thanks,
Christian.


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

Re: [PATCH 1/2] drm/sched: select new rq even if there is only one v3

[Jiang, Sonny]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Sonny Jiang 

From: Christian König 
Sent: Friday, March 5, 2021 7:51 AM
To: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org 
Cc: Liu, Leo ; Jiang, Sonny 
Subject: [PATCH 1/2] drm/sched: select new rq even if there is only one v3

This is necessary when changing priorities of an entity.

v2: test the sched_list instead of num_sched.
v3: set the sched_list to NULL when there is only one entry

Signed-off-by: Christian König 
---
 drivers/gpu/drm/scheduler/sched_entity.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c
index 92d965b629c6..f0790e9471d1 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -453,7 +453,7 @@ void drm_sched_entity_select_rq(struct drm_sched_entity 
*entity)
 struct drm_gpu_scheduler *sched;
 struct drm_sched_rq *rq;

-   if (spsc_queue_count(&entity->job_queue) || entity->num_sched_list <= 1)
+   if (spsc_queue_count(&entity->job_queue) || !entity->sched_list)
 return;

 fence = READ_ONCE(entity->last_scheduled);
@@ -467,8 +467,10 @@ void drm_sched_entity_select_rq(struct drm_sched_entity 
*entity)
 drm_sched_rq_remove_entity(entity->rq, entity);
 entity->rq = rq;
 }
-
 spin_unlock(&entity->rq_lock);
+
+   if (entity->num_sched_list == 1)
+   entity->sched_list = NULL;
 }

 /**
--
2.25.1

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

Re: [PATCH 2/2] drm/amdgpu: load balance VCN3 decode as well v8

[Jiang, Sonny]

[AMD Official Use Only - Internal Distribution Only]

Reviewed-by: Sonny Jiang 

From: Christian König 
Sent: Friday, March 5, 2021 7:51 AM
To: dri-devel@lists.freedesktop.org ; 
amd-...@lists.freedesktop.org 
Cc: Liu, Leo ; Jiang, Sonny 
Subject: [PATCH 2/2] drm/amdgpu: load balance VCN3 decode as well v8

Add VCN3 IB parsing to figure out to which instance we can send the
stream for decode.

v2: remove VCN instance limit as well, fix amdgpu_cs_find_mapping,
check supported formats instead of unsupported.
v3: fix typo and error handling
v4: make sure the message BO is CPU accessible
v5: fix addr calculation once more
v6: only check message buffers
v7: fix constant and use defines
v8: fix create msg calculation

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 132 +-
 1 file changed, 130 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
index b33f513fd2ac..77932003b4c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c
@@ -50,6 +50,9 @@
 #define VCN_INSTANCES_SIENNA_CICHLID2
 #define DEC_SW_RING_ENABLED FALSE

+#define RDECODE_MSG_CREATE 0x
+#define RDECODE_MESSAGE_CREATE 0x0001
+
 static int amdgpu_ih_clientid_vcns[] = {
 SOC15_IH_CLIENTID_VCN,
 SOC15_IH_CLIENTID_VCN1
@@ -208,8 +211,6 @@ static int vcn_v3_0_sw_init(void *handle)
 } else {
 ring->doorbell_index = 
(adev->doorbell_index.vcn.vcn_ring0_1 << 1) + 8 * i;
 }
-   if (adev->asic_type == CHIP_SIENNA_CICHLID && i != 0)
-   ring->no_scheduler = true;
 sprintf(ring->name, "vcn_dec_%d", i);
 r = amdgpu_ring_init(adev, ring, 512, &adev->vcn.inst[i].irq, 
0,
  AMDGPU_RING_PRIO_DEFAULT,
@@ -1825,6 +1826,132 @@ static const struct amdgpu_ring_funcs 
vcn_v3_0_dec_sw_ring_vm_funcs = {
 .emit_reg_write_reg_wait = amdgpu_ring_emit_reg_write_reg_wait_helper,
 };

+static int vcn_v3_0_limit_sched(struct amdgpu_cs_parser *p)
+{
+   struct drm_gpu_scheduler **scheds;
+
+   /* The create msg must be in the first IB submitted */
+   if (atomic_read(&p->entity->fence_seq))
+   return -EINVAL;
+
+   scheds = p->adev->gpu_sched[AMDGPU_HW_IP_VCN_DEC]
+   [AMDGPU_RING_PRIO_DEFAULT].sched;
+   drm_sched_entity_modify_sched(p->entity, scheds, 1);
+   return 0;
+}
+
+static int vcn_v3_0_dec_msg(struct amdgpu_cs_parser *p, uint64_t addr)
+{
+   struct ttm_operation_ctx ctx = { false, false };
+   struct amdgpu_bo_va_mapping *map;
+   uint32_t *msg, num_buffers;
+   struct amdgpu_bo *bo;
+   uint64_t start, end;
+   unsigned int i;
+   void * ptr;
+   int r;
+
+   addr &= AMDGPU_GMC_HOLE_MASK;
+   r = amdgpu_cs_find_mapping(p, addr, &bo, &map);
+   if (r) {
+   DRM_ERROR("Can't find BO for addr 0x%08Lx\n", addr);
+   return r;
+   }
+
+   start = map->start * AMDGPU_GPU_PAGE_SIZE;
+   end = (map->last + 1) * AMDGPU_GPU_PAGE_SIZE;
+   if (addr & 0x7) {
+   DRM_ERROR("VCN messages must be 8 byte aligned!\n");
+   return -EINVAL;
+   }
+
+   bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
+   amdgpu_bo_placement_from_domain(bo, bo->allowed_domains);
+   r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
+   if (r) {
+   DRM_ERROR("Failed validating the VCN message BO (%d)!\n", r);
+   return r;
+   }
+
+   r = amdgpu_bo_kmap(bo, &ptr);
+   if (r) {
+   DRM_ERROR("Failed mapping the VCN message (%d)!\n", r);
+   return r;
+   }
+
+   msg = ptr + addr - start;
+
+   /* Check length */
+   if (msg[1] > end - addr) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   if (msg[3] != RDECODE_MSG_CREATE)
+   goto out;
+
+   num_buffers = msg[2];
+   for (i = 0, msg = &msg[6]; i < num_buffers; ++i, msg += 4) {
+   uint32_t offset, size, *create;
+
+   if (msg[0] != RDECODE_MESSAGE_CREATE)
+   continue;
+
+   offset = msg[1];
+   size = msg[2];
+
+   if (offset + size > end) {
+   r = -EINVAL;
+   goto out;
+   }
+
+   create = ptr + addr + offset - start;
+
+   /* H246, HEVC and VP9 can run on any instance */
+   if (create[0] == 0x7 || create[0] == 0x10 || create[0] == 0x11)
+   continue;
+
+   r = vcn_v3_0_limit_sched(p);
+   if (r)
+   goto o

Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml

[Laurent Pinchart]

Hi Dafna,

Thank you for the patch.

On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote:
> ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
> DisplayPort 1.3 Ultra-HDi (4096x2160p60).
> The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer
> along with the DisplayPort Alternate Mode signaling over USB Type-C.
> Additionally, an on-chip microcontroller (OCM) is available to manage the
> signal switching, Channel Configuration (CC) detection, USB Power
> Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other
> functions as defined in the USB TypeC and USB Power Delivery
> specifications.
> 
> ANX7688 is found on Acer Chromebook R13 (elm) and on
> Pine64 PinePhone.
> 
> Signed-off-by: Dafna Hirschfeld 
> ---
>  .../bindings/usb/analogix,anx7688.yaml| 177 ++
>  1 file changed, 177 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> 
> diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml 
> b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> new file mode 100644
> index ..6c4dd6b4b28b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> @@ -0,0 +1,177 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion
> +
> +maintainers:
> +  - Nicolas Boichat 
> +  - Enric Balletbo i Serra 
> +
> +description: |
> +  ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
> +  DisplayPort 1.3 Ultra-HDi (4096x2160p60).
> +  The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer 
> along with
> +  the DisplayPort Alternate Mode signaling over USB Type-C. Additionally,
> +  an on-chip microcontroller (OCM) is available to manage the signal 
> switching,
> +  Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor
> +  Defined Message (VDM) protocol support and other functions as defined in 
> the
> +  USB TypeC and USB Power Delivery specifications.
> +
> +

Extra blank line ?

> +properties:
> +  compatible:
> +const: analogix,anx7688
> +
> +  reg:
> +maxItems: 1
> +
> +  avdd33-supply:
> +description: 3.3V Analog core supply voltage.
> +
> +  dvdd18-supply:
> +description: 1.8V Digital I/O supply voltage.
> +
> +  avdd18-supply:
> +description: 1.8V Analog core power supply voltage.
> +
> +  avdd10-supply:
> +description: 1.0V Analog core power supply voltage.
> +
> +  dvdd10-supply:
> +description: 1.0V Digital core supply voltage.
> +

That's lots of supplies. If there's a reasonable chance that some of
them will always be driven by the same regulator (especially if the
ANX7688 documentation requires that), then they could be grouped. For
instance dvdd18-supply and avdd18-supply could be grouped into
vdd18-supply. It would still allow us to extend the bindings in a
backward compatible way later if a system uses different regulators. You
have more information about the hardware than I do, so it's your call.

> +  hdmi5v-supply:
> +description: 5V power supply for the HDMI.
> +
> +  hdmi_vt-supply:
> +description: Termination voltage for HDMI input.

Maybe hdmi-vt-supply ?

> +
> +  clocks:
> +description: The input clock specifier.
> +maxItems: 1

How about

items:
  - description: The input clock specifier.

> +
> +  clock-names:
> +items:
> +  - const: xtal
> +
> +  hpd-gpios:
> +description: |
> +  In USB Type-C applications, DP_HPD has no use. In standard DisplayPort
> +  applications, DP_HPD is used as DP hot-plug.
> +maxItems: 1
> +
> +  enable-gpios:
> +description: Chip power down control. No internal pull-down or pull-up 
> resistor.
> +maxItems: 1
> +
> +  reset-gpios:
> +description: Reset input signal. Active low.
> +maxItems: 1
> +
> +  vbus-det-gpios:
> +description: |
> +  An input gpio for VBUS detection and high voltage detection,
> +  external resistance divide VBUS voltage to 1/8.
> +maxItems: 1
> +
> +  interrupts:
> +description: |
> +  The interrupt notifies 4 possible events - TCPC ALERT int, PD int, DP 
> int, HDMI int.
> +maxItems: 1
> +
> +  cabledet-gpios:
> +description: An output gpio, indicates by the device that a cable is 
> plugged.
> +maxItems: 1
> +
> +  vbus-ctrl-gpios:
> +description:
> +  External VBUS power path. Enable VBUS source and disable VBUS sink or 
> vice versa.
> +maxItems: 1
> +
> +  vconn-en1-gpios:
> +description: Controls the VCONN switch on the CC1 pin.
> +maxItems: 1
> +
> +  vconn-en2-gpios:
> +description: Controls the VCONN switch on the CC2 pin.
> +maxItems: 1
> +
> +  ports:
> +$ref: /schemas/gra

[Bug 209457] AMDGPU resume fail with RX 580 GPU

[bugzilla-daemon]

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

Sven Neumann (ker...@svenfoo.org) changed:

   What|Removed |Added

 CC||ker...@svenfoo.org

--- Comment #20 from Sven Neumann (ker...@svenfoo.org) ---
I am experiencing what appears to be the same problem. My hardware is a Lenovo
Thinkpad 14s with AMD Ryzen 4750u. The notebook quite frequently doesn't come
out of suspend. Or rather it seems to come out of suspend, but can not
initialize the graphics hardware, resulting in a black screen:

Mar 05 13:31:23 zapp systemd[1]: Starting Suspend...
Mar 05 13:31:23 zapp systemd-sleep[4072]: Suspending system...
Mar 05 13:31:23 zapp kernel: PM: suspend entry (s2idle)
Mar 05 13:31:23 zapp kernel: Filesystems sync: 0.009 seconds
Mar 05 13:31:38 zapp kernel: rfkill: input handler enabled
Mar 05 13:31:38 zapp kernel: Freezing user space processes ... (elapsed 0.003
seconds) done.
Mar 05 13:31:38 zapp kernel: OOM killer disabled.
Mar 05 13:31:38 zapp kernel: Freezing remaining freezable tasks ... (elapsed
0.001 seconds) done.
Mar 05 13:31:38 zapp kernel: [drm] free PSP TMR buffer
Mar 05 13:31:38 zapp kernel: ACPI: EC: interrupt blocked
Mar 05 13:31:38 zapp kernel: ACPI: button: The lid device is not compliant to
SW_LID.
Mar 05 13:31:38 zapp kernel: ACPI: EC: interrupt unblocked
Mar 05 13:31:38 zapp kernel: pci :00:00.2: can't derive routing for PCI INT
A
Mar 05 13:31:38 zapp kernel: pci :00:00.2: PCI INT A: no GSI
Mar 05 13:31:38 zapp kernel: usb usb2: root hub lost power or was reset
Mar 05 13:31:38 zapp kernel: usb usb3: root hub lost power or was reset
Mar 05 13:31:38 zapp kernel: xhci_hcd :05:00.0: Zeroing 64bit base
registers, expecting fault
Mar 05 13:31:38 zapp kernel: [drm] PCIE GART of 1024M enabled (table at
0x00F40090).
Mar 05 13:31:38 zapp kernel: [drm] PSP is resuming...
Mar 05 13:31:38 zapp kernel: [drm] reserve 0x40 from 0xf41f80 for PSP
TMR
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: SMU is resuming...
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: dpm has been disabled
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: SMU is resumed
successfully!
Mar 05 13:31:38 zapp kernel: usb 2-2: reset high-speed USB device number 2
using xhci_hcd
Mar 05 13:31:38 zapp kernel: [drm] kiq ring mec 2 pipe 1 q 0
Mar 05 13:31:38 zapp kernel: [drm] DMUB hardware initialized:
version=0x0001
Mar 05 13:31:38 zapp kernel: [drm] VCN decode and encode initialized
successfully(under DPG Mode).
Mar 05 13:31:38 zapp kernel: [drm] JPEG decode initialized successfully.
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring gfx uses VM inv
eng 0 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.0.0 uses
VM inv eng 1 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.1.0 uses
VM inv eng 4 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.2.0 uses
VM inv eng 5 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.3.0 uses
VM inv eng 6 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.0.1 uses
VM inv eng 7 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.1.1 uses
VM inv eng 8 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.2.1 uses
VM inv eng 9 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring comp_1.3.1 uses
VM inv eng 10 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring kiq_2.1.0 uses
VM inv eng 11 on hub 0
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring sdma0 uses VM
inv eng 0 on hub 1
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring vcn_dec uses VM
inv eng 1 on hub 1
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring vcn_enc0 uses VM
inv eng 4 on hub 1
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring vcn_enc1 uses VM
inv eng 5 on hub 1
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: amdgpu: ring jpeg_dec uses VM
inv eng 6 on hub 1
Mar 05 13:31:38 zapp kernel: amdgpu :06:00.0: [drm:amdgpu_ib_ring_tests
[amdgpu]] *ERROR* IB test failed on gfx (-110).
Mar 05 13:31:38 zapp kernel: fbcon: Taking over console
Mar 05 13:31:38 zapp kernel: [drm:amdgpu_device_delayed_init_work_handler
[amdgpu]] *ERROR* ib ring test failed (-110).
Mar 05 13:31:38 zapp kernel: [drm] Failed to add display topology, DTM TA is
not initialized.


The most relevant part seems to be

[drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110).

This is on 5.12-rc1+, compiled from master this morning. But I have seen this
problem with Ubuntu mainline kernels 5.10.17, 5.10.20 and 5.11.3 as well.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
__

Re: [PATCH v5 2/2] drm/bridge: anx7688: Add ANX7688 bridge driver support

[Laurent Pinchart]

Hi Dafna,

Thank you for the patch.

On Fri, Mar 05, 2021 at 01:43:51PM +0100, Dafna Hirschfeld wrote:
> From: Enric Balletbo i Serra 
> 
> This driver adds support for the ANX7688 HDMI to DP converter block of the
> ANX7688 device.
> 
> For our use case, the only reason the Linux kernel driver is necessary is
> to reject resolutions that require more bandwidth than what is available
> on the DP side. DP bandwidth and lane count are reported by the bridge via
> 2 registers and, as far as we know, only chips that have a firmware
> version greater than 0.85 support these two registers.
> 
> Signed-off-by: Nicolas Boichat 
> Signed-off-by: Hsin-Yi Wang 
> [The driver is OF only so should depends on CONFIG_OF]
> Reported-by: kbuild test robot 
> Signed-off-by: Enric Balletbo i Serra 
> [convert the driver to be a i2c driver]
> Signed-off-by: Dafna Hirschfeld 
> ---
>  drivers/gpu/drm/bridge/analogix/Kconfig   |  11 ++
>  drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
>  .../drm/bridge/analogix/analogix-anx7688.c| 186 ++
>  3 files changed, 198 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index 024ea2a570e7..323327aabc38 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -11,6 +11,17 @@ config DRM_ANALOGIX_ANX6345
> ANX6345 transforms the LVTTL RGB output of an
> application processor to eDP or DisplayPort.
>  
> +config DRM_ANALOGIX_ANX7688
> + tristate "Analogix ANX7688 bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> +   ANX7688 is an ultra-low power 4K Ultra-HD (4096x2160p60)
> +   mobile HD transmitter designed for portable
> +   devices. The ANX7688 converts HDMI 2.0 to
> +   DisplayPort 1.3 Ultra-HD.
> +
>  config DRM_ANALOGIX_ANX78XX
>   tristate "Analogix ANX78XX bridge"
>   select DRM_ANALOGIX_DP
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 44da392bb9f9..8f2272b8b732 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -2,5 +2,6 @@
>  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> new file mode 100644
> index ..85a4b1a23035
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
> @@ -0,0 +1,186 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * ANX7688 HDMI->DP bridge driver
> + *
> + * Copyright 2020 Google LLC
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Alphabetical order please :-)

> +
> +/* Register addresses */
> +#define ANX7688_VENDOR_ID_REG0x00
> +#define ANX7688_DEVICE_ID_REG0x02
> +
> +#define ANX7688_FW_VERSION_REG   0x80
> +
> +#define ANX7688_DP_BANDWIDTH_REG 0x85
> +#define ANX7688_DP_LANE_COUNT_REG0x86
> +
> +#define ANX7688_VENDOR_ID0x1f29
> +#define ANX7688_DEVICE_ID0x7688
> +
> +/* First supported firmware version (0.85) */
> +#define ANX7688_MINIMUM_FW_VERSION   0x0085
> +
> +static const struct regmap_config anx7688_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +struct anx7688 {
> + struct i2c_client *client;
> + struct regmap *regmap;
> + struct drm_bridge bridge;
> + bool filter;
> +};
> +
> +static inline struct anx7688 *
> +bridge_to_anx7688(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct anx7688, bridge);
> +}
> +
> +static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
> +   const struct drm_display_mode *mode,
> +   struct drm_display_mode *adjusted_mode)
> +{
> + struct anx7688 *anx = bridge_to_anx7688(bridge);
> + int totalbw, requiredbw;
> + u8 dpbw, lanecount;
> + u8 regs[2];
> + int ret;
> +
> + if (!anx->filter)
> + return true;
> +
> + /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
> + ret = regmap_bulk_read(anx->regmap, ANX7688_DP_BANDWIDTH_REG, regs, 2);
> + if (ret < 0) {
> + DRM_ERROR("Failed to read bandwidth/lane count\n");
> + return false;
> + }
> + dpbw = regs[0];
> + lanecount = regs[1];
> +
> + /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
> + if (dpbw > 0x19 || 

Re: [PATCH 1/3] drm/msm: Fix speed-bin support not to access outside valid memory

[Doug Anderson]

Hi,

On Fri, Mar 5, 2021 at 2:28 AM Srinivas Kandagatla
 wrote:
>
>
>
> On 27/02/2021 00:26, Douglas Anderson wrote:
> > When running the latest kernel on an sc7180 with KASAN I got this
> > splat:
> >BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644
> >Read of size 4 at addr ff8088f36100 by task kworker/7:1/58
> >CPU: 7 PID: 58 Comm: kworker/7:1 Not tainted 5.11.0+ #3
> >Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
> >Workqueue: events deferred_probe_work_func
> >Call trace:
> > dump_backtrace+0x0/0x3a8
> > show_stack+0x24/0x30
> > dump_stack+0x174/0x1e0
> > print_address_description+0x70/0x2e4
> > kasan_report+0x178/0x1bc
> > __asan_report_load4_noabort+0x44/0x50
> > a6xx_gpu_init+0x618/0x644
> > adreno_bind+0x26c/0x438
> >
> > This is because the speed bin is defined like this:
> >gpu_speed_bin: gpu_speed_bin@1d2 {
> >  reg = <0x1d2 0x2>;
> >  bits = <5 8>;
> >};
> >
> > As you can see the "length" is 2 bytes. That means that the nvmem
> > subsystem allocates only 2 bytes. The GPU code, however, was casting
> > the pointer allocated by nvmem to a (u32 *) and dereferencing. That's
> > not so good.
> >
> > Let's fix this to just use the nvmem_cell_read_u16() accessor function
> > which simplifies things and also gets rid of the splat.
> >
> > Let's also put an explicit conversion from little endian in place just
> > to make things clear. The nvmem subsystem today is assuming little
> > endian and this makes it clear. Specifically, the way the above sc7180
> > cell is interpreted:
> >
> > NVMEM:
> >   ++++++
> >   | .. | 0x1d3  | 0x1d2  | .. | 0x000  |
> >   ++++++
> >^   ^
> >   msb lsb
> >
> > You can see that the least significant data is at the lower address
> > which is little endian.
> >
> > NOTE: someone who is truly paying attention might wonder about me
> > picking the "u16" version of this accessor instead of the "u8" (since
> > the value is 8 bits big) or the u32 version (just for fun). At the
> > moment you need to pick the accessor that exactly matches the length
> > the cell was specified as in the device tree. Hopefully future
> > patches to the nvmem subsystem will fix this.
> >
> > Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
> > Signed-off-by: Douglas Anderson 
> > ---
> >
> >   drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
> >   1 file changed, 8 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > index ba8e9d3cf0fe..0e2024defd79 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > @@ -1350,35 +1350,20 @@ static int a6xx_set_supported_hw(struct device 
> > *dev, struct a6xx_gpu *a6xx_gpu,
> >   u32 revn)
> >   {
> >   struct opp_table *opp_table;
> > - struct nvmem_cell *cell;
> >   u32 supp_hw = UINT_MAX;
> > - void *buf;
> > -
> > - cell = nvmem_cell_get(dev, "speed_bin");
> > - /*
> > -  * -ENOENT means that the platform doesn't support speedbin which is
> > -  * fine
> > -  */
> > - if (PTR_ERR(cell) == -ENOENT)
> > - return 0;
> > - else if (IS_ERR(cell)) {
> > - DRM_DEV_ERROR(dev,
> > - "failed to read speed-bin. Some OPPs may not 
> > be supported by hardware");
> > - goto done;
> > - }
> > + u16 speedbin;
> > + int ret;
> >
> > - buf = nvmem_cell_read(cell, NULL);
>
> I think the issue here is not passing len pointer which should return
> how many bytes the cell is!
>
> Then from there we can decide to do le16_to_cpu or le32_to_cpu or not!
> This will also future proof the code to handle speed_bins of different
> sizes!

I think what you're saying is that you want to copy/paste this code
(or something similar) everywhere that accesses an nvmem cell.  Is
that correct?  ...or maybe you can suggest some smaller / shorter code
that I'm missing?

---

{
  struct nvmem_cell *cell;
  ssize_t len;
  char *ret;
  int i;

  *data = 0;

  cell = nvmem_cell_get(dev, cname);
  if (IS_ERR(cell)) {
if (PTR_ERR(cell) != -EPROBE_DEFER)
  dev_err(dev, "undefined cell %s\n", cname);
return PTR_ERR(cell);
  }

  ret = nvmem_cell_read(cell, &len);
  nvmem_cell_put(cell);
  if (IS_ERR(ret)) {
dev_err(dev, "can't read cell %s\n", cname);
return PTR_ERR(ret);
  }

  for (i = 0; i < len; i++)
*data |= ret[i] << (8 * i);

  kfree(ret);
  dev_dbg(dev, "efuse read(%s) = %x, bytes %zd\n", cname, *data, len);

  return 0;
}

---

The above code is from cpr_read_efuse() in "cpr.c".  I mentioned in
the cover letter that I thought about doing this and decided it wasn't
a great idea.  There should be _some_ function in the nvmem core that
says: there's an in

[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #12 from kolAflash (kolafl...@kolahilft.de) ---
I've tried doing a bisect using this script. Unfortunately I couldn't reproduce
the bug this way. So I bisecting will take a lot longer.

for i in {0..19}; do
  echo -e "\n${i}"
  /usr/sbin/rtcwake --seconds 15 --mode no
  systemctl start suspend.target
  sleep 15
done

-- 
You may reply to this email to add a comment.

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 v3 2/5] phy: Add LVDS configuration options

[Robert Foss]

Hey Liu,

This patch seems to be included in both this series and the "Add some
DRM bridge drivers support for i.MX8qm/qxp SoCs" series. Instead of
having the two series have a conflict I would suggest either merging
them (if that makes sense) or removing this patch from one of them and
explicitly stating that there is a dependency on the other series.

(the patch itself still looks good though :) )

On Fri, 11 Dec 2020 at 02:56, Liu Ying  wrote:
>
> This patch allows LVDS PHYs to be configured through
> the generic functions and through a custom structure
> added to the generic union.
>
> The parameters added here are based on common LVDS PHY
> implementation practices.  The set of parameters
> should cover all potential users.
>
> Cc: Kishon Vijay Abraham I 
> Cc: Vinod Koul 
> Cc: NXP Linux Team 
> Signed-off-by: Liu Ying 
> ---
> v2->v3:
> * No change.
>
> v1->v2:
> * No change.
>
>  include/linux/phy/phy-lvds.h | 48 
> 
>  include/linux/phy/phy.h  |  4 
>  2 files changed, 52 insertions(+)
>  create mode 100644 include/linux/phy/phy-lvds.h
>
> diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
> new file mode 100644
> index ..1b5b9d6
> --- /dev/null
> +++ b/include/linux/phy/phy-lvds.h
> @@ -0,0 +1,48 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#ifndef __PHY_LVDS_H_
> +#define __PHY_LVDS_H_
> +
> +/**
> + * struct phy_configure_opts_lvds - LVDS configuration set
> + *
> + * This structure is used to represent the configuration state of a
> + * LVDS phy.
> + */
> +struct phy_configure_opts_lvds {
> +   /**
> +* @bits_per_lane_and_dclk_cycle:
> +*
> +* Number of bits per data lane and differential clock cycle.
> +*/
> +   unsigned int bits_per_lane_and_dclk_cycle;
> +
> +   /**
> +* @differential_clk_rate:
> +*
> +* Clock rate, in Hertz, of the LVDS differential clock.
> +*/
> +   unsigned long differential_clk_rate;
> +
> +   /**
> +* @lanes:
> +*
> +* Number of active, consecutive, data lanes, starting from
> +* lane 0, used for the transmissions.
> +*/
> +   unsigned int lanes;
> +
> +   /**
> +* @is_slave:
> +*
> +* Boolean, true if the phy is a slave which works together
> +* with a master phy to support dual link transmission,
> +* otherwise a regular phy or a master phy.
> +*/
> +   bool is_slave;
> +};
> +
> +#endif /* __PHY_LVDS_H_ */
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index e435bdb..d450b44 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -17,6 +17,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>  struct phy;
> @@ -51,10 +52,13 @@ enum phy_mode {
>   * the MIPI_DPHY phy mode.
>   * @dp:Configuration set applicable for phys supporting
>   * the DisplayPort protocol.
> + * @lvds:  Configuration set applicable for phys supporting
> + * the LVDS phy mode.
>   */
>  union phy_configure_opts {
> struct phy_configure_opts_mipi_dphy mipi_dphy;
> struct phy_configure_opts_dpdp;
> +   struct phy_configure_opts_lvds  lvds;
>  };
>
>  /**
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail

[bugzilla-daemon]

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

--- Comment #13 from Jerome C (m...@jeromec.com) ---
(In reply to kolAflash from comment #12)
> I've tried doing a bisect using this script. Unfortunately I couldn't
> reproduce the bug this way. So I bisecting will take a lot longer.
> 
> for i in {0..19}; do
>   echo -e "\n${i}"
>   /usr/sbin/rtcwake --seconds 15 --mode no
>   systemctl start suspend.target
>   sleep 15
> done

Hiya

I did some testing myself recently and unfortunately doing 20 tests was not
enough for me. I found that it could be 50 - 100 resumes before it would fail
so I capped mine at 150 resumes, there were too many times where things looked
fine for me with less than 50. After I tested kernels between 5.10.4 to
5.11-rc5 ( I didn't use 5.10.0 to 5.10.3 ) and found that this commit

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a10aad137326d137a969fc6cc3555992b99ff9fc

was causing the issue for me

-- 
You may reply to this email to add a comment.

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 v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml

[Dafna Hirschfeld]

Hi

On 05.03.21 15:34, Laurent Pinchart wrote:

Hi Dafna,

Thank you for the patch.

On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote:

ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
DisplayPort 1.3 Ultra-HDi (4096x2160p60).
The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer
along with the DisplayPort Alternate Mode signaling over USB Type-C.
Additionally, an on-chip microcontroller (OCM) is available to manage the
signal switching, Channel Configuration (CC) detection, USB Power
Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other
functions as defined in the USB TypeC and USB Power Delivery
specifications.

ANX7688 is found on Acer Chromebook R13 (elm) and on
Pine64 PinePhone.

Signed-off-by: Dafna Hirschfeld 
---
  .../bindings/usb/analogix,anx7688.yaml| 177 ++
  1 file changed, 177 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/analogix,anx7688.yaml

diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml 
b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
new file mode 100644
index ..6c4dd6b4b28b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion
+
+maintainers:
+  - Nicolas Boichat 
+  - Enric Balletbo i Serra 
+
+description: |
+  ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
+  DisplayPort 1.3 Ultra-HDi (4096x2160p60).
+  The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer 
along with
+  the DisplayPort Alternate Mode signaling over USB Type-C. Additionally,
+  an on-chip microcontroller (OCM) is available to manage the signal switching,
+  Channel Configuration (CC) detection, USB Power Delivery (USB-PD), Vendor
+  Defined Message (VDM) protocol support and other functions as defined in the
+  USB TypeC and USB Power Delivery specifications.
+
+


Extra blank line ?


+properties:
+  compatible:
+const: analogix,anx7688
+
+  reg:
+maxItems: 1
+
+  avdd33-supply:
+description: 3.3V Analog core supply voltage.
+
+  dvdd18-supply:
+description: 1.8V Digital I/O supply voltage.
+
+  avdd18-supply:
+description: 1.8V Analog core power supply voltage.
+
+  avdd10-supply:
+description: 1.0V Analog core power supply voltage.
+
+  dvdd10-supply:
+description: 1.0V Digital core supply voltage.
+


That's lots of supplies. If there's a reasonable chance that some of
them will always be driven by the same regulator (especially if the
ANX7688 documentation requires that), then they could be grouped. For
instance dvdd18-supply and avdd18-supply could be grouped into
vdd18-supply. It would still allow us to extend the bindings in a
backward compatible way later if a system uses different regulators. You
have more information about the hardware than I do, so it's your call.


+  hdmi5v-supply:
+description: 5V power supply for the HDMI.
+
+  hdmi_vt-supply:
+description: Termination voltage for HDMI input.


Maybe hdmi-vt-supply ?


+
+  clocks:
+description: The input clock specifier.
+maxItems: 1


How about

 items:
   - description: The input clock specifier.


+
+  clock-names:
+items:
+  - const: xtal
+
+  hpd-gpios:
+description: |
+  In USB Type-C applications, DP_HPD has no use. In standard DisplayPort
+  applications, DP_HPD is used as DP hot-plug.
+maxItems: 1
+
+  enable-gpios:
+description: Chip power down control. No internal pull-down or pull-up 
resistor.
+maxItems: 1
+
+  reset-gpios:
+description: Reset input signal. Active low.
+maxItems: 1
+
+  vbus-det-gpios:
+description: |
+  An input gpio for VBUS detection and high voltage detection,
+  external resistance divide VBUS voltage to 1/8.
+maxItems: 1
+
+  interrupts:
+description: |
+  The interrupt notifies 4 possible events - TCPC ALERT int, PD int, DP 
int, HDMI int.
+maxItems: 1
+
+  cabledet-gpios:
+description: An output gpio, indicates by the device that a cable is 
plugged.
+maxItems: 1
+
+  vbus-ctrl-gpios:
+description:
+  External VBUS power path. Enable VBUS source and disable VBUS sink or 
vice versa.
+maxItems: 1
+
+  vconn-en1-gpios:
+description: Controls the VCONN switch on the CC1 pin.
+maxItems: 1
+
+  vconn-en2-gpios:
+description: Controls the VCONN switch on the CC2 pin.
+maxItems: 1
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for HDMI input.
+
+  port@1:
+$ref: /schemas/graph.yaml#/

Re: [PATCH v5 2/2] drm/bridge: anx7688: Add ANX7688 bridge driver support

[Dafna Hirschfeld]

Adding meg...@megous.com and linux-...@vger.kernel.org to the list

Thanks,
Dafna

On 05.03.21 13:43, Dafna Hirschfeld wrote:

From: Enric Balletbo i Serra 

This driver adds support for the ANX7688 HDMI to DP converter block of the
ANX7688 device.

For our use case, the only reason the Linux kernel driver is necessary is
to reject resolutions that require more bandwidth than what is available
on the DP side. DP bandwidth and lane count are reported by the bridge via
2 registers and, as far as we know, only chips that have a firmware
version greater than 0.85 support these two registers.

Signed-off-by: Nicolas Boichat 
Signed-off-by: Hsin-Yi Wang 
[The driver is OF only so should depends on CONFIG_OF]
Reported-by: kbuild test robot 
Signed-off-by: Enric Balletbo i Serra 
[convert the driver to be a i2c driver]
Signed-off-by: Dafna Hirschfeld 
---
  drivers/gpu/drm/bridge/analogix/Kconfig   |  11 ++
  drivers/gpu/drm/bridge/analogix/Makefile  |   1 +
  .../drm/bridge/analogix/analogix-anx7688.c| 186 ++
  3 files changed, 198 insertions(+)
  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-anx7688.c

diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 024ea2a570e7..323327aabc38 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -11,6 +11,17 @@ config DRM_ANALOGIX_ANX6345
  ANX6345 transforms the LVTTL RGB output of an
  application processor to eDP or DisplayPort.
  
+config DRM_ANALOGIX_ANX7688

+   tristate "Analogix ANX7688 bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   help
+ ANX7688 is an ultra-low power 4K Ultra-HD (4096x2160p60)
+ mobile HD transmitter designed for portable
+ devices. The ANX7688 converts HDMI 2.0 to
+ DisplayPort 1.3 Ultra-HD.
+
  config DRM_ANALOGIX_ANX78XX
tristate "Analogix ANX78XX bridge"
select DRM_ANALOGIX_DP
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
b/drivers/gpu/drm/bridge/analogix/Makefile
index 44da392bb9f9..8f2272b8b732 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -2,5 +2,6 @@
  analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
  obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
  obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
+obj-$(CONFIG_DRM_ANALOGIX_ANX7688) += analogix-anx7688.o
  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
new file mode 100644
index ..85a4b1a23035
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx7688.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ANX7688 HDMI->DP bridge driver
+ *
+ * Copyright 2020 Google LLC
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register addresses */
+#define ANX7688_VENDOR_ID_REG  0x00
+#define ANX7688_DEVICE_ID_REG  0x02
+
+#define ANX7688_FW_VERSION_REG 0x80
+
+#define ANX7688_DP_BANDWIDTH_REG   0x85
+#define ANX7688_DP_LANE_COUNT_REG  0x86
+
+#define ANX7688_VENDOR_ID  0x1f29
+#define ANX7688_DEVICE_ID  0x7688
+
+/* First supported firmware version (0.85) */
+#define ANX7688_MINIMUM_FW_VERSION 0x0085
+
+static const struct regmap_config anx7688_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+struct anx7688 {
+   struct i2c_client *client;
+   struct regmap *regmap;
+   struct drm_bridge bridge;
+   bool filter;
+};
+
+static inline struct anx7688 *
+bridge_to_anx7688(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct anx7688, bridge);
+}
+
+static bool anx7688_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+   struct anx7688 *anx = bridge_to_anx7688(bridge);
+   int totalbw, requiredbw;
+   u8 dpbw, lanecount;
+   u8 regs[2];
+   int ret;
+
+   if (!anx->filter)
+   return true;
+
+   /* Read both regs 0x85 (bandwidth) and 0x86 (lane count). */
+   ret = regmap_bulk_read(anx->regmap, ANX7688_DP_BANDWIDTH_REG, regs, 2);
+   if (ret < 0) {
+   DRM_ERROR("Failed to read bandwidth/lane count\n");
+   return false;
+   }
+   dpbw = regs[0];
+   lanecount = regs[1];
+
+   /* Maximum 0x19 bandwidth (6.75 Gbps Turbo mode), 2 lanes */
+   if (dpbw > 0x19 || lanecount > 2) {
+   DRM_ERROR("Invalid bandwidth/lane count (%02x/%d)\n", dpbw,
+ lanecount);
+   return false;
+   }
+
+   /* Compute availabl

Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml

[Laurent Pinchart]

Hi Dafna,

On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote:
> On 05.03.21 15:34, Laurent Pinchart wrote:
> > On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote:
> >> ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 to
> >> DisplayPort 1.3 Ultra-HDi (4096x2160p60).
> >> The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer
> >> along with the DisplayPort Alternate Mode signaling over USB Type-C.
> >> Additionally, an on-chip microcontroller (OCM) is available to manage the
> >> signal switching, Channel Configuration (CC) detection, USB Power
> >> Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other
> >> functions as defined in the USB TypeC and USB Power Delivery
> >> specifications.
> >>
> >> ANX7688 is found on Acer Chromebook R13 (elm) and on
> >> Pine64 PinePhone.
> >>
> >> Signed-off-by: Dafna Hirschfeld 
> >> ---
> >>   .../bindings/usb/analogix,anx7688.yaml| 177 ++
> >>   1 file changed, 177 insertions(+)
> >>   create mode 100644 
> >> Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml 
> >> b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> >> new file mode 100644
> >> index ..6c4dd6b4b28b
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/usb/analogix,anx7688.yaml
> >> @@ -0,0 +1,177 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/usb/analogix,anx7688.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Analogix ANX7688 Type-C Port Controller with HDMI to DP conversion
> >> +
> >> +maintainers:
> >> +  - Nicolas Boichat 
> >> +  - Enric Balletbo i Serra 
> >> +
> >> +description: |
> >> +  ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 
> >> 2.0 to
> >> +  DisplayPort 1.3 Ultra-HDi (4096x2160p60).
> >> +  The integrated crosspoint switch (the MUX) supports USB 3.1 data 
> >> transfer along with
> >> +  the DisplayPort Alternate Mode signaling over USB Type-C. Additionally,
> >> +  an on-chip microcontroller (OCM) is available to manage the signal 
> >> switching,
> >> +  Channel Configuration (CC) detection, USB Power Delivery (USB-PD), 
> >> Vendor
> >> +  Defined Message (VDM) protocol support and other functions as defined 
> >> in the
> >> +  USB TypeC and USB Power Delivery specifications.
> >> +
> >> +
> > 
> > Extra blank line ?
> > 
> >> +properties:
> >> +  compatible:
> >> +const: analogix,anx7688
> >> +
> >> +  reg:
> >> +maxItems: 1
> >> +
> >> +  avdd33-supply:
> >> +description: 3.3V Analog core supply voltage.
> >> +
> >> +  dvdd18-supply:
> >> +description: 1.8V Digital I/O supply voltage.
> >> +
> >> +  avdd18-supply:
> >> +description: 1.8V Analog core power supply voltage.
> >> +
> >> +  avdd10-supply:
> >> +description: 1.0V Analog core power supply voltage.
> >> +
> >> +  dvdd10-supply:
> >> +description: 1.0V Digital core supply voltage.
> >> +
> > 
> > That's lots of supplies. If there's a reasonable chance that some of
> > them will always be driven by the same regulator (especially if the
> > ANX7688 documentation requires that), then they could be grouped. For
> > instance dvdd18-supply and avdd18-supply could be grouped into
> > vdd18-supply. It would still allow us to extend the bindings in a
> > backward compatible way later if a system uses different regulators. You
> > have more information about the hardware than I do, so it's your call.
> > 
> >> +  hdmi5v-supply:
> >> +description: 5V power supply for the HDMI.
> >> +
> >> +  hdmi_vt-supply:
> >> +description: Termination voltage for HDMI input.
> > 
> > Maybe hdmi-vt-supply ?
> > 
> >> +
> >> +  clocks:
> >> +description: The input clock specifier.
> >> +maxItems: 1
> > 
> > How about
> > 
> >  items:
> >- description: The input clock specifier.
> > 
> >> +
> >> +  clock-names:
> >> +items:
> >> +  - const: xtal
> >> +
> >> +  hpd-gpios:
> >> +description: |
> >> +  In USB Type-C applications, DP_HPD has no use. In standard 
> >> DisplayPort
> >> +  applications, DP_HPD is used as DP hot-plug.
> >> +maxItems: 1
> >> +
> >> +  enable-gpios:
> >> +description: Chip power down control. No internal pull-down or 
> >> pull-up resistor.
> >> +maxItems: 1
> >> +
> >> +  reset-gpios:
> >> +description: Reset input signal. Active low.
> >> +maxItems: 1
> >> +
> >> +  vbus-det-gpios:
> >> +description: |
> >> +  An input gpio for VBUS detection and high voltage detection,
> >> +  external resistance divide VBUS voltage to 1/8.
> >> +maxItems: 1
> >> +
> >> +  interrupts:
> >> +description: |
> >> +  The interrupt notifies 4 possible events - TCPC ALERT int, PD int, 
> >> DP int, HDMI int.
> >> +maxItems: 1
> >> +
>

Re: [PATCH v3 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Robert Foss]

Hey Liu,

Looking at this series[1], all but patch#2 has been reviewed, and #2
looks good to me. So I think this series is ready to have v4 re-spun
and and all of the r-bs from v3 added to the relevant patches.

[1] 
https://patchwork.kernel.org/project/dri-devel/cover/1607651182-12307-1-git-send-email-victor@nxp.com/

On Fri, 19 Feb 2021 at 10:22, Liu Ying  wrote:
>
> A gentle ping.
>
> Vinod, Kishon, it would be nice if you may help review this.
>
> Thanks,
> Liu Ying
>
> On Fri, 2020-12-11 at 09:46 +0800, Liu Ying wrote:
> > Hi,
> >
> > This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the
> > Freescale i.MX8qxp SoC.
> >
> > The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
> > MIPI DPHY mode or LVDS PHY mode.  The PHY mode is controlled by i.MX8qxp
> > SCU firmware.  The PHY driver would call a SCU function to configure the
> > mode.
> >
> > The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC,
> > where it appears to be a single MIPI DPHY.
> >
> >
> > Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host controller
> > bridge driver, since i.MX8qxp SoC embeds this controller IP to support
> > MIPI DSI displays together with the Mixel PHY.
> >
> > Patch 2/5 allows LVDS PHYs to be configured through the generic PHY 
> > functions
> > and through a custom structure added to the generic PHY configuration union.
> >
> > Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to json-schema.
> >
> > Patch 4/5 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC.
> >
> > Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver.
> >
> >
> > Welcome comments, thanks.
> >
> > v2->v3:
> > * Improve readability of mixel_dphy_set_mode() in the Mixel PHY driver. 
> > (Guido)
> > * Improve the 'clock-names' property in the PHY dt binding.
> >
> > v1->v2:
> > * Convert mixel,mipi-dsi-phy plain text dt binding to json-schema. (Guido)
> > * Print invalid PHY mode in dmesg from the Mixel PHY driver. (Guido)
> > * Add Guido's R-b tag on the patch for the nwl-dsi drm bridge driver.
> >
> > Liu Ying (5):
> >   drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable()
> >   phy: Add LVDS configuration options
> >   dt-bindings: phy: Convert mixel,mipi-dsi-phy to json-schema
> >   dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for
> > i.MX8qxp
> >   phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode
> > support
> >
> >  .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt |  29 ---
> >  .../bindings/phy/mixel,mipi-dsi-phy.yaml   | 107 
> >  drivers/gpu/drm/bridge/nwl-dsi.c   |   6 +
> >  drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 269 
> > -
> >  include/linux/phy/phy-lvds.h   |  48 
> >  include/linux/phy/phy.h|   4 +
> >  6 files changed, 423 insertions(+), 40 deletions(-)
> >  delete mode 100644 
> > Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml
> >  create mode 100644 include/linux/phy/phy-lvds.h
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/5] phy: Add LVDS configuration options

[Robert Foss]

On Fri, 5 Mar 2021 at 16:03, Robert Foss  wrote:
>
> Hey Liu,
>
> This patch seems to be included in both this series and the "Add some
> DRM bridge drivers support for i.MX8qm/qxp SoCs" series. Instead of
> having the two series have a conflict I would suggest either merging
> them (if that makes sense) or removing this patch from one of them and
> explicitly stating that there is a dependency on the other series.
>
> (the patch itself still looks good though :) )

After having looked through the rest of the series, and seeing it is
pretty much ready to be merged. Feel free to add my r-b to this patch.

Reviewed-by: Robert Foss 

>
> On Fri, 11 Dec 2020 at 02:56, Liu Ying  wrote:
> >
> > This patch allows LVDS PHYs to be configured through
> > the generic functions and through a custom structure
> > added to the generic union.
> >
> > The parameters added here are based on common LVDS PHY
> > implementation practices.  The set of parameters
> > should cover all potential users.
> >
> > Cc: Kishon Vijay Abraham I 
> > Cc: Vinod Koul 
> > Cc: NXP Linux Team 
> > Signed-off-by: Liu Ying 
> > ---
> > v2->v3:
> > * No change.
> >
> > v1->v2:
> > * No change.
> >
> >  include/linux/phy/phy-lvds.h | 48 
> > 
> >  include/linux/phy/phy.h  |  4 
> >  2 files changed, 52 insertions(+)
> >  create mode 100644 include/linux/phy/phy-lvds.h
> >
> > diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
> > new file mode 100644
> > index ..1b5b9d6
> > --- /dev/null
> > +++ b/include/linux/phy/phy-lvds.h
> > @@ -0,0 +1,48 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright 2020 NXP
> > + */
> > +
> > +#ifndef __PHY_LVDS_H_
> > +#define __PHY_LVDS_H_
> > +
> > +/**
> > + * struct phy_configure_opts_lvds - LVDS configuration set
> > + *
> > + * This structure is used to represent the configuration state of a
> > + * LVDS phy.
> > + */
> > +struct phy_configure_opts_lvds {
> > +   /**
> > +* @bits_per_lane_and_dclk_cycle:
> > +*
> > +* Number of bits per data lane and differential clock cycle.
> > +*/
> > +   unsigned int bits_per_lane_and_dclk_cycle;
> > +
> > +   /**
> > +* @differential_clk_rate:
> > +*
> > +* Clock rate, in Hertz, of the LVDS differential clock.
> > +*/
> > +   unsigned long differential_clk_rate;
> > +
> > +   /**
> > +* @lanes:
> > +*
> > +* Number of active, consecutive, data lanes, starting from
> > +* lane 0, used for the transmissions.
> > +*/
> > +   unsigned int lanes;
> > +
> > +   /**
> > +* @is_slave:
> > +*
> > +* Boolean, true if the phy is a slave which works together
> > +* with a master phy to support dual link transmission,
> > +* otherwise a regular phy or a master phy.
> > +*/
> > +   bool is_slave;
> > +};
> > +
> > +#endif /* __PHY_LVDS_H_ */
> > diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> > index e435bdb..d450b44 100644
> > --- a/include/linux/phy/phy.h
> > +++ b/include/linux/phy/phy.h
> > @@ -17,6 +17,7 @@
> >  #include 
> >
> >  #include 
> > +#include 
> >  #include 
> >
> >  struct phy;
> > @@ -51,10 +52,13 @@ enum phy_mode {
> >   * the MIPI_DPHY phy mode.
> >   * @dp:Configuration set applicable for phys supporting
> >   * the DisplayPort protocol.
> > + * @lvds:  Configuration set applicable for phys supporting
> > + * the LVDS phy mode.
> >   */
> >  union phy_configure_opts {
> > struct phy_configure_opts_mipi_dphy mipi_dphy;
> > struct phy_configure_opts_dpdp;
> > +   struct phy_configure_opts_lvds  lvds;
> >  };
> >
> >  /**
> > --
> > 2.7.4
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND 00/53] Rid GPU from W=1 warnings

[Roland Scheidegger]

The vmwgfx ones look all good to me, so for
23-53: Reviewed-by: Roland Scheidegger 
That said, they were already signed off by Zack, so not sure what
happened here.

Roland

On 03.03.21 14:42, Lee Jones wrote:
> This is a resend.  All of these patches have been sent before.
> 
> The vmwgfx ones were even applied, but were dropped for some reason.
> 
> Lee Jones (53):
>   drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc
>   drm/nouveau/dispnv50/disp: Remove unused variable 'ret'
>   drm/msm/dp/dp_display: Remove unused variable 'hpd'
>   drm/amd/display/dc/bios/command_table: Remove unused variable
>   include: drm: drm_atomic: Make use of 'new_plane_state'
>   drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc
> headers
>   drm/amd/display/dc/bios/command_table: Remove unused variable and
> associated comment
>   drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the
> stack to the heap
>   drm/amd/display/dc/calcs/dce_calcs: Remove some large variables from
> the stack
>   drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing 'field
> overwritten' issue
>   drm/amd/display/dc/dce80/dce80_resource: Make local functions static
>   drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc
> header
>   drm/nouveau/nouveau_bo: Remove unused variables 'dev'
>   drm/nouveau/nouveau_display: Remove set but unused variable 'width'
>   drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers
>   drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function
> returning void
>   drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut'
> static
>   drm/nouveau/nv50_display: Remove superfluous prototype for local
> static functions
>   drm/nouveau/dispnv50/disp: Include header containing our prototypes
>   drm/nouveau/nouveau_ioc32: File headers are not good candidates for
> kernel-doc
>   drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void
> function
>   drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment
> block
>   drm/vmwgfx/vmwgfx_execbuf: Fix some kernel-doc related issues
>   drm/vmwgfx/vmwgfx_kms: Remove unused variable 'ret' from
> 'vmw_du_primary_plane_atomic_check()'
>   drm/vmwgfx/vmwgfx_kms: Mark vmw_{cursor,primary}_plane_formats as
> __maybe_unused
>   drm/vmwgfx/vmwgfx_drv: Fix some kernel-doc misdemeanours
>   drm/vmwgfx/vmwgfx_ioctl: Provide missing '@' sign required by
> kernel-doc
>   drm/vmwgfx/vmwgfx_resource: Fix worthy function headers demote some
> others
>   drm/vmwgfx/vmwgfx_ttm_buffer: Supply some missing parameter
> descriptions
>   drm/vmwgfx/vmwgfx_fifo: Demote non-conformant kernel-doc header
>   drm/vmwgfx/vmwgfx_ldu: Supply descriptions for 'state' function
> parameter
>   drm/vmwgfx/vmwgfx_kms: Update worthy function headers and demote
> others
>   drm/vmwgfx/vmwgfx_overlay: Demote kernel-doc abuses to standard
> comment blocks
>   drm/vmwgfx/vmwgfx_fence: Add, remove and demote various documentation
> params/headers
>   drm/vmwgfx/vmwgfx_bo: Remove superfluous param description and supply
> another
>   drm/vmwgfx/vmwgfx_context: Demote kernel-doc abuses
>   drm/vmwgfx/vmwgfx_scrn: Demote unworthy kernel-doc headers and update
> others
>   drm/vmwgfx/vmwgfx_surface: Fix some kernel-doc related issues
>   drm/vmwgfx/vmwgfx_cmdbuf_res: Rename param description and remove
> another
>   drm/vmwgfx/vmwgfx_shader: Demote kernel-doc abuses and fix-up worthy
> headers
>   drm/vmwgfx/vmwgfx_cmdbuf: Fix a bunch of missing or incorrectly
> formatted/named params
>   drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable 'ret'
>   drm/vmwgfx/vmwgfx_stdu: Add some missing param/member descriptions
>   drm/vmwgfx/vmwgfx_cmdbuf: Fix misnaming of 'headers' should be plural
>   drm/vmwgfx/vmwgfx_cotable: Fix a couple of simple documentation
> problems
>   drm/vmwgfx/vmwgfx_so: Add description for 'vmw_view's 'rcu' member
>   drm/vmwgfx/vmwgfx_binding: Provide some missing param descriptions and
> remove others
>   drm/vmwgfx/vmwgfx_msg: Fix misspelling of 'msg'
>   drm/vmwgfx/vmwgfx_blit: Add description for 'vmw_bo_cpu_blit's 'diff'
> param
>   drm/vmwgfx/vmwgfx_validation: Add some missing struct member/function
> param descriptions
>   drm/vmwgfx/ttm_object: Demote half-assed headers and fix-up another
>   drm/vmwgfx/vmwgfx_thp: Add description for 'vmw_thp_manager's member
> 'manager'
>   drm/vmwgfx/ttm_object: Reorder header to immediately precede its
> struct
> 
>  .../drm/amd/display/dc/bios/command_table.c   |   16 +-
>  .../gpu/drm/amd/display/dc/calcs/dce_calcs.c  | 1151 +
>  drivers/gpu/drm/amd/display/dc/dce/dce_aux.h  |1 -
>  .../drm/amd/display/dc/dce80/dce80_resource.c |   16 +-
>  drivers/gpu/drm/msm/dp/dp_display.c   |3 -
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c   |4 +-
>  drivers/gpu/drm/n

[Bug 209457] AMDGPU resume fail with RX 580 GPU

[bugzilla-daemon]

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

--- Comment #21 from Alex Deucher (alexdeuc...@gmail.com) ---
Unless you have a polaris board please file your own bug.

-- 
You may reply to this email to add a comment.

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 2/7] drm/vmgfx: Replace kmap_atomic()

[Roland Scheidegger]

On 03.03.21 14:20, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> There is no reason to disable pagefaults and preemption as a side effect of
> kmap_atomic_prot().
> 
> Use kmap_local_page_prot() instead and document the reasoning for the
> mapping usage with the given pgprot.
> 
> Remove the NULL pointer check for the map. These functions return a valid
> address for valid pages and the return was bogus anyway as it would have
> left preemption and pagefaults disabled.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: VMware Graphics 
> Cc: Roland Scheidegger 
> Cc: Zack Rusin 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_blit.c |   30 --
>  1 file changed, 12 insertions(+), 18 deletions(-)
> 
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
> @@ -375,12 +375,12 @@ static int vmw_bo_cpu_blit_line(struct v
>   copy_size = min_t(u32, copy_size, PAGE_SIZE - src_page_offset);
>  
>   if (unmap_src) {
> - kunmap_atomic(d->src_addr);
> + kunmap_local(d->src_addr);
>   d->src_addr = NULL;
>   }
>  
>   if (unmap_dst) {
> - kunmap_atomic(d->dst_addr);
> + kunmap_local(d->dst_addr);
>   d->dst_addr = NULL;
>   }
>  
> @@ -388,12 +388,8 @@ static int vmw_bo_cpu_blit_line(struct v
>   if (WARN_ON_ONCE(dst_page >= d->dst_num_pages))
>   return -EINVAL;
>  
> - d->dst_addr =
> - kmap_atomic_prot(d->dst_pages[dst_page],
> -  d->dst_prot);
> - if (!d->dst_addr)
> - return -ENOMEM;
> -
> + d->dst_addr = 
> kmap_local_page_prot(d->dst_pages[dst_page],
> +d->dst_prot);
>   d->mapped_dst = dst_page;
>   }
>  
> @@ -401,12 +397,8 @@ static int vmw_bo_cpu_blit_line(struct v
>   if (WARN_ON_ONCE(src_page >= d->src_num_pages))
>   return -EINVAL;
>  
> - d->src_addr =
> - kmap_atomic_prot(d->src_pages[src_page],
> -  d->src_prot);
> - if (!d->src_addr)
> - return -ENOMEM;
> -
> + d->src_addr = 
> kmap_local_page_prot(d->src_pages[src_page],
> +d->src_prot);
>   d->mapped_src = src_page;
>   }
>   diff->do_cpy(diff, d->dst_addr + dst_page_offset,
> @@ -436,8 +428,10 @@ static int vmw_bo_cpu_blit_line(struct v
>   *
>   * Performs a CPU blit from one buffer object to another avoiding a full
>   * bo vmap which may exhaust- or fragment vmalloc space.
> - * On supported architectures (x86), we're using kmap_atomic which avoids
> - * cross-processor TLB- and cache flushes and may, on non-HIGHMEM systems
> + *
> + * On supported architectures (x86), we're using kmap_local_prot() which
> + * avoids cross-processor TLB- and cache flushes. kmap_local_prot() will
> + * either map a highmem page with the proper pgprot on HIGHMEM=y systems or
>   * reference already set-up mappings.
>   *
>   * Neither of the buffer objects may be placed in PCI memory
> @@ -500,9 +494,9 @@ int vmw_bo_cpu_blit(struct ttm_buffer_ob
>   }
>  out:
>   if (d.src_addr)
> - kunmap_atomic(d.src_addr);
> + kunmap_local(d.src_addr);
>   if (d.dst_addr)
> - kunmap_atomic(d.dst_addr);
> + kunmap_local(d.dst_addr);
>  
>   return ret;
>  }
> 
> 

Seems reasonable to me.
Reviewed-by: Roland Scheidegger 

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

Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1

[Doug Anderson]

Hi folks,

On Fri, Jan 15, 2021 at 2:44 PM Douglas Anderson  wrote:
>
> This series is to get the N116BCA-EA1 panel working. Most of the
> patches are simple, but on hardware I have in front of me the panel
> sometimes doesn't come up. I'm still working with the hardware
> manufacturer to get to the bottom of it, but I've got it working with
> retries. Adding the retries doesn't seem like an insane thing to do
> and makes some of the error handling more robust, so I've gone ahead
> and included those patches here. Hopefully they look OK.
>
> Changes in v2:
> - Set the "unprepared_time" so if we retry we give the proper delay.
> - ("drm/panel-simple: Don't wait longer for HPD...") new for v2.
> - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2.
> - ("dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1") new for v2.
> - ("drm/panel-simple: Add N116BCA-EA1") new for v2.
>
> Douglas Anderson (5):
>   drm/panel-simple: Undo enable if HPD never asserts
>   drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay
>   drm/panel-simple: Retry if we timeout waiting for HPD
>   dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1
>   drm/panel-simple: Add N116BCA-EA1
>
>  .../bindings/display/panel/panel-simple.yaml  |  2 +
>  drivers/gpu/drm/panel/panel-simple.c  | 84 +--
>  2 files changed, 80 insertions(+), 6 deletions(-)

While this isn't massively urgent, I'm hoping to get some confirmation
that it's still in someone's queue to look at.  A quick "it's still in
my queue" would be much appreciated!  :-)  If I don't hear anything
then I guess next week I'll see if I can find other ways to poke folks
or find a different route to land this series.  Thanks!

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

Re: Query regarding DRM mastership sharing between multiple process

[Pekka Paalanen]

On Thu, 4 Mar 2021 09:43:22 +0530
Hardik Panchal  wrote:

> Hello Sir/Madam,
> 
> I am trying to render some stuff using DRM with Qt GUI application and
> decoded stream from Intel H/w decoder.
> 
> I have two applications one is for GUI content and another one is for
> decoded video streams. While doing this I am facing an issue that only
> singal process acquires DRM mastership while the other one is getting
> error.

Hi,

yes, this is deliberate and by design.

The idea of having two separate processes simultaneously controlling
KMS planes of the same CRTC is fundamentally forbidden. Even if it was
not forbidden, doing so would lead to other technical problems.

You have to change your architecture so that only one process controls
KMS. It you need other processes, they have to pass buffers or
rendering commands to the process that does control KMS. In other
words, you need a display server.

> While wondering how to get the privilege to render stuff I came
> across GET_MAGIC and AUTH_MAGIC.
> Please refer to this text from the MAN page of DRM.

Those will not help you with breaking the DRM master concept.

> > All DRM devices provide authentication mechanisms. Only a DRM-Master is
> > allowed to perform mode-setting or modify core state and only one user can
> > be DRM-Master at a time. See drmSetMaster
> > (3) for
> > information on how to become DRM-Master and what the limitations are. Other
> > DRM users can be authenticated to the DRM-Master via drmAuthMagic
> > (3) so
> > they can perform buffer allocations and rendering.
> >  
> 
> As per this the client which is authenticated using magic code should be
> able to allocate buffer and rendering.
> But while doing this I am not able to use drmModeSetPlane() for rendering
> stuff on display from an authenticated client application. It is giving me
> Permission Denied.
> 
> As per my understanding if the client is authenticated by using
> GET/AUTH_MAGIC it should be able to set a plane and render stuff on the
> display.

No. Authentication gives access to buffer allocation and submitting
rendering commands to the GPU. It does not give access to KMS.


Sorry,
pq


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

Re: [PATCH 1/3] drm/msm: Fix speed-bin support not to access outside valid memory

[Srinivas Kandagatla]

On 05/03/2021 14:45, Doug Anderson wrote:

Hi,

On Fri, Mar 5, 2021 at 2:28 AM Srinivas Kandagatla
 wrote:




On 27/02/2021 00:26, Douglas Anderson wrote:

When running the latest kernel on an sc7180 with KASAN I got this
splat:
BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644
Read of size 4 at addr ff8088f36100 by task kworker/7:1/58
CPU: 7 PID: 58 Comm: kworker/7:1 Not tainted 5.11.0+ #3
Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
Workqueue: events deferred_probe_work_func
Call trace:
 dump_backtrace+0x0/0x3a8
 show_stack+0x24/0x30
 dump_stack+0x174/0x1e0
 print_address_description+0x70/0x2e4
 kasan_report+0x178/0x1bc
 __asan_report_load4_noabort+0x44/0x50
 a6xx_gpu_init+0x618/0x644
 adreno_bind+0x26c/0x438

This is because the speed bin is defined like this:
gpu_speed_bin: gpu_speed_bin@1d2 {
  reg = <0x1d2 0x2>;
  bits = <5 8>;
};

As you can see the "length" is 2 bytes. That means that the nvmem
subsystem allocates only 2 bytes. The GPU code, however, was casting
the pointer allocated by nvmem to a (u32 *) and dereferencing. That's
not so good.

Let's fix this to just use the nvmem_cell_read_u16() accessor function
which simplifies things and also gets rid of the splat.

Let's also put an explicit conversion from little endian in place just
to make things clear. The nvmem subsystem today is assuming little
endian and this makes it clear. Specifically, the way the above sc7180
cell is interpreted:

NVMEM:
   ++++++
   | .. | 0x1d3  | 0x1d2  | .. | 0x000  |
   ++++++
^   ^
   msb lsb

You can see that the least significant data is at the lower address
which is little endian.

NOTE: someone who is truly paying attention might wonder about me
picking the "u16" version of this accessor instead of the "u8" (since
the value is 8 bits big) or the u32 version (just for fun). At the
moment you need to pick the accessor that exactly matches the length
the cell was specified as in the device tree. Hopefully future
patches to the nvmem subsystem will fix this.

Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
Signed-off-by: Douglas Anderson 
---

   drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
   1 file changed, 8 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..0e2024defd79 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1350,35 +1350,20 @@ static int a6xx_set_supported_hw(struct device *dev, 
struct a6xx_gpu *a6xx_gpu,
   u32 revn)
   {
   struct opp_table *opp_table;
- struct nvmem_cell *cell;
   u32 supp_hw = UINT_MAX;
- void *buf;
-
- cell = nvmem_cell_get(dev, "speed_bin");
- /*
-  * -ENOENT means that the platform doesn't support speedbin which is
-  * fine
-  */
- if (PTR_ERR(cell) == -ENOENT)
- return 0;
- else if (IS_ERR(cell)) {
- DRM_DEV_ERROR(dev,
- "failed to read speed-bin. Some OPPs may not be 
supported by hardware");
- goto done;
- }
+ u16 speedbin;
+ int ret;

- buf = nvmem_cell_read(cell, NULL);


I think the issue here is not passing len pointer which should return
how many bytes the cell is!

Then from there we can decide to do le16_to_cpu or le32_to_cpu or not!
This will also future proof the code to handle speed_bins of different
sizes!


I think what you're saying is that you want to copy/paste this code
(or something similar) everywhere that accesses an nvmem cell.  Is
that correct?  ...or maybe you can suggest some smaller / shorter code
that I'm missing?



It depends what the consumer is doing! If it is already aware of what 
size of data its expecting then you can use nvmem_cell_read_u8/16/32/64 
variants, however it wants to do bit more with the data then 
nvmem_cell_read() should give more flexibility!



---

{
   struct nvmem_cell *cell;
   ssize_t len;
   char *ret;
   int i;

   *data = 0;

   cell = nvmem_cell_get(dev, cname);
   if (IS_ERR(cell)) {
 if (PTR_ERR(cell) != -EPROBE_DEFER)
   dev_err(dev, "undefined cell %s\n", cname);
 return PTR_ERR(cell);
   }

   ret = nvmem_cell_read(cell, &len);
   nvmem_cell_put(cell);
   if (IS_ERR(ret)) {
 dev_err(dev, "can't read cell %s\n", cname);
 return PTR_ERR(ret);
   }

   for (i = 0; i < len; i++)
 *data |= ret[i] << (8 * i);

   kfree(ret);
   dev_dbg(dev, "efuse read(%s) = %x, bytes %zd\n", cname, *data, len);

   return 0;
}

---

The above code is from cpr_read_efuse() in "cpr.c".  I mentioned in
the cover letter that I thought about doing this and decided it wasn't
a great idea.  There should be _some_ function in the nvmem core that
says: there's an integer tha

[PATCH v7 1/3] drm/uapi: Add USB connector type

[Noralf Trønnes]

Add a connector type for USB connected display panels.

Some examples of what current userspace will name the connector:
- Weston: "UNNAMED-%d"
- Mutter: "Unknown20-%d"
- X: "Unknown20-%d"

v2:
- Update drm_connector_enum_list
- Add examples to commit message

Acked-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_connector.c | 1 +
 include/uapi/drm/drm_mode.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 717c4e7271b0..52712daed3bc 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -94,6 +94,7 @@ static struct drm_conn_prop_enum_list 
drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
{ DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{ DRM_MODE_CONNECTOR_SPI, "SPI" },
+   { DRM_MODE_CONNECTOR_USB, "USB" },
 };
 
 void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fed66a03c7ae..33024cc5d26e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -367,6 +367,7 @@ enum drm_mode_subconnector {
 #define DRM_MODE_CONNECTOR_DPI 17
 #define DRM_MODE_CONNECTOR_WRITEBACK   18
 #define DRM_MODE_CONNECTOR_SPI 19
+#define DRM_MODE_CONNECTOR_USB 20
 
 /**
  * struct drm_mode_get_connector - Get connector metadata.
-- 
2.23.0

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

[PATCH v7 2/3] drm/probe-helper: Check epoch counter in output_poll_execute()

[Noralf Trønnes]

drm_helper_hpd_irq_event() checks the epoch counter to determine
connector status change. This was introduced in
commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector").
Do the same for output_poll_execute() so it can detect other changes
beside connection status value changes.

v2:
- Add Fixes tag (Daniel)

Fixes: 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector")
Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_probe_helper.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index d6017726cc2a..e5432dcf6999 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -623,6 +623,7 @@ static void output_poll_execute(struct work_struct *work)
struct drm_connector_list_iter conn_iter;
enum drm_connector_status old_status;
bool repoll = false, changed;
+   u64 old_epoch_counter;
 
if (!dev->mode_config.poll_enabled)
return;
@@ -659,8 +660,9 @@ static void output_poll_execute(struct work_struct *work)
 
repoll = true;
 
+   old_epoch_counter = connector->epoch_counter;
connector->status = drm_helper_probe_detect(connector, NULL, 
false);
-   if (old_status != connector->status) {
+   if (old_epoch_counter != connector->epoch_counter) {
const char *old, *new;
 
/*
@@ -689,6 +691,9 @@ static void output_poll_execute(struct work_struct *work)
  connector->base.id,
  connector->name,
  old, new);
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] epoch counter %llu -> 
%llu\n",
+ connector->base.id, connector->name,
+ old_epoch_counter, 
connector->epoch_counter);
 
changed = true;
}
-- 
2.23.0

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

[PATCH v7 0/3] GUD USB Display driver

[Noralf Trønnes]

Hi,

A while back I had the idea to turn a Raspberry Pi Zero into a $5
USB to HDMI/SDTV/DPI display adapter.

The protocol is open so people are free to make displays implementing it and
use this driver, all that's needed is to add a USB vid:pid to the driver for
the display.

See the wiki[1] for more information and images for the Raspberry Pi Zero/4.

Changes in this version:
- LZ4_compress_default() can return zero, check for that
- Fix memory leak in gud_pipe_check() error path (Peter)
- Improve debug and error messages (Peter)
- Don't pass length in protocol structs (Peter)
- Pass USB interface to gud_usb_control_msg() et al. (Peter)
- Improve gud_connector_fill_properties() (Peter)
- Add GUD_PIXEL_FORMAT_RGB111 (Peter)
- Remove GUD_REQ_SET_VERSION (Peter)
- Fix DRM_IOCTL_MODE_OBJ_SETPROPERTY and the rotation property
- Fix dma-buf import (Thomas)

Note: There are several changes to the protocol.

I plan to apply the patches in a week or so unless something turns out to be
broken.

Dependency:
drm: Use USB controller's DMA mask when importing dmabufs[2]
(currently in drm-misc-fixes but not in drm-misc-next yet, also present in
drm-tip and linux-next)

Noralf.

[1] https://github.com/notro/gud/wiki
[2] 
https://patchwork.freedesktop.org/patch/msgid/20210303133229.3288-1-tzimmerm...@suse.de


Noralf Trønnes (3):
  drm/uapi: Add USB connector type
  drm/probe-helper: Check epoch counter in output_poll_execute()
  drm: Add GUD USB Display driver

 MAINTAINERS |   8 +
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_connector.c |   1 +
 drivers/gpu/drm/drm_probe_helper.c  |   7 +-
 drivers/gpu/drm/gud/Kconfig |  14 +
 drivers/gpu/drm/gud/Makefile|   4 +
 drivers/gpu/drm/gud/gud_connector.c | 729 
 drivers/gpu/drm/gud/gud_drv.c   | 659 +
 drivers/gpu/drm/gud/gud_internal.h  | 154 ++
 drivers/gpu/drm/gud/gud_pipe.c  | 535 
 include/drm/gud.h   | 333 +
 include/uapi/drm/drm_mode.h |   1 +
 13 files changed, 2447 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/gud/Kconfig
 create mode 100644 drivers/gpu/drm/gud/Makefile
 create mode 100644 drivers/gpu/drm/gud/gud_connector.c
 create mode 100644 drivers/gpu/drm/gud/gud_drv.c
 create mode 100644 drivers/gpu/drm/gud/gud_internal.h
 create mode 100644 drivers/gpu/drm/gud/gud_pipe.c
 create mode 100644 include/drm/gud.h

-- 
2.23.0

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

[PATCH v7 3/3] drm: Add GUD USB Display driver

[Noralf Trønnes]

This adds a USB display driver with the intention that it can be
used with future USB interfaced low end displays/adapters. The Linux
gadget device driver will serve as the canonical device implementation.

The following DRM properties are supported:
- Plane rotation
- Connector TV properties

There is also support for backlight brightness exposed as a backlight
device.

Display modes can be made available to the host driver either as DRM
display modes or through EDID. If both are present, EDID is just passed
on to userspace.

Performance is preferred over color depth, so if the device supports
RGB565, DRM_CAP_DUMB_PREFERRED_DEPTH will return 16.

If the device transfer buffer can't fit an uncompressed framebuffer
update, the update is split up into parts that do fit.

Optimal user experience is achieved by providing damage reports either by
setting FB_DAMAGE_CLIPS on pageflips or calling DRM_IOCTL_MODE_DIRTYFB.

LZ4 compression is used if the device supports it.

The driver supports a one bit monochrome transfer format: R1. This is not
implemented in the gadget driver. It is added in preparation for future
monochrome e-ink displays.

The driver is MIT licensed to smooth the path for any BSD port of the
driver.

v2:
- Use devm_drm_dev_alloc() and drmm_mode_config_init()
- drm_fbdev_generic_setup: Use preferred_bpp=0, 16 was a copy paste error
- The drm_backlight_helper is dropped, copy in the code
- Support protocol version backwards compatibility for device

v3:
- Use donated Openmoko USB pid
- Use direct compression from framebuffer when pitch matches, not only on
  full frames, so split updates can benefit
- Use __le16 in struct gud_drm_req_get_connector_status
- Set edid property when the device only provides edid
- Clear compression fields in struct gud_drm_req_set_buffer
- Fix protocol version negotiation
- Remove mode->vrefresh, it's calculated

v4:
- Drop the status req polling which was a workaround for something that
  turned out to be a dwc2 udc driver problem
- Add a flag for the Linux gadget to require a status request on
  SET operations. Other devices will only get status req on STALL errors
- Use protocol specific error codes (Peter)
- Add a flag for devices that want to receive the entire framebuffer on
  each flush (Lubomir)
- Retry a failed framebuffer flush
- If mode has changed wait for worker and clear pending damage before
  queuing up new damage, fb width/height might have changed
- Increase error counter on bulk transfer failures
- Use DRM_MODE_CONNECTOR_USB
- Handle R1 kmalloc error (Peter)
- Don't try and replicate the USB get descriptor request standard for the
  display descriptor (Peter)
- Make max_buffer_size optional (Peter), drop the pow2 requirement since
  it's not necessary anymore.
- Don't pre-alloc a control request buffer, it was only 4k
- Let gud.h describe the whole protocol explicitly and don't let DRM
  leak into it (Peter)
- Drop display mode .hskew and .vscan from the protocol
- Shorten names: s/GUD_DRM_/GUD_/ s/gud_drm_/gud_/ (Peter)
- Fix gud_pipe_check() connector picking when switching connector
- Drop gud_drm_driver_gem_create_object() cached is default now
- Retrieve USB device from struct drm_device.dev instead of keeping a
  pointer
- Honour fb->offsets[0]
- Fix mode fetching when connector status is forced
- Check EDID length reported by the device
- Use drm_do_get_edid() so userspace can overrride EDID
- Set epoch counter to signal connector status change
- gud_drm_driver can be const now

v5:
- GUD_DRM_FORMAT_R1: Use non-human ascii values (Daniel)
- Change name to: GUD USB Display (Thomas, Simon)
- Change one __u32 -> __le32 in protocol header
- Always log fb flush errors, unless the previous one failed
- Run backlight update in a worker to avoid upsetting lockdep (Daniel)
- Drop backlight_ops.get_brightness, there's no readback from the device
  so it doesn't really add anything.
- Set dma mask, needed by dma-buf importers

v6:
- Use obj-y in Makefile (Peter)
- Fix missing le32_to_cpu() when using GUD_DISPLAY_MAGIC (Peter)
- Set initial brightness on backlight device

v7:
- LZ4_compress_default() can return zero, check for that
- Fix memory leak in gud_pipe_check() error path (Peter)
- Improve debug and error messages (Peter)
- Don't pass length in protocol structs (Peter)
- Pass USB interface to gud_usb_control_msg() et al. (Peter)
- Improve gud_connector_fill_properties() (Peter)
- Add GUD_PIXEL_FORMAT_RGB111 (Peter)
- Remove GUD_REQ_SET_VERSION (Peter)
- Fix DRM_IOCTL_MODE_OBJ_SETPROPERTY and the rotation property
- Fix dma-buf import (Thomas)

Cc: Peter Stuge 
Cc: Lubomir Rintel 
Acked-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
---
 MAINTAINERS |   8 +
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/gud/Kconfig |  14 +
 drivers/gpu/drm/gud/Makefile|   4 +
 drivers/gpu/drm/gud/gud_connector.c | 729 
 drivers/gpu/dr

[PATCH] drm/komeda: Fix off-by-1 when with readback conn due to rounding

[carsten . haitzler]

From: Carsten Haitzler 

When setting up a readback conenctor that writes data back to memory
rather than to an actual output device (HDMI etc.), rounding was ses
to round-down. As the DPU uses a higher internal number of bits when
generating a color value, this round-down back to 8bit ended up with
everything being off-by one. e.g. #ff became #fefefe. This sets
rounding to "round" so things end up correct by turning on the round
flag (LW_TRC).

Signed-off-by: Carsten Haitzler 
---
 drivers/gpu/drm/arm/display/komeda/d71/d71_component.c | 6 +-
 drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h  | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 8a02ade369db..d551e79fa0f1 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -468,7 +468,11 @@ static void d71_wb_layer_update(struct komeda_component *c,
struct komeda_layer_state *st = to_layer_st(state);
struct drm_connector_state *conn_st = state->wb_conn->state;
struct komeda_fb *kfb = to_kfb(conn_st->writeback_job->fb);
-   u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
+   /* LW_TRC sets rounding to round not truncate which is needed for
+ * the output of writeback to match the input in the most common
+ * use cases like RGB888 -> RGB888, so set this bit by default */
+   u32 ctrl = L_EN | LW_OFM | LW_TRC;
+   u32 mask = L_EN | LW_OFM | LW_TBU_EN | LW_TRC;
u32 __iomem *reg = c->reg;
 
d71_layer_update_fb(c, kfb, st->addr);
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
index e80172a0b320..a8036689d721 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
@@ -321,6 +321,7 @@
 #define LAYER_WR_FORMAT0x0D8
 
 /* Layer_WR control bits */
+#define LW_TRC BIT(1)
 #define LW_OFM BIT(4)
 #define LW_LALPHA(x)   (((x) & 0xFF) << 8)
 #define LW_A_WCACHE(x) (((x) & 0xF) << 28)
-- 
2.30.0

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

[PATCH v2 2/4] devfreq/drivers/lima: Use devfreq cooling device registration

[Daniel Lezcano]

The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.

Use this flag and remove the cooling device registering code.

Signed-off-by: Daniel Lezcano 
---
 drivers/gpu/drm/lima/lima_devfreq.c | 14 +-
 drivers/gpu/drm/lima/lima_devfreq.h |  2 --
 2 files changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_devfreq.c 
b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..86aea1bdc4f4 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -7,7 +7,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -84,17 +83,13 @@ static struct devfreq_dev_profile lima_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = lima_devfreq_target,
.get_dev_status = lima_devfreq_get_dev_status,
+   .is_cooling_device = true,
 };
 
 void lima_devfreq_fini(struct lima_device *ldev)
 {
struct lima_devfreq *devfreq = &ldev->devfreq;
 
-   if (devfreq->cooling) {
-   devfreq_cooling_unregister(devfreq->cooling);
-   devfreq->cooling = NULL;
-   }
-
if (devfreq->devfreq) {
devm_devfreq_remove_device(ldev->dev, devfreq->devfreq);
devfreq->devfreq = NULL;
@@ -110,7 +105,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
 
 int lima_devfreq_init(struct lima_device *ldev)
 {
-   struct thermal_cooling_device *cooling;
struct device *dev = ldev->dev;
struct opp_table *opp_table;
struct devfreq *devfreq;
@@ -173,12 +167,6 @@ int lima_devfreq_init(struct lima_device *ldev)
 
ldevfreq->devfreq = devfreq;
 
-   cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
-   if (IS_ERR(cooling))
-   dev_info(dev, "Failed to register cooling device\n");
-   else
-   ldevfreq->cooling = cooling;
-
return 0;
 
 err_fini:
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h 
b/drivers/gpu/drm/lima/lima_devfreq.h
index 2d9b3008ce77..c43a2069e5d3 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -9,7 +9,6 @@
 
 struct devfreq;
 struct opp_table;
-struct thermal_cooling_device;
 
 struct lima_device;
 
@@ -17,7 +16,6 @@ struct lima_devfreq {
struct devfreq *devfreq;
struct opp_table *clkname_opp_table;
struct opp_table *regulators_opp_table;
-   struct thermal_cooling_device *cooling;
 
ktime_t busy_time;
ktime_t idle_time;
-- 
2.17.1

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

[PATCH v2 4/4] devfreq/drivers/panfrost: Use devfreq cooling device registration

[Daniel Lezcano]

The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.

Use this flag and remove the cooling device registering code.

Tested on rock960.

Signed-off-by: Daniel Lezcano 
---
 drivers/gpu/drm/panfrost/panfrost_devfreq.c | 14 +-
 drivers/gpu/drm/panfrost/panfrost_devfreq.h |  3 ---
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..4d96edf1bc54 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -3,7 +3,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -80,6 +79,7 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = panfrost_devfreq_target,
.get_dev_status = panfrost_devfreq_get_dev_status,
+   .is_cooling_device = true,
 };
 
 int panfrost_devfreq_init(struct panfrost_device *pfdev)
@@ -90,7 +90,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = &pfdev->pdev->dev;
struct devfreq *devfreq;
struct opp_table *opp_table;
-   struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
 
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
@@ -139,12 +138,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
}
pfdevfreq->devfreq = devfreq;
 
-   cooling = devfreq_cooling_em_register(devfreq, NULL);
-   if (IS_ERR(cooling))
-   DRM_DEV_INFO(dev, "Failed to register cooling device\n");
-   else
-   pfdevfreq->cooling = cooling;
-
return 0;
 
 err_fini:
@@ -156,11 +149,6 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
 {
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
 
-   if (pfdevfreq->cooling) {
-   devfreq_cooling_unregister(pfdevfreq->cooling);
-   pfdevfreq->cooling = NULL;
-   }
-
if (pfdevfreq->opp_of_table_added) {
dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
pfdevfreq->opp_of_table_added = false;
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h 
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..470f5c974703 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -9,14 +9,11 @@
 
 struct devfreq;
 struct opp_table;
-struct thermal_cooling_device;
-
 struct panfrost_device;
 
 struct panfrost_devfreq {
struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
-   struct thermal_cooling_device *cooling;
bool opp_of_table_added;
 
ktime_t busy_time;
-- 
2.17.1

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

[PATCH v2 3/4] devfreq/drivers/msm: Use devfreq cooling device registration

[Daniel Lezcano]

The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.

Use this flag and remove the cooling device registering code.

Tested on dragonboard 845c

Signed-off-by: Daniel Lezcano 
---
 drivers/gpu/drm/msm/msm_gpu.c | 12 +---
 drivers/gpu/drm/msm/msm_gpu.h |  2 --
 2 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ab7c167b0623..eade94271a60 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -82,6 +81,7 @@ static struct devfreq_dev_profile msm_devfreq_profile = {
.target = msm_devfreq_target,
.get_dev_status = msm_devfreq_get_dev_status,
.get_cur_freq = msm_devfreq_get_cur_freq,
+   .is_cooling_device = true,
 };
 
 static void msm_devfreq_init(struct msm_gpu *gpu)
@@ -112,14 +112,6 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
}
 
devfreq_suspend_device(gpu->devfreq.devfreq);
-
-   gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
-   gpu->devfreq.devfreq);
-   if (IS_ERR(gpu->cooling)) {
-   DRM_DEV_ERROR(&gpu->pdev->dev,
-   "Couldn't register GPU cooling device\n");
-   gpu->cooling = NULL;
-   }
 }
 
 static int enable_pwrrail(struct msm_gpu *gpu)
@@ -1056,6 +1048,4 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
if (gpu->worker) {
kthread_destroy_worker(gpu->worker);
}
-
-   devfreq_cooling_unregister(gpu->cooling);
 }
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index d7cd02cd2109..93419368bac8 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -155,8 +155,6 @@ struct msm_gpu {
struct msm_gpu_state *crashstate;
/* True if the hardware supports expanded apriv (a650 and newer) */
bool hw_apriv;
-
-   struct thermal_cooling_device *cooling;
 };
 
 static inline struct msm_gpu *dev_to_gpu(struct device *dev)
-- 
2.17.1

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

[PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

[Jason Ekstrand]

This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7.  Ever
since that commit, we've been having issues where a hang in one client
can propagate to another.  In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.

Signed-off-by: Jason Ekstrand 
Reported-by: Marcin Slusarz 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled 
fences")
---
 drivers/gpu/drm/i915/i915_request.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a64..870d6083bb57e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1232,10 +1232,8 @@ i915_request_await_execution(struct i915_request *rq,
 
do {
fence = *child++;
-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
-   i915_sw_fence_set_error_once(&rq->submit, fence->error);
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
-   }
 
if (fence->context == rq->fence.context)
continue;
@@ -1333,10 +1331,8 @@ i915_request_await_dma_fence(struct i915_request *rq, 
struct dma_fence *fence)
 
do {
fence = *child++;
-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
-   i915_sw_fence_set_error_once(&rq->submit, fence->error);
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
-   }
 
/*
 * Requests on the same timeline are explicitly ordered, along
-- 
2.29.2

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

Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"

[Chris Wilson]

Quoting Jason Ekstrand (2021-03-05 17:05:46)
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7.  Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another.  In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.

The fence error handling is required to prevent user's circumventing
incomplete work, such as security validation or escaping isolation.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm/ttm: Ignore signaled move fences

[Felix Kuehling]

It fixed an intermittent failure to allocate page tables in the page
fault handler (turning retry faults into no-retry faults). I'm not sure
if this caused real problems. I think it could potentially result in
fault storms and a failure to report page faults properly. I'm not sure
if it's a regression or was always present. So I'm not sure if it's an
urgent fix.

Regards,
  Felix

Am 2021-03-05 um 2:56 a.m. schrieb Christian König:
>
>
> Am 05.03.21 um 02:21 schrieb Felix Kuehling:
>> Am 2021-03-01 um 10:09 a.m. schrieb Christian König:
>>> Am 27.02.21 um 04:45 schrieb Felix Kuehling:
 Move fences that have already signaled should not prevent memory
 allocations with no_wait_gpu.

 Signed-off-by: Felix Kuehling 
>>> Reviewed-by: Christian König 
>> I work on this on Alex's rebased amd-staging-drm-next. Should this go
>> into any other branches?
>
> I have a branch with stuff for 5.13 which I want to push to
> drm-misc-next as soon as 5.12-rc1 is out.
>
> Going to add this one here to that collection as well unless you say
> that this is really a bug fix and we need it earlier.
>
> Regards,
> Christian.
>
>>
>> Thanks,
>>    Felix
>>
>>
 ---
    drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
 b/drivers/gpu/drm/ttm/ttm_bo.c
 index 3a10bebb75d6..de1ec838cf8b 100644
 --- a/drivers/gpu/drm/ttm/ttm_bo.c
 +++ b/drivers/gpu/drm/ttm/ttm_bo.c
 @@ -730,8 +730,9 @@ static int ttm_bo_add_move_fence(struct
 ttm_buffer_object *bo,
    return 0;
      if (no_wait_gpu) {
 +    ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY;
    dma_fence_put(fence);
 -    return -EBUSY;
 +    return ret;
    }
      dma_resv_add_shared_fence(bo->base.resv, fence);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/display: Remove unnecessary conversion to bool

[Alex Deucher]

Applied.  Thanks!

Alex

On Thu, Mar 4, 2021 at 3:02 AM Jiapeng Chong
 wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:956:52-57: WARNING:
> conversion to bool not needed here.
>
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8311:16-21: WARNING:
> conversion to bool not needed here.
>
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3e1fd1e..0e6b7415 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -953,7 +953,7 @@ static void event_mall_stutter(struct work_struct *work)
>
>
> dc_allow_idle_optimizations(
> -   dm->dc, dm->active_vblank_irq_count == 0 ? true : false);
> +   dm->dc, dm->active_vblank_irq_count == 0);
>
> DRM_DEBUG_DRIVER("Allow idle optimizations (MALL): %d\n", 
> dm->active_vblank_irq_count == 0);
>
> @@ -8307,8 +8307,7 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
> hdcp_update_display(
> adev->dm.hdcp_workqueue, 
> aconnector->dc_link->link_index, aconnector,
> new_con_state->hdcp_content_type,
> -   new_con_state->content_protection == 
> DRM_MODE_CONTENT_PROTECTION_DESIRED ? true
> - 
>: false);
> +   new_con_state->content_protection == 
> DRM_MODE_CONTENT_PROTECTION_DESIRED);
> }
>  #endif
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH] drm/msm/dp: Fix warnings reported by kbot in DP driver

[abhinavk]

Hi Stephen

Thanks for the review.
I will break this up into patches according to the class of warning to 
show the warning in the commit text

and resend the patches.

Abhinav
On 2021-03-04 23:23, Dan Carpenter wrote:

On Thu, Mar 04, 2021 at 10:55:58PM -0800, Stephen Boyd wrote:

> @@ -368,44 +368,21 @@ static int dp_debug_init(struct dp_debug *dp_debug, 
struct drm_minor *minor)
> int rc = 0;
> struct dp_debug_private *debug = container_of(dp_debug,
> struct dp_debug_private, dp_debug);
> -   struct dentry *file;
> -   struct dentry *test_active;
> -   struct dentry *test_data, *test_type;
>
> -   file = debugfs_create_file("dp_debug", 0444, minor->debugfs_root,
> +   debugfs_create_file("dp_debug", 0444, minor->debugfs_root,
> debug, &dp_debug_fops);
> -   if (IS_ERR_OR_NULL(file)) {
> -   rc = PTR_ERR(file);
> -   DRM_ERROR("[%s] debugfs create file failed, rc=%d\n",
> - DEBUG_NAME, rc);
> -   }
>
> -   test_active = debugfs_create_file("msm_dp_test_active", 0444,
> +   debugfs_create_file("msm_dp_test_active", 0444,
> minor->debugfs_root,
> debug, &test_active_fops);
> -   if (IS_ERR_OR_NULL(test_active)) {
> -   rc = PTR_ERR(test_active);
> -   DRM_ERROR("[%s] debugfs test_active failed, rc=%d\n",
> - DEBUG_NAME, rc);
> -   }
>
> -   test_data = debugfs_create_file("msm_dp_test_data", 0444,
> +   debugfs_create_file("msm_dp_test_data", 0444,
> minor->debugfs_root,
> debug, &dp_test_data_fops);
> -   if (IS_ERR_OR_NULL(test_data)) {
> -   rc = PTR_ERR(test_data);
> -   DRM_ERROR("[%s] debugfs test_data failed, rc=%d\n",
> - DEBUG_NAME, rc);
> -   }
>
> -   test_type = debugfs_create_file("msm_dp_test_type", 0444,
> +   debugfs_create_file("msm_dp_test_type", 0444,
> minor->debugfs_root,
> debug, &dp_test_type_fops);
> -   if (IS_ERR_OR_NULL(test_type)) {
> -   rc = PTR_ERR(test_type);
> -   DRM_ERROR("[%s] debugfs test_type failed, rc=%d\n",
> - DEBUG_NAME, rc);
> -   }

Debugfs failures.


[ Update.  I misunderstood what you were saying, and initially thought
  you were critiquing the patch instead of the commit message.  The
  patch looks okay.  Probably a lot of maintainers would prefer it
  broken multiple chunks with one patch per class of warning.  But I
  already wrote this email and I love the sound of my own voice so I'm
  sending it.  - dan ]

The Smatch warning for this was that the error handling was slightly
off because debugfs_create_file() doesn't return NULL these days.  But
really these functions are not supposed to be error checked in the
normal case.

If you do a `git grep -w debugfs_create_file` there are 1472 callers
and only 192 check.  This is partly because Greg went through and did a
mass delete of error handling.

The way that debugfs works is if you fail to create a directory then
the debugfs_create_file will check if the root is an error pointer.  So
passing it "handles" errors itself.

The one time where I've seen that checking for errors is essential is
if they driver dereferences the "test_data" dentry itself.  That's
pretty uncommon.

[ So probably the commit message for this chunk should be:

  Delete unnecessary debugfs error handling

  Debugfs functions are not supposed to be checked in the normal case
  so delete this code.  Also it silences a Smatch warning that we're
  checking for NULL when these functions only return error pointers.  ]

regards,
dan carpenter

___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

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

Re: [PATCH][next] drm/amd/display: remove redundant initialization of variable status

[Alex Deucher]

Applied.  Thanks!

Alex

On Wed, Mar 3, 2021 at 9:07 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> The variable status is being initialized with a value that is never read
> and it is being updated later with a new value.  The initialization is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c 
> b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
> index 03741e170b61..15ed09b7a452 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c
> @@ -81,7 +81,7 @@ static void dmub_psr_get_state(struct dmub_psr *dmub, enum 
> dc_psr_state *state)
>  {
> struct dmub_srv *srv = dmub->ctx->dmub_srv->dmub;
> uint32_t raw_state;
> -   enum dmub_status status = DMUB_STATUS_INVALID;
> +   enum dmub_status status;
>
> // Send gpint command and wait for ack
> status = dmub_srv_send_gpint_command(srv, DMUB_GPINT__GET_PSR_STATE, 
> 0, 30);
> --
> 2.30.0
>
> ___
> 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

[PATCH 0/7] Microship SAMA5D4 VPU support et al

[Emil Velikov]

Hi all,

This series adds support for the Microchip SAMA5D4 VPU, which it based
on the Hantro G1.

The hardware can support up-to 1280x720 for each of the MPEG2, VP8 and
H264 codecs. There is only a single decoder and no encoders on the SoC.

To minimise duplication, the series starts with a few small cleanups.


As you may have noticed, this is my first patches series to linux-media,
so any tips how to make this as smoother process are appreciated.


Looking forward to your feedback,
Emil


Emil Velikov (7):
  media: hantro: use G1_REG_INTERRUPT directly for the mpeg2
  media: hantro: imx: reuse MB_DIM define
  media: hantro: imx: remove duplicate dec_base init
  media: hantro: imx: remove unused include
  media: hantro: introduce hantro_g1.c for common API
  ARM: configs: at91: sama5: update with savedefconfig
  ARM: dts: at91: sama5d4: add vdec0 component

 arch/arm/boot/dts/sama5d4.dtsi|   9 ++
 arch/arm/configs/sama5_defconfig  |  51 
 drivers/staging/media/hantro/Kconfig  |  10 +-
 drivers/staging/media/hantro/Makefile |   4 +
 drivers/staging/media/hantro/hantro_drv.c |   3 +
 drivers/staging/media/hantro/hantro_g1.c  |  39 ++
 .../media/hantro/hantro_g1_mpeg2_dec.c|   5 +-
 drivers/staging/media/hantro/hantro_hw.h  |   4 +
 drivers/staging/media/hantro/imx8m_vpu_hw.c   |  27 +---
 drivers/staging/media/hantro/rk3288_vpu_hw.c  |  36 +-
 .../staging/media/hantro/sama5d4_vdec_hw.c| 118 ++
 11 files changed, 216 insertions(+), 90 deletions(-)
 create mode 100644 drivers/staging/media/hantro/hantro_g1.c
 create mode 100644 drivers/staging/media/hantro/sama5d4_vdec_hw.c

-- 
2.30.1

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

[PATCH 1/7] media: hantro: use G1_REG_INTERRUPT directly for the mpeg2

[Emil Velikov]

From: Emil Velikov 

Use the register directly over the existing SWREG().

Ideally we'll port the driver away from the local registers, but for
now this is enough. For context - I was reading through the IRQ register
handling across the variants.

Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov 
---
 drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c 
b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
index 6386a3989bfe..0fd306806f16 100644
--- a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
@@ -10,6 +10,7 @@
 #include 
 #include "hantro.h"
 #include "hantro_hw.h"
+#include "hantro_g1_regs.h"
 
 #define G1_SWREG(nr)   ((nr) * 4)
 
@@ -20,7 +21,6 @@
 #define G1_REG_REFER2_BASE G1_SWREG(16)
 #define G1_REG_REFER3_BASE G1_SWREG(17)
 #define G1_REG_QTABLE_BASE G1_SWREG(40)
-#define G1_REG_DEC_E(v)((v) ? BIT(0) : 0)
 
 #define G1_REG_DEC_AXI_RD_ID(v)(((v) << 24) & GENMASK(31, 24))
 #define G1_REG_DEC_TIMEOUT_E(v)((v) ? BIT(23) : 0)
@@ -246,6 +246,5 @@ void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx)
 
hantro_end_prepare_run(ctx);
 
-   reg = G1_REG_DEC_E(1);
-   vdpu_write(vpu, reg, G1_SWREG(1));
+   vdpu_write(vpu, G1_REG_INTERRUPT_DEC_E, G1_REG_INTERRUPT);
 }
-- 
2.30.1

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

[PATCH 2/7] media: hantro: imx: reuse MB_DIM define

[Emil Velikov]

From: Emil Velikov 

Swap the hardcoded 16 with MB_DIM define.

Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov 
---
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c 
b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index c222de075ef4..1f48c1956cd2 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -109,10 +109,10 @@ static const struct hantro_fmt imx8m_vpu_dec_fmts[] = {
.frmsize = {
.min_width = 48,
.max_width = 3840,
-   .step_width = 16,
+   .step_width = MB_DIM,
.min_height = 48,
.max_height = 2160,
-   .step_height = 16,
+   .step_height = MB_DIM,
},
},
{
-- 
2.30.1

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

[PATCH 3/7] media: hantro: imx: remove duplicate dec_base init

[Emil Velikov]

From: Emil Velikov 

The vpu->dec_base is already set by the hantro driver itself.

Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov 
---
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c 
b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index 1f48c1956cd2..cb1ac02c03d2 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -150,7 +150,6 @@ static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
 
 static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
 {
-   vpu->dec_base = vpu->reg_bases[0];
vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
 
return 0;
-- 
2.30.1

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

[PATCH 4/7] media: hantro: imx: remove unused include

[Emil Velikov]

From: Emil Velikov 

The current imx8 code does not use the jpeg encoder. Remove the
unnecessary include.

Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov 
---
 drivers/staging/media/hantro/imx8m_vpu_hw.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c 
b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index cb1ac02c03d2..f36c1bd681ba 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -9,7 +9,6 @@
 #include 
 
 #include "hantro.h"
-#include "hantro_jpeg.h"
 #include "hantro_g1_regs.h"
 
 #define CTRL_SOFT_RESET0x00
-- 
2.30.1

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

[PATCH 6/7] ARM: configs: at91: sama5: update with savedefconfig

[Emil Velikov]

From: Emil Velikov 

While enabling an extra config, I've noticed that savedefconfig produced
a notable delta. Split out the no-op changes for clarity sake.

Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov 
---
 arch/arm/configs/sama5_defconfig | 48 
 1 file changed, 18 insertions(+), 30 deletions(-)

diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index 5f6297e6c549..0dca50c64503 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -1,7 +1,6 @@
 # CONFIG_LOCALVERSION_AUTO is not set
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
-CONFIG_FHANDLE=y
 CONFIG_NO_HZ_IDLE=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=14
@@ -9,29 +8,26 @@ CONFIG_CGROUPS=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EMBEDDED=y
 CONFIG_SLAB=y
-CONFIG_MODULES=y
-CONFIG_MODULE_FORCE_LOAD=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_AT91=y
 CONFIG_SOC_SAMA5D2=y
 CONFIG_SOC_SAMA5D3=y
 CONFIG_SOC_SAMA5D4=y
 # CONFIG_ATMEL_CLOCKSOURCE_PIT is not set
-CONFIG_AEABI=y
 CONFIG_UACCESS_WITH_MEMCPY=y
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x2110,25165824 root=/dev/ram0 
rw"
 CONFIG_KEXEC=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_KERNEL_MODE_NEON=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_PM_DEBUG=y
 CONFIG_PM_ADVANCED_DEBUG=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -41,13 +37,7 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_IP_PNP_BOOTP=y
 CONFIG_IP_PNP_RARP=y
-# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_DIAG is not set
-# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
-# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
-# CONFIG_INET6_XFRM_MODE_BEET is not set
 CONFIG_IPV6_SIT_6RD=y
 CONFIG_BRIDGE=m
 CONFIG_BRIDGE_VLAN_FILTERING=y
@@ -68,7 +58,6 @@ CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_CFI=y
-CONFIG_MTD_M25P80=y
 CONFIG_MTD_RAW_NAND=y
 CONFIG_MTD_NAND_ATMEL=y
 CONFIG_MTD_SPI_NOR=y
@@ -87,8 +76,8 @@ CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 CONFIG_NET_DSA_MICROCHIP_KSZ9477=m
 CONFIG_NET_DSA_MICROCHIP_KSZ9477_SPI=m
-CONFIG_MACB=y
 # CONFIG_NET_VENDOR_BROADCOM is not set
+CONFIG_MACB=y
 # CONFIG_NET_VENDOR_CIRRUS is not set
 # CONFIG_NET_VENDOR_FARADAY is not set
 # CONFIG_NET_VENDOR_INTEL is not set
@@ -103,7 +92,9 @@ CONFIG_MACB=y
 CONFIG_MICREL_PHY=y
 CONFIG_LIBERTAS_THINFIRM=m
 CONFIG_LIBERTAS_THINFIRM_USB=m
-CONFIG_RTL8187=m
+CONFIG_MWIFIEX=m
+CONFIG_MWIFIEX_SDIO=m
+CONFIG_MWIFIEX_USB=m
 CONFIG_RT2X00=m
 CONFIG_RT2500USB=m
 CONFIG_RT73USB=m
@@ -111,10 +102,7 @@ CONFIG_RT2800USB=m
 CONFIG_RT2800USB_RT53XX=y
 CONFIG_RT2800USB_RT55XX=y
 CONFIG_RT2800USB_UNKNOWN=y
-CONFIG_MWIFIEX=m
-CONFIG_MWIFIEX_SDIO=m
-CONFIG_MWIFIEX_USB=m
-# CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_RTL8187=m
 CONFIG_INPUT_EVDEV=y
 # CONFIG_KEYBOARD_ATKBD is not set
 CONFIG_KEYBOARD_QT1070=y
@@ -136,9 +124,9 @@ CONFIG_SPI_ATMEL=y
 CONFIG_SPI_GPIO=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_SAMA5D2_PIOBU=m
+CONFIG_POWER_RESET=y
 CONFIG_POWER_SUPPLY=y
 CONFIG_BATTERY_ACT8945A=y
-CONFIG_POWER_RESET=y
 CONFIG_SENSORS_JC42=m
 CONFIG_WATCHDOG=y
 CONFIG_AT91SAM9X_WATCHDOG=y
@@ -177,11 +165,11 @@ CONFIG_SND=y
 CONFIG_SND_SOC=y
 CONFIG_SND_ATMEL_SOC=y
 CONFIG_SND_ATMEL_SOC_WM8904=y
-# CONFIG_HID_GENERIC is not set
 CONFIG_SND_ATMEL_SOC_CLASSD=y
 CONFIG_SND_ATMEL_SOC_PDMIC=y
 CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=m
 CONFIG_SND_ATMEL_SOC_I2S=y
+# CONFIG_HID_GENERIC is not set
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_EHCI_HCD=y
@@ -235,14 +223,14 @@ CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_CODEPAGE_850=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_UTF8=y
+CONFIG_CRYPTO_USER_API_HASH=m
+CONFIG_CRYPTO_USER_API_SKCIPHER=m
+CONFIG_CRYPTO_DEV_ATMEL_AES=y
+CONFIG_CRYPTO_DEV_ATMEL_TDES=y
+CONFIG_CRYPTO_DEV_ATMEL_SHA=y
 CONFIG_STRIP_ASM_SYMS=y
 CONFIG_DEBUG_FS=y
 CONFIG_DEBUG_MEMORY_INIT=y
 # CONFIG_SCHED_DEBUG is not set
 # CONFIG_FTRACE is not set
 CONFIG_DEBUG_USER=y
-CONFIG_CRYPTO_USER_API_HASH=m
-CONFIG_CRYPTO_USER_API_SKCIPHER=m
-CONFIG_CRYPTO_DEV_ATMEL_AES=y
-CONFIG_CRYPTO_DEV_ATMEL_TDES=y
-CONFIG_CRYPTO_DEV_ATMEL_SHA=y
-- 
2.30.1

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

[PATCH 7/7] ARM: dts: at91: sama5d4: add vdec0 component

[Emil Velikov]

From: Emil Velikov 

The SoC features a Hantro G1 compatible video decoder.

Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov 
---
 arch/arm/boot/dts/sama5d4.dtsi|   9 ++
 arch/arm/configs/sama5_defconfig  |   3 +
 drivers/staging/media/hantro/Kconfig  |  10 +-
 drivers/staging/media/hantro/Makefile |   3 +
 drivers/staging/media/hantro/hantro_drv.c |   3 +
 drivers/staging/media/hantro/hantro_hw.h  |   1 +
 .../staging/media/hantro/sama5d4_vdec_hw.c| 118 ++
 7 files changed, 146 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/media/hantro/sama5d4_vdec_hw.c

diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 05c55875835d..deaf1f6cc784 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -101,6 +101,15 @@ nfc_sram: sram@10 {
ranges = <0 0x10 0x2400>;
};
 
+   vdec0: vdec@0030 {
+   compatible = "atmel,sama5d4-vdec";
+   reg = <0x0030 0x10>;
+   interrupts = <19 IRQ_TYPE_LEVEL_HIGH 4>;
+   interrupt-names = "vdec";
+   clocks = <&pmc PMC_TYPE_PERIPHERAL 19>;
+   clock-names = "vdec_clk";
+   };
+
usb0: gadget@40 {
compatible = "atmel,sama5d3-udc";
reg = <0x0040 0x10
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index 0dca50c64503..10806f38abfb 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -200,6 +200,9 @@ CONFIG_RTC_DRV_AT91RM9200=y
 CONFIG_DMADEVICES=y
 CONFIG_AT_HDMAC=y
 CONFIG_AT_XDMAC=y
+CONFIG_STAGING=y
+CONFIG_STAGING_MEDIA=y
+CONFIG_VIDEO_HANTRO=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_IIO=y
 CONFIG_AT91_ADC=y
diff --git a/drivers/staging/media/hantro/Kconfig 
b/drivers/staging/media/hantro/Kconfig
index 5b6cf9f62b1a..43762c8164e0 100644
--- a/drivers/staging/media/hantro/Kconfig
+++ b/drivers/staging/media/hantro/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 config VIDEO_HANTRO
tristate "Hantro VPU driver"
-   depends on ARCH_MXC || ARCH_ROCKCHIP || COMPILE_TEST
+   depends on ARCH_MXC || ARCH_ROCKCHIP || ARCH_AT91 || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
select MEDIA_CONTROLLER
select MEDIA_CONTROLLER_REQUEST_API
@@ -24,6 +24,14 @@ config VIDEO_HANTRO_IMX8M
help
  Enable support for i.MX8M SoCs.
 
+config VIDEO_HANTRO_SAMA5D4
+   bool "Hantro VDEC SAMA5D4 support"
+   depends on VIDEO_HANTRO
+   depends on ARCH_AT91 || COMPILE_TEST
+   default y
+   help
+ Enable support for Atmel SAMA5D4 SoCs.
+
 config VIDEO_HANTRO_ROCKCHIP
bool "Hantro VPU Rockchip support"
depends on VIDEO_HANTRO
diff --git a/drivers/staging/media/hantro/Makefile 
b/drivers/staging/media/hantro/Makefile
index 3747a32799b2..f4b99901 100644
--- a/drivers/staging/media/hantro/Makefile
+++ b/drivers/staging/media/hantro/Makefile
@@ -22,6 +22,9 @@ hantro-vpu-y += \
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_IMX8M) += \
imx8m_vpu_hw.o
 
+hantro-vpu-$(CONFIG_VIDEO_HANTRO_SAMA5D4) += \
+   sama5d4_vdec_hw.o
+
 hantro-vpu-$(CONFIG_VIDEO_HANTRO_ROCKCHIP) += \
rk3288_vpu_hw.o \
rk3399_vpu_hw.o
diff --git a/drivers/staging/media/hantro/hantro_drv.c 
b/drivers/staging/media/hantro/hantro_drv.c
index e5f200e64993..19f1202574a2 100644
--- a/drivers/staging/media/hantro/hantro_drv.c
+++ b/drivers/staging/media/hantro/hantro_drv.c
@@ -478,6 +478,9 @@ static const struct of_device_id of_hantro_match[] = {
 #endif
 #ifdef CONFIG_VIDEO_HANTRO_IMX8M
{ .compatible = "nxp,imx8mq-vpu", .data = &imx8mq_vpu_variant, },
+#endif
+#ifdef CONFIG_VIDEO_HANTRO_SAMA5D4
+   { .compatible = "atmel,sama5d4-vdec", .data = &sama5d4_vdec_variant, },
 #endif
{ /* sentinel */ }
 };
diff --git a/drivers/staging/media/hantro/hantro_hw.h 
b/drivers/staging/media/hantro/hantro_hw.h
index 73c71bb2320c..4d39da1d1581 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -152,6 +152,7 @@ extern const struct hantro_variant rk3399_vpu_variant;
 extern const struct hantro_variant rk3328_vpu_variant;
 extern const struct hantro_variant rk3288_vpu_variant;
 extern const struct hantro_variant imx8mq_vpu_variant;
+extern const struct hantro_variant sama5d4_vdec_variant;
 
 extern const struct hantro_postproc_regs hantro_g1_postproc_regs;
 
diff --git a/drivers/staging/media/hantro/sama5d4_vdec_hw.c 
b/drivers/staging/media/hantro/sama5d4_vdec_hw.c
new file mode 100644
index ..9cf1068d986b
--- /dev/null
+++ b/drivers/staging/media/hantr

[PATCH 5/7] media: hantro: introduce hantro_g1.c for common API

[Emil Velikov]

From: Emil Velikov 

The Hantro G1 IRQ and reset handling it pretty standard. I was this
close to duplicating it, yet again, before reconsidering and refactoring
it to a separate file.

Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Emil Velikov 
---
 drivers/staging/media/hantro/Makefile|  1 +
 drivers/staging/media/hantro/hantro_g1.c | 39 
 drivers/staging/media/hantro/hantro_hw.h |  3 ++
 drivers/staging/media/hantro/imx8m_vpu_hw.c  | 21 +--
 drivers/staging/media/hantro/rk3288_vpu_hw.c | 36 ++
 5 files changed, 48 insertions(+), 52 deletions(-)
 create mode 100644 drivers/staging/media/hantro/hantro_g1.c

diff --git a/drivers/staging/media/hantro/Makefile 
b/drivers/staging/media/hantro/Makefile
index 743ce08eb184..3747a32799b2 100644
--- a/drivers/staging/media/hantro/Makefile
+++ b/drivers/staging/media/hantro/Makefile
@@ -7,6 +7,7 @@ hantro-vpu-y += \
hantro_v4l2.o \
hantro_postproc.o \
hantro_h1_jpeg_enc.o \
+   hantro_g1.o \
hantro_g1_h264_dec.o \
hantro_g1_mpeg2_dec.o \
hantro_g1_vp8_dec.o \
diff --git a/drivers/staging/media/hantro/hantro_g1.c 
b/drivers/staging/media/hantro/hantro_g1.c
new file mode 100644
index ..0ab1cee62218
--- /dev/null
+++ b/drivers/staging/media/hantro/hantro_g1.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hantro VPU codec driver
+ *
+ * Copyright (C) 2018 Rockchip Electronics Co., Ltd.
+ * Jeffy Chen 
+ * Copyright (C) 2019 Pengutronix, Philipp Zabel 
+ * Copyright (C) 2021 Collabora Ltd, Emil Velikov 
+ */
+
+#include "hantro.h"
+#include "hantro_g1_regs.h"
+
+irqreturn_t hantro_g1_irq(int irq, void *dev_id)
+{
+   struct hantro_dev *vpu = dev_id;
+   enum vb2_buffer_state state;
+   u32 status;
+
+   status = vdpu_read(vpu, G1_REG_INTERRUPT);
+   state = (status & G1_REG_INTERRUPT_DEC_RDY_INT) ?
+VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
+
+   vdpu_write(vpu, 0, G1_REG_INTERRUPT);
+   vdpu_write(vpu, G1_REG_CONFIG_DEC_CLK_GATE_E, G1_REG_CONFIG);
+
+   hantro_irq_done(vpu, state);
+
+   return IRQ_HANDLED;
+}
+
+void hantro_g1_reset(struct hantro_ctx *ctx)
+{
+   struct hantro_dev *vpu = ctx->dev;
+
+   vdpu_write(vpu, G1_REG_INTERRUPT_DEC_IRQ_DIS, G1_REG_INTERRUPT);
+   vdpu_write(vpu, G1_REG_CONFIG_DEC_CLK_GATE_E, G1_REG_CONFIG);
+   vdpu_write(vpu, 1, G1_REG_SOFT_RESET);
+}
diff --git a/drivers/staging/media/hantro/hantro_hw.h 
b/drivers/staging/media/hantro/hantro_hw.h
index 34c9e4649a25..73c71bb2320c 100644
--- a/drivers/staging/media/hantro/hantro_hw.h
+++ b/drivers/staging/media/hantro/hantro_hw.h
@@ -164,6 +164,9 @@ void hantro_irq_done(struct hantro_dev *vpu,
 void hantro_start_prepare_run(struct hantro_ctx *ctx);
 void hantro_end_prepare_run(struct hantro_ctx *ctx);
 
+irqreturn_t hantro_g1_irq(int irq, void *dev_id);
+void hantro_g1_reset(struct hantro_ctx *ctx);
+
 void hantro_h1_jpeg_enc_run(struct hantro_ctx *ctx);
 void rk3399_vpu_jpeg_enc_run(struct hantro_ctx *ctx);
 int hantro_jpeg_enc_init(struct hantro_ctx *ctx);
diff --git a/drivers/staging/media/hantro/imx8m_vpu_hw.c 
b/drivers/staging/media/hantro/imx8m_vpu_hw.c
index f36c1bd681ba..9eb556460e52 100644
--- a/drivers/staging/media/hantro/imx8m_vpu_hw.c
+++ b/drivers/staging/media/hantro/imx8m_vpu_hw.c
@@ -9,7 +9,6 @@
 #include 
 
 #include "hantro.h"
-#include "hantro_g1_regs.h"
 
 #define CTRL_SOFT_RESET0x00
 #define RESET_G1   BIT(1)
@@ -129,24 +128,6 @@ static const struct hantro_fmt imx8m_vpu_dec_fmts[] = {
},
 };
 
-static irqreturn_t imx8m_vpu_g1_irq(int irq, void *dev_id)
-{
-   struct hantro_dev *vpu = dev_id;
-   enum vb2_buffer_state state;
-   u32 status;
-
-   status = vdpu_read(vpu, G1_REG_INTERRUPT);
-   state = (status & G1_REG_INTERRUPT_DEC_RDY_INT) ?
-VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
-
-   vdpu_write(vpu, 0, G1_REG_INTERRUPT);
-   vdpu_write(vpu, G1_REG_CONFIG_DEC_CLK_GATE_E, G1_REG_CONFIG);
-
-   hantro_irq_done(vpu, state);
-
-   return IRQ_HANDLED;
-}
-
 static int imx8mq_vpu_hw_init(struct hantro_dev *vpu)
 {
vpu->ctrl_base = vpu->reg_bases[vpu->variant->num_regs - 1];
@@ -191,7 +172,7 @@ static const struct hantro_codec_ops imx8mq_vpu_codec_ops[] 
= {
  */
 
 static const struct hantro_irq imx8mq_irqs[] = {
-   { "g1", imx8m_vpu_g1_irq },
+   { "g1", hantro_g1_irq },
{ "g2", NULL /* TODO: imx8m_vpu_g2_irq */ },
 };
 
diff --git a/drivers/staging/media/hantro/rk3288_vpu_hw.c 
b/drivers/staging/media/hantro/rk3288_vpu_hw.c
index 7b299ee3e93d..fefd45269e52 100644
--- a/drivers/staging/media/hantro/rk3288_vpu_hw.c
+++ b/drivers/staging/media/hantro/rk3288_vpu_hw.c
@@ -10,7 +10,6 @@
 
 #include "hantro.h"
 #include "hant

Re: [PATCH][next] drm/amdgpu/display: remove redundant continue statement

[Alex Deucher]

Applied.  thanks.

Alex

On Wed, Mar 3, 2021 at 8:25 AM Colin King  wrote:
>
> From: Colin Ian King 
>
> The continue statement in a for-loop is redudant and can be removed.
> Clean up the code to address this.
>
> Addresses-Coverity: ("Continue as no effect")
> Fixes: b6f91fc183f7 ("drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT 
> interrupt work")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
> index 8ce10d0973c5..d3c687d07ee6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
> @@ -520,9 +520,7 @@ static void amdgpu_dm_irq_schedule_work(struct 
> amdgpu_device *adev,
> return;
>
> list_for_each_entry (handler_data, handler_list, list) {
> -   if (!queue_work(system_highpri_wq, &handler_data->work)) {
> -   continue;
> -   } else {
> +   if (queue_work(system_highpri_wq, &handler_data->work)) {
> work_queued = true;
> break;
> }
> --
> 2.30.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/radeon/si_dpm: Replace one-element array with flexible-array in struct SISLANDS_SMC_SWSTATE

[Alex Deucher]

Applied.  Thanks!

Alex

On Wed, Mar 3, 2021 at 2:05 PM Gustavo A. R. Silva
 wrote:
>
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> style of one-element or zero-length arrays should no longer be used[2].
>
> Refactor the code according to the use of a flexible-array member in
> struct SISLANDS_SMC_SWSTATE, instead of a one-element array, and use
> the struct_size() helper to calculate the size for the allocation.
>
> Also, this helps with the ongoing efforts to enable -Warray-bounds by
> fixing the following warnings:
>
> drivers/gpu/drm/radeon/si_dpm.c: In function ‘si_convert_power_state_to_smc’:
> drivers/gpu/drm/radeon/si_dpm.c:2350:20: warning: array subscript 1 is above 
> array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2350 |   smc_state->levels[i].dpm2.MaxPS = 
> (u8)((SISLANDS_DPM2_MAX_PULSE_SKIP * (max_sclk - min_sclk)) / max_sclk);
>   |   ~^~~
> drivers/gpu/drm/radeon/si_dpm.c:2351:20: warning: array subscript 1 is above 
> array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2351 |   smc_state->levels[i].dpm2.NearTDPDec = SISLANDS_DPM2_NEAR_TDP_DEC;
>   |   ~^~~
> drivers/gpu/drm/radeon/si_dpm.c:2352:20: warning: array subscript 1 is above 
> array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2352 |   smc_state->levels[i].dpm2.AboveSafeInc = 
> SISLANDS_DPM2_ABOVE_SAFE_INC;
>   |   ~^~~
> drivers/gpu/drm/radeon/si_dpm.c:2353:20: warning: array subscript 1 is above 
> array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2353 |   smc_state->levels[i].dpm2.BelowSafeInc = 
> SISLANDS_DPM2_BELOW_SAFE_INC;
>   |   ~^~~
> drivers/gpu/drm/radeon/si_dpm.c:2354:20: warning: array subscript 1 is above 
> array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  2354 |   smc_state->levels[i].dpm2.PwrEfficiencyRatio = 
> cpu_to_be16(pwr_efficiency_ratio);
>   |   ~^~~
> drivers/gpu/drm/radeon/si_dpm.c:5105:20: warning: array subscript 1 is above 
> array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct 
> SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds]
>  5105 |   smc_state->levels[i + 1].aT = cpu_to_be32(a_t);
>   |   ~^~~
>
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] 
> https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays
>
> Link: https://github.com/KSPP/linux/issues/79
> Link: https://github.com/KSPP/linux/issues/109
> Build-tested-by: kernel test robot 
> Link: https://lore.kernel.org/lkml/603f9a8f.adlrpmfzzsapzvyq%25...@intel.com/
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/gpu/drm/radeon/si_dpm.c   |  5 ++---
>  drivers/gpu/drm/radeon/sislands_smc.h | 10 +-
>  2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index 91bfc4762767..918609551804 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -5250,10 +5250,9 @@ static int si_upload_sw_state(struct radeon_device 
> *rdev,
> int ret;
> u32 address = si_pi->state_table_start +
> offsetof(SISLANDS_SMC_STATETABLE, driverState);
> -   u32 state_size = sizeof(SISLANDS_SMC_SWSTATE) +
> -   ((new_state->performance_level_count - 1) *
> -sizeof(SISLANDS_SMC_HW_PERFORMANCE_LEVEL));
> SISLANDS_SMC_SWSTATE *smc_state = &si_pi->smc_statetable.driverState;
> +   size_t state_size = struct_size(smc_state, levels,
> +   new_state->performance_level_count);
>
> memset(smc_state, 0, state_size);
>
> diff --git a/drivers/gpu/drm/radeon/sislands_smc.h 
> b/drivers/gpu/drm/radeon/sislands_smc.h
> index 966e3a556011..fbd6589bdab9 100644
> --- a/drivers/gpu/drm/radeon/sislands_smc.h
> +++ b/drivers/gpu/drm/radeon/sislands_smc.h
> @@ -182,11 +182,11 @@ typedef struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL 
> SISLANDS_SMC_HW_PERFORMANCE_LEV
>
>  struct SISLANDS_SMC_SWSTATE
>  {
> -uint8_t flags;
> -uint8_t levelCount;
> -uint8_t padding2;
> -uint8_t padding3;
> -SISLANDS_SMC_HW_PERFORMANCE_LEVEL   levels[1];
> +   uint8_t flags;
> +   uint8_t levelCount;
> +  

Re: [PATCH] drm/amd/display: Remove unnecessary conversion to bool

[Alex Deucher]

The same patch was already applied a while ago.

Thanks,

Alex

On Fri, Mar 5, 2021 at 1:41 AM Jiapeng Chong
 wrote:
>
> Fix the following coccicheck warnings:
>
> ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8257:16-21: WARNING:
> conversion to bool not needed here.
>
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3e1fd1e..10de6c2 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8307,8 +8307,7 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
> hdcp_update_display(
> adev->dm.hdcp_workqueue, 
> aconnector->dc_link->link_index, aconnector,
> new_con_state->hdcp_content_type,
> -   new_con_state->content_protection == 
> DRM_MODE_CONTENT_PROTECTION_DESIRED ? true
> - 
>: false);
> +   new_con_state->content_protection == 
> DRM_MODE_CONTENT_PROTECTION_DESIRED);
> }
>  #endif
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7] dt-bindings: display: panel: one file of all simple LVDS panels with dual ports

[Rob Herring]

On Thu, 11 Feb 2021 12:27:52 +0800, Liu Ying wrote:
> To complement panel-simple.yaml, create panel-simple-lvds-dual-ports.yaml.
> panel-simple-lvds-dual-ports.yaml is for all simple LVDS panels that
> have dual LVDS ports and require only a single power-supply.
> The first port receives odd pixels, and the second port receives even pixels.
> Optionally, a backlight and an enable GPIO can be specified as properties.
> 
> Panels with swapped pixel order, if any, need dedicated bindings.
> 
> Migrate 'auo,g133han01', 'auo,g185han01', 'auo,g190ean01',
> 'koe,tx26d202vm0bwa' and 'nlt,nl192108ac18-02d' over to the new file.
> 
> The objectives with one file for all the simple LVDS panels with dual ports 
> are:
> - Make it simpler to add bindings for this kind of LVDS panels
> - Keep the number of bindings file lower
> - Keep the binding documentation for this kind of LVDS panels more consistent
> - Make it possible for drivers to get pixel order via
>   drm_of_lvds_get_dual_link_pixel_order(), as the 'ports' property is required
> 
> Suggested-by: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rob Herring 
> Cc: Lucas Stach 
> Cc: Sebastian Reichel 
> Signed-off-by: Liu Ying 
> ---
> v6->v7:
> * Reference '#/$defs/port-base' instead of '#/properties/port'. (Rob)
> 
> v5->v6:
> * Use OF graph schema.
> * Drop Rob's R-b tag, as review is needed.
> 
> v4->v5:
> * Require the 'ports' property and update commit message accordingly. (Rob)
> * Add Rob's R-b tag.
> 
> v3->v4:
> * Add type and descriptions for dual-lvds-{odd,even}-pixels properties.
>   Also, update descriptions for port@0 and port@1 properties accordingly. 
> (Rob)
> 
> v2->v3:
> * Do not allow 'port' property. (Rob)
> * Define port number. (Rob)
> * Specify 'dual-lvds-odd-pixels' and 'dual-lvds-even-pixels' properties. (Rob)
> 
> v1->v2:
> * Correct pixel order in example LVDS panel node.
> 
>  .../panel/panel-simple-lvds-dual-ports.yaml| 118 
> +
>  .../bindings/display/panel/panel-simple.yaml   |  10 --
>  2 files changed, 118 insertions(+), 10 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml
> 

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

[PATCH 2/3] drm/msm/dp: Fix incorrect NULL check kbot warnings in DP driver

[Abhinav Kumar]

Fix an incorrect NULL check reported by kbot in the MSM DP driver

smatch warnings:
drivers/gpu/drm/msm/dp/dp_hpd.c:37 dp_hpd_connect()
error: we previously assumed 'hpd_priv->dp_cb' could be null
(see line 37)

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dp/dp_hpd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_hpd.c b/drivers/gpu/drm/msm/dp/dp_hpd.c
index 5b8fe3202..e1c90fa 100644
--- a/drivers/gpu/drm/msm/dp/dp_hpd.c
+++ b/drivers/gpu/drm/msm/dp/dp_hpd.c
@@ -34,8 +34,8 @@ int dp_hpd_connect(struct dp_usbpd *dp_usbpd, bool hpd)
 
dp_usbpd->hpd_high = hpd;
 
-   if (!hpd_priv->dp_cb && !hpd_priv->dp_cb->configure
-   && !hpd_priv->dp_cb->disconnect) {
+   if (!hpd_priv->dp_cb || !hpd_priv->dp_cb->configure
+   || !hpd_priv->dp_cb->disconnect) {
pr_err("hpd dp_cb not initialized\n");
return -EINVAL;
}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 1/3] drm/msm/dp: Fix indentation kbot warnings in DP driver

[Abhinav Kumar]

Fix a couple of indentation warnings reported by
kbot across MSM DP driver:

New smatch warnings:
drivers/gpu/drm/msm/dp/dp_debug.c:229 dp_test_data_show()
warn: inconsistent indenting

drivers/gpu/drm/msm/dp/dp_power.c:203 dp_power_clk_enable()
warn: inconsistent indenting

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dp/dp_debug.c | 2 +-
 drivers/gpu/drm/msm/dp/dp_power.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c 
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 84670bc..6c6998f 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -226,7 +226,7 @@ static int dp_test_data_show(struct seq_file *m, void *data)
debug->link->test_video.test_h_width);
seq_printf(m, "vdisplay: %d\n",
debug->link->test_video.test_v_height);
-   seq_printf(m, "bpc: %u\n",
+   seq_printf(m, "bpc: %u\n",
dp_link_bit_depth_to_bpc(bpc));
} else
seq_puts(m, "0");
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c 
b/drivers/gpu/drm/msm/dp/dp_power.c
index 9c4ea00..3961ba4 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -269,7 +269,7 @@ int dp_power_clk_enable(struct dp_power *dp_power,
DRM_ERROR("failed to '%s' clks for: %s. err=%d\n",
enable ? "enable" : "disable",
dp_parser_pm_name(pm_type), rc);
-   return rc;
+   return rc;
}
 
if (pm_type == DP_CORE_PM)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 3/3] drm/msm/dp: delete unnecessary debugfs error handling

[Abhinav Kumar]

Currently the error checking logic in the dp_debug module could
pass zero to PTR_ERR and it causes the below kbot warnings:

drivers/gpu/drm/msm/dp/dp_debug.c:378 dp_debug_init()
warn: passing zero to 'PTR_ERR'
drivers/gpu/drm/msm/dp/dp_debug.c:387 dp_debug_init()
warn: passing zero to 'PTR_ERR'
drivers/gpu/drm/msm/dp/dp_debug.c:396 dp_debug_init()
warn: passing zero to 'PTR_ERR'
drivers/gpu/drm/msm/dp/dp_debug.c:405 dp_debug_init()
warn: passing zero to 'PTR_ERR'

Debugfs functions are not supposed to be checked in the normal
case so delete this code.  Also it silences the above Smatch
warnings that we're checking for NULL when these functions only
return error pointers.

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dp/dp_debug.c | 31 ---
 1 file changed, 4 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c 
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 6c6998f..2f6247e 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -368,44 +368,21 @@ static int dp_debug_init(struct dp_debug *dp_debug, 
struct drm_minor *minor)
int rc = 0;
struct dp_debug_private *debug = container_of(dp_debug,
struct dp_debug_private, dp_debug);
-   struct dentry *file;
-   struct dentry *test_active;
-   struct dentry *test_data, *test_type;
 
-   file = debugfs_create_file("dp_debug", 0444, minor->debugfs_root,
+   debugfs_create_file("dp_debug", 0444, minor->debugfs_root,
debug, &dp_debug_fops);
-   if (IS_ERR_OR_NULL(file)) {
-   rc = PTR_ERR(file);
-   DRM_ERROR("[%s] debugfs create file failed, rc=%d\n",
- DEBUG_NAME, rc);
-   }
 
-   test_active = debugfs_create_file("msm_dp_test_active", 0444,
+   debugfs_create_file("msm_dp_test_active", 0444,
minor->debugfs_root,
debug, &test_active_fops);
-   if (IS_ERR_OR_NULL(test_active)) {
-   rc = PTR_ERR(test_active);
-   DRM_ERROR("[%s] debugfs test_active failed, rc=%d\n",
- DEBUG_NAME, rc);
-   }
 
-   test_data = debugfs_create_file("msm_dp_test_data", 0444,
+   debugfs_create_file("msm_dp_test_data", 0444,
minor->debugfs_root,
debug, &dp_test_data_fops);
-   if (IS_ERR_OR_NULL(test_data)) {
-   rc = PTR_ERR(test_data);
-   DRM_ERROR("[%s] debugfs test_data failed, rc=%d\n",
- DEBUG_NAME, rc);
-   }
 
-   test_type = debugfs_create_file("msm_dp_test_type", 0444,
+   debugfs_create_file("msm_dp_test_type", 0444,
minor->debugfs_root,
debug, &dp_test_type_fops);
-   if (IS_ERR_OR_NULL(test_type)) {
-   rc = PTR_ERR(test_type);
-   DRM_ERROR("[%s] debugfs test_type failed, rc=%d\n",
- DEBUG_NAME, rc);
-   }
 
debug->root = minor->debugfs_root;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH][next] drm/radeon/si_dpm: Replace one-element array with flexible-array in struct SISLANDS_SMC_SWSTATE

[Gustavo A. R. Silva]

On Fri, Mar 05, 2021 at 02:10:44PM -0500, Alex Deucher wrote:
> Applied.  Thanks!

Awesome. :)

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

[Bug 212077] New: AMD GPU at highest frequency even not in use

[bugzilla-daemon]

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

Bug ID: 212077
   Summary: AMD GPU at highest frequency even not in use
   Product: Drivers
   Version: 2.5
Kernel Version: 5.11.3
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: bat_ma...@abv.bg
Regression: No

Created attachment 295677
  --> https://bugzilla.kernel.org/attachment.cgi?id=295677&action=edit
Dmesg

1.240847] amdgpu: Clock is not in range of specified clock range for watermark
from DAL!  Using highest water mark set.
[1.240850] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240851] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240852] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240853] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240854] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240855] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240856] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240857] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
[1.240858] amdgpu: Clock is not in range of specified clock range for
watermark from DAL!  Using highest water mark set.
Dmesg attached

-- 
You may reply to this email to add a comment.

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 212077] AMD GPU discrete card memory at highest frequency even not in use

[bugzilla-daemon]

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

Bat Malin (bat_ma...@abv.bg) changed:

   What|Removed |Added

Summary|AMD GPU at highest  |AMD GPU discrete card
   |frequency even not in use   |memory at highest frequency
   ||even not in use

-- 
You may reply to this email to add a comment.

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