[PATCH 1/6] drm: Inline AGP wrappers into their only callers
The AGP wrapper functions serve no purpose.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_agpsupport.c | 12 ++--
drivers/gpu/drm/drm_memory.c | 18 --
include/drm/drm_agpsupport.h | 18 --
3 files changed, 6 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 4c7ad46fdd21..8b690ef306de 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -285,7 +285,7 @@ int drm_agp_unbind(struct drm_device *dev, struct
drm_agp_binding *request)
entry = drm_agp_lookup_entry(dev, request->handle);
if (!entry || !entry->bound)
return -EINVAL;
- ret = drm_unbind_agp(entry->memory);
+ ret = agp_unbind_memory(entry->memory);
if (ret == 0)
entry->bound = 0;
return ret;
@@ -326,7 +326,7 @@ int drm_agp_bind(struct drm_device *dev, struct
drm_agp_binding *request)
if (!entry || entry->bound)
return -EINVAL;
page = DIV_ROUND_UP(request->offset, PAGE_SIZE);
- retcode = drm_bind_agp(entry->memory, page);
+ retcode = agp_bind_memory(entry->memory, page);
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
@@ -369,11 +369,11 @@ int drm_agp_free(struct drm_device *dev, struct
drm_agp_buffer *request)
if (!entry)
return -EINVAL;
if (entry->bound)
- drm_unbind_agp(entry->memory);
+ agp_unbind_memory(entry->memory);
list_del(&entry->head);
- drm_free_agp(entry->memory, entry->pages);
+ agp_free_memory(entry->memory);
kfree(entry);
return 0;
}
@@ -453,8 +453,8 @@ void drm_legacy_agp_clear(struct drm_device *dev)
list_for_each_entry_safe(entry, tempe, &dev->agp->memory, head) {
if (entry->bound)
- drm_unbind_agp(entry->memory);
- drm_free_agp(entry->memory, entry->pages);
+ agp_unbind_memory(entry->memory);
+ agp_free_memory(entry->memory);
kfree(entry);
}
INIT_LIST_HEAD(&dev->agp->memory);
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index fbea69d6f909..f4f2bffdd5bd 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -100,24 +100,6 @@ static void *agp_remap(unsigned long offset, unsigned long
size,
return addr;
}
-/** Wrapper around agp_free_memory() */
-void drm_free_agp(struct agp_memory *handle, int pages)
-{
- agp_free_memory(handle);
-}
-
-/** Wrapper around agp_bind_memory() */
-int drm_bind_agp(struct agp_memory *handle, unsigned int start)
-{
- return agp_bind_memory(handle, start);
-}
-
-/** Wrapper around agp_unbind_memory() */
-int drm_unbind_agp(struct agp_memory *handle)
-{
- return agp_unbind_memory(handle);
-}
-
#else /* CONFIG_AGP */
static inline void *agp_remap(unsigned long offset, unsigned long size,
struct drm_device *dev)
diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
index 664e120b93e6..f3136750c490 100644
--- a/include/drm/drm_agpsupport.h
+++ b/include/drm/drm_agpsupport.h
@@ -28,10 +28,6 @@ struct drm_agp_head {
#if IS_ENABLED(CONFIG_AGP)
-void drm_free_agp(struct agp_memory * handle, int pages);
-int drm_bind_agp(struct agp_memory * handle, unsigned int start);
-int drm_unbind_agp(struct agp_memory * handle);
-
struct drm_agp_head *drm_agp_init(struct drm_device *dev);
void drm_legacy_agp_clear(struct drm_device *dev);
int drm_agp_acquire(struct drm_device *dev);
@@ -61,20 +57,6 @@ int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
#else /* CONFIG_AGP */
-static inline void drm_free_agp(struct agp_memory * handle, int pages)
-{
-}
-
-static inline int drm_bind_agp(struct agp_memory * handle, unsigned int start)
-{
- return -ENODEV;
-}
-
-static inline int drm_unbind_agp(struct agp_memory * handle)
-{
- return -ENODEV;
-}
-
static inline struct drm_agp_head *drm_agp_init(struct drm_device *dev)
{
return NULL;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] Move struct drm_device.hose to legacy section
This patchset moves struct drm_device.hose to the section for legacy drivers. As part of this, a number of other changes are applied in order to protect all uses of hose by CONFIG_DRM_LEGACY. Patches 1 to 3 move non-legacy code out put drm_memory.c and add the remaining I/O-memory helpers to the legacy code. Patch 4 addresses CONFIG_DRM_VM, which is only selected by legacy drivers, so drm_vm.c can directly be compiled by CONFIG_DRM_LEGACY. Patch 5 changes radeon to maintain its own copy of the hose field of struct drm_device. Patch 6 makes the hose field legacy. The patchset has been compile-tested w/o CONFIG_DRM_LEGACY enabled. Thomas Zimmermann (6): drm: Inline AGP wrappers into their only callers drm: Implement drm_need_swiotlb() in drm_cache.c drm: Build drm_memory.o only for legacy drivers drm: Merge CONFIG_DRM_VM into CONFIG_DRM_LEGACY drm/radeon: Store PCI controller in struct radeon_device.hose drm: Move struct drm_device.hose to legacy section drivers/gpu/drm/Kconfig | 5 --- drivers/gpu/drm/Makefile| 6 ++-- drivers/gpu/drm/drm_agpsupport.c| 12 +++ drivers/gpu/drm/drm_cache.c | 32 ++ drivers/gpu/drm/drm_file.c | 2 ++ drivers/gpu/drm/drm_legacy.h| 2 +- drivers/gpu/drm/drm_memory.c| 51 - drivers/gpu/drm/radeon/radeon.h | 3 ++ drivers/gpu/drm/radeon/radeon_drv.c | 4 --- drivers/gpu/drm/radeon/radeon_kms.c | 4 +++ drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- include/drm/drm_agpsupport.h| 18 -- include/drm/drm_device.h| 9 ++--- 13 files changed, 57 insertions(+), 93 deletions(-) base-commit: cd0df21e28c36de80356344ff8683be2813c6ff2 prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm: Implement drm_need_swiotlb() in drm_cache.c
The function is declared in drm_cache.h. I also removed the curly
braces from the for loop to adhere to kernel coding style.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_cache.c | 32
drivers/gpu/drm/drm_memory.c | 33 -
2 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 0fe3c496002a..49551a7fa22f 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
@@ -176,3 +177,34 @@ drm_clflush_virt_range(void *addr, unsigned long length)
#endif
}
EXPORT_SYMBOL(drm_clflush_virt_range);
+
+bool drm_need_swiotlb(int dma_bits)
+{
+ struct resource *tmp;
+ resource_size_t max_iomem = 0;
+
+ /*
+* Xen paravirtual hosts require swiotlb regardless of requested dma
+* transfer size.
+*
+* NOTE: Really, what it requires is use of the dma_alloc_coherent
+* allocator used in ttm_dma_populate() instead of
+* ttm_populate_and_map_pages(), which bounce buffers so much in
+* Xen it leads to swiotlb buffer exhaustion.
+*/
+ if (xen_pv_domain())
+ return true;
+
+ /*
+* Enforce dma_alloc_coherent when memory encryption is active as well
+* for the same reasons as for Xen paravirtual hosts.
+*/
+ if (mem_encrypt_active())
+ return true;
+
+ for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling)
+ max_iomem = max(max_iomem, tmp->end);
+
+ return max_iomem > ((u64)1 << dma_bits);
+}
+EXPORT_SYMBOL(drm_need_swiotlb);
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index f4f2bffdd5bd..e4f20a2eb6e7 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
#include
@@ -138,35 +137,3 @@ void drm_legacy_ioremapfree(struct drm_local_map *map,
struct drm_device *dev)
iounmap(map->handle);
}
EXPORT_SYMBOL(drm_legacy_ioremapfree);
-
-bool drm_need_swiotlb(int dma_bits)
-{
- struct resource *tmp;
- resource_size_t max_iomem = 0;
-
- /*
-* Xen paravirtual hosts require swiotlb regardless of requested dma
-* transfer size.
-*
-* NOTE: Really, what it requires is use of the dma_alloc_coherent
-* allocator used in ttm_dma_populate() instead of
-* ttm_populate_and_map_pages(), which bounce buffers so much in
-* Xen it leads to swiotlb buffer exhaustion.
-*/
- if (xen_pv_domain())
- return true;
-
- /*
-* Enforce dma_alloc_coherent when memory encryption is active as well
-* for the same reasons as for Xen paravirtual hosts.
-*/
- if (mem_encrypt_active())
- return true;
-
- for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
- max_iomem = max(max_iomem, tmp->end);
- }
-
- return max_iomem > ((u64)1 << dma_bits);
-}
-EXPORT_SYMBOL(drm_need_swiotlb);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm: Build drm_memory.o only for legacy drivers
The file contains I/O-memory functions that are only used by legacy drivers. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index fefaff4c832d..ba0ecb7756c6 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -5,7 +5,7 @@ drm-y := drm_auth.o drm_cache.o \ drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \ - drm_memory.o drm_drv.o \ + drm_drv.o \ drm_sysfs.o drm_hashtab.o drm_mm.o \ drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \ drm_encoder_slave.o \ @@ -20,7 +20,8 @@ drm-y :=drm_auth.o drm_cache.o \ drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \ drm_managed.o drm_vblank_work.o -drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o +drm-$(CONFIG_DRM_LEGACY) += drm_bufs.o drm_context.o drm_dma.o drm_legacy_misc.o drm_lock.o \ + drm_memory.o drm_scatter.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o drm-$(CONFIG_DRM_VM) += drm_vm.o drm-$(CONFIG_COMPAT) += drm_ioc32.o -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm: Move struct drm_device.hose to legacy section
The field is only relevant for legacy DRM drivers. Its only non-legacy
user in the DRM core is in drm_file.c. This code is now protected by
CONFIG_DRM_LEGACY. Radeon, the only driver that used the field, has been
changed to maintain it's own copy.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_file.c | 2 ++
include/drm/drm_device.h | 9 +
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 80886d50d0f1..86c405d86a68 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -370,6 +370,7 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
list_add(&priv->lhead, &dev->filelist);
mutex_unlock(&dev->filelist_mutex);
+#ifdef CONFIG_DRM_LEGACY
#ifdef __alpha__
/*
* Default the hose
@@ -389,6 +390,7 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
dev->hose = b->sysdata;
}
}
+#endif
#endif
return 0;
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 939904ae88fc..d647223e8390 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -282,10 +282,6 @@ struct drm_device {
/** @pdev: PCI device structure */
struct pci_dev *pdev;
-#ifdef __alpha__
- /** @hose: PCI hose, only used on ALPHA platforms. */
- struct pci_controller *hose;
-#endif
/** @num_crtcs: Number of CRTCs on this device */
unsigned int num_crtcs;
@@ -328,6 +324,11 @@ struct drm_device {
/* List of devices per driver for stealth attach cleanup */
struct list_head legacy_dev_list;
+#ifdef __alpha__
+ /** @hose: PCI hose, only used on ALPHA platforms. */
+ struct pci_controller *hose;
+#endif
+
/* Context handle management - linked list of context handles */
struct list_head ctxlist;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/radeon: Store PCI controller in struct radeon_device.hose
Moves struct drm_device.hose into struct radeon_device. The field in
struct DRM device is only for legacy drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon.h | 3 +++
drivers/gpu/drm/radeon/radeon_drv.c | 4
drivers/gpu/drm/radeon/radeon_kms.c | 4
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
4 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 6bcb851d7e22..f09989bdce98 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2313,6 +2313,9 @@ struct radeon_device {
struct device *dev;
struct drm_device *ddev;
struct pci_dev *pdev;
+#ifdef __alpha__
+ struct pci_controller *hose;
+#endif
struct rw_semaphore exclusive_lock;
/* ASIC */
union radeon_asic_configconfig;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 8193a2e9c415..efeb115ae70e 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -342,10 +342,6 @@ static int radeon_pci_probe(struct pci_dev *pdev,
if (ret)
goto err_free;
-#ifdef __alpha__
- dev->hose = pdev->sysdata;
-#endif
-
pci_set_drvdata(pdev, dev);
if (pci_find_capability(pdev, PCI_CAP_ID_AGP))
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 7c360d31ab6a..2479d6ab7a36 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -115,6 +115,10 @@ int radeon_driver_load_kms(struct drm_device *dev,
unsigned long flags)
}
dev->dev_private = (void *)rdev;
+#ifdef __alpha__
+ rdev->hose = pdev->sysdata;
+#endif
+
/* update BUS flag */
if (pci_find_capability(pdev, PCI_CAP_ID_AGP)) {
flags |= RADEON_IS_AGP;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 35b715f82ed8..e8c66d10478f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -324,7 +324,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device
*bdev, struct ttm_reso
* access, as done in ttm_bo_vm_fault().
*/
mem->bus.offset = (mem->bus.offset & 0x0UL) +
- rdev->ddev->hose->dense_mem_base;
+ rdev->hose->dense_mem_base;
#endif
break;
default:
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm: Merge CONFIG_DRM_VM into CONFIG_DRM_LEGACY
CONFIG_DRM_VM gets selected by CONFIG_DRM_LEGACY, but nothing else. So
remove it and build drm_vm.o as part of CONFIG_DRM_LEGACY.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconfig | 5 -
drivers/gpu/drm/Makefile | 3 +--
drivers/gpu/drm/drm_legacy.h | 2 +-
3 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..8bf103de1594 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -214,10 +214,6 @@ config DRM_GEM_SHMEM_HELPER
help
Choose this if you need the GEM shmem helper functions
-config DRM_VM
- bool
- depends on DRM && MMU
-
config DRM_SCHED
tristate
depends on DRM
@@ -391,7 +387,6 @@ source "drivers/gpu/drm/xlnx/Kconfig"
menuconfig DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
depends on DRM && MMU
- select DRM_VM
help
Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
APIs to user-space, which can be used to circumvent access
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ba0ecb7756c6..926adef289db 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -21,9 +21,8 @@ drm-y :=drm_auth.o drm_cache.o \
drm_managed.o drm_vblank_work.o
drm-$(CONFIG_DRM_LEGACY) += drm_bufs.o drm_context.o drm_dma.o
drm_legacy_misc.o drm_lock.o \
- drm_memory.o drm_scatter.o
+ drm_memory.o drm_scatter.o drm_vm.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
-drm-$(CONFIG_DRM_VM) += drm_vm.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_gem_shmem_helper.o
diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
index 1be3ea320474..f71358f9eac9 100644
--- a/drivers/gpu/drm/drm_legacy.h
+++ b/drivers/gpu/drm/drm_legacy.h
@@ -127,7 +127,7 @@ static inline void drm_legacy_master_rmmaps(struct
drm_device *dev,
static inline void drm_legacy_rmmaps(struct drm_device *dev) {}
#endif
-#if IS_ENABLED(CONFIG_DRM_VM) && IS_ENABLED(CONFIG_DRM_LEGACY)
+#if IS_ENABLED(CONFIG_DRM_LEGACY)
void drm_legacy_vma_flush(struct drm_device *d);
#else
static inline void drm_legacy_vma_flush(struct drm_device *d)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
On Thu, Jan 7, 2021 at 2:52 PM Lyude Paul wrote:
>
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR backlights, in particular VESA and Intel's HDR backlight
> implementations, can end up being more complicated. With Intel's
> proprietary interface, HDR backlight controls always run through the
> DPCD. When the backlight is in SDR backlight mode however, the driver
> may need to bypass the TCON and control the backlight directly through
> PWM.
>
> So, in order to support this we'll need to split our backlight callbacks
> into two groups: a set of high-level backlight control callbacks in
> intel_panel, and an additional set of pwm-specific backlight control
> callbacks. This also implies a functional changes for how these
> callbacks are used:
>
> * We now keep track of two separate backlight level ranges, one for the
> high-level backlight, and one for the pwm backlight range
> * We also keep track of backlight enablement and PWM backlight
> enablement separately
> * Since the currently set backlight level might not be the same as the
> currently programmed PWM backlight level, we stop setting
> panel->backlight.level with the currently programmed PWM backlight
> level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> on the higher level backlight control functions to retrieve the
> current PWM backlight level (in this case, intel_pwm_get_backlight()).
> Note that there are still a few PWM backlight setup callbacks that
> do actually need to retrieve the current PWM backlight level, although
> we no longer save this value in panel->backlight.level like before.
>
> Additionally, we drop the call to lpt_get_backlight() in
> lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
> we get from it and only write it back if we're in CPU mode, and switching
> to PCH mode. The reason for this is because in the original codepath for
> this, it was expected that the intel_panel_bl_funcs->setup() hook would be
> responsible for fetching the initial backlight level. On lpt systems, the
> only time we could ever be in PCH backlight mode is during the initial
> driver load - meaning that outside of the setup() hook, lpt_get_backlight()
> will always be the callback used for retrieving the current backlight
> level. After this patch we still need to fetch and write-back the PCH
> backlight value if we're switching from CPU mode to PCH, but because
> intel_pwm_setup_backlight() will retrieve the backlight level after setup()
> using the get() hook, which always ends up being lpt_get_backlight(). Thus
> - an additional call to lpt_get_backlight() in lpt_setup_backlight() is
> made redundant.
>
> v5:
> * Fix indenting warnings from checkpatch
> v4:
> * Fix commit message
> * Remove outdated comment in intel_panel.c
> * Rename pwm_(min|max) to pwm_level_(min|max)
> * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
> indirection
> * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
> intel_panel_init_backlight_funcs() quite yet
> v3:
> * Reuse intel_panel_bl_funcs() for pwm_funcs
> * Explain why we drop lpt_get_backlight()
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
Whole series is:
Tested-by: Vasily Khoruzhick
> ---
> .../drm/i915/display/intel_display_types.h| 4 +
> drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
> 2 files changed, 187 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 1067bd073c95..ee5c2d50b81a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -252,6 +252,9 @@ struct intel_panel {
> bool alternate_pwm_increment; /* lpt+ */
>
> /* PWM chip */
> + u32 pwm_level_min;
> + u32 pwm_level_max;
> + bool pwm_enabled;
> bool util_pin_active_low; /* bxt+ */
> u8 controller; /* bxt+ only */
> struct pwm_device *pwm;
> @@ -263,6 +266,7 @@ struct intel_panel {
> struct backlight_device *device;
>
> const struct intel_panel_bl_funcs *funcs;
> + const struct intel_panel_bl_funcs *pwm_funcs;
> void (*power)(struct intel_connector *, bool enable);
> } backlight;
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 67f81ae995c4..8c99bf404a32 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -511,25 +511,34 @@ static u32 scale_hw_to_user
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Am 11.01.21 um 17:13 schrieb Daniel Vetter: On Fri, Jan 08, 2021 at 04:49:55PM +, Grodzovsky, Andrey wrote: Ok then, I guess I will proceed with the dummy pages list implementation then. Andrey From: Koenig, Christian Sent: 08 January 2021 09:52 To: Grodzovsky, Andrey ; Daniel Vetter Cc: amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; daniel.vet...@ffwll.ch ; r...@kernel.org ; l.st...@pengutronix.de ; yuq...@gmail.com ; e...@anholt.net ; Deucher, Alexander ; gre...@linuxfoundation.org ; ppaala...@gmail.com ; Wentland, Harry Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object Mhm, I'm not aware of any let over pointer between TTM and GEM and we worked quite hard on reducing the size of the amdgpu_bo, so another extra pointer just for that corner case would suck quite a bit. We have a ton of other pointers in struct amdgpu_bo (or any of it's lower things) which are fairly single-use, so I'm really not much seeing the point in making this a special case. It also means the lifetime management becomes a bit iffy, since we can't throw away the dummy page then the last reference to the bo is released (since we don't track it there), but only when the last pointer to the device is released. Potentially this means a pile of dangling pages hanging around for too long. Yeah, all of them are already on my TODO list, but see below. If you need some ideas for redundant pointers: - destroy callback (kinda not cool to not have this const anyway), we could refcount it all with the overall gem bo. Quite a bit of work. The bigger problems is that TTM based drivers are using the destroy callback pointer to distinct ghost objects from real ones. We first need to get rid of those. I already have a plan for that and ~20% of it implemented, but it is more complicated because of the driver specific backends in Nouveau, Amdgpu and vmwgfx. - bdev pointer, if we move the device ttm stuff into struct drm_device, or create a common struct ttm_device, we can ditch that Yes, exactly that's what my device structure rename patch set is aiming for :) - We could probably merge a few of the fields and find 8 bytes somewhere Please point out where. - we still have 2 krefs, would probably need to fix that before we can merge the destroy callbacks Yes, already on my TODO list as well. But the last time I looked into this I was blocked by the struct_mutex once more. So there's plenty of room still, if the size of a bo struct is really that critical. Imo it's not. It is. See we had a size of struct amdgpu_bo of over 1500 bytes because we stopped caring for that, no we are down to 816 at the moment. We really need to get rid of this duplication of functionality and structure between TTM and GEM. Christian. -Daniel Christian. Am 08.01.21 um 15:46 schrieb Andrey Grodzovsky: Daniel had some objections to this (see bellow) and so I guess I need you both to agree on the approach before I proceed. Andrey On 1/8/21 9:33 AM, Christian König wrote: Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: Hey Christian, just a ping. Was there any question for me here? As far as I can see the best approach would still be to fill the VMA with a single dummy page and avoid pointers in the GEM object. Christian. Andrey On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: On 1/7/21 11:30 AM, Daniel Vetter wrote: On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote: On 1/7/21 11:21 AM, Daniel Vetter wrote: On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote: On 11/23/20 3:01 AM, Christian König wrote: Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky: On 11/21/20 9:15 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: Will be used to reroute CPU mapped BO's page faults once device is removed. Uff, one page for each exported DMA-buf? That's not something we can do. We need to find a different approach here. Can't we call alloc_page() on each fault and link them together so they are freed when the device is finally reaped? For sure better to optimize and allocate on demand when we reach this corner case, but why the linking ? Shouldn't drm_prime_gem_destroy be good enough place to free ? I want to avoid keeping the page in the GEM object. What we can do is to allocate a page on demand for each fault and link the together in the bdev instead. And when the bdev is then finally destroyed after the last application closed we can finally release all of them. Christian. Hey, started to implement this and then realized that by allocating a page for each fault indiscriminately we will be allocating a new page for each faulting virtual address within a VA range belonging the same BO and this is obviously too much and not the intention. Should I instead use let's say a hashtable with the hash key being faulting BO address to actually keep allocating and reusing same dummy z
Re: [PATCH 0/6] Move struct drm_device.hose to legacy section
I'm not even sure the radeon stuff still compiles/works on alpha :) Anyway looks sane to me and the whole set is Reviewed-by: Christian König . Thanks, Christian. Am 12.01.21 um 09:10 schrieb Thomas Zimmermann: This patchset moves struct drm_device.hose to the section for legacy drivers. As part of this, a number of other changes are applied in order to protect all uses of hose by CONFIG_DRM_LEGACY. Patches 1 to 3 move non-legacy code out put drm_memory.c and add the remaining I/O-memory helpers to the legacy code. Patch 4 addresses CONFIG_DRM_VM, which is only selected by legacy drivers, so drm_vm.c can directly be compiled by CONFIG_DRM_LEGACY. Patch 5 changes radeon to maintain its own copy of the hose field of struct drm_device. Patch 6 makes the hose field legacy. The patchset has been compile-tested w/o CONFIG_DRM_LEGACY enabled. Thomas Zimmermann (6): drm: Inline AGP wrappers into their only callers drm: Implement drm_need_swiotlb() in drm_cache.c drm: Build drm_memory.o only for legacy drivers drm: Merge CONFIG_DRM_VM into CONFIG_DRM_LEGACY drm/radeon: Store PCI controller in struct radeon_device.hose drm: Move struct drm_device.hose to legacy section drivers/gpu/drm/Kconfig | 5 --- drivers/gpu/drm/Makefile| 6 ++-- drivers/gpu/drm/drm_agpsupport.c| 12 +++ drivers/gpu/drm/drm_cache.c | 32 ++ drivers/gpu/drm/drm_file.c | 2 ++ drivers/gpu/drm/drm_legacy.h| 2 +- drivers/gpu/drm/drm_memory.c| 51 - drivers/gpu/drm/radeon/radeon.h | 3 ++ drivers/gpu/drm/radeon/radeon_drv.c | 4 --- drivers/gpu/drm/radeon/radeon_kms.c | 4 +++ drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- include/drm/drm_agpsupport.h| 18 -- include/drm/drm_device.h| 9 ++--- 13 files changed, 57 insertions(+), 93 deletions(-) base-commit: cd0df21e28c36de80356344ff8683be2813c6ff2 prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: arc: Use simple encoder
On Tue, Jan 12, 2021 at 10:10:11AM +0800, Tian Tao wrote:
> The arc driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Tian Tao
I have an entire patch series to convert arc over to simple display pipe.
It's not seen much action (I sent it out in Sept last year), I'll send it
out again and cc: you.
-Daniel
> ---
> drivers/gpu/drm/arc/arcpgu_hdmi.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
> b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> index 5283993..71ef75f 100644
> --- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
> +++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> @@ -9,13 +9,10 @@
> #include
> #include
> #include
> +#include
>
> #include "arcpgu.h"
>
> -static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
> {
> struct drm_encoder *encoder;
> @@ -34,8 +31,7 @@ int arcpgu_drm_hdmi_init(struct drm_device *drm, struct
> device_node *np)
>
> encoder->possible_crtcs = 1;
> encoder->possible_clones = 0;
> - ret = drm_encoder_init(drm, encoder, &arcpgu_drm_encoder_funcs,
> -DRM_MODE_ENCODER_TMDS, NULL);
> + ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
> if (ret)
> return ret;
>
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/15] drm/arc: Switch to devm_drm_dev_alloc
- Need to embedded the drm_device, but for now we keep the usual
pointer chasing.
- No more devm_kzalloc, which fixes a lifetime issues on driver
remove.
- No more drm_dev_put, that's done by devm_ now.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_drv.c | 33 +---
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 6aac44b953ad..cd9e932f501e 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -9,6 +9,7 @@
#define _ARCPGU_H_
struct arcpgu_drm_private {
+ struct drm_device drm;
void __iomem*regs;
struct clk *clk;
struct drm_framebuffer *fb;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index f164818ec477..68eb4a31c54b 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -42,18 +42,14 @@ static void arcpgu_setup_mode_config(struct drm_device *drm)
DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
-static int arcpgu_load(struct drm_device *drm)
+static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
{
- struct platform_device *pdev = to_platform_device(drm->dev);
- struct arcpgu_drm_private *arcpgu;
+ struct platform_device *pdev = to_platform_device(arcpgu->drm.dev);
struct device_node *encoder_node = NULL, *endpoint_node = NULL;
+ struct drm_device *drm = &arcpgu->drm;
struct resource *res;
int ret;
- arcpgu = devm_kzalloc(&pdev->dev, sizeof(*arcpgu), GFP_KERNEL);
- if (arcpgu == NULL)
- return -ENOMEM;
-
drm->dev_private = arcpgu;
arcpgu->clk = devm_clk_get(drm->dev, "pxlclk");
@@ -162,30 +158,28 @@ static struct drm_driver arcpgu_drm_driver = {
static int arcpgu_probe(struct platform_device *pdev)
{
- struct drm_device *drm;
+ struct arcpgu_drm_private *arcpgu;
int ret;
- drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev);
- if (IS_ERR(drm))
- return PTR_ERR(drm);
+ arcpgu = devm_drm_dev_alloc(&pdev->dev, &arcpgu_drm_driver,
+ struct arcpgu_drm_private, drm);
+ if (IS_ERR(arcpgu))
+ return PTR_ERR(arcpgu);
- ret = arcpgu_load(drm);
+ ret = arcpgu_load(arcpgu);
if (ret)
- goto err_unref;
+ return ret;
- ret = drm_dev_register(drm, 0);
+ ret = drm_dev_register(&arcpgu->drm, 0);
if (ret)
goto err_unload;
- drm_fbdev_generic_setup(drm, 16);
+ drm_fbdev_generic_setup(&arcpgu->drm, 16);
return 0;
err_unload:
- arcpgu_unload(drm);
-
-err_unref:
- drm_dev_put(drm);
+ arcpgu_unload(&arcpgu->drm);
return ret;
}
@@ -196,7 +190,6 @@ static int arcpgu_remove(struct platform_device *pdev)
drm_dev_unregister(drm);
arcpgu_unload(drm);
- drm_dev_put(drm);
return 0;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/15] drm/arc: Stop using drm_device->dev_private
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 2 ++
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 ++--
drivers/gpu/drm/arc/arcpgu_drv.c | 4 +---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index cd9e932f501e..87821c91a00c 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -17,6 +17,8 @@ struct arcpgu_drm_private {
struct drm_plane*plane;
};
+#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
+
#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 042d7b54a6de..c32038b6366f 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -178,7 +178,7 @@ static const struct drm_plane_funcs arc_pgu_plane_funcs = {
static struct drm_plane *arc_pgu_plane_init(struct drm_device *drm)
{
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
struct drm_plane *plane = NULL;
int ret;
@@ -202,7 +202,7 @@ static struct drm_plane *arc_pgu_plane_init(struct
drm_device *drm)
int arc_pgu_setup_crtc(struct drm_device *drm)
{
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
struct drm_plane *primary;
int ret;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 68eb4a31c54b..c6a8deb56b0f 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -50,8 +50,6 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
struct resource *res;
int ret;
- drm->dev_private = arcpgu;
-
arcpgu->clk = devm_clk_get(drm->dev, "pxlclk");
if (IS_ERR(arcpgu->clk))
return PTR_ERR(arcpgu->clk);
@@ -120,7 +118,7 @@ static int arcpgu_show_pxlclock(struct seq_file *m, void
*arg)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *drm = node->minor->dev;
- struct arcpgu_drm_private *arcpgu = drm->dev_private;
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
unsigned long clkrate = clk_get_rate(arcpgu->clk);
unsigned long mode_clock = arcpgu->crtc.mode.crtc_clock * 1000;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/15] drm/arc: Delete arcpgu_priv->fb
Leftover from the conversion to the generic fbdev emulation.
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 87821c91a00c..ed77dd5dd5cb 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -12,7 +12,6 @@ struct arcpgu_drm_private {
struct drm_device drm;
void __iomem*regs;
struct clk *clk;
- struct drm_framebuffer *fb;
struct drm_crtc crtc;
struct drm_plane*plane;
};
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/15] drm/arc: Embedd a drm_connector for sim case
Removes the last devm_kzalloc, which means we're now prepared to use
drmm_mode_config_cleanup!
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_sim.c | 14 +-
2 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 52afd638a4d2..c52cdd2274e1 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -15,6 +15,7 @@ struct arcpgu_drm_private {
void __iomem*regs;
struct clk *clk;
struct drm_simple_display_pipe pipe;
+ struct drm_connectorsim_conn;
};
#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 134afb9fa625..e42fe5d05a3d 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -18,10 +18,6 @@
#define YRES_MAX 8192
-struct arcpgu_drm_connector {
- struct drm_connector connector;
-};
-
static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
{
int count;
@@ -57,7 +53,6 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
{
struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
- struct arcpgu_drm_connector *arcpgu_connector;
struct drm_encoder *encoder;
struct drm_connector *connector;
int ret;
@@ -72,14 +67,7 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
if (ret)
return ret;
- arcpgu_connector = devm_kzalloc(drm->dev, sizeof(*arcpgu_connector),
- GFP_KERNEL);
- if (!arcpgu_connector) {
- ret = -ENOMEM;
- goto error_encoder_cleanup;
- }
-
- connector = &arcpgu_connector->connector;
+ connector = &arcpgu->sim_conn;
drm_connector_helper_add(connector, &arcpgu_drm_connector_helper_funcs);
ret = drm_connector_init(drm, connector, &arcpgu_drm_connector_funcs,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/15] drm/arc: Drop surplus connector registration
drm_connector_register does nothing before drm_dev_register(), it
is meant for hotpluggable connectors only. Same for the unregister side.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_sim.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index e42fe5d05a3d..3772df1647aa 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -29,7 +29,6 @@ static int arcpgu_drm_connector_get_modes(struct
drm_connector *connector)
static void arcpgu_drm_connector_destroy(struct drm_connector *connector)
{
- drm_connector_unregister(connector);
drm_connector_cleanup(connector);
}
@@ -80,7 +79,6 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
ret = drm_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
- drm_connector_unregister(connector);
goto error_connector_cleanup;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/15] drm/arc: Embedded a drm_simple_display_pipe
This is a prep step to convert arc over to the simple kms helpers, for
now we just use this as an embedding container to drop all the various
allocations. Big change is the removal of the various devm_kzalloc,
which have the wrong lifetimes anyway.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 7 ---
drivers/gpu/drm/arc/arcpgu_crtc.c | 9 +++--
drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
drivers/gpu/drm/arc/arcpgu_hdmi.c | 5 ++---
drivers/gpu/drm/arc/arcpgu_sim.c | 5 ++---
5 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index ed77dd5dd5cb..52afd638a4d2 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -8,17 +8,18 @@
#ifndef _ARCPGU_H_
#define _ARCPGU_H_
+#include
+
struct arcpgu_drm_private {
struct drm_device drm;
void __iomem*regs;
struct clk *clk;
- struct drm_crtc crtc;
- struct drm_plane*plane;
+ struct drm_simple_display_pipe pipe;
};
#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
-#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, crtc)
+#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private,
pipe.crtc)
static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
unsigned int reg, u32 value)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index c32038b6366f..31a85c703307 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -182,9 +182,7 @@ static struct drm_plane *arc_pgu_plane_init(struct
drm_device *drm)
struct drm_plane *plane = NULL;
int ret;
- plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
- if (!plane)
- return ERR_PTR(-ENOMEM);
+ plane = &arcpgu->pipe.plane;
ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs,
arc_pgu_supported_formats,
@@ -195,7 +193,6 @@ static struct drm_plane *arc_pgu_plane_init(struct
drm_device *drm)
return ERR_PTR(ret);
drm_plane_helper_add(plane, &arc_pgu_plane_helper_funcs);
- arcpgu->plane = plane;
return plane;
}
@@ -210,13 +207,13 @@ int arc_pgu_setup_crtc(struct drm_device *drm)
if (IS_ERR(primary))
return PTR_ERR(primary);
- ret = drm_crtc_init_with_planes(drm, &arcpgu->crtc, primary, NULL,
+ ret = drm_crtc_init_with_planes(drm, &arcpgu->pipe.crtc, primary, NULL,
&arc_pgu_crtc_funcs, NULL);
if (ret) {
arc_pgu_plane_destroy(primary);
return ret;
}
- drm_crtc_helper_add(&arcpgu->crtc, &arc_pgu_crtc_helper_funcs);
+ drm_crtc_helper_add(&arcpgu->pipe.crtc, &arc_pgu_crtc_helper_funcs);
return 0;
}
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index c6a8deb56b0f..9020352816fa 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -120,7 +120,7 @@ static int arcpgu_show_pxlclock(struct seq_file *m, void
*arg)
struct drm_device *drm = node->minor->dev;
struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
unsigned long clkrate = clk_get_rate(arcpgu->clk);
- unsigned long mode_clock = arcpgu->crtc.mode.crtc_clock * 1000;
+ unsigned long mode_clock = arcpgu->pipe.crtc.mode.crtc_clock * 1000;
seq_printf(m, "hw : %lu\n", clkrate);
seq_printf(m, "mode: %lu\n", mode_clock);
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index 52839934f2fb..dbad2c9237fe 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -18,14 +18,13 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
{
+ struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
struct drm_encoder *encoder;
struct drm_bridge *bridge;
int ret = 0;
- encoder = devm_kzalloc(drm->dev, sizeof(*encoder), GFP_KERNEL);
- if (encoder == NULL)
- return -ENOMEM;
+ encoder = &arcpgu->pipe.encoder;
/* Locate drm bridge from the hdmi encoder DT node */
bridge = of_drm_find_bridge(np);
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 37d961668dfe..134afb9fa625 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -56,14 +56,13 @@ static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
{
+ struct arcpgu_drm_private *arcp
[PATCH 07/15] drm/arc: Use drmm_mode_config_cleanup
With autocleanup through drm_device management we can delete all the
code. Possible now that there's no confusion against devm_kzalloc'ed
structures anymore.
I inlined arcpgu_setup_mode_config because it's tiny and the newly
needed return value handling would have been more ...
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 +---
drivers/gpu/drm/arc/arcpgu_drv.c | 21 +
drivers/gpu/drm/arc/arcpgu_hdmi.c | 6 +-
drivers/gpu/drm/arc/arcpgu_sim.c | 11 ++-
4 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 31a85c703307..43313adb1981 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -209,10 +209,8 @@ int arc_pgu_setup_crtc(struct drm_device *drm)
ret = drm_crtc_init_with_planes(drm, &arcpgu->pipe.crtc, primary, NULL,
&arc_pgu_crtc_funcs, NULL);
- if (ret) {
- arc_pgu_plane_destroy(primary);
+ if (ret)
return ret;
- }
drm_crtc_helper_add(&arcpgu->pipe.crtc, &arc_pgu_crtc_helper_funcs);
return 0;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 9020352816fa..6349e9dc770e 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -30,16 +30,6 @@ static const struct drm_mode_config_funcs
arcpgu_drm_modecfg_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static void arcpgu_setup_mode_config(struct drm_device *drm)
-{
- drm_mode_config_init(drm);
- drm->mode_config.min_width = 0;
- drm->mode_config.min_height = 0;
- drm->mode_config.max_width = 1920;
- drm->mode_config.max_height = 1080;
- drm->mode_config.funcs = &arcpgu_drm_modecfg_funcs;
-}
-
DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
@@ -54,7 +44,15 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
if (IS_ERR(arcpgu->clk))
return PTR_ERR(arcpgu->clk);
- arcpgu_setup_mode_config(drm);
+ ret = drmm_mode_config_init(drm);
+ if (ret)
+ return ret;
+
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+ drm->mode_config.max_width = 1920;
+ drm->mode_config.max_height = 1080;
+ drm->mode_config.funcs = &arcpgu_drm_modecfg_funcs;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
arcpgu->regs = devm_ioremap_resource(&pdev->dev, res);
@@ -108,7 +106,6 @@ static int arcpgu_unload(struct drm_device *drm)
{
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
- drm_mode_config_cleanup(drm);
return 0;
}
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index dbad2c9237fe..925d6d31bb78 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -39,9 +39,5 @@ int arcpgu_drm_hdmi_init(struct drm_device *drm, struct
device_node *np)
return ret;
/* Link drm_bridge to encoder */
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
- if (ret)
- drm_encoder_cleanup(encoder);
-
- return ret;
+ return drm_bridge_attach(encoder, bridge, NULL, 0);
}
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 3772df1647aa..afc34f8b4de0 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -73,21 +73,14 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
DRM_MODE_CONNECTOR_VIRTUAL);
if (ret < 0) {
dev_err(drm->dev, "failed to initialize drm connector\n");
- goto error_encoder_cleanup;
+ return ret;
}
ret = drm_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
- goto error_connector_cleanup;
+ return ret;
}
return 0;
-
-error_connector_cleanup:
- drm_connector_cleanup(connector);
-
-error_encoder_cleanup:
- drm_encoder_cleanup(encoder);
- return ret;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/15] drm/arc: Drop crtc check in arc_pgu_update
It's redundant, drm core guarantees that state->fb is set iff state->crtc is set. v2: I had a misconception about simple helpers here and thought they filter this out. They don't. Issue reported by Eugeniy. Cc: Eugeniy Paltsev Signed-off-by: Daniel Vetter Cc: Alexey Brodkin --- drivers/gpu/drm/arc/arcpgu_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c b/drivers/gpu/drm/arc/arcpgu_crtc.c index ef7dca789868..30fbb3052bc7 100644 --- a/drivers/gpu/drm/arc/arcpgu_crtc.c +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c @@ -134,7 +134,7 @@ static void arc_pgu_update(struct drm_simple_display_pipe *pipe, struct arcpgu_drm_private *arcpgu; struct drm_gem_cma_object *gem; - if (!pipe->plane.state->crtc || !pipe->plane.state->fb) + if (!pipe->plane.state->fb) return; arcpgu = pipe_to_arcpgu_priv(pipe); -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/15] drm/arc: Convert to drm_simple_kms_pipe_helper
Really straighforward, only slight issue is that the sim connector is
created after the pipe is set up, so can't use the helpers perfectly
yet. Subsequent patches will fix that.
Aside from lots of deleting code no functional changes in here.
v2: Delete now unused crtc funcs (0day)
v3: Move endcoder setup removal to right patch (Sam)
Cc: Sam Ravnborg
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 4 +-
drivers/gpu/drm/arc/arcpgu_crtc.c | 111 --
drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
drivers/gpu/drm/arc/arcpgu_hdmi.c | 18 +
drivers/gpu/drm/arc/arcpgu_sim.c | 12
5 files changed, 31 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index c52cdd2274e1..b5c699d14f27 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -20,7 +20,7 @@ struct arcpgu_drm_private {
#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
-#define crtc_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private,
pipe.crtc)
+#define pipe_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, pipe)
static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
unsigned int reg, u32 value)
@@ -34,7 +34,7 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private
*arcpgu,
return ioread32(arcpgu->regs + reg);
}
-int arc_pgu_setup_crtc(struct drm_device *dev);
+int arc_pgu_setup_pipe(struct drm_device *dev);
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 3538c1686ca4..ef7dca789868 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -25,10 +25,9 @@ static const u32 arc_pgu_supported_formats[] = {
DRM_FORMAT_ARGB,
};
-static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
+static void arc_pgu_set_pxl_fmt(struct arcpgu_drm_private *arcpgu)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- const struct drm_framebuffer *fb = crtc->primary->state->fb;
+ const struct drm_framebuffer *fb = arcpgu->pipe.plane.state->fb;
uint32_t pixel_format = fb->format->format;
u32 format = DRM_FORMAT_INVALID;
int i;
@@ -50,19 +49,10 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
arc_pgu_write(arcpgu, ARCPGU_REG_CTRL, reg_ctrl);
}
-static const struct drm_crtc_funcs arc_pgu_crtc_funcs = {
- .destroy = drm_crtc_cleanup,
- .set_config = drm_atomic_helper_set_config,
- .page_flip = drm_atomic_helper_page_flip,
- .reset = drm_atomic_helper_crtc_reset,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
-};
-
-static enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
- const struct
drm_display_mode *mode)
+static enum drm_mode_status arc_pgu_mode_valid(struct drm_simple_display_pipe
*pipe,
+ const struct drm_display_mode
*mode)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
long rate, clk_rate = mode->clock * 1000;
long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */
@@ -109,15 +99,16 @@ static void arc_pgu_mode_set(struct arcpgu_drm_private
*arcpgu)
arc_pgu_write(arcpgu, ARCPGU_REG_STRIDE, 0);
arc_pgu_write(arcpgu, ARCPGU_REG_START_SET, 1);
- arc_pgu_set_pxl_fmt(&arcpgu->pipe.crtc);
+ arc_pgu_set_pxl_fmt(arcpgu);
clk_set_rate(arcpgu->clk, m->crtc_clock * 1000);
}
-static void arc_pgu_crtc_atomic_enable(struct drm_crtc *crtc,
- struct drm_atomic_state *state)
+static void arc_pgu_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
arc_pgu_mode_set(arcpgu);
@@ -127,10 +118,9 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc
*crtc,
ARCPGU_CTRL_ENABLE_MASK);
}
-static void arc_pgu_crtc_atomic_disable(struct drm_crtc *crtc,
- struct drm_atomic_state *state)
+static void arc_pgu_disable(struct drm_simple_display_pipe *pipe)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
[PATCH 13/15] drm/arc: Inline remaining files
At less than 500 lines total feels like the right thing to do.
Also noticed that the simple wrapper around drm_connector_cleanup can
be dropped.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Cc: Alexey Brodkin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 39
drivers/gpu/drm/arc/arcpgu_drv.c | 102 +-
drivers/gpu/drm/arc/arcpgu_regs.h | 31 -
drivers/gpu/drm/arc/arcpgu_sim.c | 74 --
5 files changed, 101 insertions(+), 147 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/arcpgu.h
delete mode 100644 drivers/gpu/drm/arc/arcpgu_regs.h
delete mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index 379a1145bc2f..b26f2495c532 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_sim.o arcpgu_drv.o
+arcpgu-y := arcpgu_drv.o
obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
deleted file mode 100644
index 7dce0c2313ba..
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * ARC PGU DRM driver.
- *
- * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
- */
-
-#ifndef _ARCPGU_H_
-#define _ARCPGU_H_
-
-#include
-
-struct arcpgu_drm_private {
- struct drm_device drm;
- void __iomem*regs;
- struct clk *clk;
- struct drm_simple_display_pipe pipe;
- struct drm_connectorsim_conn;
-};
-
-#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
-
-#define pipe_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, pipe)
-
-static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
-unsigned int reg, u32 value)
-{
- iowrite32(value, arcpgu->regs + reg);
-}
-
-static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
- unsigned int reg)
-{
- return ioread32(arcpgu->regs + reg);
-}
-
-int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
-
-#endif
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 0e959e42893d..0a0b54993773 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -17,13 +17,111 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include "arcpgu.h"
-#include "arcpgu_regs.h"
+#define ARCPGU_REG_CTRL0x00
+#define ARCPGU_REG_STAT0x04
+#define ARCPGU_REG_FMT 0x10
+#define ARCPGU_REG_HSYNC 0x14
+#define ARCPGU_REG_VSYNC 0x18
+#define ARCPGU_REG_ACTIVE 0x1c
+#define ARCPGU_REG_BUF0_ADDR 0x40
+#define ARCPGU_REG_STRIDE 0x50
+#define ARCPGU_REG_START_SET 0x84
+
+#define ARCPGU_REG_ID 0x3FC
+
+#define ARCPGU_CTRL_ENABLE_MASK0x02
+#define ARCPGU_CTRL_VS_POL_MASK0x1
+#define ARCPGU_CTRL_VS_POL_OFST0x3
+#define ARCPGU_CTRL_HS_POL_MASK0x1
+#define ARCPGU_CTRL_HS_POL_OFST0x4
+#define ARCPGU_MODE_XRGB BIT(2)
+#define ARCPGU_STAT_BUSY_MASK 0x02
+
+struct arcpgu_drm_private {
+ struct drm_device drm;
+ void __iomem*regs;
+ struct clk *clk;
+ struct drm_simple_display_pipe pipe;
+ struct drm_connectorsim_conn;
+};
+
+#define dev_to_arcpgu(x) container_of(x, struct arcpgu_drm_private, drm)
+
+#define pipe_to_arcpgu_priv(x) container_of(x, struct arcpgu_drm_private, pipe)
+
+static inline void arc_pgu_write(struct arcpgu_drm_private *arcpgu,
+unsigned int reg, u32 value)
+{
+ iowrite32(value, arcpgu->regs + reg);
+}
+
+static inline u32 arc_pgu_read(struct arcpgu_drm_private *arcpgu,
+ unsigned int reg)
+{
+ return ioread32(arcpgu->regs + reg);
+}
+
+#define XRES_DEF 640
+#define YRES_DEF 480
+
+#define XRES_MAX 8192
+#define YRES_MAX 8192
+
+static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
+{
+ int count;
+
+ count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
+ drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
+ return count;
+}
+
+static const struct drm_connector_helper_funcs
+arcpgu_drm_connector_helper_funcs = {
+ .get_modes = arcpgu_drm_connector_get_modes,
+};
+
+static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_d
[PATCH 11/15] drm/arc: Inline arcpgu_crtc.c
Really not big anymore.
Note that we no longer clamp all errors to ENODEV, highlighted by Sam.
v2: Fixup update function, bug reported by Eugeniy
v3: Delete now unused crtc funcs (0day)
v4: Move encoder removal to right patch (Sam).
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_crtc.c | 160 --
drivers/gpu/drm/arc/arcpgu_drv.c | 141 +-
4 files changed, 140 insertions(+), 164 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/arcpgu_crtc.c
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index c7028b7427b3..c686e0287a71 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
+arcpgu-y := arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index b5c699d14f27..cee2448a07d6 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -34,7 +34,6 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private
*arcpgu,
return ioread32(arcpgu->regs + reg);
}
-int arc_pgu_setup_pipe(struct drm_device *dev);
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
deleted file mode 100644
index 30fbb3052bc7..
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ /dev/null
@@ -1,160 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * ARC PGU DRM driver.
- *
- * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "arcpgu.h"
-#include "arcpgu_regs.h"
-
-#define ENCODE_PGU_XY(x, y)x) - 1) << 16) | ((y) - 1))
-
-static const u32 arc_pgu_supported_formats[] = {
- DRM_FORMAT_RGB565,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
-};
-
-static void arc_pgu_set_pxl_fmt(struct arcpgu_drm_private *arcpgu)
-{
- const struct drm_framebuffer *fb = arcpgu->pipe.plane.state->fb;
- uint32_t pixel_format = fb->format->format;
- u32 format = DRM_FORMAT_INVALID;
- int i;
- u32 reg_ctrl;
-
- for (i = 0; i < ARRAY_SIZE(arc_pgu_supported_formats); i++) {
- if (arc_pgu_supported_formats[i] == pixel_format)
- format = arc_pgu_supported_formats[i];
- }
-
- if (WARN_ON(format == DRM_FORMAT_INVALID))
- return;
-
- reg_ctrl = arc_pgu_read(arcpgu, ARCPGU_REG_CTRL);
- if (format == DRM_FORMAT_RGB565)
- reg_ctrl &= ~ARCPGU_MODE_XRGB;
- else
- reg_ctrl |= ARCPGU_MODE_XRGB;
- arc_pgu_write(arcpgu, ARCPGU_REG_CTRL, reg_ctrl);
-}
-
-static enum drm_mode_status arc_pgu_mode_valid(struct drm_simple_display_pipe
*pipe,
- const struct drm_display_mode
*mode)
-{
- struct arcpgu_drm_private *arcpgu = pipe_to_arcpgu_priv(pipe);
- long rate, clk_rate = mode->clock * 1000;
- long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */
-
- rate = clk_round_rate(arcpgu->clk, clk_rate);
- if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0))
- return MODE_OK;
-
- return MODE_NOCLOCK;
-}
-
-static void arc_pgu_mode_set(struct arcpgu_drm_private *arcpgu)
-{
- struct drm_display_mode *m = &arcpgu->pipe.crtc.state->adjusted_mode;
- u32 val;
-
- arc_pgu_write(arcpgu, ARCPGU_REG_FMT,
- ENCODE_PGU_XY(m->crtc_htotal, m->crtc_vtotal));
-
- arc_pgu_write(arcpgu, ARCPGU_REG_HSYNC,
- ENCODE_PGU_XY(m->crtc_hsync_start - m->crtc_hdisplay,
- m->crtc_hsync_end - m->crtc_hdisplay));
-
- arc_pgu_write(arcpgu, ARCPGU_REG_VSYNC,
- ENCODE_PGU_XY(m->crtc_vsync_start - m->crtc_vdisplay,
- m->crtc_vsync_end - m->crtc_vdisplay));
-
- arc_pgu_write(arcpgu, ARCPGU_REG_ACTIVE,
- ENCODE_PGU_XY(m->crtc_hblank_end - m->crtc_hblank_start,
- m->crtc_vblank_end - m->crtc_vblank_start));
-
- val = arc_pgu_read(arcpgu, ARCPGU_REG_CTRL);
-
- if (m->flags & DRM_MODE_FLAG_PVSYNC)
- val |= ARCPGU_CTRL_VS_POL_MASK << ARCPGU_CTRL_VS_POL_OFST;
- else
- val &= ~(ARCPGU_CTRL_VS_POL_MASK << ARCPGU_CTRL_VS_POL_OFST);
-
- if (m->flags & DRM_MODE_FLAG_PHSYNC)
- val |= ARCPGU_CTRL_HS_POL_MASK << ARCPGU_CTRL_HS_POL_OFST;
- else
-
[PATCH 08/15] drm/arc: Align with simple pipe helpers
Simple pipe helpers only have an enable and disable hook, no more
mode_set_nofb. Call it from our enable hook to align with that
conversions.
Atomic helpers always call mode_set_nofb and enable together, so
there's no functional change here.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 43313adb1981..3538c1686ca4 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -73,10 +73,9 @@ static enum drm_mode_status arc_pgu_crtc_mode_valid(struct
drm_crtc *crtc,
return MODE_NOCLOCK;
}
-static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
+static void arc_pgu_mode_set(struct arcpgu_drm_private *arcpgu)
{
- struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
- struct drm_display_mode *m = &crtc->state->adjusted_mode;
+ struct drm_display_mode *m = &arcpgu->pipe.crtc.state->adjusted_mode;
u32 val;
arc_pgu_write(arcpgu, ARCPGU_REG_FMT,
@@ -110,7 +109,7 @@ static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc
*crtc)
arc_pgu_write(arcpgu, ARCPGU_REG_STRIDE, 0);
arc_pgu_write(arcpgu, ARCPGU_REG_START_SET, 1);
- arc_pgu_set_pxl_fmt(crtc);
+ arc_pgu_set_pxl_fmt(&arcpgu->pipe.crtc);
clk_set_rate(arcpgu->clk, m->crtc_clock * 1000);
}
@@ -120,6 +119,8 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc
*crtc,
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+ arc_pgu_mode_set(arcpgu);
+
clk_prepare_enable(arcpgu->clk);
arc_pgu_write(arcpgu, ARCPGU_REG_CTRL,
arc_pgu_read(arcpgu, ARCPGU_REG_CTRL) |
@@ -139,7 +140,6 @@ static void arc_pgu_crtc_atomic_disable(struct drm_crtc
*crtc,
static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
.mode_valid = arc_pgu_crtc_mode_valid,
- .mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
.atomic_enable = arc_pgu_crtc_atomic_enable,
.atomic_disable = arc_pgu_crtc_atomic_disable,
};
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/15] drm/arc: Initialize sim connector before display pipe
That way we can get rid of this final piece of init code, and use the
simple pipe helpers as intended.
v2: Fix indent (Sam)
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_drv.c | 53 ++--
1 file changed, 17 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 0a0b54993773..8edfe6601151 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -95,32 +95,11 @@ static const struct drm_connector_funcs
arcpgu_drm_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
+static int arcpgu_drm_sim_init(struct drm_device *drm, struct drm_connector
*connector)
{
- struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
- struct drm_encoder *encoder;
- struct drm_connector *connector;
- int ret;
-
- encoder = &arcpgu->pipe.encoder;
-
- connector = &arcpgu->sim_conn;
drm_connector_helper_add(connector, &arcpgu_drm_connector_helper_funcs);
-
- ret = drm_connector_init(drm, connector, &arcpgu_drm_connector_funcs,
- DRM_MODE_CONNECTOR_VIRTUAL);
- if (ret < 0) {
- dev_err(drm->dev, "failed to initialize drm connector\n");
- return ret;
- }
-
- ret = drm_connector_attach_encoder(connector, encoder);
- if (ret < 0) {
- dev_err(drm->dev, "could not attach connector to encoder\n");
- return ret;
- }
-
- return 0;
+ return drm_connector_init(drm, connector, &arcpgu_drm_connector_funcs,
+ DRM_MODE_CONNECTOR_VIRTUAL);
}
#define ENCODE_PGU_XY(x, y)x) - 1) << 16) | ((y) - 1))
@@ -267,6 +246,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
{
struct platform_device *pdev = to_platform_device(arcpgu->drm.dev);
struct device_node *encoder_node = NULL, *endpoint_node = NULL;
+ struct drm_connector *connector = NULL;
struct drm_device *drm = &arcpgu->drm;
struct resource *res;
int ret;
@@ -301,13 +281,6 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
if (dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32)))
return -ENODEV;
- ret = drm_simple_display_pipe_init(drm, &arcpgu->pipe,
&arc_pgu_pipe_funcs,
- arc_pgu_supported_formats,
-
ARRAY_SIZE(arc_pgu_supported_formats),
- NULL, NULL);
- if (ret)
- return ret;
-
/*
* There is only one output port inside each device. It is linked with
* encoder endpoint.
@@ -316,8 +289,21 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
if (endpoint_node) {
encoder_node = of_graph_get_remote_port_parent(endpoint_node);
of_node_put(endpoint_node);
+ } else {
+ connector = &arcpgu->sim_conn;
+ dev_info(drm->dev, "no encoder found. Assumed virtual LCD on
simulation platform\n");
+ ret = arcpgu_drm_sim_init(drm, connector);
+ if (ret < 0)
+ return ret;
}
+ ret = drm_simple_display_pipe_init(drm, &arcpgu->pipe,
&arc_pgu_pipe_funcs,
+ arc_pgu_supported_formats,
+
ARRAY_SIZE(arc_pgu_supported_formats),
+ NULL, connector);
+ if (ret)
+ return ret;
+
if (encoder_node) {
struct drm_bridge *bridge;
@@ -329,11 +315,6 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
ret = drm_simple_display_pipe_attach_bridge(&arcpgu->pipe,
bridge);
if (ret)
return ret;
- } else {
- dev_info(drm->dev, "no encoder found. Assumed virtual LCD on
simulation platform\n");
- ret = arcpgu_drm_sim_init(drm, NULL);
- if (ret < 0)
- return ret;
}
drm_mode_config_reset(drm);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/15] drm/arc: Inline arcpgu_drm_hdmi_init
Really not worth the function, much less the separate file now that
almost all the code is gone.
Cc: Eugeniy Paltsev
Cc: Alexey Brodkin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 12 +---
drivers/gpu/drm/arc/arcpgu_hdmi.c | 27 ---
4 files changed, 10 insertions(+), 32 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/arcpgu_hdmi.c
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index c686e0287a71..379a1145bc2f 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
+arcpgu-y := arcpgu_sim.o arcpgu_drv.o
obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index cee2448a07d6..7dce0c2313ba 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -34,7 +34,6 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private
*arcpgu,
return ioread32(arcpgu->regs + reg);
}
-int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
#endif
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index e49e80b8b089..0e959e42893d 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -221,9 +221,15 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
}
if (encoder_node) {
- ret = arcpgu_drm_hdmi_init(drm, encoder_node);
- of_node_put(encoder_node);
- if (ret < 0)
+ struct drm_bridge *bridge;
+
+ /* Locate drm bridge from the hdmi encoder DT node */
+ bridge = of_drm_find_bridge(encoder_node);
+ if (!bridge)
+ return -EPROBE_DEFER;
+
+ ret = drm_simple_display_pipe_attach_bridge(&arcpgu->pipe,
bridge);
+ if (ret)
return ret;
} else {
dev_info(drm->dev, "no encoder found. Assumed virtual LCD on
simulation platform\n");
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
deleted file mode 100644
index d430af686cbc..
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ /dev/null
@@ -1,27 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * ARC PGU DRM driver.
- *
- * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
- */
-
-#include
-#include
-#include
-#include
-
-#include "arcpgu.h"
-
-int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
-{
- struct arcpgu_drm_private *arcpgu = dev_to_arcpgu(drm);
- struct drm_bridge *bridge;
-
- /* Locate drm bridge from the hdmi encoder DT node */
- bridge = of_drm_find_bridge(np);
- if (!bridge)
- return -EPROBE_DEFER;
-
- /* Link drm_bridge to encoder */
- return drm_simple_display_pipe_attach_bridge(&arcpgu->pipe, bridge);
-}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/15] drm/arc: Move to drm/tiny
Because it is.
v2: Delete now unused crtc funcs (0day)
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
MAINTAINERS | 2 +-
drivers/gpu/drm/Kconfig | 2 --
drivers/gpu/drm/Makefile| 1 -
drivers/gpu/drm/arc/Kconfig | 10 --
drivers/gpu/drm/arc/Makefile| 3 ---
drivers/gpu/drm/tiny/Kconfig| 10 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} | 0
8 files changed, 12 insertions(+), 17 deletions(-)
delete mode 100644 drivers/gpu/drm/arc/Kconfig
delete mode 100644 drivers/gpu/drm/arc/Makefile
rename drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 17b92e6a0f06..9330902cc9e9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1307,7 +1307,7 @@ ARC PGU DRM DRIVER
M: Alexey Brodkin
S: Supported
F: Documentation/devicetree/bindings/display/snps,arcpgu.txt
-F: drivers/gpu/drm/arc/
+F: drivers/gpu/drm/tiny/arcpgu.c
ARCNET NETWORK LAYER
M: Michael Grzeschik
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..041af75ee6fa 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -352,8 +352,6 @@ source "drivers/gpu/drm/vc4/Kconfig"
source "drivers/gpu/drm/etnaviv/Kconfig"
-source "drivers/gpu/drm/arc/Kconfig"
-
source "drivers/gpu/drm/hisilicon/Kconfig"
source "drivers/gpu/drm/mediatek/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index fefaff4c832d..4e4937609269 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -110,7 +110,6 @@ obj-y += panel/
obj-y += bridge/
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
-obj-$(CONFIG_DRM_ARCPGU)+= arc/
obj-y += hisilicon/
obj-$(CONFIG_DRM_ZTE) += zte/
obj-$(CONFIG_DRM_MXSFB)+= mxsfb/
diff --git a/drivers/gpu/drm/arc/Kconfig b/drivers/gpu/drm/arc/Kconfig
deleted file mode 100644
index e8f3d63e0b91..
--- a/drivers/gpu/drm/arc/Kconfig
+++ /dev/null
@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-config DRM_ARCPGU
- tristate "ARC PGU"
- depends on DRM && OF
- select DRM_KMS_CMA_HELPER
- select DRM_KMS_HELPER
- help
- Choose this option if you have an ARC PGU controller.
-
- If M is selected the module will be called arcpgu.
diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
deleted file mode 100644
index b26f2495c532..
--- a/drivers/gpu/drm/arc/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-arcpgu-y := arcpgu_drv.o
-obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa75..9bbaa1a69050 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -1,5 +1,15 @@
# SPDX-License-Identifier: GPL-2.0-only
+config DRM_ARCPGU
+ tristate "ARC PGU"
+ depends on DRM && OF
+ select DRM_KMS_CMA_HELPER
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you have an ARC PGU controller.
+
+ If M is selected the module will be called arcpgu.
+
config DRM_CIRRUS_QEMU
tristate "Cirrus driver for QEMU emulated device"
depends on DRM && PCI && MMU
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35f..bef6780bdd6f 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/tiny/arcpgu.c
similarity index 100%
rename from drivers/gpu/drm/arc/arcpgu_drv.c
rename to drivers/gpu/drm/tiny/arcpgu.c
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: nwl-dsi: Avoid potential multiplication overflow on 32-bit
Hi Laurent,
On Tue, Jan 12, 2021 at 5:38 AM Laurent Pinchart
wrote:
> On Mon, Jan 11, 2021 at 01:57:02PM +0100, Geert Uytterhoeven wrote:
> > As nwl_dsi.lanes is u32, and NSEC_PER_SEC is 10L, the second
> > multiplication in
> >
> > dsi->lanes * 8 * NSEC_PER_SEC
> >
> > will overflow on a 32-bit platform. Fix this by making the constant
> > unsigned long long, forcing 64-bit arithmetic.
> >
> > While iMX8 is arm64, this driver is currently used on 64-bit platforms
> > only, where long is 64-bit, so this cannot happen. But the issue may
> > start to happen when the driver is reused for a 32-bit SoC, or when code
> > is copied for a new driver.
> >
> > Signed-off-by: Geert Uytterhoeven
> > --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> > @@ -195,7 +195,7 @@ static u32 ps2bc(struct nwl_dsi *dsi, unsigned long
> > long ps)
> > u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> >
> > return DIV64_U64_ROUND_UP(ps * dsi->mode.clock * bpp,
> > - dsi->lanes * 8 * NSEC_PER_SEC);
> > + dsi->lanes * 8ULL * NSEC_PER_SEC);
>
> I wonder if we could get rid of a whole class of bugs by turning
> NSEC_PER_SEC into a ULL, but I suppose there are valid cases where a
> 32-bit integer is enough.
Indeed, and 64-bit arithmetic is more expensive on 32-bit platforms.
I considered that change, but doing so would require updates all over
the place (e.g. printing a value derived from NSEC_PER_SEC, divisions
that need to be changed to do_div or div_u64(), ...)
Note that the selftests already use such a definition.
> Reviewed-by: Laurent Pinchart
Thanks!
> How did you come across this by the way ?
https://lore.kernel.org/linux-renesas-soc/CAMuHMdXQvPY_mYicjPKjDSCwdO_rP-9PJOvqD0J6=s3opr1...@mail.gmail.com/
and of course I grepped for similar use patterns...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/vmwgfx: Drop svga_lock
Hi Roland,
Hopefully you had a nice start into the new year! Ping for some
review/testing on this series.
Thanks, Daniel
On Fri, Dec 11, 2020 at 5:29 PM Daniel Vetter wrote:
>
> This isn't actually protecting anything becuase:
> - when running, ttm_resource_manager->use_type is protected through
> vmw_private->reservation_semaphore against concurrent execbuf or
> well anything else that might evict or reserve buffers
> - during suspend/resume there's nothing else running, hence
> vmw_pm_freeze and vmw_pm_restore do not need to take the same lock.
> - this also holds for the SVGA_REG_ENABLE register write
>
> Hence it is safe to just remove that spinlock.
>
> Signed-off-by: Daniel Vetter
> Cc: VMware Graphics
> Cc: Roland Scheidegger
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 -
> 2 files changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 0008be02d31c..204f7a1830f0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -672,7 +672,6 @@ static int vmw_driver_load(struct drm_device *dev,
> unsigned long chipset)
> spin_lock_init(&dev_priv->hw_lock);
> spin_lock_init(&dev_priv->waiter_lock);
> spin_lock_init(&dev_priv->cap_lock);
> - spin_lock_init(&dev_priv->svga_lock);
> spin_lock_init(&dev_priv->cursor_lock);
>
> for (i = vmw_res_context; i < vmw_res_max; ++i) {
> @@ -1189,12 +1188,10 @@ static void __vmw_svga_enable(struct vmw_private
> *dev_priv)
> {
> struct ttm_resource_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
>
> - spin_lock(&dev_priv->svga_lock);
> if (!ttm_resource_manager_used(man)) {
> vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE);
> ttm_resource_manager_set_used(man, true);
> }
> - spin_unlock(&dev_priv->svga_lock);
> }
>
> /**
> @@ -1220,14 +1217,12 @@ static void __vmw_svga_disable(struct vmw_private
> *dev_priv)
> {
> struct ttm_resource_manager *man = ttm_manager_type(&dev_priv->bdev,
> TTM_PL_VRAM);
>
> - spin_lock(&dev_priv->svga_lock);
> if (ttm_resource_manager_used(man)) {
> ttm_resource_manager_set_used(man, false);
> vmw_write(dev_priv, SVGA_REG_ENABLE,
> SVGA_REG_ENABLE_HIDE |
> SVGA_REG_ENABLE_ENABLE);
> }
> - spin_unlock(&dev_priv->svga_lock);
> }
>
> /**
> @@ -1254,17 +1249,14 @@ void vmw_svga_disable(struct vmw_private *dev_priv)
> */
> vmw_kms_lost_device(dev_priv->dev);
> ttm_write_lock(&dev_priv->reservation_sem, false);
> - spin_lock(&dev_priv->svga_lock);
> if (ttm_resource_manager_used(man)) {
> ttm_resource_manager_set_used(man, false);
> - spin_unlock(&dev_priv->svga_lock);
> if (ttm_resource_manager_evict_all(&dev_priv->bdev, man))
> DRM_ERROR("Failed evicting VRAM buffers.\n");
> vmw_write(dev_priv, SVGA_REG_ENABLE,
> SVGA_REG_ENABLE_HIDE |
> SVGA_REG_ENABLE_ENABLE);
> - } else
> - spin_unlock(&dev_priv->svga_lock);
> + }
> ttm_write_unlock(&dev_priv->reservation_sem);
> }
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 5b9a28157dd3..715f2bfee08a 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -596,7 +596,6 @@ struct vmw_private {
>
> bool stealth;
> bool enable_fb;
> - spinlock_t svga_lock;
>
> /**
> * PM management.
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: make sure context is created in gem open
On Thu, Jan 07, 2021 at 01:07:26PM -0800, Chia-I Wu wrote:
The context might still be missing when DRM_IOCTL_PRIME_FD_TO_HANDLE is
the first ioctl on the drm_file.
Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after the first
3D ioctl")
Cc: Gurchetan Singh
Cc: Gerd Hoffmann
Signed-off-by: Chia-I Wu
Reviewed-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index c30c75ee83fc..8502400b2f9c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -39,9 +39,6 @@ static int virtio_gpu_gem_create(struct drm_file *file,
int ret;
u32 handle;
- if (vgdev->has_virgl_3d)
- virtio_gpu_create_context(dev, file);
-
ret = virtio_gpu_object_create(vgdev, params, &obj, NULL);
if (ret < 0)
return ret;
@@ -119,6 +116,11 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
if (!vgdev->has_virgl_3d)
goto out_notify;
+ /* the context might still be missing when the first ioctl is
+* DRM_IOCTL_MODE_CREATE_DUMB or DRM_IOCTL_PRIME_FD_TO_HANDLE
+*/
+ virtio_gpu_create_context(obj->dev, file);
+
objs = virtio_gpu_array_alloc(1);
if (!objs)
return -ENOMEM;
--
2.29.2.729.g45daf8777d-goog
___
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] drm/virtio: fix prime export for vram objects
On Thu, Jan 07, 2021 at 01:07:43PM -0800, Chia-I Wu wrote:
commit 16845c5d5409 ("drm/virtio: implement blob resources: implement
vram object") and commit c6069a02fa55 ("drm/virtgpu: Set PRIME export
function in struct drm_gem_object_funcs") landed from different trees,
resulting in prime export never working for vram objects.
Cc: Gurchetan Singh
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Signed-off-by: Chia-I Wu
Reviewed-by: Anthoine Bourgeois
---
drivers/gpu/drm/virtio/virtgpu_vram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vram.c
b/drivers/gpu/drm/virtio/virtgpu_vram.c
index d6f215c4ff8d..5cc34e7330fa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vram.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vram.c
@@ -69,6 +69,7 @@ static const struct drm_gem_object_funcs
virtio_gpu_vram_funcs = {
.close = virtio_gpu_gem_object_close,
.free = virtio_gpu_vram_free,
.mmap = virtio_gpu_vram_mmap,
+ .export = virtgpu_gem_prime_export,
};
bool virtio_gpu_is_vram(struct virtio_gpu_object *bo)
--
2.29.2.729.g45daf8777d-goog
___
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] drm: Removes invalid function return value comment information
On Tue, Jan 12, 2021 at 09:39:27AM +0800, Zhaoge Zhang wrote:
> Signed-off-by: Zhaoge Zhang
Applied, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_file.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index b50380f..8548e8b 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -240,9 +240,6 @@ static void drm_events_release(struct drm_file *file_priv)
> * before calling this.
> *
> * If NULL is passed, this is a no-op.
> - *
> - * RETURNS:
> - * 0 on success, or error code on failure.
> */
> void drm_file_free(struct drm_file *file)
> {
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix macro name DRM_MODE_PROP_OBJECT in code comment
On Tue, Jan 12, 2021 at 09:54:39AM +0800, Zhaoge Zhang wrote:
> Signed-off-by: Zhaoge Zhang
> ---
> include/drm/drm_property.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
> index 4a0a80d..bbf5c1fd 100644
> --- a/include/drm/drm_property.h
> +++ b/include/drm/drm_property.h
> @@ -114,7 +114,7 @@ struct drm_property {
>* by the property. Bitmask properties are created using
>* drm_property_create_bitmask().
>*
> - * DRM_MODE_PROB_OBJECT
> + * DRM_MODE_PROP_OBJECT
Nice catch, merged to drm-misc-next, thanks for your patch.
-Daniel
>* Object properties are used to link modeset objects. This is used
>* extensively in the atomic support to create the display pipeline,
>* by linking &drm_framebuffer to &drm_plane, &drm_plane to
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm: Inline AGP wrappers into their only callers
On Tue, Jan 12, 2021 at 09:10:30AM +0100, Thomas Zimmermann wrote:
> The AGP wrapper functions serve no purpose.
>
> Signed-off-by: Thomas Zimmermann
They do, without them we fail compiling (I think at least) when agp isn't
enabled. Did you check for that? I should all work if we have the dummy
inlines for relevant agp functions in linux/agp_backend.h.
-Daniel
> ---
> drivers/gpu/drm/drm_agpsupport.c | 12 ++--
> drivers/gpu/drm/drm_memory.c | 18 --
> include/drm/drm_agpsupport.h | 18 --
> 3 files changed, 6 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_agpsupport.c
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4c7ad46fdd21..8b690ef306de 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -285,7 +285,7 @@ int drm_agp_unbind(struct drm_device *dev, struct
> drm_agp_binding *request)
> entry = drm_agp_lookup_entry(dev, request->handle);
> if (!entry || !entry->bound)
> return -EINVAL;
> - ret = drm_unbind_agp(entry->memory);
> + ret = agp_unbind_memory(entry->memory);
> if (ret == 0)
> entry->bound = 0;
> return ret;
> @@ -326,7 +326,7 @@ int drm_agp_bind(struct drm_device *dev, struct
> drm_agp_binding *request)
> if (!entry || entry->bound)
> return -EINVAL;
> page = DIV_ROUND_UP(request->offset, PAGE_SIZE);
> - retcode = drm_bind_agp(entry->memory, page);
> + retcode = agp_bind_memory(entry->memory, page);
> if (retcode)
> return retcode;
> entry->bound = dev->agp->base + (page << PAGE_SHIFT);
> @@ -369,11 +369,11 @@ int drm_agp_free(struct drm_device *dev, struct
> drm_agp_buffer *request)
> if (!entry)
> return -EINVAL;
> if (entry->bound)
> - drm_unbind_agp(entry->memory);
> + agp_unbind_memory(entry->memory);
>
> list_del(&entry->head);
>
> - drm_free_agp(entry->memory, entry->pages);
> + agp_free_memory(entry->memory);
> kfree(entry);
> return 0;
> }
> @@ -453,8 +453,8 @@ void drm_legacy_agp_clear(struct drm_device *dev)
>
> list_for_each_entry_safe(entry, tempe, &dev->agp->memory, head) {
> if (entry->bound)
> - drm_unbind_agp(entry->memory);
> - drm_free_agp(entry->memory, entry->pages);
> + agp_unbind_memory(entry->memory);
> + agp_free_memory(entry->memory);
> kfree(entry);
> }
> INIT_LIST_HEAD(&dev->agp->memory);
> diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
> index fbea69d6f909..f4f2bffdd5bd 100644
> --- a/drivers/gpu/drm/drm_memory.c
> +++ b/drivers/gpu/drm/drm_memory.c
> @@ -100,24 +100,6 @@ static void *agp_remap(unsigned long offset, unsigned
> long size,
> return addr;
> }
>
> -/** Wrapper around agp_free_memory() */
> -void drm_free_agp(struct agp_memory *handle, int pages)
> -{
> - agp_free_memory(handle);
> -}
> -
> -/** Wrapper around agp_bind_memory() */
> -int drm_bind_agp(struct agp_memory *handle, unsigned int start)
> -{
> - return agp_bind_memory(handle, start);
> -}
> -
> -/** Wrapper around agp_unbind_memory() */
> -int drm_unbind_agp(struct agp_memory *handle)
> -{
> - return agp_unbind_memory(handle);
> -}
> -
> #else /* CONFIG_AGP */
> static inline void *agp_remap(unsigned long offset, unsigned long size,
> struct drm_device *dev)
> diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
> index 664e120b93e6..f3136750c490 100644
> --- a/include/drm/drm_agpsupport.h
> +++ b/include/drm/drm_agpsupport.h
> @@ -28,10 +28,6 @@ struct drm_agp_head {
>
> #if IS_ENABLED(CONFIG_AGP)
>
> -void drm_free_agp(struct agp_memory * handle, int pages);
> -int drm_bind_agp(struct agp_memory * handle, unsigned int start);
> -int drm_unbind_agp(struct agp_memory * handle);
> -
> struct drm_agp_head *drm_agp_init(struct drm_device *dev);
> void drm_legacy_agp_clear(struct drm_device *dev);
> int drm_agp_acquire(struct drm_device *dev);
> @@ -61,20 +57,6 @@ int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
>
> #else /* CONFIG_AGP */
>
> -static inline void drm_free_agp(struct agp_memory * handle, int pages)
> -{
> -}
> -
> -static inline int drm_bind_agp(struct agp_memory * handle, unsigned int
> start)
> -{
> - return -ENODEV;
> -}
> -
> -static inline int drm_unbind_agp(struct agp_memory * handle)
> -{
> - return -ENODEV;
> -}
> -
> static inline struct drm_agp_head *drm_agp_init(struct drm_device *dev)
> {
> return NULL;
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm: Implement drm_need_swiotlb() in drm_cache.c
On Tue, Jan 12, 2021 at 09:10:31AM +0100, Thomas Zimmermann wrote:
> The function is declared in drm_cache.h. I also removed the curly
> braces from the for loop to adhere to kernel coding style.
>
> Signed-off-by: Thomas Zimmermann
s/implement in/move to/ in the subject. Also would be nice to add
kerneldoc while moving (there's not kerneldoc for drm_memory) to avoid the
new warning. With that fixed:
Reviewed-by: Daniel Vetter
It's mildly confusing, but in a way drm_cache.c is our "hack around
dma-api layering issues" pile, so fits :-) Maybe we should even make this
the official DOC: kerneldoc intro section for this file ...
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_cache.c | 32
> drivers/gpu/drm/drm_memory.c | 33 -
> 2 files changed, 32 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
> index 0fe3c496002a..49551a7fa22f 100644
> --- a/drivers/gpu/drm/drm_cache.c
> +++ b/drivers/gpu/drm/drm_cache.c
> @@ -30,6 +30,7 @@
>
> #include
> #include
> +#include
>
> #include
>
> @@ -176,3 +177,34 @@ drm_clflush_virt_range(void *addr, unsigned long length)
> #endif
> }
> EXPORT_SYMBOL(drm_clflush_virt_range);
> +
> +bool drm_need_swiotlb(int dma_bits)
> +{
> + struct resource *tmp;
> + resource_size_t max_iomem = 0;
> +
> + /*
> + * Xen paravirtual hosts require swiotlb regardless of requested dma
> + * transfer size.
> + *
> + * NOTE: Really, what it requires is use of the dma_alloc_coherent
> + * allocator used in ttm_dma_populate() instead of
> + * ttm_populate_and_map_pages(), which bounce buffers so much in
> + * Xen it leads to swiotlb buffer exhaustion.
> + */
> + if (xen_pv_domain())
> + return true;
> +
> + /*
> + * Enforce dma_alloc_coherent when memory encryption is active as well
> + * for the same reasons as for Xen paravirtual hosts.
> + */
> + if (mem_encrypt_active())
> + return true;
> +
> + for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling)
> + max_iomem = max(max_iomem, tmp->end);
> +
> + return max_iomem > ((u64)1 << dma_bits);
> +}
> +EXPORT_SYMBOL(drm_need_swiotlb);
> diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
> index f4f2bffdd5bd..e4f20a2eb6e7 100644
> --- a/drivers/gpu/drm/drm_memory.c
> +++ b/drivers/gpu/drm/drm_memory.c
> @@ -37,7 +37,6 @@
> #include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -138,35 +137,3 @@ void drm_legacy_ioremapfree(struct drm_local_map *map,
> struct drm_device *dev)
> iounmap(map->handle);
> }
> EXPORT_SYMBOL(drm_legacy_ioremapfree);
> -
> -bool drm_need_swiotlb(int dma_bits)
> -{
> - struct resource *tmp;
> - resource_size_t max_iomem = 0;
> -
> - /*
> - * Xen paravirtual hosts require swiotlb regardless of requested dma
> - * transfer size.
> - *
> - * NOTE: Really, what it requires is use of the dma_alloc_coherent
> - * allocator used in ttm_dma_populate() instead of
> - * ttm_populate_and_map_pages(), which bounce buffers so much in
> - * Xen it leads to swiotlb buffer exhaustion.
> - */
> - if (xen_pv_domain())
> - return true;
> -
> - /*
> - * Enforce dma_alloc_coherent when memory encryption is active as well
> - * for the same reasons as for Xen paravirtual hosts.
> - */
> - if (mem_encrypt_active())
> - return true;
> -
> - for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
> - max_iomem = max(max_iomem, tmp->end);
> - }
> -
> - return max_iomem > ((u64)1 << dma_bits);
> -}
> -EXPORT_SYMBOL(drm_need_swiotlb);
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm: Build drm_memory.o only for legacy drivers
On Tue, Jan 12, 2021 at 09:10:32AM +0100, Thomas Zimmermann wrote: > The file contains I/O-memory functions that are only used by legacy > drivers. Yay! > Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter > --- > drivers/gpu/drm/Makefile | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index fefaff4c832d..ba0ecb7756c6 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -5,7 +5,7 @@ > > drm-y := drm_auth.o drm_cache.o \ > drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \ > - drm_memory.o drm_drv.o \ > + drm_drv.o \ > drm_sysfs.o drm_hashtab.o drm_mm.o \ > drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \ > drm_encoder_slave.o \ > @@ -20,7 +20,8 @@ drm-y := drm_auth.o drm_cache.o \ > drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \ > drm_managed.o drm_vblank_work.o > > -drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o > drm_dma.o drm_scatter.o drm_lock.o > +drm-$(CONFIG_DRM_LEGACY) += drm_bufs.o drm_context.o drm_dma.o > drm_legacy_misc.o drm_lock.o \ > + drm_memory.o drm_scatter.o > drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o > drm-$(CONFIG_DRM_VM) += drm_vm.o > drm-$(CONFIG_COMPAT) += drm_ioc32.o > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm: Merge CONFIG_DRM_VM into CONFIG_DRM_LEGACY
On Tue, Jan 12, 2021 at 09:10:33AM +0100, Thomas Zimmermann wrote:
> CONFIG_DRM_VM gets selected by CONFIG_DRM_LEGACY, but nothing else. So
> remove it and build drm_vm.o as part of CONFIG_DRM_LEGACY.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/Kconfig | 5 -
> drivers/gpu/drm/Makefile | 3 +--
> drivers/gpu/drm/drm_legacy.h | 2 +-
> 3 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 0973f408d75f..8bf103de1594 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -214,10 +214,6 @@ config DRM_GEM_SHMEM_HELPER
> help
> Choose this if you need the GEM shmem helper functions
>
> -config DRM_VM
> - bool
> - depends on DRM && MMU
> -
> config DRM_SCHED
> tristate
> depends on DRM
> @@ -391,7 +387,6 @@ source "drivers/gpu/drm/xlnx/Kconfig"
> menuconfig DRM_LEGACY
> bool "Enable legacy drivers (DANGEROUS)"
> depends on DRM && MMU
Ah we already depend upon MMU here, so should be all good.
Reviewed-by: Daniel Vetter
> - select DRM_VM
> help
> Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
> APIs to user-space, which can be used to circumvent access
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index ba0ecb7756c6..926adef289db 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -21,9 +21,8 @@ drm-y := drm_auth.o drm_cache.o \
> drm_managed.o drm_vblank_work.o
>
> drm-$(CONFIG_DRM_LEGACY) += drm_bufs.o drm_context.o drm_dma.o
> drm_legacy_misc.o drm_lock.o \
> - drm_memory.o drm_scatter.o
> + drm_memory.o drm_scatter.o drm_vm.o
> drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
> -drm-$(CONFIG_DRM_VM) += drm_vm.o
> drm-$(CONFIG_COMPAT) += drm_ioc32.o
> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_gem_shmem_helper.o
> diff --git a/drivers/gpu/drm/drm_legacy.h b/drivers/gpu/drm/drm_legacy.h
> index 1be3ea320474..f71358f9eac9 100644
> --- a/drivers/gpu/drm/drm_legacy.h
> +++ b/drivers/gpu/drm/drm_legacy.h
> @@ -127,7 +127,7 @@ static inline void drm_legacy_master_rmmaps(struct
> drm_device *dev,
> static inline void drm_legacy_rmmaps(struct drm_device *dev) {}
> #endif
>
> -#if IS_ENABLED(CONFIG_DRM_VM) && IS_ENABLED(CONFIG_DRM_LEGACY)
> +#if IS_ENABLED(CONFIG_DRM_LEGACY)
> void drm_legacy_vma_flush(struct drm_device *d);
> #else
> static inline void drm_legacy_vma_flush(struct drm_device *d)
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On Mon, Jan 11, 2021 at 01:31:00PM -0500, Andrey Grodzovsky wrote: > > On 1/11/21 12:41 PM, Andrey Grodzovsky wrote: > > > > On 1/11/21 11:15 AM, Daniel Vetter wrote: > > > On Mon, Jan 11, 2021 at 05:13:56PM +0100, Daniel Vetter wrote: > > > > On Fri, Jan 08, 2021 at 04:49:55PM +, Grodzovsky, Andrey wrote: > > > > > Ok then, I guess I will proceed with the dummy pages list > > > > > implementation then. > > > > > > > > > > Andrey > > > > > > > > > > > > > > > From: Koenig, Christian > > > > > Sent: 08 January 2021 09:52 > > > > > To: Grodzovsky, Andrey ; Daniel > > > > > Vetter > > > > > Cc: amd-...@lists.freedesktop.org > > > > > ; > > > > > dri-devel@lists.freedesktop.org > > > > > ; daniel.vet...@ffwll.ch > > > > > ; r...@kernel.org ; > > > > > l.st...@pengutronix.de ; > > > > > yuq...@gmail.com ; e...@anholt.net > > > > > ; Deucher, Alexander > > > > > ; gre...@linuxfoundation.org > > > > > ; ppaala...@gmail.com > > > > > ; Wentland, Harry > > > > > > > > > > Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM > > > > > object > > > > > > > > > > Mhm, I'm not aware of any let over pointer between TTM and GEM and we > > > > > worked quite hard on reducing the size of the amdgpu_bo, so another > > > > > extra pointer just for that corner case would suck quite a bit. > > > > We have a ton of other pointers in struct amdgpu_bo (or any of it's > > > > lower > > > > things) which are fairly single-use, so I'm really not much seeing the > > > > point in making this a special case. It also means the lifetime > > > > management > > > > becomes a bit iffy, since we can't throw away the dummy page then the > > > > last > > > > reference to the bo is released (since we don't track it there), but > > > > only > > > > when the last pointer to the device is released. Potentially this means > > > > a > > > > pile of dangling pages hanging around for too long. > > > Also if you really, really, really want to have this list, please don't > > > reinvent it since we have it already. drmm_ is exactly meant for resources > > > that should be freed when the final drm_device reference disappears. > > > -Daniel > > > > > > Can you elaborate ? We still need to actually implement the list but you > > want me to use > > drmm_add_action for it's destruction instead of explicitly doing it > > (like I'm already doing from ttm_bo_device_release) ? > > > > Andrey > > > Oh, i get it i think, you want me to allocate each page using drmm_kzalloc > so when drm_dev dies it will be freed on it's own. > Great idea and makes my implementation much less cumbersome. That was my idea, but now after a night's worth of sleep I'm not so sure it's a bright one: We don't just want 4k of memory, we want a page. And I'm not sure kzalloc will give us that (plus using a slab page for mmap might result in fireworks shows). So maybe just drmm_add_action_or_reset (since I'm also not sure we can just use the lists in struct page itself for the page we got when we use alloc_page). -Daniel > > Andrey > > > > > > > > > > If you need some ideas for redundant pointers: > > > > - destroy callback (kinda not cool to not have this const anyway), we > > > > could refcount it all with the overall gem bo. Quite a bit of work. > > > > - bdev pointer, if we move the device ttm stuff into struct drm_device, > > > > or > > > > create a common struct ttm_device, we can ditch that > > > > - We could probably merge a few of the fields and find 8 bytes somewhere > > > > - we still have 2 krefs, would probably need to fix that before we can > > > > merge the destroy callbacks > > > > > > > > So there's plenty of room still, if the size of a bo struct is really > > > > that > > > > critical. Imo it's not. > > > > > > > > > > > > > Christian. > > > > > > > > > > Am 08.01.21 um 15:46 schrieb Andrey Grodzovsky: > > > > > > Daniel had some objections to this (see bellow) and so I guess I > > > > > > need > > > > > > you both to agree on the approach before I proceed. > > > > > > > > > > > > Andrey > > > > > > > > > > > > On 1/8/21 9:33 AM, Christian König wrote: > > > > > > > Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: > > > > > > > > Hey Christian, just a ping. > > > > > > > Was there any question for me here? > > > > > > > > > > > > > > As far as I can see the best approach would still be to fill the > > > > > > > VMA > > > > > > > with a single dummy page and avoid pointers in the GEM object. > > > > > > > > > > > > > > Christian. > > > > > > > > > > > > > > > Andrey > > > > > > > > > > > > > > > > On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: > > > > > > > > > On 1/7/21 11:30 AM, Daniel Vetter wrote: > > > > > > > > > > On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky > > > > > > > > > > wrote: > > > > > > > > > > > On 1/7/21 11:21 AM, Daniel Vetter wrote: > > > > > > > > > > > > On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey > > > > > > > > > > > > Grodzovs
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On Mon, Jan 11, 2021 at 03:45:10PM -0500, Andrey Grodzovsky wrote: > > On 1/11/21 11:15 AM, Daniel Vetter wrote: > > On Mon, Jan 11, 2021 at 05:13:56PM +0100, Daniel Vetter wrote: > > > On Fri, Jan 08, 2021 at 04:49:55PM +, Grodzovsky, Andrey wrote: > > > > Ok then, I guess I will proceed with the dummy pages list > > > > implementation then. > > > > > > > > Andrey > > > > > > > > > > > > From: Koenig, Christian > > > > Sent: 08 January 2021 09:52 > > > > To: Grodzovsky, Andrey ; Daniel Vetter > > > > > > > > Cc: amd-...@lists.freedesktop.org ; > > > > dri-devel@lists.freedesktop.org ; > > > > daniel.vet...@ffwll.ch ; r...@kernel.org > > > > ; l.st...@pengutronix.de ; > > > > yuq...@gmail.com ; e...@anholt.net ; > > > > Deucher, Alexander ; > > > > gre...@linuxfoundation.org ; > > > > ppaala...@gmail.com ; Wentland, Harry > > > > > > > > Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM > > > > object > > > > > > > > Mhm, I'm not aware of any let over pointer between TTM and GEM and we > > > > worked quite hard on reducing the size of the amdgpu_bo, so another > > > > extra pointer just for that corner case would suck quite a bit. > > > We have a ton of other pointers in struct amdgpu_bo (or any of it's lower > > > things) which are fairly single-use, so I'm really not much seeing the > > > point in making this a special case. It also means the lifetime management > > > becomes a bit iffy, since we can't throw away the dummy page then the last > > > reference to the bo is released (since we don't track it there), but only > > > when the last pointer to the device is released. Potentially this means a > > > pile of dangling pages hanging around for too long. > > Also if you really, really, really want to have this list, please don't > > reinvent it since we have it already. drmm_ is exactly meant for resources > > that should be freed when the final drm_device reference disappears. > > -Daniel > > > I maybe was eager to early, see i need to explicitly allocate the dummy page > using page_alloc so > i cannot use drmm_kmalloc for this, so once again like with the list i need > to wrap it with a container struct > which i can then allocate using drmm_kmalloc and inside there will be page > pointer. But then > on release it needs to free the page and so i supposedly need to use > drmm_add_action > to free the page before the container struct is released but drmm_kmalloc > doesn't allow to set > release action on struct allocation. So I created a new > drmm_kmalloc_with_action API function > but then you also need to supply the optional data pointer for the release > action (the struct page in this case) > and so this all becomes a bit overcomplicated (but doable). Is this extra > API worth adding ? Maybe it can > be useful in general. drm_add_action_or_reset (for better control flow) has both a void * data and a cleanup function (and it internally allocates the tracking structure for that for you). So should work as-is? Allocating a tracking structure for our tracking structure for a page would definitely be a bit too much. Essentiall drmm_add_action is your kcalloc_with_action function you want, as long as all you need is a single void * pointer (we could do the kzalloc_with_action though, there's enough space, just no need yet for any of the current users). -Daniel > > Andrey > > > > > > If you need some ideas for redundant pointers: > > > - destroy callback (kinda not cool to not have this const anyway), we > > >could refcount it all with the overall gem bo. Quite a bit of work. > > > - bdev pointer, if we move the device ttm stuff into struct drm_device, or > > >create a common struct ttm_device, we can ditch that > > > - We could probably merge a few of the fields and find 8 bytes somewhere > > > - we still have 2 krefs, would probably need to fix that before we can > > >merge the destroy callbacks > > > > > > So there's plenty of room still, if the size of a bo struct is really that > > > critical. Imo it's not. > > > > > > > > > > Christian. > > > > > > > > Am 08.01.21 um 15:46 schrieb Andrey Grodzovsky: > > > > > Daniel had some objections to this (see bellow) and so I guess I need > > > > > you both to agree on the approach before I proceed. > > > > > > > > > > Andrey > > > > > > > > > > On 1/8/21 9:33 AM, Christian König wrote: > > > > > > Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: > > > > > > > Hey Christian, just a ping. > > > > > > Was there any question for me here? > > > > > > > > > > > > As far as I can see the best approach would still be to fill the VMA > > > > > > with a single dummy page and avoid pointers in the GEM object. > > > > > > > > > > > > Christian. > > > > > > > > > > > > > Andrey > > > > > > > > > > > > > > On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: > > > > > > > > On 1/7/21 11:30 AM, Daniel Vetter wrote: > > > > > > > > > On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andre
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On Tue, Jan 12, 2021 at 9:12 AM Christian König wrote: > > Am 11.01.21 um 17:13 schrieb Daniel Vetter: > > On Fri, Jan 08, 2021 at 04:49:55PM +, Grodzovsky, Andrey wrote: > >> Ok then, I guess I will proceed with the dummy pages list implementation > >> then. > >> > >> Andrey > >> > >> > >> From: Koenig, Christian > >> Sent: 08 January 2021 09:52 > >> To: Grodzovsky, Andrey ; Daniel Vetter > >> > >> Cc: amd-...@lists.freedesktop.org ; > >> dri-devel@lists.freedesktop.org ; > >> daniel.vet...@ffwll.ch ; r...@kernel.org > >> ; l.st...@pengutronix.de ; > >> yuq...@gmail.com ; e...@anholt.net ; > >> Deucher, Alexander ; gre...@linuxfoundation.org > >> ; ppaala...@gmail.com ; > >> Wentland, Harry > >> Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object > >> > >> Mhm, I'm not aware of any let over pointer between TTM and GEM and we > >> worked quite hard on reducing the size of the amdgpu_bo, so another > >> extra pointer just for that corner case would suck quite a bit. > > We have a ton of other pointers in struct amdgpu_bo (or any of it's lower > > things) which are fairly single-use, so I'm really not much seeing the > > point in making this a special case. It also means the lifetime management > > becomes a bit iffy, since we can't throw away the dummy page then the last > > reference to the bo is released (since we don't track it there), but only > > when the last pointer to the device is released. Potentially this means a > > pile of dangling pages hanging around for too long. > > Yeah, all of them are already on my TODO list, but see below. > > > If you need some ideas for redundant pointers: > > - destroy callback (kinda not cool to not have this const anyway), we > >could refcount it all with the overall gem bo. Quite a bit of work. > > The bigger problems is that TTM based drivers are using the destroy > callback pointer to distinct ghost objects from real ones. > > We first need to get rid of those. I already have a plan for that and > ~20% of it implemented, but it is more complicated because of the driver > specific backends in Nouveau, Amdgpu and vmwgfx. > > > - bdev pointer, if we move the device ttm stuff into struct drm_device, or > >create a common struct ttm_device, we can ditch that > > Yes, exactly that's what my device structure rename patch set is aiming > for :) Hm already on the list and did I miss it? > > - We could probably merge a few of the fields and find 8 bytes somewhere > > Please point out where. Flags and bool deleted looked compressible at a glance. Not sure that's worth it. > > - we still have 2 krefs, would probably need to fix that before we can > >merge the destroy callbacks > > Yes, already on my TODO list as well. But the last time I looked into > this I was blocked by the struct_mutex once more. Uh struct_mutex, I thought we've killed that for good. How is it getting in the way? > > So there's plenty of room still, if the size of a bo struct is really that > > critical. Imo it's not. > > It is. See we had a size of struct amdgpu_bo of over 1500 bytes because > we stopped caring for that, no we are down to 816 at the moment. > > We really need to get rid of this duplication of functionality and > structure between TTM and GEM. Yeah, and if you have patches nag me, happy to review them anytime really. Cheers, Daniel > > Christian. > > > -Daniel > > > > > >> Christian. > >> > >> Am 08.01.21 um 15:46 schrieb Andrey Grodzovsky: > >>> Daniel had some objections to this (see bellow) and so I guess I need > >>> you both to agree on the approach before I proceed. > >>> > >>> Andrey > >>> > >>> On 1/8/21 9:33 AM, Christian König wrote: > Am 08.01.21 um 15:26 schrieb Andrey Grodzovsky: > > Hey Christian, just a ping. > Was there any question for me here? > > As far as I can see the best approach would still be to fill the VMA > with a single dummy page and avoid pointers in the GEM object. > > Christian. > > > Andrey > > > > On 1/7/21 11:37 AM, Andrey Grodzovsky wrote: > >> On 1/7/21 11:30 AM, Daniel Vetter wrote: > >>> On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote: > On 1/7/21 11:21 AM, Daniel Vetter wrote: > > On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote: > >> On 11/23/20 3:01 AM, Christian König wrote: > >>> Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky: > On 11/21/20 9:15 AM, Christian König wrote: > > Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: > >> Will be used to reroute CPU mapped BO's page faults once > >> device is removed. > > Uff, one page for each exported DMA-buf? That's not > > something we can do. > > > > We need to find a different approach here. > > > > Can't we call alloc_page() on each fault and link them tog
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
On Tue, Jan 12, 2021 at 08:53:03AM +0100, Christian König wrote:
> Am 11.01.21 um 17:17 schrieb Daniel Vetter:
> > On Mon, Jan 11, 2021 at 11:16:13AM +0100, Christian König wrote:
> > > Am 08.01.21 um 16:53 schrieb Daniel Vetter:
> > > > On Fri, Jan 8, 2021 at 3:36 PM Christian König
> > > > wrote:
> > > > > Am 08.01.21 um 15:31 schrieb Daniel Vetter:
> > > > > > On Thu, Jan 07, 2021 at 09:08:29PM +0100, Christian König wrote:
> > > > > > > Am 07.01.21 um 19:07 schrieb Daniel Vetter:
> > > > > > > > On Tue, Jan 05, 2021 at 07:23:08PM +0100, Christian König wrote:
> > > > > > > > > Drivers are not supposed to init the page pool directly any
> > > > > > > > > more.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Christian König
> > > > > > > > Please include reported-by credits and link to the bug reports
> > > > > > > > on
> > > > > > > > lore.kernel.org when merging this. Also I guess this should
> > > > > > > > have a Fixes:
> > > > > > > > line?
> > > > > > > I'm not aware of a bug report, but the reported-by/Fixes lines
> > > > > > > are indeed
> > > > > > > missing.
> > > > > > This one here:
> > > > > >
> > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20201231104020.GA4504%40zn.tnic%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7Cff77249040634cf2750308d8b64c616d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637459786459556204%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m8tjDXFtsEwtcv9byq5r1sbUuqb8q%2BAn63r4aKMpcaM%3D&reserved=0
> > > > > >
> > > > > > Or did I get confused, and the above is yet another bug?
> > > > > Yeah, but that was just reported by mail. The bug tracker I've saw was
> > > > > opened after the patch was already pushed.
> > > > Still good to give reported-by credits for mailing list reports and
> > > > link to lore.kernel.org for the report, that's not just useful for
> > > > bugzilla reports.
> > > That's indeed true, but I was distracted by the fact that drm-misc-fixes
> > > wasn't up to date :)
> > >
> > > Going to add that earlier next time.
> > >
> > > > > > > BTW: Any idea why dim add-link doesn't work?
> > > > > > Hm we occasionally have fun with email parsing (it's hard) and
> > > > > > especially
> > > > > > python changes in how encodings are handled differently between
> > > > > > python2
> > > > > > and python3. If you have a specific example I can try and take a
> > > > > > look why
> > > > > > it doesn't work.
> > > > > It just looks up and doesn't seem to do anything. I'm not familiar
> > > > > with
> > > > > python so I can just describe the symptoms.
> > > > I meant tell me which mail (patchwork or lore) and I'll try to
> > > > reproduce and see what's maybe up.
> > > It doesn't seem to work in general. E.g. any patch I try I just don't get
> > > any progress in over 10 Minutes.
> > >
> > > Maybe some server is not responding?
> > Uh dim add-link pretty similar to dim apply-patch, it takes the mbox on
> > stdin and does only local git stuff with it.
>
> AH! Since it was getting a branch parameter I was assuming that it looks at
> patches on that branch!
Yeah the branch parameter is just so it knows where it should add the
Link: Since the link is presumably not there yet we can't fish out the
original mbox from archives anyway.
-Daniel
>
> Thanks for the explanation,
> Christian.
>
> > -Daniel
> >
> > > Christian.
> > >
> > > > -Daniel
> > > >
> > > > > Christian.
> > > > >
> > > > > > -Daniel
> > > > > >
> > > > > > > > And maybe some words on how/why stuff blows up.
> > > > > > > Just a typo. I've forgot to remove two lines in radeon while
> > > > > > > rebasing and
> > > > > > > still had the symbols exported so never noticed this.
> > > > > > >
> > > > > > > Christian.
> > > > > > >
> > > > > > > > -Daniel
> > > > > > > >
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> > > > > > > > > 1 file changed, 3 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > > > > > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > > > > > index d4328ff57757..35b715f82ed8 100644
> > > > > > > > > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > > > > > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > > > > > > > > @@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device
> > > > > > > > > *rdev)
> > > > > > > > > }
> > > > > > > > > rdev->mman.initialized = true;
> > > > > > > > > - ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev,
> > > > > > > > > rdev->need_swiotlb,
> > > > > > > > > -dma_addressing_limited(&rdev->pdev->dev));
> > > > > > > > > -
> > > > > > > > > r = radeon_ttm_init_vram(rdev);
> > > > > > > > > if (r) {
> > > > > > > > > DRM_ERROR("Failed initializing VRAM
> > > > > > > > > heap.\n");
> > > > > > > > > --
> > > > > > > >
Re: [PATCH v4 11/13] drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update
On Tue, Jan 12, 2021 at 08:54:02AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 18:06 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:38AM +0100, Thomas Zimmermann wrote:
> > > Cursor updates in vboxvideo require a short-term mapping of the
> > > source BO. Use drm_gem_vram_vmap_local() and avoid the pinning
> > > operations.
> > >
> > > Signed-off-by: Thomas Zimmermann
> >
> > All these drivers patches break the dma_resv_lock vs
> > dma_fence_begin/end_signalling nesting rules, so this doesn't work.
> >
> > Generally this is what the prepare/cleanup_fb hooks are for, that's where
> > mappings (including vmaps) are meant to be set up, permanently.
> >
> > I'm kinda not clear on why we need all these changes, I thought the
> > locking problem is just in the fb helper paths, because it's outside of
> > the atomic path and could conflict with an atomic update at the same time?
> > So only that one should get the vmap_local treatment, everything else
> > should keep the normal vmap treatment.
>
> Kind of responding to all your comment on the driver changes:
>
> These drivers only require short-term mappings, so using vmap_local would be
> the natural choice. For SHMEM helpers, it's mostly a cosmetic thing. For
> VRAM helpers, I was hoping to remove the vmap/vunmap helpers entirely. One
> cannot really map the BOs for the long-term, so not having the helpers at
> all would make sense.
>
> But reading all your comments on the driver patches, I'd rather not update
> the drivers here but later convert them to use prepare_fb/cleanup_fb in the
> correct way.
Ack from me on this plan. I think I got all the other patches with an r-b
or ack?
-Daniel
>
> Best regards
> Thomas
>
> > -Daniel
> > > ---
> > > drivers/gpu/drm/vboxvideo/vbox_mode.c | 15 +--
> > > 1 file changed, 9 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > index dbc0dd53c69e..215b37c78c10 100644
> > > --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > @@ -381,7 +381,8 @@ static void vbox_cursor_atomic_update(struct
> > > drm_plane *plane,
> > > container_of(plane->dev, struct vbox_private, ddev);
> > > struct vbox_crtc *vbox_crtc = to_vbox_crtc(plane->state->crtc);
> > > struct drm_framebuffer *fb = plane->state->fb;
> > > - struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
> > > + struct drm_gem_object *obj = fb->obj[0];
> > > + struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(obj);
> > > u32 width = plane->state->crtc_w;
> > > u32 height = plane->state->crtc_h;
> > > size_t data_size, mask_size;
> > > @@ -401,11 +402,12 @@ static void vbox_cursor_atomic_update(struct
> > > drm_plane *plane,
> > > vbox_crtc->cursor_enabled = true;
> > > - ret = drm_gem_vram_vmap(gbo, &map);
> > > + ret = dma_resv_lock(obj->resv, NULL);
> > > + if (ret)
> > > + return;
> > > + ret = drm_gem_vram_vmap_local(gbo, &map);
> > > if (ret) {
> > > - /*
> > > - * BUG: we should have pinned the BO in prepare_fb().
> > > - */
> > > + dma_resv_unlock(obj->resv);
> > > mutex_unlock(&vbox->hw_mutex);
> > > DRM_WARN("Could not map cursor bo, skipping update\n");
> > > return;
> > > @@ -421,7 +423,8 @@ static void vbox_cursor_atomic_update(struct
> > > drm_plane *plane,
> > > data_size = width * height * 4 + mask_size;
> > > copy_cursor_image(src, vbox->cursor_data, width, height,
> > > mask_size);
> > > - drm_gem_vram_vunmap(gbo, &map);
> > > + drm_gem_vram_vunmap_local(gbo, &map);
> > > + dma_resv_unlock(obj->resv);
> > > flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
> > > VBOX_MOUSE_POINTER_ALPHA;
> > > --
> > > 2.29.2
> > >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Check actual format for legacy pageflip.
On Mon, Jan 11, 2021 at 04:28:31PM -0500, Alex Deucher wrote:
> On Mon, Jan 11, 2021 at 11:39 AM Bas Nieuwenhuizen
> wrote:
> >
> > On Mon, Jan 11, 2021 at 4:02 PM Alex Deucher wrote:
> > >
> > > On Sat, Jan 9, 2021 at 9:11 PM Bas Nieuwenhuizen
> > > wrote:
> > > >
> > > > With modifiers one can actually have different format_info structs
> > > > for the same format, which now matters for AMDGPU since we convert
> > > > implicit modifiers to explicit modifiers with multiple planes.
> > > >
> > > > I checked other drivers and it doesn't look like they end up triggering
> > > > this case so I think this is safe to relax.
> > > >
> > > > Signed-off-by: Bas Nieuwenhuizen
> > > > Reviewed-by: Daniel Vetter
> > > > Reviewed-by: Zhan Liu
> > > > Acked-by: Christian König
> > > > Acked-by: Alex Deucher
> > > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for
> > > > converted metadata.")
> > >
> > > Do you have commit rights to drm-misc or do you need someone to commit
> > > this for you?
> >
> > I don't have commit rights so if the patch could be committed for me
> > that would be appreciated!
>
> Pushed to drm-misc-fixes. Thanks!
>
> If you want access to drm-misc, I don't see any reason you shouldn't have it.
There's some old-school bash tooling involved since we're (not yet, I can
hope) doing gitlab MR:
https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html
Otherwise makes sense imo.
-Daniel
>
> Alex
>
>
> > >
> > > Thanks!
> > >
> > > Alex
> > >
> > > > ---
> > > > drivers/gpu/drm/drm_plane.c | 9 -
> > > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > > index e6231947f987..a0cb746bcb0a 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -1163,7 +1163,14 @@ int drm_mode_page_flip_ioctl(struct drm_device
> > > > *dev,
> > > > if (ret)
> > > > goto out;
> > > >
> > > > - if (old_fb->format != fb->format) {
> > > > + /*
> > > > +* Only check the FOURCC format code, excluding modifiers. This
> > > > is
> > > > +* enough for all legacy drivers. Atomic drivers have their own
> > > > +* checks in their ->atomic_check implementation, which will
> > > > +* return -EINVAL if any hw or driver constraint is violated due
> > > > +* to modifier changes.
> > > > +*/
> > > > + if (old_fb->format->format != fb->format->format) {
> > > > DRM_DEBUG_KMS("Page flip is not allowed to change frame
> > > > buffer format.\n");
> > > > ret = -EINVAL;
> > > > goto out;
> > > > --
> > > > 2.29.2
> > > >
> > > > ___
> > > > amd-gfx mailing list
> > > > amd-...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm: distinguish return value of drm_dp_check_and_send_link_address.
On Tuesday, January 12th, 2021 at 7:36 AM, Chen, Xiaogang wrote: > Any comment? > > -Original Message- > From: Xiaogang.Chen > Sent: Monday, January 4, 2021 12:02 AM > To: amd-...@lists.freedesktop.org; Wentland, Harry ; > dri-devel@lists.freedesktop.org; airl...@linux.ie > Cc: Chen, Xiaogang > Subject: [PATCH 1/2] drm: distinguish return value of > drm_dp_check_and_send_link_address. > > From: Xiaogang Chen > > drm_dp_check_and_send_link_address discovers MST device topology. > It can return both positive and negative values. When it returns positive > values there is no error found. If it returns negative values there is error > found, such as get NAK , timeout, etc. Following drm_kms_helper_hotplug_event > should be called when drm_dp_check_and_send_link_address returns positive > value. > > Signed-off-by: Xiaogang Chen To the best of my knowledge, this sounds correct. Please wrap your commit message into 80-character lines so that it's easier to read. Regardless, this is: Acked-by: Simon Ser ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] dp/dp_mst: Add support for sink event notify messages
Hi Sam,
This series still hasn't been merged. It still applies cleanly to v5.11-rc1.
Daniel, can you merge this series for 5.12? Or Ack this series so I can merge
it?
The first three patches deal with DP MST support, and this needs review from
you or David.
Regards,
Hans
On 23/09/2020 04:13, Sam McNally wrote:
> Sink event notify messages are used for MST CEC IRQs. Add parsing
> support for sink event notify messages in preparation for handling MST
> CEC IRQs.
>
> Signed-off-by: Sam McNally
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
> include/drm/drm_dp_mst_helper.h | 14 ++
> 2 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 17dbed0a9800..15b6cc39a754 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1027,6 +1027,30 @@ static bool
> drm_dp_sideband_parse_resource_status_notify(struct drm_dp_sideband_
> return false;
> }
>
> +static bool drm_dp_sideband_parse_sink_event_notify(
> + struct drm_dp_sideband_msg_rx *raw,
> + struct drm_dp_sideband_msg_req_body *msg)
> +{
> + int idx = 1;
> +
> + msg->u.sink_event.port_number = (raw->msg[idx] & 0xf0) >> 4;
> + idx++;
> + if (idx > raw->curlen)
> + goto fail_len;
> +
> + memcpy(msg->u.sink_event.guid, &raw->msg[idx], 16);
> + idx += 16;
> + if (idx > raw->curlen)
> + goto fail_len;
> +
> + msg->u.sink_event.event_id = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
> + idx++;
> + return true;
> +fail_len:
> + DRM_DEBUG_KMS("sink event notify parse length fail %d %d\n", idx,
> raw->curlen);
> + return false;
> +}
> +
> static bool drm_dp_sideband_parse_req(struct drm_dp_sideband_msg_rx *raw,
> struct drm_dp_sideband_msg_req_body *msg)
> {
> @@ -1038,6 +1062,8 @@ static bool drm_dp_sideband_parse_req(struct
> drm_dp_sideband_msg_rx *raw,
> return drm_dp_sideband_parse_connection_status_notify(raw, msg);
> case DP_RESOURCE_STATUS_NOTIFY:
> return drm_dp_sideband_parse_resource_status_notify(raw, msg);
> + case DP_SINK_EVENT_NOTIFY:
> + return drm_dp_sideband_parse_sink_event_notify(raw, msg);
> default:
> DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
> drm_dp_mst_req_type_str(msg->req_type));
> @@ -3875,6 +3901,8 @@ drm_dp_mst_process_up_req(struct
> drm_dp_mst_topology_mgr *mgr,
> guid = msg->u.conn_stat.guid;
> else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
> guid = msg->u.resource_stat.guid;
> + else if (msg->req_type == DP_SINK_EVENT_NOTIFY)
> + guid = msg->u.sink_event.guid;
>
> if (guid)
> mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> @@ -3948,7 +3976,8 @@ static int drm_dp_mst_handle_up_req(struct
> drm_dp_mst_topology_mgr *mgr)
> drm_dp_sideband_parse_req(&mgr->up_req_recv, &up_req->msg);
>
> if (up_req->msg.req_type != DP_CONNECTION_STATUS_NOTIFY &&
> - up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY) {
> + up_req->msg.req_type != DP_RESOURCE_STATUS_NOTIFY &&
> + up_req->msg.req_type != DP_SINK_EVENT_NOTIFY) {
> DRM_DEBUG_KMS("Received unknown up req type, ignoring: %x\n",
> up_req->msg.req_type);
> kfree(up_req);
> @@ -3976,6 +4005,12 @@ static int drm_dp_mst_handle_up_req(struct
> drm_dp_mst_topology_mgr *mgr)
> DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n",
> res_stat->port_number,
> res_stat->available_pbn);
> + } else if (up_req->msg.req_type == DP_SINK_EVENT_NOTIFY) {
> + const struct drm_dp_sink_event_notify *sink_event =
> + &up_req->msg.u.sink_event;
> +
> + DRM_DEBUG_KMS("Got SEN: pn: %d event_id %d\n",
> + sink_event->port_number, sink_event->event_id);
> }
>
> up_req->hdr = mgr->up_req_recv.initial_hdr;
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 6ae5860d8644..c7c79e0ced18 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -402,6 +402,19 @@ struct drm_dp_resource_status_notify {
> u16 available_pbn;
> };
>
> +#define DP_SINK_EVENT_PANEL_REPLAY_ACTIVE_FRAME_CRC_ERRORBIT(0)
> +#define DP_SINK_EVENT_PANEL_REPLAY_RFB_STORAGE_ERROR BIT(1)
> +#define DP_SINK_EVENT_DSC_RC_BUFFER_UNDER_RUNBIT(2)
> +#define DP_SINK_EVENT_DSC_RC_BUFFER_OVERFLOW BIT(3)
> +#define DP_SINK_EVENT_DSC_CHUNK_LENGTH_ERROR BIT(4)
> +#de
Re: [PATCH v4 11/13] drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update
Hi
Am 12.01.21 um 10:17 schrieb Daniel Vetter:
On Tue, Jan 12, 2021 at 08:54:02AM +0100, Thomas Zimmermann wrote:
Hi
Am 11.01.21 um 18:06 schrieb Daniel Vetter:
On Fri, Jan 08, 2021 at 10:43:38AM +0100, Thomas Zimmermann wrote:
Cursor updates in vboxvideo require a short-term mapping of the
source BO. Use drm_gem_vram_vmap_local() and avoid the pinning
operations.
Signed-off-by: Thomas Zimmermann
All these drivers patches break the dma_resv_lock vs
dma_fence_begin/end_signalling nesting rules, so this doesn't work.
Generally this is what the prepare/cleanup_fb hooks are for, that's where
mappings (including vmaps) are meant to be set up, permanently.
I'm kinda not clear on why we need all these changes, I thought the
locking problem is just in the fb helper paths, because it's outside of
the atomic path and could conflict with an atomic update at the same time?
So only that one should get the vmap_local treatment, everything else
should keep the normal vmap treatment.
Kind of responding to all your comment on the driver changes:
These drivers only require short-term mappings, so using vmap_local would be
the natural choice. For SHMEM helpers, it's mostly a cosmetic thing. For
VRAM helpers, I was hoping to remove the vmap/vunmap helpers entirely. One
cannot really map the BOs for the long-term, so not having the helpers at
all would make sense.
But reading all your comments on the driver patches, I'd rather not update
the drivers here but later convert them to use prepare_fb/cleanup_fb in the
correct way.
Ack from me on this plan. I think I got all the other patches with an r-b
or ack?
The shmem patch needs an update from my side.
Best regards
Thomas
-Daniel
Best regards
Thomas
-Daniel
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index dbc0dd53c69e..215b37c78c10 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -381,7 +381,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
container_of(plane->dev, struct vbox_private, ddev);
struct vbox_crtc *vbox_crtc = to_vbox_crtc(plane->state->crtc);
struct drm_framebuffer *fb = plane->state->fb;
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ struct drm_gem_object *obj = fb->obj[0];
+ struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(obj);
u32 width = plane->state->crtc_w;
u32 height = plane->state->crtc_h;
size_t data_size, mask_size;
@@ -401,11 +402,12 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
vbox_crtc->cursor_enabled = true;
- ret = drm_gem_vram_vmap(gbo, &map);
+ ret = dma_resv_lock(obj->resv, NULL);
+ if (ret)
+ return;
+ ret = drm_gem_vram_vmap_local(gbo, &map);
if (ret) {
- /*
-* BUG: we should have pinned the BO in prepare_fb().
-*/
+ dma_resv_unlock(obj->resv);
mutex_unlock(&vbox->hw_mutex);
DRM_WARN("Could not map cursor bo, skipping update\n");
return;
@@ -421,7 +423,8 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
data_size = width * height * 4 + mask_size;
copy_cursor_image(src, vbox->cursor_data, width, height, mask_size);
- drm_gem_vram_vunmap(gbo, &map);
+ drm_gem_vram_vunmap_local(gbo, &map);
+ dma_resv_unlock(obj->resv);
flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
VBOX_MOUSE_POINTER_ALPHA;
--
2.29.2
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm: Inline AGP wrappers into their only callers
Hi
Am 12.01.21 um 09:59 schrieb Daniel Vetter:
On Tue, Jan 12, 2021 at 09:10:30AM +0100, Thomas Zimmermann wrote:
The AGP wrapper functions serve no purpose.
Signed-off-by: Thomas Zimmermann
They do, without them we fail compiling (I think at least) when agp isn't
I thought so. But the only callers are in drm_agpsupport.c, which
depends on CONFIG_AGP in the Makefile. So I expected this to work.
Best regards
Thomas
enabled. Did you check for that? I should all work if we have the dummy
inlines for relevant agp functions in linux/agp_backend.h.
-Daniel
---
drivers/gpu/drm/drm_agpsupport.c | 12 ++--
drivers/gpu/drm/drm_memory.c | 18 --
include/drm/drm_agpsupport.h | 18 --
3 files changed, 6 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 4c7ad46fdd21..8b690ef306de 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -285,7 +285,7 @@ int drm_agp_unbind(struct drm_device *dev, struct
drm_agp_binding *request)
entry = drm_agp_lookup_entry(dev, request->handle);
if (!entry || !entry->bound)
return -EINVAL;
- ret = drm_unbind_agp(entry->memory);
+ ret = agp_unbind_memory(entry->memory);
if (ret == 0)
entry->bound = 0;
return ret;
@@ -326,7 +326,7 @@ int drm_agp_bind(struct drm_device *dev, struct
drm_agp_binding *request)
if (!entry || entry->bound)
return -EINVAL;
page = DIV_ROUND_UP(request->offset, PAGE_SIZE);
- retcode = drm_bind_agp(entry->memory, page);
+ retcode = agp_bind_memory(entry->memory, page);
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
@@ -369,11 +369,11 @@ int drm_agp_free(struct drm_device *dev, struct
drm_agp_buffer *request)
if (!entry)
return -EINVAL;
if (entry->bound)
- drm_unbind_agp(entry->memory);
+ agp_unbind_memory(entry->memory);
list_del(&entry->head);
- drm_free_agp(entry->memory, entry->pages);
+ agp_free_memory(entry->memory);
kfree(entry);
return 0;
}
@@ -453,8 +453,8 @@ void drm_legacy_agp_clear(struct drm_device *dev)
list_for_each_entry_safe(entry, tempe, &dev->agp->memory, head) {
if (entry->bound)
- drm_unbind_agp(entry->memory);
- drm_free_agp(entry->memory, entry->pages);
+ agp_unbind_memory(entry->memory);
+ agp_free_memory(entry->memory);
kfree(entry);
}
INIT_LIST_HEAD(&dev->agp->memory);
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index fbea69d6f909..f4f2bffdd5bd 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -100,24 +100,6 @@ static void *agp_remap(unsigned long offset, unsigned long
size,
return addr;
}
-/** Wrapper around agp_free_memory() */
-void drm_free_agp(struct agp_memory *handle, int pages)
-{
- agp_free_memory(handle);
-}
-
-/** Wrapper around agp_bind_memory() */
-int drm_bind_agp(struct agp_memory *handle, unsigned int start)
-{
- return agp_bind_memory(handle, start);
-}
-
-/** Wrapper around agp_unbind_memory() */
-int drm_unbind_agp(struct agp_memory *handle)
-{
- return agp_unbind_memory(handle);
-}
-
#else /* CONFIG_AGP */
static inline void *agp_remap(unsigned long offset, unsigned long size,
struct drm_device *dev)
diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
index 664e120b93e6..f3136750c490 100644
--- a/include/drm/drm_agpsupport.h
+++ b/include/drm/drm_agpsupport.h
@@ -28,10 +28,6 @@ struct drm_agp_head {
#if IS_ENABLED(CONFIG_AGP)
-void drm_free_agp(struct agp_memory * handle, int pages);
-int drm_bind_agp(struct agp_memory * handle, unsigned int start);
-int drm_unbind_agp(struct agp_memory * handle);
-
struct drm_agp_head *drm_agp_init(struct drm_device *dev);
void drm_legacy_agp_clear(struct drm_device *dev);
int drm_agp_acquire(struct drm_device *dev);
@@ -61,20 +57,6 @@ int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
#else /* CONFIG_AGP */
-static inline void drm_free_agp(struct agp_memory * handle, int pages)
-{
-}
-
-static inline int drm_bind_agp(struct agp_memory * handle, unsigned int start)
-{
- return -ENODEV;
-}
-
-static inline int drm_unbind_agp(struct agp_memory * handle)
-{
- return -ENODEV;
-}
-
static inline struct drm_agp_head *drm_agp_init(struct drm_device *dev)
{
return NULL;
--
2.29.2
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH][next] drm/amdgpu: Add missing BOOTUP_DEFAULT to profile_name[]
On Mon, Jan 11, 2021 at 11:46:38AM +, Colin King wrote: > From: Colin Ian King > > A recent change added a new BOOTUP_DEFAULT power profile mode > to the PP_SMC_POWER_PROFILE enum but omitted updating the > corresponding profile_name array. Fix this by adding in the > missing BOOTUP_DEFAULT to profile_name[]. > Still not enough to prevent the array overflow. It needs POWERSAVE as well. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 1/3] drm/vkms: Add vkms_config type
On 01/12, Sumera Priyadarsini wrote:
> Currently, data for the device instance is held by vkms_device.
> Add a separate type, vkms_config to contain configuration details
> for the device and various modes to be later used by configfs.
> This config data stays constant once the device is created.
>
> Accordingly, add vkms_create and vkms_destroy to initialize/destroy
> device through configfs. Currently, they are being called from vkms_init
> and vkms_exit, but will be evoked from configfs later on. When configfs
> is added, device configuration will be tracked by configfs and only vkms
> device lifetime will be handled by vkms_init and vkms_exit functions.
>
> Modify usage of enable_cursor feature to reflect the changes in
> relevant files.
>
> Co-developed-by: Daniel Vetter
> Signed-off-by: Daniel Vetter
> Signed-off-by: Sumera Priyadarsini
> ---
> drivers/gpu/drm/vkms/vkms_drv.c| 40 --
> drivers/gpu/drm/vkms/vkms_drv.h| 12 +++--
> drivers/gpu/drm/vkms/vkms_output.c | 4 +--
> 3 files changed, 44 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index aef29393b811..6b33975a5cb2 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -34,9 +34,9 @@
> #define DRIVER_MAJOR 1
> #define DRIVER_MINOR 0
>
> -static struct vkms_device *vkms_device;
> +static struct vkms_config *default_config;
>
> -bool enable_cursor = true;
> +static bool enable_cursor = true;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>
> @@ -122,10 +122,11 @@ static int vkms_modeset_init(struct vkms_device
> *vkmsdev)
> return vkms_output_init(vkmsdev, 0);
> }
>
> -static int __init vkms_init(void)
> +static int vkms_create(struct vkms_config *config)
> {
> int ret;
> struct platform_device *pdev;
> + struct vkms_device *vkms_device;
>
> pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
> if (IS_ERR(pdev))
> @@ -143,6 +144,8 @@ static int __init vkms_init(void)
> goto out_devres;
> }
> vkms_device->platform = pdev;
> + vkms_device->config = config;
> + config->dev = vkms_device;
>
> ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
> DMA_BIT_MASK(64));
> @@ -179,21 +182,42 @@ static int __init vkms_init(void)
> return ret;
> }
>
> -static void __exit vkms_exit(void)
> +static int __init vkms_init(void)
> +{
> + struct vkms_config *config = kmalloc(sizeof(*config), GFP_KERNEL);
> +
> + default_config = config;
> +
> + config->cursor = enable_cursor;
> +
> + return vkms_create(config);
> +}
> +
> +static void vkms_destroy(struct vkms_config *config)
> {
> struct platform_device *pdev;
>
> - if (!vkms_device) {
> + if (!config->dev) {
> DRM_INFO("vkms_device is NULL.\n");
> return;
> }
>
> - pdev = vkms_device->platform;
> + pdev = config->dev->platform;
>
> - drm_dev_unregister(&vkms_device->drm);
> - drm_atomic_helper_shutdown(&vkms_device->drm);
> + drm_dev_unregister(&config->dev->drm);
> + drm_atomic_helper_shutdown(&config->dev->drm);
> devres_release_group(&pdev->dev, NULL);
> platform_device_unregister(pdev);
> +
> + config->dev = NULL;
> +}
> +
> +static void __exit vkms_exit(void)
> +{
> + if (default_config->dev)
> + vkms_destroy(default_config);
> +
> + kfree(default_config);
> }
>
> module_init(vkms_init);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 5ed91ff08cb3..6a27bd8875f2 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -19,8 +19,6 @@
> #define XRES_MAX 8192
> #define YRES_MAX 8192
>
> -extern bool enable_cursor;
> -
> struct vkms_composer {
> struct drm_framebuffer fb;
> struct drm_rect src, dst;
> @@ -82,10 +80,19 @@ struct vkms_output {
> spinlock_t composer_lock;
> };
>
> +struct vkms_device;
> +
> +struct vkms_config {
> + bool cursor;
> + /* only set when instantiated */
> + struct vkms_device *dev;
> +};
> +
> struct vkms_device {
> struct drm_device drm;
> struct platform_device *platform;
> struct vkms_output output;
> + const struct vkms_config *config;
> };
>
> #define drm_crtc_to_vkms_output(target) \
> @@ -124,3 +131,4 @@ void vkms_set_composer(struct vkms_output *out, bool
> enabled);
> int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
>
> #endif /* _VKMS_DRV_H_ */
> +
There is an extra line here
Apart from that, looks good to me.
Reviewed-by: Melissa Wen
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index 4a1848b0318f..8f3ffb28b9d1 100644
> --- a/drivers/gpu/d
Re: [PATCH V5 2/3] drm/vkms: Add support for writeback module
On 01/12, Sumera Priyadarsini wrote:
> Add enable_writeback feature to vkms_config as a module.
>
> Signed-off-by: Sumera Priyadarsini
> ---
> drivers/gpu/drm/vkms/vkms_drv.c| 5 +
> drivers/gpu/drm/vkms/vkms_drv.h| 1 +
> drivers/gpu/drm/vkms/vkms_output.c | 9 ++---
> 3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 6b33975a5cb2..708f7f54001d 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -40,6 +40,10 @@ static bool enable_cursor = true;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>
> +static bool enable_writeback = true;
> +module_param_named(enable_writeback, enable_writeback, bool, 0444);
> +MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector
> support");
> +
> DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
>
> static void vkms_release(struct drm_device *dev)
> @@ -189,6 +193,7 @@ static int __init vkms_init(void)
> default_config = config;
>
> config->cursor = enable_cursor;
> + config->writeback = enable_writeback;
>
> return vkms_create(config);
> }
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 6a27bd8875f2..b9b4e2bc11c0 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -83,6 +83,7 @@ struct vkms_output {
> struct vkms_device;
>
> struct vkms_config {
> + bool writeback;
> bool cursor;
> /* only set when instantiated */
> struct vkms_device *dev;
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index 8f3ffb28b9d1..f5f6f15c362c 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -41,6 +41,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
> struct drm_crtc *crtc = &output->crtc;
> struct drm_plane *primary, *cursor = NULL;
> int ret;
> + int writeback;
>
> primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY, index);
> if (IS_ERR(primary))
> @@ -80,9 +81,11 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
> index)
> goto err_attach;
> }
>
> - ret = vkms_enable_writeback_connector(vkmsdev);
> - if (ret)
> - DRM_ERROR("Failed to init writeback connector\n");
> + if (vkmsdev->config->writeback) {
> + writeback = vkms_enable_writeback_connector(vkmsdev);
> + if (writeback)
> + DRM_ERROR("Failed to init writeback connector\n");
> + }
Thanks,
Reviewed-by: Melissa Wen
>
> drm_mode_config_reset(dev);
>
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 3/3] drm/vkms: Add information about module options
On 01/12, Sumera Priyadarsini wrote: > Update vkms documentation to contain usage of `modinfo` > command and steps to load vkms with module options enabled. > > Signed-off-by: Sumera Priyadarsini > --- > Documentation/gpu/vkms.rst | 12 > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > index 9e030c74a82e..2c9b376da5ca 100644 > --- a/Documentation/gpu/vkms.rst > +++ b/Documentation/gpu/vkms.rst > @@ -35,6 +35,18 @@ Now, to load the driver, use:: > On running the lsmod command now, the VKMS driver will appear listed. > You can also observe the driver being loaded in the dmesg logs. > > +The VKMS driver has optional features to simulate different kinds of > hardware, > +which are exposed as module options. You can use the `modinfo` command > +to see the module options for vkms:: > + > + modinfo vkms > + > +Module options are helpful when testing, and enabling modules > +can be done while loading vkms. For example, to load vkms with cursor > enabled, > +use:: > + > + sudo modprobe vkms enable_cursor=1 > + Hi Sumera, Thanks for documenting. You forgot to bring Daniel's ack; however, as I also reviewed and lgtm, Reviewed-by: Melissa Wen > To disable the driver, use :: > >sudo modprobe -r vkms > -- > 2.25.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 098/162] drm/i915/gtt: map the PD up front
On Fri, 27 Nov 2020 at 13:32, Chris Wilson wrote: > > Quoting Matthew Auld (2020-11-27 12:06:14) > > We need to general our accessor for the page directories and tables from > > using the simple kmap_atomic to support local memory, and this setup > > must be done on acquisition of the backing storage prior to entering > > fence execution contexts. Here we replace the kmap with the object > > maping code that for simple single page shmemfs object will return a > > plain kmap, that is then kept for the lifetime of the page directory. > > > > Signed-off-by: Matthew Auld > > Signed-off-by: Chris Wilson > > We are going to really struggle with this on 32b :( Just go back to mapping everything on demand like we did previously, and unmap as soon as we are done with the current directory across alloc/insert/clear? > -Chris > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: make the pool shrinker lock a mutex
Ping? Ray can I get an acked-by? It's an important bug fix.
Thanks,
Christian.
Am 11.01.21 um 14:57 schrieb Christian König:
set_pages_wb() might sleep and so we can't do this in an atomic context.
Signed-off-by: Christian König
Reported-by: Mikhail Gavrilov
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
---
drivers/gpu/drm/ttm/ttm_pool.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index a00b7ab9c14c..6a6eeba423d1 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -66,7 +66,7 @@ static struct ttm_pool_type global_uncached[MAX_ORDER];
static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
-static spinlock_t shrinker_lock;
+static struct mutex shrinker_lock;
static struct list_head shrinker_list;
static struct shrinker mm_shrinker;
@@ -249,9 +249,9 @@ static void ttm_pool_type_init(struct ttm_pool_type *pt, struct ttm_pool *pool,
spin_lock_init(&pt->lock);
INIT_LIST_HEAD(&pt->pages);
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
list_add_tail(&pt->shrinker_list, &shrinker_list);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
}
/* Remove a pool_type from the global shrinker list and free all pages */
@@ -259,9 +259,9 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
{
struct page *p, *tmp;
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
list_del(&pt->shrinker_list);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
list_for_each_entry_safe(p, tmp, &pt->pages, lru)
ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
@@ -302,7 +302,7 @@ static unsigned int ttm_pool_shrink(void)
unsigned int num_freed;
struct page *p;
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list);
p = ttm_pool_type_take(pt);
@@ -314,7 +314,7 @@ static unsigned int ttm_pool_shrink(void)
}
list_move_tail(&pt->shrinker_list, &shrinker_list);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
return num_freed;
}
@@ -564,7 +564,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct seq_file
*m)
{
unsigned int i;
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
seq_puts(m, "\t ");
for (i = 0; i < MAX_ORDER; ++i)
@@ -600,7 +600,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct seq_file
*m)
seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
atomic_long_read(&allocated_pages), page_pool_size);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
return 0;
}
@@ -644,7 +644,7 @@ int ttm_pool_mgr_init(unsigned long num_pages)
if (!page_pool_size)
page_pool_size = num_pages;
- spin_lock_init(&shrinker_lock);
+ mutex_init(&shrinker_lock);
INIT_LIST_HEAD(&shrinker_list);
for (i = 0; i < MAX_ORDER; ++i) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu: Avoid sleeping during FPU critical sections
Am 11.01.21 um 17:32 schrieb Daniel Vetter:
On Mon, Jan 11, 2021 at 09:53:56AM +0100, Christian König wrote:
Am 08.01.21 um 22:58 schrieb Jeremy Cline:
dcn20_resource_construct() includes a number of kzalloc(GFP_KERNEL)
calls which can sleep, but kernel_fpu_begin() disables preemption and
sleeping in this context is invalid.
The only places the FPU appears to be required is in the
init_soc_bounding_box() function and when calculating the
{min,max}_fill_clk_mhz. Narrow the scope to just these two parts to
avoid sleeping while using the FPU.
Fixes: 7a8a3430be15 ("amdgpu: Wrap FPU dependent functions in dc20")
Cc: Timothy Pearson
Signed-off-by: Jeremy Cline
Good catch, but I would rather replace the kzalloc(GFP_KERNEL) with a
kzalloc(GFP_ATOMIC) for now.
We have tons of problems with this DC_FP_START()/DC_FP_END() annotations and
are even in the process of moving them out of the file because the compiles
tend to clutter FP registers even outside of the annotated ranges on some
architectures.
Out of curiosity, what's the plan? Soft-fp implementation for DC so you
can keep the algorithms all unchanged, or redoing them as some fixed point
with careful review and retesting everything? Something else?
My last status is that we want to move all FP related functions into a
separate C file.
Then compile only that file with FP enabled and all callers of those
functions must protected the function calls with FP enable/disable.
That's the only way we can guarantee that no FP state is corrupted.
Regards,
Christian.
-Daniel
Regards,
Christian.
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index e04ecf0fc0db..a4fa5bf016c1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -3622,6 +3622,7 @@ static bool init_soc_bounding_box(struct dc *dc,
if (bb && ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev)) {
int i;
+ DC_FP_START();
dcn2_0_nv12_soc.sr_exit_time_us =
fixed16_to_double_to_cpu(bb->sr_exit_time_us);
dcn2_0_nv12_soc.sr_enter_plus_exit_time_us =
@@ -3721,6 +3722,7 @@ static bool init_soc_bounding_box(struct dc *dc,
dcn2_0_nv12_soc.clock_limits[i].dram_speed_mts =
fixed16_to_double_to_cpu(bb->clock_limits[i].dram_speed_mts);
}
+ DC_FP_END();
}
if (pool->base.pp_smu) {
@@ -3777,8 +3779,6 @@ static bool dcn20_resource_construct(
enum dml_project dml_project_version =
get_dml_project_version(ctx->asic_id.hw_internal_rev);
- DC_FP_START();
-
ctx->dc_bios->regs = &bios_regs;
pool->base.funcs = &dcn20_res_pool_funcs;
@@ -3959,8 +3959,10 @@ static bool dcn20_resource_construct(
ranges.reader_wm_sets[i].wm_inst = i;
ranges.reader_wm_sets[i].min_drain_clk_mhz =
PP_SMU_WM_SET_RANGE_CLK_UNCONSTRAINED_MIN;
ranges.reader_wm_sets[i].max_drain_clk_mhz =
PP_SMU_WM_SET_RANGE_CLK_UNCONSTRAINED_MAX;
+ DC_FP_START();
ranges.reader_wm_sets[i].min_fill_clk_mhz = (i >
0) ? (loaded_bb->clock_limits[i - 1].dram_speed_mts / 16) + 1 : 0;
ranges.reader_wm_sets[i].max_fill_clk_mhz =
loaded_bb->clock_limits[i].dram_speed_mts / 16;
+ DC_FP_END();
ranges.num_reader_wm_sets = i + 1;
}
@@ -4125,12 +4127,10 @@ static bool dcn20_resource_construct(
pool->base.oem_device = NULL;
}
- DC_FP_END();
return true;
create_fail:
- DC_FP_END();
dcn20_resource_destruct(pool);
return false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu: Avoid sleeping during FPU critical sections
Am 11.01.21 um 16:39 schrieb Jeremy Cline:
Hi,
On Mon, Jan 11, 2021 at 09:53:56AM +0100, Christian König wrote:
Am 08.01.21 um 22:58 schrieb Jeremy Cline:
dcn20_resource_construct() includes a number of kzalloc(GFP_KERNEL)
calls which can sleep, but kernel_fpu_begin() disables preemption and
sleeping in this context is invalid.
The only places the FPU appears to be required is in the
init_soc_bounding_box() function and when calculating the
{min,max}_fill_clk_mhz. Narrow the scope to just these two parts to
avoid sleeping while using the FPU.
Fixes: 7a8a3430be15 ("amdgpu: Wrap FPU dependent functions in dc20")
Cc: Timothy Pearson
Signed-off-by: Jeremy Cline
Good catch, but I would rather replace the kzalloc(GFP_KERNEL) with a
kzalloc(GFP_ATOMIC) for now.
We have tons of problems with this DC_FP_START()/DC_FP_END() annotations and
are even in the process of moving them out of the file because the compiles
tend to clutter FP registers even outside of the annotated ranges on some
architectures.
Thanks for the review. Is it acceptable to move the DC_FP_END()
annotation up to the last usage? Keeping it where it is is probably
do-able, but covers things like calls to resource_construct() which
makes use of struct resource_create_funcs. I'm guessing only a sub-set
of the implementations are called via this function, but having an
interface which can't sleep sometimes doesn't sound appealing.
Happy to do it, but before I go down that road I just wanted to make
sure that's what you had in mind.
I can't fully judge that either. Harry and the rest of our DC team needs
to decide that.
Thanks,
Christian.
Thanks,
Jeremy
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index e04ecf0fc0db..a4fa5bf016c1 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -3622,6 +3622,7 @@ static bool init_soc_bounding_box(struct dc *dc,
if (bb && ASICREV_IS_NAVI12_P(dc->ctx->asic_id.hw_internal_rev)) {
int i;
+ DC_FP_START();
dcn2_0_nv12_soc.sr_exit_time_us =
fixed16_to_double_to_cpu(bb->sr_exit_time_us);
dcn2_0_nv12_soc.sr_enter_plus_exit_time_us =
@@ -3721,6 +3722,7 @@ static bool init_soc_bounding_box(struct dc *dc,
dcn2_0_nv12_soc.clock_limits[i].dram_speed_mts =
fixed16_to_double_to_cpu(bb->clock_limits[i].dram_speed_mts);
}
+ DC_FP_END();
}
if (pool->base.pp_smu) {
@@ -3777,8 +3779,6 @@ static bool dcn20_resource_construct(
enum dml_project dml_project_version =
get_dml_project_version(ctx->asic_id.hw_internal_rev);
- DC_FP_START();
-
ctx->dc_bios->regs = &bios_regs;
pool->base.funcs = &dcn20_res_pool_funcs;
@@ -3959,8 +3959,10 @@ static bool dcn20_resource_construct(
ranges.reader_wm_sets[i].wm_inst = i;
ranges.reader_wm_sets[i].min_drain_clk_mhz =
PP_SMU_WM_SET_RANGE_CLK_UNCONSTRAINED_MIN;
ranges.reader_wm_sets[i].max_drain_clk_mhz =
PP_SMU_WM_SET_RANGE_CLK_UNCONSTRAINED_MAX;
+ DC_FP_START();
ranges.reader_wm_sets[i].min_fill_clk_mhz = (i >
0) ? (loaded_bb->clock_limits[i - 1].dram_speed_mts / 16) + 1 : 0;
ranges.reader_wm_sets[i].max_fill_clk_mhz =
loaded_bb->clock_limits[i].dram_speed_mts / 16;
+ DC_FP_END();
ranges.num_reader_wm_sets = i + 1;
}
@@ -4125,12 +4127,10 @@ static bool dcn20_resource_construct(
pool->base.oem_device = NULL;
}
- DC_FP_END();
return true;
create_fail:
- DC_FP_END();
dcn20_resource_destruct(pool);
return false;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: make the pool shrinker lock a mutex
On Tue, Jan 12, 2021 at 06:49:18PM +0800, Christian König wrote:
> Ping? Ray can I get an acked-by? It's an important bug fix.
>
> Thanks,
> Christian.
>
> Am 11.01.21 um 14:57 schrieb Christian König:
> > set_pages_wb() might sleep and so we can't do this in an atomic context.
> >
> > Signed-off-by: Christian König
> > Reported-by: Mikhail Gavrilov
> > Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Sorry, missed this mail yesterday.
Patch looks good for me.
Reviewed-by: Huang Rui
> > ---
> > drivers/gpu/drm/ttm/ttm_pool.c | 20 ++--
> > 1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > index a00b7ab9c14c..6a6eeba423d1 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -66,7 +66,7 @@ static struct ttm_pool_type global_uncached[MAX_ORDER];
> > static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> > static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> >
> > -static spinlock_t shrinker_lock;
> > +static struct mutex shrinker_lock;
> > static struct list_head shrinker_list;
> > static struct shrinker mm_shrinker;
> >
> > @@ -249,9 +249,9 @@ static void ttm_pool_type_init(struct ttm_pool_type
> > *pt, struct ttm_pool *pool,
> > spin_lock_init(&pt->lock);
> > INIT_LIST_HEAD(&pt->pages);
> >
> > - spin_lock(&shrinker_lock);
> > + mutex_lock(&shrinker_lock);
> > list_add_tail(&pt->shrinker_list, &shrinker_list);
> > - spin_unlock(&shrinker_lock);
> > + mutex_unlock(&shrinker_lock);
> > }
> >
> > /* Remove a pool_type from the global shrinker list and free all pages */
> > @@ -259,9 +259,9 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
> > {
> > struct page *p, *tmp;
> >
> > - spin_lock(&shrinker_lock);
> > + mutex_lock(&shrinker_lock);
> > list_del(&pt->shrinker_list);
> > - spin_unlock(&shrinker_lock);
> > + mutex_unlock(&shrinker_lock);
> >
> > list_for_each_entry_safe(p, tmp, &pt->pages, lru)
> > ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
> > @@ -302,7 +302,7 @@ static unsigned int ttm_pool_shrink(void)
> > unsigned int num_freed;
> > struct page *p;
> >
> > - spin_lock(&shrinker_lock);
> > + mutex_lock(&shrinker_lock);
> > pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list);
> >
> > p = ttm_pool_type_take(pt);
> > @@ -314,7 +314,7 @@ static unsigned int ttm_pool_shrink(void)
> > }
> >
> > list_move_tail(&pt->shrinker_list, &shrinker_list);
> > - spin_unlock(&shrinker_lock);
> > + mutex_unlock(&shrinker_lock);
> >
> > return num_freed;
> > }
> > @@ -564,7 +564,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> > seq_file *m)
> > {
> > unsigned int i;
> >
> > - spin_lock(&shrinker_lock);
> > + mutex_lock(&shrinker_lock);
> >
> > seq_puts(m, "\t ");
> > for (i = 0; i < MAX_ORDER; ++i)
> > @@ -600,7 +600,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> > seq_file *m)
> > seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
> >atomic_long_read(&allocated_pages), page_pool_size);
> >
> > - spin_unlock(&shrinker_lock);
> > + mutex_unlock(&shrinker_lock);
> >
> > return 0;
> > }
> > @@ -644,7 +644,7 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> > if (!page_pool_size)
> > page_pool_size = num_pages;
> >
> > - spin_lock_init(&shrinker_lock);
> > + mutex_init(&shrinker_lock);
> > INIT_LIST_HEAD(&shrinker_list);
> >
> > for (i = 0; i < MAX_ORDER; ++i) {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/15] drm/arc: Use drmm_mode_config_cleanup
Hi
Am 12.01.21 um 09:43 schrieb Daniel Vetter:
With autocleanup through drm_device management we can delete all the
code. Possible now that there's no confusion against devm_kzalloc'ed
structures anymore.
I inlined arcpgu_setup_mode_config because it's tiny and the newly
needed return value handling would have been more ...
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 +---
drivers/gpu/drm/arc/arcpgu_drv.c | 21 +
drivers/gpu/drm/arc/arcpgu_hdmi.c | 6 +-
drivers/gpu/drm/arc/arcpgu_sim.c | 11 ++-
4 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index 31a85c703307..43313adb1981 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -209,10 +209,8 @@ int arc_pgu_setup_crtc(struct drm_device *drm)
ret = drm_crtc_init_with_planes(drm, &arcpgu->pipe.crtc, primary, NULL,
&arc_pgu_crtc_funcs, NULL);
- if (ret) {
- arc_pgu_plane_destroy(primary);
+ if (ret)
return ret;
- }
drm_crtc_helper_add(&arcpgu->pipe.crtc, &arc_pgu_crtc_helper_funcs);
return 0;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 9020352816fa..6349e9dc770e 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -30,16 +30,6 @@ static const struct drm_mode_config_funcs
arcpgu_drm_modecfg_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static void arcpgu_setup_mode_config(struct drm_device *drm)
-{
- drm_mode_config_init(drm);
- drm->mode_config.min_width = 0;
- drm->mode_config.min_height = 0;
- drm->mode_config.max_width = 1920;
- drm->mode_config.max_height = 1080;
- drm->mode_config.funcs = &arcpgu_drm_modecfg_funcs;
-}
-
DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
@@ -54,7 +44,15 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
if (IS_ERR(arcpgu->clk))
return PTR_ERR(arcpgu->clk);
- arcpgu_setup_mode_config(drm);
+ ret = drmm_mode_config_init(drm);
+ if (ret)
+ return ret;
+
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+ drm->mode_config.max_width = 1920;
+ drm->mode_config.max_height = 1080;
+ drm->mode_config.funcs = &arcpgu_drm_modecfg_funcs;
It feels wrong to do this before even acquiring I/O memory. I would have
moved all this just before the call to arc_pgu_setup_crtc().
Best regards
Thomas
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
arcpgu->regs = devm_ioremap_resource(&pdev->dev, res);
@@ -108,7 +106,6 @@ static int arcpgu_unload(struct drm_device *drm)
{
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
- drm_mode_config_cleanup(drm);
return 0;
}
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index dbad2c9237fe..925d6d31bb78 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -39,9 +39,5 @@ int arcpgu_drm_hdmi_init(struct drm_device *drm, struct
device_node *np)
return ret;
/* Link drm_bridge to encoder */
- ret = drm_bridge_attach(encoder, bridge, NULL, 0);
- if (ret)
- drm_encoder_cleanup(encoder);
-
- return ret;
+ return drm_bridge_attach(encoder, bridge, NULL, 0);
}
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 3772df1647aa..afc34f8b4de0 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -73,21 +73,14 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
DRM_MODE_CONNECTOR_VIRTUAL);
if (ret < 0) {
dev_err(drm->dev, "failed to initialize drm connector\n");
- goto error_encoder_cleanup;
+ return ret;
}
ret = drm_connector_attach_encoder(connector, encoder);
if (ret < 0) {
dev_err(drm->dev, "could not attach connector to encoder\n");
- goto error_connector_cleanup;
+ return ret;
}
return 0;
-
-error_connector_cleanup:
- drm_connector_cleanup(connector);
-
-error_encoder_cleanup:
- drm_encoder_cleanup(encoder);
- return ret;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
[PATCH 2/2] drm/tegra: vic: Add comments on STREAMID registers
Add comments clarifying use of the THI_STREAMID0 and THI_STREAMID1
registers.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/vic.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index a3dbb8813faf..48e98a60ab6e 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -117,7 +117,19 @@ static int vic_boot(struct vic *vic)
if (spec->num_ids > 0) {
value = spec->ids[0] & 0x;
+ /*
+* STREAMID0 is used for input/output buffers.
+* Initialize it to SID_VIC in case context isolation
+* is not enabled, and SID_VIC is used for both firmware
+* and data buffers.
+*
+* If context isolation is enabled, it will be
+* overridden by the SETSTREAMID opcode as part of
+* each job.
+*/
vic_writel(vic, value, VIC_THI_STREAMID0);
+
+ /* STREAMID1 is used for firmware loading. */
vic_writel(vic, value, VIC_THI_STREAMID1);
}
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/tegra: falcon: Support newer VIC firmware
Support newer VIC firmware by accepting the new magic number 0x10fe,
loading the full code segment instead of just the first page at boot
time, and skipping FCE setup if the firmware header indicates that
FCE is handled internally by the firmware.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/falcon.c | 9 +
drivers/gpu/drm/tegra/vic.c| 21 +
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falcon.c
index 56edef06c48e..223ab2ceb7e6 100644
--- a/drivers/gpu/drm/tegra/falcon.c
+++ b/drivers/gpu/drm/tegra/falcon.c
@@ -72,7 +72,7 @@ static int falcon_parse_firmware_image(struct falcon *falcon)
struct falcon_fw_os_header_v1 *os;
/* endian problems would show up right here */
- if (bin->magic != PCI_VENDOR_ID_NVIDIA) {
+ if (bin->magic != PCI_VENDOR_ID_NVIDIA && bin->magic != 0x10fe) {
dev_err(falcon->dev, "incorrect firmware magic\n");
return -EINVAL;
}
@@ -178,9 +178,10 @@ int falcon_boot(struct falcon *falcon)
falcon->firmware.data.offset + offset,
offset, FALCON_MEMORY_DATA);
- /* copy the first code segment into Falcon internal memory */
- falcon_copy_chunk(falcon, falcon->firmware.code.offset,
- 0, FALCON_MEMORY_IMEM);
+ /* copy the code segment into Falcon internal memory */
+ for (offset = 0; offset < falcon->firmware.code.size; offset += 256)
+ falcon_copy_chunk(falcon, falcon->firmware.code.offset + offset,
+ offset, FALCON_MEMORY_IMEM);
/* setup falcon interrupts */
falcon_writel(falcon, FALCON_IRQMSET_EXT(0xff) |
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index ade56b860cf9..a3dbb8813faf 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -135,16 +135,21 @@ static int vic_boot(struct vic *vic)
hdr = vic->falcon.firmware.virt;
fce_bin_data_offset = *(u32 *)(hdr + VIC_UCODE_FCE_DATA_OFFSET);
- hdr = vic->falcon.firmware.virt +
- *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
- fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
falcon_execute_method(&vic->falcon, VIC_SET_APPLICATION_ID, 1);
- falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_SIZE,
- fce_ucode_size);
- falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_OFFSET,
- (vic->falcon.firmware.iova + fce_bin_data_offset)
- >> 8);
+
+ /* Old VIC firmware needs kernel help with setting up FCE microcode. */
+ if (fce_bin_data_offset != 0x0 && fce_bin_data_offset != 0xa5a5a5a5) {
+ hdr = vic->falcon.firmware.virt +
+ *(u32 *)(hdr + VIC_UCODE_FCE_HEADER_OFFSET);
+ fce_ucode_size = *(u32 *)(hdr + FCE_UCODE_SIZE_OFFSET);
+
+ falcon_execute_method(&vic->falcon, VIC_SET_FCE_UCODE_SIZE,
+ fce_ucode_size);
+ falcon_execute_method(
+ &vic->falcon, VIC_SET_FCE_UCODE_OFFSET,
+ (vic->falcon.firmware.iova + fce_bin_data_offset) >> 8);
+ }
err = falcon_wait_idle(&vic->falcon);
if (err < 0) {
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/15] drm/arc: Switch to devm_drm_dev_alloc
Hi
Am 12.01.21 um 09:43 schrieb Daniel Vetter:
- Need to embedded the drm_device, but for now we keep the usual
pointer chasing.
- No more devm_kzalloc, which fixes a lifetime issues on driver
remove.
- No more drm_dev_put, that's done by devm_ now.
Acked-by: Sam Ravnborg
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
For the whole patchset:
Acked-by: Thomas Zimmermann
There's a comment on patch 7.
Best regards
Thomas
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_drv.c | 33 +---
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 6aac44b953ad..cd9e932f501e 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -9,6 +9,7 @@
#define _ARCPGU_H_
struct arcpgu_drm_private {
+ struct drm_device drm;
void __iomem*regs;
struct clk *clk;
struct drm_framebuffer *fb;
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index f164818ec477..68eb4a31c54b 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -42,18 +42,14 @@ static void arcpgu_setup_mode_config(struct drm_device *drm)
DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops);
-static int arcpgu_load(struct drm_device *drm)
+static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
{
- struct platform_device *pdev = to_platform_device(drm->dev);
- struct arcpgu_drm_private *arcpgu;
+ struct platform_device *pdev = to_platform_device(arcpgu->drm.dev);
struct device_node *encoder_node = NULL, *endpoint_node = NULL;
+ struct drm_device *drm = &arcpgu->drm;
struct resource *res;
int ret;
- arcpgu = devm_kzalloc(&pdev->dev, sizeof(*arcpgu), GFP_KERNEL);
- if (arcpgu == NULL)
- return -ENOMEM;
-
drm->dev_private = arcpgu;
arcpgu->clk = devm_clk_get(drm->dev, "pxlclk");
@@ -162,30 +158,28 @@ static struct drm_driver arcpgu_drm_driver = {
static int arcpgu_probe(struct platform_device *pdev)
{
- struct drm_device *drm;
+ struct arcpgu_drm_private *arcpgu;
int ret;
- drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev);
- if (IS_ERR(drm))
- return PTR_ERR(drm);
+ arcpgu = devm_drm_dev_alloc(&pdev->dev, &arcpgu_drm_driver,
+ struct arcpgu_drm_private, drm);
+ if (IS_ERR(arcpgu))
+ return PTR_ERR(arcpgu);
- ret = arcpgu_load(drm);
+ ret = arcpgu_load(arcpgu);
if (ret)
- goto err_unref;
+ return ret;
- ret = drm_dev_register(drm, 0);
+ ret = drm_dev_register(&arcpgu->drm, 0);
if (ret)
goto err_unload;
- drm_fbdev_generic_setup(drm, 16);
+ drm_fbdev_generic_setup(&arcpgu->drm, 16);
return 0;
err_unload:
- arcpgu_unload(drm);
-
-err_unref:
- drm_dev_put(drm);
+ arcpgu_unload(&arcpgu->drm);
return ret;
}
@@ -196,7 +190,6 @@ static int arcpgu_remove(struct platform_device *pdev)
drm_dev_unregister(drm);
arcpgu_unload(drm);
- drm_dev_put(drm);
return 0;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm: rcar-du: Add cubic LUT support
On Mon, 21 Dec 2020 03:57:26 +0200 Laurent Pinchart wrote: > Hello, > > This patch series adds cubic (3D) look up table support to the CMM and > DU drivers, and extend the KMS userspace API to expose the cubic LUT to > userspace. Hi, when you say "cubic" I immediately think "polynomial of third degree", and got really curious how that works. But it seems that is not at all what you have here, instead you have a 3D LUT with probably trilinear(?) interpolation. I would suggest to stop using the misleading term "cubic" (e.g. cubic interpolation is a thing). Where does the abbreviation CLU come from? If that refers to cubic as well, it would be best to change that too to avoid misleading. Unless your hardware actually does cubic interpolation in the 3D LUT? > The code is fairly straightforward. Patch 1/4 refactors the CMM (color > management module, the Renesas R-Car IP core that handles 1D and 3D > lookup tables for the display) driver, which currently supports the 1D > (a.k.a. gamma) table only, to prepare for 3D LUT support (including a > modification to the API between the CMM and DU drivers). The CMM driver > is then extended in patch 2/4 to support the 3D LUT. > > Patch 3/4 adds support for the 3D LUT in the KMS core and the KMS > userspace API, in the form of two new properties. I expect this to be > the most controversial part of the series, not so much for the feature > itself, but for when it is inserted in the color management pipeline. > > Finally, patch 4/4 wires the KMS extension to the DU driver. > > The R-Car CMM applies the 3D LUT at the output of the display, where > data is transmitted in RGB space (when outputting YUV data to the > display the CMM can't be used according to the documentation, but I > wouldn't be entirely surprised if this limitation could be worked > around), before the 1D LUT. I've located the 3D LUT between the CTM and > the gamma LUT, but it could equally be placed before the degamma LUT or > between the degamma LUT and the CTM in my case, as the R-Car color > management pipeline has no CTM and has a single 1D LUT on the output > side (there's provision for 1D LUT on the input side for some of the > planes, but that's a separate topic). > > I however don't expect this to necessarily match all hardware though, > and this feature may require us to give up on a fixed, one size fits > them all, color management pipeline exposed to userspace. Whether this > would mean device-specific APIs (not necessarily in the form of > device-specific properties, but in how they map to hardware features, as > I think helpers to handle a 3D LUT property in the KMS core can save > code duplication in drivers), or the need for a new property to expose > the order in which color management operations are implemented, I don't > know. That is a difficult problem indeed. Userspace must know everything what happens to the pixel values exactly, beyond that I have no suggestions there. > I started having a look at userspace to see how this could be handled, > searching for color management support in weston, kwin and wlroots/sway. > All three support setting the gamma table when using the DRM/KMS > backend, weston and kwin through the legacy API, and wlroots through the > atomic API. Weston reads an ICC profile using Little CMS and applies the > gamma table. kwin is a bit more elaborate, it also uses Little CMS to > read an ICC profile, but additionally supports setting the brightness > and color temperature. It however only sets a gamma table in the end. > Wlroots seems to have an API to set the gamma table, but I haven't seen > where sway uses it (I may have missed that though). In any case, there's > limited support there for color management. > > Inputs would be appreciated on this, for instance with feedback on how > X.org and Android handle color management, on how 3D LUTs are > implemented on other platforms, or in general on how we would like to > use them. I don't mind doing some work in userspace to prototype this, > but I won't have the bandwidth to design a completely new framework. The idea for Weston (and Wayland in general) is that the display server uses a CMM to compute a transformation it needs to apply, based on the display and content color properties (e.g. ICC profiles) and more. What that transformation exactly is depends on the CMM, and it may further depend on what kind of ICC profiles are being used (an ICC file may contain different kinds of transformation definitions, from parameterised standard formulas to 1D and 3D LUTs and chains of those). So a display server gets a more or less opaque transformation object from a CMM and needs to implement what it describes somehow. Implementing the transformation depends on what kind of API the CMM offers. The good thing with a 3D LUT is that, AFAIU, no matter what the actual transformation is, it can always be represented as a 3D LUT. The only open question then is the size and precision of the 3D LUT, and how it i
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Am 12.01.21 um 10:10 schrieb Daniel Vetter: On Mon, Jan 11, 2021 at 03:45:10PM -0500, Andrey Grodzovsky wrote: On 1/11/21 11:15 AM, Daniel Vetter wrote: On Mon, Jan 11, 2021 at 05:13:56PM +0100, Daniel Vetter wrote: On Fri, Jan 08, 2021 at 04:49:55PM +, Grodzovsky, Andrey wrote: Ok then, I guess I will proceed with the dummy pages list implementation then. Andrey From: Koenig, Christian Sent: 08 January 2021 09:52 To: Grodzovsky, Andrey ; Daniel Vetter Cc: amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; daniel.vet...@ffwll.ch ; r...@kernel.org ; l.st...@pengutronix.de ; yuq...@gmail.com ; e...@anholt.net ; Deucher, Alexander ; gre...@linuxfoundation.org ; ppaala...@gmail.com ; Wentland, Harry Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object Mhm, I'm not aware of any let over pointer between TTM and GEM and we worked quite hard on reducing the size of the amdgpu_bo, so another extra pointer just for that corner case would suck quite a bit. We have a ton of other pointers in struct amdgpu_bo (or any of it's lower things) which are fairly single-use, so I'm really not much seeing the point in making this a special case. It also means the lifetime management becomes a bit iffy, since we can't throw away the dummy page then the last reference to the bo is released (since we don't track it there), but only when the last pointer to the device is released. Potentially this means a pile of dangling pages hanging around for too long. Also if you really, really, really want to have this list, please don't reinvent it since we have it already. drmm_ is exactly meant for resources that should be freed when the final drm_device reference disappears. -Daniel I maybe was eager to early, see i need to explicitly allocate the dummy page using page_alloc so i cannot use drmm_kmalloc for this, so once again like with the list i need to wrap it with a container struct which i can then allocate using drmm_kmalloc and inside there will be page pointer. But then on release it needs to free the page and so i supposedly need to use drmm_add_action to free the page before the container struct is released but drmm_kmalloc doesn't allow to set release action on struct allocation. So I created a new drmm_kmalloc_with_action API function but then you also need to supply the optional data pointer for the release action (the struct page in this case) and so this all becomes a bit overcomplicated (but doable). Is this extra API worth adding ? Maybe it can be useful in general. drm_add_action_or_reset (for better control flow) has both a void * data and a cleanup function (and it internally allocates the tracking structure for that for you). So should work as-is? Allocating a tracking structure for our tracking structure for a page would definitely be a bit too much. Essentiall drmm_add_action is your kcalloc_with_action function you want, as long as all you need is a single void * pointer (we could do the kzalloc_with_action though, there's enough space, just no need yet for any of the current users). Yeah, but my thinking was that we should use the page LRU for this and not another container structure. Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 41/51] drm/amd/display: fix sysfs amdgpu_current_backlight_pwm NULL pointer issue
From: Kevin Wang
[ Upstream commit a7b5d9dd57298333e6e9f4c167f01385d922bbfb ]
fix NULL pointer issue when read sysfs amdgpu_current_backlight_pwm sysfs node.
Call Trace:
[ 248.273833] BUG: kernel NULL pointer dereference, address: 0130
[ 248.273930] #PF: supervisor read access in kernel mode
[ 248.273993] #PF: error_code(0x) - not-present page
[ 248.274054] PGD 0 P4D 0
[ 248.274092] Oops: [#1] SMP PTI
[ 248.274138] CPU: 2 PID: 1377 Comm: cat Tainted: G OE
5.9.0-rc5-drm-next-5.9+ #1
[ 248.274233] Hardware name: System manufacturer System Product Name/Z170-A,
BIOS 3802 03/15/2018
[ 248.274641] RIP: 0010:dc_link_get_backlight_level+0x5/0x70 [amdgpu]
[ 248.274718] Code: 67 ff ff ff 41 b9 03 00 00 00 e9 45 ff ff ff d1 ea e9 55
ff ff ff 0f 1f 44 00 00 66 2e
0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <48> 8b 87 30 01 00 00 48 8b 00 48 8b 88
88 03 00 00 48 8d 81 e8 01
[ 248.274919] RSP: 0018:b5ad809b3df0 EFLAGS: 00010203
[ 248.274982] RAX: a0f77d1c0010 RBX: a0f793ae9168 RCX: 0001
[ 248.275064] RDX: a0f79753db00 RSI: 0001 RDI:
[ 248.275145] RBP: b5ad809b3e00 R08: b5ad809b3da0 R09:
[ 248.275225] R10: b5ad809b3e68 R11: R12: a0f793ae9190
[ 248.275306] R13: b5ad809b3ef0 R14: 0001 R15: a0f793ae9168
[ 248.275388] FS: 7f5f1ec4d540() GS:a0f79ec8()
knlGS:
[ 248.275480] CS: 0010 DS: ES: CR0: 80050033
[ 248.275547] CR2: 0130 CR3: 00042a03c005 CR4: 003706e0
[ 248.275628] DR0: DR1: DR2:
[ 248.275708] DR3: DR6: fffe0ff0 DR7: 0400
[ 248.275789] Call Trace:
[ 248.276124] ? current_backlight_read+0x24/0x40 [amdgpu]
[ 248.276194] seq_read+0xc3/0x3f0
[ 248.276240] full_proxy_read+0x5c/0x90
[ 248.276290] vfs_read+0xa7/0x190
[ 248.276334] ksys_read+0xa7/0xe0
[ 248.276379] __x64_sys_read+0x1a/0x20
[ 248.276429] do_syscall_64+0x37/0x80
[ 248.276477] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 248.276538] RIP: 0033:0x7f5f1e75c191
[ 248.276585] Code: fe ff ff 48 8d 3d b7 9d 0a 00 48 83 ec 08 e8 46 4d 02 00
66 0f 1f 44 00 00 48 8d 05 71 07
2e 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00
00 41 54 55 49 89 d4 53Hw
[ 248.276784] RSP: 002b:7ffcb1fc3f38 EFLAGS: 0246 ORIG_RAX:
[ 248.276872] RAX: ffda RBX: 0002 RCX: 7f5f1e75c191
[ 248.276953] RDX: 0002 RSI: 7f5f1ec2b000 RDI: 0003
[ 248.277034] RBP: 0002 R08: R09:
[ 248.277115] R10: 0022 R11: 0246 R12: 7f5f1ec2b000
[ 248.277195] R13: 0003 R14: 7f5f1ec2b00f R15: 0002
[ 248.277279] Modules linked in: amdgpu(OE) iommu_v2 gpu_sched ttm(OE)
drm_kms_helper cec drm
i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt rpcsec_gss_krb5
auth_rpcgss nfsv4 nfs
lockd grace fscache nls_iso8859_1 snd_hda_codec_realtek snd_hda_codec_hdmi
snd_hda_codec_generic
ledtrig_audio intel_rapl_msr intel_rapl_common snd_hda_intel snd_intel_dspcfg
x86_pkg_temp_thermal
intel_powerclamp snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi
snd_seq_midi_event mei_hdcp
coretemp snd_rawmidi snd_seq kvm_intel kvm snd_seq_device snd_timer irqbypass
joydev snd input_leds soundcore
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd
cryptd glue_helper rapl intel_cstate
mac_hid mei_me serio_raw mei eeepc_wmi wmi_bmof asus_wmi mxm_wmi
intel_wmi_thunderbolt acpi_pad sparse_keymap
efi_pstore sch_fq_codel parport_pc ppdev lp parport sunrpc ip_tables x_tables
autofs4 hid_logitech_hidpp
hid_logitech_dj hid_generic usbhid hid e1000e psmouse ahci libahci wmi video
[ 248.278211] CR2: 0130
[ 248.278221] ---[ end trace 1fbe72fe6f91091d ]---
[ 248.357226] RIP: 0010:dc_link_get_backlight_level+0x5/0x70 [amdgpu]
[ 248.357272] Code: 67 ff ff ff 41 b9 03 00 00 00 e9 45 ff ff ff d1 ea e9 55
ff ff ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <48> 8b 87
30 01 00 00 48 8b 00 48 8b 88 88 03 00 00 48 8d 81 e8 01
Signed-off-by: Kevin Wang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 5b0cedfa824a9..e1e5d81a5e438 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -2471,9 +2471,14 @@ enum dc_status dc_link_validate_mode_timing(
static struct abm *get_abm_from_stream_res(const struct dc_link *link)
{
int i;
- struct dc *dc = link->ctx->dc;
+ struct dc *dc = N
[PATCH AUTOSEL 5.10 42/51] drm/amdgpu: fix a GPU hang issue when remove device
From: Dennis Li
[ Upstream commit 88e21af1b3f887d217f2fb14fc7e7d3cd87ebf57 ]
When GFXOFF is enabled and GPU is idle, driver will fail to access some
registers. Therefore change to disable power gating before all access
registers with MMIO.
Dmesg log is as following:
amdgpu :03:00.0: amdgpu: amdgpu: finishing device.
amdgpu: cp queue pipe 4 queue 0 preemption failed
amdgpu :03:00.0: amdgpu: failed to write reg 2890 wait reg 28a2
amdgpu :03:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706
amdgpu :03:00.0: amdgpu: failed to write reg 2890 wait reg 28a2
amdgpu :03:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706
Signed-off-by: Dennis Li
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 026789b466db9..30c9d60c9b515 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2524,11 +2524,11 @@ static int amdgpu_device_ip_fini(struct amdgpu_device
*adev)
if (adev->gmc.xgmi.num_physical_nodes > 1)
amdgpu_xgmi_remove_device(adev);
- amdgpu_amdkfd_device_fini(adev);
-
amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);
amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE);
+ amdgpu_amdkfd_device_fini(adev);
+
/* need to disable SMC first */
for (i = 0; i < adev->num_ip_blocks; i++) {
if (!adev->ip_blocks[i].status.hw)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 44/51] drm/amdgpu: fix potential memory leak during navi12 deinitialization
From: Jiawei Gu
[ Upstream commit e6d5c64efaa34aae3815a9afeb1314a976142e83 ]
Navi12 HDCP & DTM deinitialization needs continue to free bo if already
created though initialized flag is not set.
Reviewed-by: Alex Deucher
Signed-off-by: Jiawei Gu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index a6dbe4b83533f..2f47f81a74a57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -1283,8 +1283,12 @@ static int psp_hdcp_terminate(struct psp_context *psp)
if (amdgpu_sriov_vf(psp->adev))
return 0;
- if (!psp->hdcp_context.hdcp_initialized)
- return 0;
+ if (!psp->hdcp_context.hdcp_initialized) {
+ if (psp->hdcp_context.hdcp_shared_buf)
+ goto out;
+ else
+ return 0;
+ }
ret = psp_hdcp_unload(psp);
if (ret)
@@ -1292,6 +1296,7 @@ static int psp_hdcp_terminate(struct psp_context *psp)
psp->hdcp_context.hdcp_initialized = false;
+out:
/* free hdcp shared memory */
amdgpu_bo_free_kernel(&psp->hdcp_context.hdcp_shared_bo,
&psp->hdcp_context.hdcp_shared_mc_addr,
@@ -1430,8 +1435,12 @@ static int psp_dtm_terminate(struct psp_context *psp)
if (amdgpu_sriov_vf(psp->adev))
return 0;
- if (!psp->dtm_context.dtm_initialized)
- return 0;
+ if (!psp->dtm_context.dtm_initialized) {
+ if (psp->dtm_context.dtm_shared_buf)
+ goto out;
+ else
+ return 0;
+ }
ret = psp_dtm_unload(psp);
if (ret)
@@ -1439,6 +1448,7 @@ static int psp_dtm_terminate(struct psp_context *psp)
psp->dtm_context.dtm_initialized = false;
+out:
/* free hdcp shared memory */
amdgpu_bo_free_kernel(&psp->dtm_context.dtm_shared_bo,
&psp->dtm_context.dtm_shared_mc_addr,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 43/51] drm/amd/pm: fix the failure when change power profile for renoir
From: Xiaojian Du [ Upstream commit 44cb39e19a05ca711bcb6e776e0a4399223204a0 ] This patch is to fix the failure when change power profile to "profile_peak" for renoir. Signed-off-by: Xiaojian Du Reviewed-by: Huang Rui Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c | 1 + drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c index 66c1026489bee..425c48e100e4f 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c @@ -188,6 +188,7 @@ static int renoir_get_dpm_clk_limited(struct smu_context *smu, enum smu_clk_type return -EINVAL; *freq = clk_table->SocClocks[dpm_level].Freq; break; + case SMU_UCLK: case SMU_MCLK: if (dpm_level >= NUM_FCLK_DPM_LEVELS) return -EINVAL; diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c index 660f403d5770c..7907c9e0b5dec 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c @@ -222,6 +222,7 @@ int smu_v12_0_set_soft_freq_limited_range(struct smu_context *smu, enum smu_clk_ break; case SMU_FCLK: case SMU_MCLK: + case SMU_UCLK: ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_SetHardMinFclkByFreq, min, NULL); if (ret) return ret; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.10 49/51] drm/msm: Call msm_init_vram before binding the gpu
From: Craig Tatlor [ Upstream commit d863f0c7b536288e2bd40cbc01c10465dd226b11 ] vram.size is needed when binding a gpu without an iommu and is defined in msm_init_vram(), so run that before binding it. Signed-off-by: Craig Tatlor Reviewed-by: Brian Masney Tested-by: Alexey Minnekhanov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/msm_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index 49685571dc0ee..d556c353e5aea 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -444,14 +444,14 @@ static int msm_drm_init(struct device *dev, struct drm_driver *drv) drm_mode_config_init(ddev); - /* Bind all our sub-components: */ - ret = component_bind_all(dev, ddev); + ret = msm_init_vram(ddev); if (ret) goto err_destroy_mdss; - ret = msm_init_vram(ddev); + /* Bind all our sub-components: */ + ret = component_bind_all(dev, ddev); if (ret) - goto err_msm_uninit; + goto err_destroy_mdss; dma_set_max_seg_size(dev, UINT_MAX); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 24/28] drm/amdgpu: fix a GPU hang issue when remove device
From: Dennis Li
[ Upstream commit 88e21af1b3f887d217f2fb14fc7e7d3cd87ebf57 ]
When GFXOFF is enabled and GPU is idle, driver will fail to access some
registers. Therefore change to disable power gating before all access
registers with MMIO.
Dmesg log is as following:
amdgpu :03:00.0: amdgpu: amdgpu: finishing device.
amdgpu: cp queue pipe 4 queue 0 preemption failed
amdgpu :03:00.0: amdgpu: failed to write reg 2890 wait reg 28a2
amdgpu :03:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706
amdgpu :03:00.0: amdgpu: failed to write reg 2890 wait reg 28a2
amdgpu :03:00.0: amdgpu: failed to write reg 1a6f4 wait reg 1a706
Signed-off-by: Dennis Li
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 29141bff4b572..3b3fc9a426e91 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2057,11 +2057,11 @@ static int amdgpu_device_ip_fini(struct amdgpu_device
*adev)
if (adev->gmc.xgmi.num_physical_nodes > 1)
amdgpu_xgmi_remove_device(adev);
- amdgpu_amdkfd_device_fini(adev);
-
amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);
amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE);
+ amdgpu_amdkfd_device_fini(adev);
+
/* need to disable SMC first */
for (i = 0; i < adev->num_ip_blocks; i++) {
if (!adev->ip_blocks[i].status.hw)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 27/28] drm/msm: Call msm_init_vram before binding the gpu
From: Craig Tatlor
[ Upstream commit d863f0c7b536288e2bd40cbc01c10465dd226b11 ]
vram.size is needed when binding a gpu without an iommu and is defined
in msm_init_vram(), so run that before binding it.
Signed-off-by: Craig Tatlor
Reviewed-by: Brian Masney
Tested-by: Alexey Minnekhanov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 108632a1f2438..8d9d86c76a4e9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -432,14 +432,14 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
drm_mode_config_init(ddev);
- /* Bind all our sub-components: */
- ret = component_bind_all(dev, ddev);
+ ret = msm_init_vram(ddev);
if (ret)
goto err_destroy_mdss;
- ret = msm_init_vram(ddev);
+ /* Bind all our sub-components: */
+ ret = component_bind_all(dev, ddev);
if (ret)
- goto err_msm_uninit;
+ goto err_destroy_mdss;
if (!dev->dma_parms) {
dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 15/16] drm/msm: Call msm_init_vram before binding the gpu
From: Craig Tatlor
[ Upstream commit d863f0c7b536288e2bd40cbc01c10465dd226b11 ]
vram.size is needed when binding a gpu without an iommu and is defined
in msm_init_vram(), so run that before binding it.
Signed-off-by: Craig Tatlor
Reviewed-by: Brian Masney
Tested-by: Alexey Minnekhanov
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 3ba3ae9749bec..81de5e1659551 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -483,14 +483,14 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
drm_mode_config_init(ddev);
- /* Bind all our sub-components: */
- ret = component_bind_all(dev, ddev);
+ ret = msm_init_vram(ddev);
if (ret)
goto err_destroy_mdss;
- ret = msm_init_vram(ddev);
+ /* Bind all our sub-components: */
+ ret = component_bind_all(dev, ddev);
if (ret)
- goto err_msm_uninit;
+ goto err_destroy_mdss;
if (!dev->dma_parms) {
dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings
Hi
Am 11.01.21 um 17:50 schrieb Daniel Vetter:
On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote:
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an issue with private SHMEM buffers, but may happen
with imported ones.
Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
operations. Callers have to hold the reservation lock while the mapping
persists.
This patch also connects GEM SHMEM helpers to GEM object functions with
equivalent functionality.
v4:
* call dma_buf_{vmap,vunmap}_local() where necessary (Daniel)
* move driver changes into separate patches (Daniel)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 90 +++---
include/drm/drm_gem_shmem_helper.h | 2 +
2 files changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 9825c378dfa6..298832b2b43b 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs
= {
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
+ .vmap_local = drm_gem_shmem_vmap_local,
+ .vunmap_local = drm_gem_shmem_vunmap_local,
.mmap = drm_gem_shmem_mmap,
};
@@ -261,7 +263,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
}
EXPORT_SYMBOL(drm_gem_shmem_unpin);
-static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, struct dma_buf_map *map)
+static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
struct dma_buf_map *map,
+bool local)
This is a bit spaghetti and also has the problem that we're not changing
shmem->vmap_use_count under different locks, depending upon which path
we're taking.
I think the cleanest would be if we pull the if (import_attach) case out
of the _locked() version completely, for all cases, and also outside of
the shmem->vmap_lock. This means no caching of vmaps in the shmem layer
anymore for imported buffers, but this is no longer a problem: We cache
them in the exporters instead (I think at least, if not maybe need to fix
that where it's expensive).
If we do that, what protects shmem->vaddr from concurrent access near
line 281? would it be kept NULL then?
Also, we have some stats in debugfs (see drm_gem_shmem_print_info) which
would be incorrect (or misleading at least).
Given all that, would it be possible to remove vmap_lock in favor of
taking the resv lock in vmap/vunmap?
Best regards
Thomas
Other option would be to unly pull it out for the _vmap_local case, but
that's a bit ugly because no longer symmetrical in the various paths.
{
struct drm_gem_object *obj = &shmem->base;
int ret = 0;
@@ -272,7 +275,10 @@ static int drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem, struct
}
if (obj->import_attach) {
- ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
+ if (local)
+ ret = dma_buf_vmap_local(obj->import_attach->dmabuf,
map);
+ else
+ ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
if (!ret) {
if (WARN_ON(map->is_iomem)) {
ret = -EIO;
@@ -313,7 +319,7 @@ static int drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem, struct
return ret;
}
-/*
+/**
* drm_gem_shmem_vmap - Create a virtual mapping for a shmem GEM object
* @shmem: shmem GEM object
* @map: Returns the kernel virtual address of the SHMEM GEM object's backing
@@ -339,15 +345,53 @@ int drm_gem_shmem_vmap(struct drm_gem_object *obj, struct
dma_buf_map *map)
ret = mutex_lock_interruptible(&shmem->vmap_lock);
if (ret)
return ret;
- ret = drm_gem_shmem_vmap_locked(shmem, map);
+ ret = drm_gem_shmem_vmap_locked(shmem, map, false);
mutex_unlock(&shmem->vmap_lock);
return ret;
}
EXPORT_SYMBOL(drm_gem_shmem_vmap);
+/**
+ * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM object
+ * @shmem: shmem GEM object
+ * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
+ * store.
+ *
+ * This function makes sure that a contiguous kernel virtual address mapping
+ * exists for the buffer backing the shmem GEM object.
+ *
+ * The function is called with the BO's reservation object locked. Callers must
+ * hold the lock until after unmapping t
Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive
Hi,
On 12/01/2021 14:02, Sebastian Reichel wrote:
> [replace Tomi's TI mail address with something working]
>
> Hi,
>
> On Fri, Jan 08, 2021 at 08:58:39PM +0100, Sam Ravnborg wrote:
>> Hi Sebastian,
>>
>> On Fri, Jan 08, 2021 at 12:24:41PM +0100, Sebastian Reichel wrote:
>>> Standard DRM panel driver for DSI command mode panel used by omapfb2 is also
>>> available now. Just like the other panels its module name clashes with the
>>> module from drivers/video/fbdev/omap2/omapfb/displays, part of the
>>> deprecated
>>> omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm
>>> driver
>>> is disabled, and the DRM panel drivers are useless in that case, make the
>>> omapfb2 panel depend on the standard DRM panels being disabled to fix
>>> the name clash.
>>>
>>> Fixes: cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
>>> Reported-by: Stephen Rothwell
>>> Signed-off-by: Sebastian Reichel
>>
>> For a backport this looks good:
>> Acked-by: Sam Ravnborg
>
> Thanks.
Thanks. I'll push to drm-misc-next, as that's where the commit that
breaks this is.
>> But why is it it we need omapfb at all when we have omapdrm?
>
> I think there are two reasons omapfb has not been killed yet. One
> reason was missing support for manually updated DSI panels, which
> have been working since 1 or 2 kernel releases now. The other reason
> is some people using it in combination with an out-of-tree PowerVR
> kernel driver. There is currently work going on to use a more recent
> PowerVR driver based on omapdrm driven by Maemo Leste people.
omapfb also has a custom sysfw API, so applications that depend on it
would not work anymore. I don't know if there are such applications, though.
>> Can we sunset all or some parts of omap support in video/?
>> If not, what is missing to do so.
>
> IDK the exact status of the PowerVR work and have not been using
> omapfb myself for years. I don't think there is a reason to rush
> this, so my suggestion is removing it in 3 steps giving people
> the chance to complain:
>
> 1. Add 'depends on EXPERT' to 'FB_OMAP2' and add deprecation notice
>referencing omapdrm in help text in 5.12
> 2. Add 'depends on BROKEN' in 5.13
> 3. Drop drivers/video/fbdev/omap2 afterwards
I'd love to remove omapfb, but I also fear that there are still people
using it. We can try the above sequence, but it's probably better to go
slower, as people may not be using the latest kernels.
Tomi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave and Daniel, here's this week's PR for drm-misc-fixes. Best regards Thomas drm-misc-fixes-2021-01-12: * dma-buf: Fix a memory leak in CMAV heap * drm: Fix format check for legacy pageflips * ttm: Pass correct address to dma_mapping_error(); Use mutex in pool shrinker The following changes since commit a73858ef4d5e1d425e171f0f6a52864176a6a979: drm/ttm: unexport ttm_pool_init/fini (2021-01-07 14:25:43 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-01-12 for you to fetch changes up to bb52cb0dec8d2fecdb22843a805131478a180728: drm/ttm: make the pool shrinker lock a mutex (2021-01-12 14:02:08 +0100) Short summary of fixes pull: * dma-buf: Fix a memory leak in CMAV heap * drm: Fix format check for legacy pageflips * ttm: Pass correct address to dma_mapping_error(); Use mutex in pool shrinker Bas Nieuwenhuizen (1): drm: Check actual format for legacy pageflip. Christian König (1): drm/ttm: make the pool shrinker lock a mutex Jeremy Cline (1): drm/ttm: Fix address passed to dma_mapping_error() in ttm_pool_map() John Stultz (1): dma-buf: cma_heap: Fix memory leak in CMA heap drivers/dma-buf/heaps/cma_heap.c | 3 +++ drivers/gpu/drm/drm_plane.c | 9 - drivers/gpu/drm/ttm/ttm_pool.c | 22 +++--- 3 files changed, 22 insertions(+), 12 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 00/17] follow_pfn and other iomap races
On Fri, Nov 27, 2020 at 05:41:14PM +0100, Daniel Vetter wrote: > Hi all > > Another update of my patch series to clamp down a bunch of races and gaps > around follow_pfn and other access to iomem mmaps. Previous version: > > v1: > https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/ > v2: > https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vet...@ffwll.ch > v3: > https://lore.kernel.org/dri-devel/20201021085655.1192025-1-daniel.vet...@ffwll.ch/ > v4: > https://lore.kernel.org/dri-devel/20201026105818.2585306-1-daniel.vet...@ffwll.ch/ > v5: > https://lore.kernel.org/dri-devel/20201030100815.2269-1-daniel.vet...@ffwll.ch/ > v6: > https://lore.kernel.org/dri-devel/20201119144146.1045202-1-daniel.vet...@ffwll.ch/ > > And the discussion that sparked this journey: > > https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/ > > I think the first 12 patches are ready for landing. The parts starting > with "mm: Add unsafe_follow_pfn" probably need more baking time. > > Andrew, can you please pick these up, or do you prefer I do a topic branch > and send them to Linus directly in the next merge window? > > Changes in v7: > - more acks/reviews > - reordered with the ready pieces at the front > - simplified the new follow_pfn function as Jason suggested > > Changes in v6: > - Tested v4l userptr as Tomasz suggested. No boom observed > - Added RFC for locking down follow_pfn, per discussion with Christoph and > Jason. > - Explain why pup_fast is safe in relevant patches, there was a bit a > confusion when discussing v5. > - Fix up the resource patch, with CONFIG_IO_STRICT_DEVMEM it crashed on > boot due to an unintended change (reported by John) > > Changes in v5: > - Tomasz found some issues in the media patches > - Polish suggested by Christoph for the unsafe_follow_pfn patch > > Changes in v4: > - Drop the s390 patch, that was very stand-alone and now queued up to land > through s390 trees. > - Comment polish per Dan's review. > > Changes in v3: > - Bunch of polish all over, no functional changes aside from one barrier > in the resource code, for consistency. > - A few more r-b tags. > > Changes in v2: > - tons of small polish&fixes all over, thanks to all the reviewers who > spotted issues > - I managed to test at least the generic_access_phys and pci mmap revoke > stuff with a few gdb sessions using our i915 debug tools (hence now also > the drm/i915 patch to properly request all the pci bar regions) > - reworked approach for the pci mmap revoke: Infrastructure moved into > kernel/resource.c, address_space mapping is now set up at open time for > everyone (which required some sysfs changes). Does indeed look a lot > cleaner and a lot less invasive than I feared at first. > > Coments and review on the remaining bits very much welcome, especially > from the kvm and vfio side. > > Cheers, Daniel > > Daniel Vetter (17): > drm/exynos: Stop using frame_vector helpers > drm/exynos: Use FOLL_LONGTERM for g2d cmdlists > misc/habana: Stop using frame_vector helpers > misc/habana: Use FOLL_LONGTERM for userptr > mm/frame-vector: Use FOLL_LONGTERM > media: videobuf2: Move frame_vector into media subsystem > mm: Close race in generic_access_phys > PCI: Obey iomem restrictions for procfs mmap > /dev/mem: Only set filp->f_mapping > resource: Move devmem revoke code to resource framework > sysfs: Support zapping of binary attr mmaps > PCI: Revoke mappings like devmem As Jason suggested, I've pulled the first 1 patches into a topic branch. Stephen, can you please add the below to linux-next for the 5.12 merge window? git://anongit.freedesktop.org/drm/drm topic/iomem-mmap-vs-gup Once this part has landed I'll see what to do with the below part. Thanks, Daniel > mm: Add unsafe_follow_pfn > media/videobuf1|2: Mark follow_pfn usage as unsafe > vfio/type1: Mark follow_pfn as unsafe > kvm: pass kvm argument to follow_pfn callsites > mm: add mmu_notifier argument to follow_pfn > > arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +- > arch/powerpc/kvm/book3s_64_mmu_radix.c| 2 +- > arch/powerpc/kvm/e500_mmu_host.c | 2 +- > arch/x86/kvm/mmu/mmu.c| 8 +- > drivers/char/mem.c| 86 +- > drivers/gpu/drm/exynos/Kconfig| 1 - > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 > drivers/media/common/videobuf2/Kconfig| 1 - > drivers/media/common/videobuf2/Makefile | 1 + > .../media/common/videobuf2}/frame_vector.c| 57 - > .../media/common/videobuf2/videobuf2-memops.c | 3 +- > drivers/media/platform/omap/Kconfig | 1 - > drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- > drivers/misc/habanalabs/Kconfig | 1 - > drivers/misc/habanalabs/common/habanalabs.h | 6 +- > drivers/misc/habanalabs/common
Re: [PATCH v7 00/17] follow_pfn and other iomap races
On Tue, Jan 12, 2021 at 2:24 PM Daniel Vetter wrote: > > On Fri, Nov 27, 2020 at 05:41:14PM +0100, Daniel Vetter wrote: > > Hi all > > > > Another update of my patch series to clamp down a bunch of races and gaps > > around follow_pfn and other access to iomem mmaps. Previous version: > > > > v1: > > https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/ > > v2: > > https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vet...@ffwll.ch > > v3: > > https://lore.kernel.org/dri-devel/20201021085655.1192025-1-daniel.vet...@ffwll.ch/ > > v4: > > https://lore.kernel.org/dri-devel/20201026105818.2585306-1-daniel.vet...@ffwll.ch/ > > v5: > > https://lore.kernel.org/dri-devel/20201030100815.2269-1-daniel.vet...@ffwll.ch/ > > v6: > > https://lore.kernel.org/dri-devel/20201119144146.1045202-1-daniel.vet...@ffwll.ch/ > > > > And the discussion that sparked this journey: > > > > https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/ > > > > I think the first 12 patches are ready for landing. The parts starting > > with "mm: Add unsafe_follow_pfn" probably need more baking time. > > > > Andrew, can you please pick these up, or do you prefer I do a topic branch > > and send them to Linus directly in the next merge window? > > > > Changes in v7: > > - more acks/reviews > > - reordered with the ready pieces at the front > > - simplified the new follow_pfn function as Jason suggested > > > > Changes in v6: > > - Tested v4l userptr as Tomasz suggested. No boom observed > > - Added RFC for locking down follow_pfn, per discussion with Christoph and > > Jason. > > - Explain why pup_fast is safe in relevant patches, there was a bit a > > confusion when discussing v5. > > - Fix up the resource patch, with CONFIG_IO_STRICT_DEVMEM it crashed on > > boot due to an unintended change (reported by John) > > > > Changes in v5: > > - Tomasz found some issues in the media patches > > - Polish suggested by Christoph for the unsafe_follow_pfn patch > > > > Changes in v4: > > - Drop the s390 patch, that was very stand-alone and now queued up to land > > through s390 trees. > > - Comment polish per Dan's review. > > > > Changes in v3: > > - Bunch of polish all over, no functional changes aside from one barrier > > in the resource code, for consistency. > > - A few more r-b tags. > > > > Changes in v2: > > - tons of small polish&fixes all over, thanks to all the reviewers who > > spotted issues > > - I managed to test at least the generic_access_phys and pci mmap revoke > > stuff with a few gdb sessions using our i915 debug tools (hence now also > > the drm/i915 patch to properly request all the pci bar regions) > > - reworked approach for the pci mmap revoke: Infrastructure moved into > > kernel/resource.c, address_space mapping is now set up at open time for > > everyone (which required some sysfs changes). Does indeed look a lot > > cleaner and a lot less invasive than I feared at first. > > > > Coments and review on the remaining bits very much welcome, especially > > from the kvm and vfio side. > > > > Cheers, Daniel > > > > Daniel Vetter (17): > > drm/exynos: Stop using frame_vector helpers > > drm/exynos: Use FOLL_LONGTERM for g2d cmdlists > > misc/habana: Stop using frame_vector helpers > > misc/habana: Use FOLL_LONGTERM for userptr > > mm/frame-vector: Use FOLL_LONGTERM > > media: videobuf2: Move frame_vector into media subsystem > > mm: Close race in generic_access_phys > > PCI: Obey iomem restrictions for procfs mmap > > /dev/mem: Only set filp->f_mapping > > resource: Move devmem revoke code to resource framework > > sysfs: Support zapping of binary attr mmaps > > PCI: Revoke mappings like devmem > > As Jason suggested, I've pulled the first 1 patches into a topic branch. Uh this was meant to read "first _12_ patches" ofc. -Daniel > > Stephen, can you please add the below to linux-next for the 5.12 merge > window? > > git://anongit.freedesktop.org/drm/drm topic/iomem-mmap-vs-gup > > Once this part has landed I'll see what to do with the below part. > > Thanks, Daniel > > > mm: Add unsafe_follow_pfn > > media/videobuf1|2: Mark follow_pfn usage as unsafe > > vfio/type1: Mark follow_pfn as unsafe > > kvm: pass kvm argument to follow_pfn callsites > > mm: add mmu_notifier argument to follow_pfn > > > > arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +- > > arch/powerpc/kvm/book3s_64_mmu_radix.c| 2 +- > > arch/powerpc/kvm/e500_mmu_host.c | 2 +- > > arch/x86/kvm/mmu/mmu.c| 8 +- > > drivers/char/mem.c| 86 +- > > drivers/gpu/drm/exynos/Kconfig| 1 - > > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 > > drivers/media/common/videobuf2/Kconfig| 1 - > > drivers/media/common/videobuf2/Makefile | 1 + > > .../media/common/videobuf2}/frame_vector.c| 57 ---
Re: [PATCH 14/40] drm/amd/display/dc/calcs/dce_calcs: Remove some large variables from the stack
On Mon, 11 Jan 2021, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function
> ‘bw_calcs_init’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2726:1: warning:
> the frame size of 1336 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> .../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 1115 +
> 1 file changed, 560 insertions(+), 555 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index a0c69fae40ced..f69c2b84d432b 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -2035,707 +2035,712 @@ void bw_calcs_init(struct bw_calcs_dceip *bw_dceip,
> struct bw_calcs_vbios *bw_vbios,
> struct hw_asic_id asic_id)
> {
> - struct bw_calcs_dceip dceip = { 0 };
> - struct bw_calcs_vbios vbios = { 0 };
> + struct bw_calcs_dceip *dceip;
> + struct bw_calcs_vbios *vbios;
>
> enum bw_calcs_version version = bw_calcs_version_from_asic_id(asic_id);
>
> - dceip.version = version;
> + dceip = kzalloc(sizeof(dceip), GFP_KERNEL);
> + vbios = kzalloc(sizeof(vbios), GFP_KERNEL);
Please don't review/merge this yet. I missed some error checking.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
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 13/40] drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap
On Mon, 11 Jan 2021, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function > ‘calculate_bandwidth’: > drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2016:1: warning: > the frame size of 1216 bytes is larger than 1024 bytes [-Wframe-larger-than=] > > Cc: Harry Wentland > Cc: Leo Li > Cc: Alex Deucher > Cc: "Christian König" > Cc: David Airlie > Cc: Daniel Vetter > Cc: Colin Ian King > Cc: amd-...@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Lee Jones > --- > .../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 21 +++ > 1 file changed, 17 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c > b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c > index 158d927c03e55..a0c69fae40ced 100644 > --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c > +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c > @@ -98,16 +98,16 @@ static void calculate_bandwidth( > int32_t num_cursor_lines; > > int32_t i, j, k; > - struct bw_fixed yclk[3]; > - struct bw_fixed sclk[8]; > + struct bw_fixed *yclk; > + struct bw_fixed *sclk; > bool d0_underlay_enable; > bool d1_underlay_enable; > bool fbc_enabled; > bool lpt_enabled; > enum bw_defines sclk_message; > enum bw_defines yclk_message; > - enum bw_defines tiling_mode[maximum_number_of_surfaces]; > - enum bw_defines surface_type[maximum_number_of_surfaces]; > + enum bw_defines *tiling_mode; > + enum bw_defines *surface_type; > enum bw_defines voltage; > enum bw_defines pipe_check; > enum bw_defines hsr_check; > @@ -122,6 +122,14 @@ static void calculate_bandwidth( > int32_t number_of_displays_enabled_with_margin = 0; > int32_t number_of_aligned_displays_with_no_margin = 0; > > + yclk = kzalloc(sizeof(*yclk) * 3, GFP_KERNEL); > + sclk = kzalloc(sizeof(*sclk) * 8, GFP_KERNEL); > + > + tiling_mode = kzalloc(sizeof(*tiling_mode) * > + maximum_number_of_surfaces, GFP_KERNEL); > + surface_type = kzalloc(sizeof(*surface_type) * > +maximum_number_of_surfaces, GFP_KERNEL); Please refrain from merging this yet. I missed some error checking. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services 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 1/6] drm: Inline AGP wrappers into their only callers
On Tue, Jan 12, 2021 at 10:56 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 12.01.21 um 09:59 schrieb Daniel Vetter:
> > On Tue, Jan 12, 2021 at 09:10:30AM +0100, Thomas Zimmermann wrote:
> >> The AGP wrapper functions serve no purpose.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >
> > They do, without them we fail compiling (I think at least) when agp isn't
>
> I thought so. But the only callers are in drm_agpsupport.c, which
> depends on CONFIG_AGP in the Makefile. So I expected this to work.
Please add that information to the commit message, with that r-b: me too.
-Daniel
>
> Best regards
> Thomas
>
> > enabled. Did you check for that? I should all work if we have the dummy
> > inlines for relevant agp functions in linux/agp_backend.h.
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/drm_agpsupport.c | 12 ++--
> >> drivers/gpu/drm/drm_memory.c | 18 --
> >> include/drm/drm_agpsupport.h | 18 --
> >> 3 files changed, 6 insertions(+), 42 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_agpsupport.c
> >> b/drivers/gpu/drm/drm_agpsupport.c
> >> index 4c7ad46fdd21..8b690ef306de 100644
> >> --- a/drivers/gpu/drm/drm_agpsupport.c
> >> +++ b/drivers/gpu/drm/drm_agpsupport.c
> >> @@ -285,7 +285,7 @@ int drm_agp_unbind(struct drm_device *dev, struct
> >> drm_agp_binding *request)
> >> entry = drm_agp_lookup_entry(dev, request->handle);
> >> if (!entry || !entry->bound)
> >> return -EINVAL;
> >> -ret = drm_unbind_agp(entry->memory);
> >> +ret = agp_unbind_memory(entry->memory);
> >> if (ret == 0)
> >> entry->bound = 0;
> >> return ret;
> >> @@ -326,7 +326,7 @@ int drm_agp_bind(struct drm_device *dev, struct
> >> drm_agp_binding *request)
> >> if (!entry || entry->bound)
> >> return -EINVAL;
> >> page = DIV_ROUND_UP(request->offset, PAGE_SIZE);
> >> -retcode = drm_bind_agp(entry->memory, page);
> >> +retcode = agp_bind_memory(entry->memory, page);
> >> if (retcode)
> >> return retcode;
> >> entry->bound = dev->agp->base + (page << PAGE_SHIFT);
> >> @@ -369,11 +369,11 @@ int drm_agp_free(struct drm_device *dev, struct
> >> drm_agp_buffer *request)
> >> if (!entry)
> >> return -EINVAL;
> >> if (entry->bound)
> >> -drm_unbind_agp(entry->memory);
> >> +agp_unbind_memory(entry->memory);
> >>
> >> list_del(&entry->head);
> >>
> >> -drm_free_agp(entry->memory, entry->pages);
> >> +agp_free_memory(entry->memory);
> >> kfree(entry);
> >> return 0;
> >> }
> >> @@ -453,8 +453,8 @@ void drm_legacy_agp_clear(struct drm_device *dev)
> >>
> >> list_for_each_entry_safe(entry, tempe, &dev->agp->memory, head) {
> >> if (entry->bound)
> >> -drm_unbind_agp(entry->memory);
> >> -drm_free_agp(entry->memory, entry->pages);
> >> +agp_unbind_memory(entry->memory);
> >> +agp_free_memory(entry->memory);
> >> kfree(entry);
> >> }
> >> INIT_LIST_HEAD(&dev->agp->memory);
> >> diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
> >> index fbea69d6f909..f4f2bffdd5bd 100644
> >> --- a/drivers/gpu/drm/drm_memory.c
> >> +++ b/drivers/gpu/drm/drm_memory.c
> >> @@ -100,24 +100,6 @@ static void *agp_remap(unsigned long offset, unsigned
> >> long size,
> >> return addr;
> >> }
> >>
> >> -/** Wrapper around agp_free_memory() */
> >> -void drm_free_agp(struct agp_memory *handle, int pages)
> >> -{
> >> -agp_free_memory(handle);
> >> -}
> >> -
> >> -/** Wrapper around agp_bind_memory() */
> >> -int drm_bind_agp(struct agp_memory *handle, unsigned int start)
> >> -{
> >> -return agp_bind_memory(handle, start);
> >> -}
> >> -
> >> -/** Wrapper around agp_unbind_memory() */
> >> -int drm_unbind_agp(struct agp_memory *handle)
> >> -{
> >> -return agp_unbind_memory(handle);
> >> -}
> >> -
> >> #else /* CONFIG_AGP */
> >> static inline void *agp_remap(unsigned long offset, unsigned long size,
> >>struct drm_device *dev)
> >> diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
> >> index 664e120b93e6..f3136750c490 100644
> >> --- a/include/drm/drm_agpsupport.h
> >> +++ b/include/drm/drm_agpsupport.h
> >> @@ -28,10 +28,6 @@ struct drm_agp_head {
> >>
> >> #if IS_ENABLED(CONFIG_AGP)
> >>
> >> -void drm_free_agp(struct agp_memory * handle, int pages);
> >> -int drm_bind_agp(struct agp_memory * handle, unsigned int start);
> >> -int drm_unbind_agp(struct agp_memory * handle);
> >> -
> >> struct drm_agp_head *drm_agp_init(struct drm_device *dev);
> >> void drm_legacy_agp_clear(struct drm_device *dev);
> >> int drm_agp_acquire(struct drm_device *dev);
> >> @@ -61,20 +57,6 @@ int drm_agp_bind_ioctl(struct drm_device *dev, void
> >> *data,
> >>
> >> #else /* CONFIG_AGP */
> >>
> >> -static inline void drm_free_agp(struct agp
Re: [PATCH] drm/ttm: make the pool shrinker lock a mutex
On Mon, Jan 11, 2021 at 2:57 PM Christian König
wrote:
>
> set_pages_wb() might sleep and so we can't do this in an atomic context.
>
> Signed-off-by: Christian König
> Reported-by: Mikhail Gavrilov
> Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Hm I guess long term proper fix would be to pull the shrinker into two
parts, first part takes the right amount of entries of the list,
holding the lock. 2nd part does the releasing (or maybe at least in
batches). lru locks should be cheap, doing expensive stuff like
flushing or rewriting ptes might not be the best idea.
-Daniel
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index a00b7ab9c14c..6a6eeba423d1 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -66,7 +66,7 @@ static struct ttm_pool_type global_uncached[MAX_ORDER];
> static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
>
> -static spinlock_t shrinker_lock;
> +static struct mutex shrinker_lock;
> static struct list_head shrinker_list;
> static struct shrinker mm_shrinker;
>
> @@ -249,9 +249,9 @@ static void ttm_pool_type_init(struct ttm_pool_type *pt,
> struct ttm_pool *pool,
> spin_lock_init(&pt->lock);
> INIT_LIST_HEAD(&pt->pages);
>
> - spin_lock(&shrinker_lock);
> + mutex_lock(&shrinker_lock);
> list_add_tail(&pt->shrinker_list, &shrinker_list);
> - spin_unlock(&shrinker_lock);
> + mutex_unlock(&shrinker_lock);
> }
>
> /* Remove a pool_type from the global shrinker list and free all pages */
> @@ -259,9 +259,9 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
> {
> struct page *p, *tmp;
>
> - spin_lock(&shrinker_lock);
> + mutex_lock(&shrinker_lock);
> list_del(&pt->shrinker_list);
> - spin_unlock(&shrinker_lock);
> + mutex_unlock(&shrinker_lock);
>
> list_for_each_entry_safe(p, tmp, &pt->pages, lru)
> ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
> @@ -302,7 +302,7 @@ static unsigned int ttm_pool_shrink(void)
> unsigned int num_freed;
> struct page *p;
>
> - spin_lock(&shrinker_lock);
> + mutex_lock(&shrinker_lock);
> pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list);
>
> p = ttm_pool_type_take(pt);
> @@ -314,7 +314,7 @@ static unsigned int ttm_pool_shrink(void)
> }
>
> list_move_tail(&pt->shrinker_list, &shrinker_list);
> - spin_unlock(&shrinker_lock);
> + mutex_unlock(&shrinker_lock);
>
> return num_freed;
> }
> @@ -564,7 +564,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
> {
> unsigned int i;
>
> - spin_lock(&shrinker_lock);
> + mutex_lock(&shrinker_lock);
>
> seq_puts(m, "\t ");
> for (i = 0; i < MAX_ORDER; ++i)
> @@ -600,7 +600,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> seq_file *m)
> seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
>atomic_long_read(&allocated_pages), page_pool_size);
>
> - spin_unlock(&shrinker_lock);
> + mutex_unlock(&shrinker_lock);
>
> return 0;
> }
> @@ -644,7 +644,7 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> if (!page_pool_size)
> page_pool_size = num_pages;
>
> - spin_lock_init(&shrinker_lock);
> + mutex_init(&shrinker_lock);
> INIT_LIST_HEAD(&shrinker_list);
>
> for (i = 0; i < MAX_ORDER; ++i) {
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: make the pool shrinker lock a mutex
Am 12.01.21 um 15:03 schrieb Daniel Vetter:
On Mon, Jan 11, 2021 at 2:57 PM Christian König
wrote:
set_pages_wb() might sleep and so we can't do this in an atomic context.
Signed-off-by: Christian König
Reported-by: Mikhail Gavrilov
Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
Hm I guess long term proper fix would be to pull the shrinker into two
parts, first part takes the right amount of entries of the list,
holding the lock. 2nd part does the releasing (or maybe at least in
batches). lru locks should be cheap, doing expensive stuff like
flushing or rewriting ptes might not be the best idea.
Yeah, agree. It should actually be trivial, but I didn't wanted the
churn in fixes.
So just going for the easy fix now and the optimal later on.
Regards,
Christian.
-Daniel
---
drivers/gpu/drm/ttm/ttm_pool.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index a00b7ab9c14c..6a6eeba423d1 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -66,7 +66,7 @@ static struct ttm_pool_type global_uncached[MAX_ORDER];
static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
-static spinlock_t shrinker_lock;
+static struct mutex shrinker_lock;
static struct list_head shrinker_list;
static struct shrinker mm_shrinker;
@@ -249,9 +249,9 @@ static void ttm_pool_type_init(struct ttm_pool_type *pt,
struct ttm_pool *pool,
spin_lock_init(&pt->lock);
INIT_LIST_HEAD(&pt->pages);
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
list_add_tail(&pt->shrinker_list, &shrinker_list);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
}
/* Remove a pool_type from the global shrinker list and free all pages */
@@ -259,9 +259,9 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
{
struct page *p, *tmp;
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
list_del(&pt->shrinker_list);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
list_for_each_entry_safe(p, tmp, &pt->pages, lru)
ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
@@ -302,7 +302,7 @@ static unsigned int ttm_pool_shrink(void)
unsigned int num_freed;
struct page *p;
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list);
p = ttm_pool_type_take(pt);
@@ -314,7 +314,7 @@ static unsigned int ttm_pool_shrink(void)
}
list_move_tail(&pt->shrinker_list, &shrinker_list);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
return num_freed;
}
@@ -564,7 +564,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct seq_file
*m)
{
unsigned int i;
- spin_lock(&shrinker_lock);
+ mutex_lock(&shrinker_lock);
seq_puts(m, "\t ");
for (i = 0; i < MAX_ORDER; ++i)
@@ -600,7 +600,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct seq_file
*m)
seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
atomic_long_read(&allocated_pages), page_pool_size);
- spin_unlock(&shrinker_lock);
+ mutex_unlock(&shrinker_lock);
return 0;
}
@@ -644,7 +644,7 @@ int ttm_pool_mgr_init(unsigned long num_pages)
if (!page_pool_size)
page_pool_size = num_pages;
- spin_lock_init(&shrinker_lock);
+ mutex_init(&shrinker_lock);
INIT_LIST_HEAD(&shrinker_list);
for (i = 0; i < MAX_ORDER; ++i) {
--
2.25.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] drm/ttm: make the pool shrinker lock a mutex
On Tue, Jan 12, 2021 at 3:06 PM Christian König
wrote:
>
> Am 12.01.21 um 15:03 schrieb Daniel Vetter:
> > On Mon, Jan 11, 2021 at 2:57 PM Christian König
> > wrote:
> >> set_pages_wb() might sleep and so we can't do this in an atomic context.
> >>
> >> Signed-off-by: Christian König
> >> Reported-by: Mikhail Gavrilov
> >> Fixes: d099fc8f540a ("drm/ttm: new TT backend allocation pool v3")
> > Hm I guess long term proper fix would be to pull the shrinker into two
> > parts, first part takes the right amount of entries of the list,
> > holding the lock. 2nd part does the releasing (or maybe at least in
> > batches). lru locks should be cheap, doing expensive stuff like
> > flushing or rewriting ptes might not be the best idea.
>
> Yeah, agree. It should actually be trivial, but I didn't wanted the
> churn in fixes.
>
> So just going for the easy fix now and the optimal later on.
Makes sense. Maybe add that as an explanation to the commit message,
if you haven't pushed yet. A-b: on the patch.
-Daniel
>
> Regards,
> Christian.
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/ttm/ttm_pool.c | 20 ++--
> >> 1 file changed, 10 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> >> b/drivers/gpu/drm/ttm/ttm_pool.c
> >> index a00b7ab9c14c..6a6eeba423d1 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> >> @@ -66,7 +66,7 @@ static struct ttm_pool_type global_uncached[MAX_ORDER];
> >> static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> >> static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> >>
> >> -static spinlock_t shrinker_lock;
> >> +static struct mutex shrinker_lock;
> >> static struct list_head shrinker_list;
> >> static struct shrinker mm_shrinker;
> >>
> >> @@ -249,9 +249,9 @@ static void ttm_pool_type_init(struct ttm_pool_type
> >> *pt, struct ttm_pool *pool,
> >> spin_lock_init(&pt->lock);
> >> INIT_LIST_HEAD(&pt->pages);
> >>
> >> - spin_lock(&shrinker_lock);
> >> + mutex_lock(&shrinker_lock);
> >> list_add_tail(&pt->shrinker_list, &shrinker_list);
> >> - spin_unlock(&shrinker_lock);
> >> + mutex_unlock(&shrinker_lock);
> >> }
> >>
> >> /* Remove a pool_type from the global shrinker list and free all pages */
> >> @@ -259,9 +259,9 @@ static void ttm_pool_type_fini(struct ttm_pool_type
> >> *pt)
> >> {
> >> struct page *p, *tmp;
> >>
> >> - spin_lock(&shrinker_lock);
> >> + mutex_lock(&shrinker_lock);
> >> list_del(&pt->shrinker_list);
> >> - spin_unlock(&shrinker_lock);
> >> + mutex_unlock(&shrinker_lock);
> >>
> >> list_for_each_entry_safe(p, tmp, &pt->pages, lru)
> >> ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
> >> @@ -302,7 +302,7 @@ static unsigned int ttm_pool_shrink(void)
> >> unsigned int num_freed;
> >> struct page *p;
> >>
> >> - spin_lock(&shrinker_lock);
> >> + mutex_lock(&shrinker_lock);
> >> pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list);
> >>
> >> p = ttm_pool_type_take(pt);
> >> @@ -314,7 +314,7 @@ static unsigned int ttm_pool_shrink(void)
> >> }
> >>
> >> list_move_tail(&pt->shrinker_list, &shrinker_list);
> >> - spin_unlock(&shrinker_lock);
> >> + mutex_unlock(&shrinker_lock);
> >>
> >> return num_freed;
> >> }
> >> @@ -564,7 +564,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> >> seq_file *m)
> >> {
> >> unsigned int i;
> >>
> >> - spin_lock(&shrinker_lock);
> >> + mutex_lock(&shrinker_lock);
> >>
> >> seq_puts(m, "\t ");
> >> for (i = 0; i < MAX_ORDER; ++i)
> >> @@ -600,7 +600,7 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> >> seq_file *m)
> >> seq_printf(m, "\ntotal\t: %8lu of %8lu\n",
> >> atomic_long_read(&allocated_pages), page_pool_size);
> >>
> >> - spin_unlock(&shrinker_lock);
> >> + mutex_unlock(&shrinker_lock);
> >>
> >> return 0;
> >> }
> >> @@ -644,7 +644,7 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> >> if (!page_pool_size)
> >> page_pool_size = num_pages;
> >>
> >> - spin_lock_init(&shrinker_lock);
> >> + mutex_init(&shrinker_lock);
> >> INIT_LIST_HEAD(&shrinker_list);
> >>
> >> for (i = 0; i < MAX_ORDER; ++i) {
> >> --
> >> 2.25.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings
On Tue, Jan 12, 2021 at 02:11:24PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 17:50 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote:
> > > Implementations of the vmap/vunmap GEM callbacks may perform pinning
> > > of the BO and may acquire the associated reservation object's lock.
> > > Callers that only require a mapping of the contained memory can thus
> > > interfere with other tasks that require exact pinning, such as scanout.
> > > This is less of an issue with private SHMEM buffers, but may happen
> > > with imported ones.
> > >
> > > Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
> > > drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
> > > operations. Callers have to hold the reservation lock while the mapping
> > > persists.
> > >
> > > This patch also connects GEM SHMEM helpers to GEM object functions with
> > > equivalent functionality.
> > >
> > > v4:
> > > * call dma_buf_{vmap,vunmap}_local() where necessary (Daniel)
> > > * move driver changes into separate patches (Daniel)
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> > > drivers/gpu/drm/drm_gem_shmem_helper.c | 90 +++---
> > > include/drm/drm_gem_shmem_helper.h | 2 +
> > > 2 files changed, 84 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > index 9825c378dfa6..298832b2b43b 100644
> > > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > > @@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs
> > > drm_gem_shmem_funcs = {
> > > .get_sg_table = drm_gem_shmem_get_sg_table,
> > > .vmap = drm_gem_shmem_vmap,
> > > .vunmap = drm_gem_shmem_vunmap,
> > > + .vmap_local = drm_gem_shmem_vmap_local,
> > > + .vunmap_local = drm_gem_shmem_vunmap_local,
> > > .mmap = drm_gem_shmem_mmap,
> > > };
> > > @@ -261,7 +263,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
> > > }
> > > EXPORT_SYMBOL(drm_gem_shmem_unpin);
> > > -static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
> > > struct dma_buf_map *map)
> > > +static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
> > > struct dma_buf_map *map,
> > > + bool local)
> >
> > This is a bit spaghetti and also has the problem that we're not changing
> > shmem->vmap_use_count under different locks, depending upon which path
> > we're taking.
> >
> > I think the cleanest would be if we pull the if (import_attach) case out
> > of the _locked() version completely, for all cases, and also outside of
> > the shmem->vmap_lock. This means no caching of vmaps in the shmem layer
> > anymore for imported buffers, but this is no longer a problem: We cache
> > them in the exporters instead (I think at least, if not maybe need to fix
> > that where it's expensive).
>
> If we do that, what protects shmem->vaddr from concurrent access near line
> 281? would it be kept NULL then?
>
> Also, we have some stats in debugfs (see drm_gem_shmem_print_info) which
> would be incorrect (or misleading at least).
We'd need to disable all that for pass-through vmap of imported objects.
> Given all that, would it be possible to remove vmap_lock in favor of taking
> the resv lock in vmap/vunmap?
All possible (and imo long-term desirable), the trouble is in rolling it
out. I've looked at rolling out dma_resv as the one and only lock for
shmem helpers before, and gave up. Exynos is the worst (but not the only)
offender:
- it has it's own per-object lock
- that per-object lock is taken most often before calling into various
vfuncs, which means for a gradual transition the dma_resv lock would
nest within that existing per-object lock (until we've completely
replaced it)
- but exynos also uses dma_resv already as an outermost lock in its
command submission path
iow as soon as you add dma_resv_lock anywhere in shmem helpers, we've
angered lockdep with a deadlock.
That means the only path I think is feasible is adding dma_resv lock to
all drivers paths first, _outside_ of any existing driver specific
per-object locks. Then remove the driver-specific object locks, and only
then can we sprinkle dma_resv_assert_locked all over shmem helpers.
Ofc any driver without per-driver locks of their own could directly switch
over to dma_resv lock, but until we've converted over all the drivers with
their own locking shmem helpers would be stuck where they are right now.
I gave up :-/ But maybe if you only try to tackle vmap it might be
feasible, since a lot fewer callers.
Cheers, Daniel
>
> Best regards
> Thomas
>
> >
> > Other option would be to unly pull it out for the _vmap_local case, but
> > that's a bit ugly because no longer symmetrical in the various paths.
> >
> > > {
> > > struct drm_gem_object *obj =
Re: [PATCH] drm: Improve the output_poll_changed description
On Tue, Jan 12, 2021 at 06:46:44PM +0800, ZhiJie.Zhang wrote:
> From: zhangzhijie
>
> codeview the implementation of few Drivers.
I'm not really understanding what you're trying to say here.
> this callback was used by drm_kms_helper_hotplug_event()
>
> Signed-off-by: zhangzhijie
> ---
> include/drm/drm_mode_config.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..e01c4d0f07d1 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -104,7 +104,7 @@ struct drm_mode_config_funcs {
>* changes.
>*
>* Drivers implementing fbdev emulation with the helpers can call
> - * drm_fb_helper_hotplug_changed from this hook to inform the fbdev
> + * drm_kms_helper_hotplug_event() from this hook to inform the fbdev
>* helper of output changes.
I think since we touch this, maybe better to revamp it complete. The best
way to handle all this is by registering a struct drm_client, since that
provides the &drm_client_funcs.hotplug callback. Also for fbdev support
drivers shouldn't even use that, but instead use the
drm_fbdev_generic_setup() function, which takes care of everything.
I think we can also remove the FIXME below, since with the drm_client
infrastructure and the generic fbdev emulation we've resolved this all
very neatly now.
Can you please respin with my suggestions taking into account somehow?
Thanks, Daniel
>*
>* FIXME:
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 098/162] drm/i915/gtt: map the PD up front
On Tue, Jan 12, 2021 at 10:47:57AM +, Matthew Auld wrote: > On Fri, 27 Nov 2020 at 13:32, Chris Wilson wrote: > > > > Quoting Matthew Auld (2020-11-27 12:06:14) > > > We need to general our accessor for the page directories and tables from > > > using the simple kmap_atomic to support local memory, and this setup > > > must be done on acquisition of the backing storage prior to entering > > > fence execution contexts. Here we replace the kmap with the object > > > maping code that for simple single page shmemfs object will return a > > > plain kmap, that is then kept for the lifetime of the page directory. > > > > > > Signed-off-by: Matthew Auld > > > Signed-off-by: Chris Wilson > > > > We are going to really struggle with this on 32b :( > > Just go back to mapping everything on demand like we did previously, > and unmap as soon as we are done with the current directory across > alloc/insert/clear? tbh if you run i915.ko on 32b kernels, on a modern platform, you deserve all the pain you get. There's quite a bit of work going on to essentially make kmap functions worse on 32b (we're not yet at the stage where people propose to nuke them, but getting there slowly), so designing code today with them in mind as primary justification is backwards. What we can't do is keep kmap around forever, it'd need to be something like vmap that has a long-term mapping intention behind it. And at that point it's probably equally amounts of work to just go back to ad-hoc kmap. Also the rules have changed somewhat with kmap_local anyway, a kmap is a lot less painful in the code than it was with kmap_atomic. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm: distinguish return value of drm_dp_check_and_send_link_address.
Pushed to drm-misc-next with a re-formatted commit message, thanks for your contribution! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9, 01/11] dt-bindings: mediatek: add rdma-fifo-size description for mt8183 display
On Thu, 07 Jan 2021 11:11:11 +0800, Yongqiang Niu wrote: > rdma fifo size may be different even in same SOC, add this > property to the corresponding rdma > > Signed-off-by: Yongqiang Niu > --- > .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 9 > + > 1 file changed, 9 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] Revert "drm/amd/display: Expose new CRC window property" and changes associated with this commit
Hi, In the V1, Wayne pointed out two problems: 1. The revert patch included one extra line that does not belong to it; 2. The original patch also had other fixes in the same commit; I removed the extra line from the reverted patch for tackling this issue, and I added one additional patch to this series that includes the other fix requested by Wayne. Thanks Original cover letter: A couple of weeks ago, Daniel highlighted [1] some issue related to a patch entitle "drm/amd/display: Expose new CRC window property". After discussion, we realize that we can revert that patch because we will need to create a debugfs or full UAPI for CRC soon, which will make this code obsolete. We got two other patches related to this same code; for this reason, this patchset reverts all changes associated with that specific commit. Rodrigo Siqueira (3): Revert "drm/amd/display: Fix unused variable warning" Revert "drm/amdgpu/disply: fix documentation warnings in display manager" Revert "drm/amd/display: Expose new CRC window property" Wayne Lin (1): drm/amd/display: Fix to be able to stop crc calculation .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 38 - .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 54 +-- .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 5 +- 4 files changed, 11 insertions(+), 228 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] Revert "drm/amd/display: Fix unused variable warning"
This reverts commit b5d8f1d02ba7021cad1bd5ad8460ce5611c479d8.
Cc: Wayne Lin
Cc: Alexander Deucher
Cc: Harry Wentland
Cc: Roman Li
Cc: Bindu R
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 2 +-
2 files changed, 4 insertions(+), 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 de71b6c21590..1ebd83337e29 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8551,7 +8551,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
manage_dm_interrupts(adev, acrtc, true);
}
- if (IS_ENABLED(CONFIG_DEBUG_FS) && new_crtc_state->active &&
+#ifdef CONFIG_DEBUG_FS
+ if (new_crtc_state->active &&
amdgpu_dm_is_valid_crc_source(dm_new_crtc_state->crc_src)) {
/**
* Frontend may have changed so reapply the CRC capture
@@ -8572,6 +8573,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
amdgpu_dm_crtc_configure_crc_source(
crtc, dm_new_crtc_state,
dm_new_crtc_state->crc_src);
}
+#endif
}
for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
index eba2f1d35d07..0235bfb246e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
@@ -46,13 +46,13 @@ static inline bool amdgpu_dm_is_valid_crc_source(enum
amdgpu_dm_pipe_crc_source
}
/* amdgpu_dm_crc.c */
+#ifdef CONFIG_DEBUG_FS
bool amdgpu_dm_crc_window_is_default(struct dm_crtc_state *dm_crtc_state);
bool amdgpu_dm_crc_window_changed(struct dm_crtc_state *dm_new_crtc_state,
struct dm_crtc_state
*dm_old_crtc_state);
int amdgpu_dm_crtc_configure_crc_source(struct drm_crtc *crtc,
struct dm_crtc_state *dm_crtc_state,
enum amdgpu_dm_pipe_crc_source source);
-#ifdef CONFIG_DEBUG_FS
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name);
int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
const char *src_name,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] Revert "drm/amdgpu/disply: fix documentation warnings in display manager"
This reverts commit 1206904465c8a9eebff9ca5a65effc8cf8f3cb84.
Cc: Wayne Lin
Cc: Alexander Deucher
Cc: Harry Wentland
Cc: Roman Li
Cc: Bindu R
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 21 +--
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 68df94a8b609..2a370d6a5a26 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -344,29 +344,10 @@ struct amdgpu_display_manager {
uint32_t active_vblank_irq_count;
#ifdef CONFIG_DEBUG_FS
- /**
-* @crc_win_x_start_property:
-*
-* X start of the crc calculation window
-*/
+ /* set the crc calculation window*/
struct drm_property *crc_win_x_start_property;
- /**
-* @crc_win_y_start_property:
-*
-* Y start of the crc calculation window
-*/
struct drm_property *crc_win_y_start_property;
- /**
-* @crc_win_x_end_property:
-*
-* X end of the crc calculation window
-*/
struct drm_property *crc_win_x_end_property;
- /**
-* @crc_win_y_end_property:
-*
-* Y end of the crc calculation window
-*/
struct drm_property *crc_win_y_end_property;
#endif
/**
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] Revert "drm/amd/display: Expose new CRC window property"
This reverts commit 110d586ba77ed573eb7464ca69b6490ec0b70c5f.
Cc: Wayne Lin
Cc: Alexander Deucher
Cc: Harry Wentland
Cc: Roman Li
Cc: Bindu R
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 19 ---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 56 +--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 3 -
4 files changed, 10 insertions(+), 210 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 1ebd83337e29..3f1e960b1d84 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -938,41 +938,6 @@ static void mmhub_read_system_context(struct amdgpu_device
*adev, struct dc_phy_
}
#endif
-#ifdef CONFIG_DEBUG_FS
-static int create_crtc_crc_properties(struct amdgpu_display_manager *dm)
-{
- dm->crc_win_x_start_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_X_START", 0, U16_MAX);
- if (!dm->crc_win_x_start_property)
- return -ENOMEM;
-
- dm->crc_win_y_start_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_Y_START", 0, U16_MAX);
- if (!dm->crc_win_y_start_property)
- return -ENOMEM;
-
- dm->crc_win_x_end_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_X_END", 0, U16_MAX);
- if (!dm->crc_win_x_end_property)
- return -ENOMEM;
-
- dm->crc_win_y_end_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_Y_END", 0, U16_MAX);
- if (!dm->crc_win_y_end_property)
- return -ENOMEM;
-
- return 0;
-}
-#endif
-
static int amdgpu_dm_init(struct amdgpu_device *adev)
{
struct dc_init_data init_data;
@@ -1119,10 +1084,6 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
dc_init_callbacks(adev->dm.dc, &init_params);
}
-#endif
-#ifdef CONFIG_DEBUG_FS
- if (create_crtc_crc_properties(&adev->dm))
- DRM_ERROR("amdgpu: failed to create crc property.\n");
#endif
if (amdgpu_dm_initialize_drm_device(adev)) {
DRM_ERROR(
@@ -5456,64 +5417,12 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
state->crc_src = cur->crc_src;
state->cm_has_degamma = cur->cm_has_degamma;
state->cm_is_degamma_srgb = cur->cm_is_degamma_srgb;
-#ifdef CONFIG_DEBUG_FS
- state->crc_window = cur->crc_window;
-#endif
+
/* TODO Duplicate dc_stream after objects are stream object is
flattened */
return &state->base;
}
-#ifdef CONFIG_DEBUG_FS
-static int amdgpu_dm_crtc_atomic_set_property(struct drm_crtc *crtc,
- struct drm_crtc_state *crtc_state,
- struct drm_property *property,
- uint64_t val)
-{
- struct drm_device *dev = crtc->dev;
- struct amdgpu_device *adev = drm_to_adev(dev);
- struct dm_crtc_state *dm_new_state =
- to_dm_crtc_state(crtc_state);
-
- if (property == adev->dm.crc_win_x_start_property)
- dm_new_state->crc_window.x_start = val;
- else if (property == adev->dm.crc_win_y_start_property)
- dm_new_state->crc_window.y_start = val;
- else if (property == adev->dm.crc_win_x_end_property)
- dm_new_state->crc_window.x_end = val;
- else if (property == adev->dm.crc_win_y_end_property)
- dm_new_state->crc_window.y_end = val;
- else
- return -EINVAL;
-
- return 0;
-}
-
-static int amdgpu_dm_crtc_atomic_get_property(struct drm_crtc *crtc,
- const struct drm_crtc_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
- struct drm_device *dev = crtc->dev;
- struct amdgpu_device *adev = drm_to_adev(dev);
- struct dm_crtc_state *dm_state =
- to_dm_crtc_state(state);
-
- if (property == adev->dm.crc_win_x_start_property)
- *val = dm_state->crc_window.x_start;
- else if (property == adev->dm.crc_win_y_start_property)
- *val = dm_state->crc_window.y_start;
- else if (property == adev->dm.crc_win_x_e
[PATCH v2 4/4] drm/amd/display: Fix to be able to stop crc calculation
From: Wayne Lin
[Why]
Find out when we try to disable CRC calculation, crc generation is still
enabled. Main reason is that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.
[How]
Add checking condition that when source is
AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call
dc_stream_configure_crc() to disable crc calculation.
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index c29dc11619f7..66cb8730586b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -113,7 +113,7 @@ int amdgpu_dm_crtc_configure_crc_source(struct drm_crtc
*crtc,
mutex_lock(&adev->dm.dc_lock);
/* Enable CRTC CRC generation if necessary. */
- if (dm_is_crc_source_crtc(source)) {
+ if (dm_is_crc_source_crtc(source) || source ==
AMDGPU_DM_PIPE_CRC_SOURCE_NONE) {
if (!dc_stream_configure_crc(stream_state->ctx->dc,
stream_state, NULL, enable,
enable)) {
ret = -EINVAL;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] Revert "drm/amd/display: Expose new CRC window property" and changes associated with this commit
On Tue, Jan 12, 2021 at 9:55 AM Rodrigo Siqueira wrote: > > Hi, > > In the V1, Wayne pointed out two problems: > > 1. The revert patch included one extra line that does not belong to it; > 2. The original patch also had other fixes in the same commit; > > I removed the extra line from the reverted patch for tackling this > issue, and I added one additional patch to this series that includes the > other fix requested by Wayne. > > Thanks > > Original cover letter: > A couple of weeks ago, Daniel highlighted [1] some issue related to a > patch entitle "drm/amd/display: Expose new CRC window property". After > discussion, we realize that we can revert that patch because we will > need to create a debugfs or full UAPI for CRC soon, which will make this > code obsolete. We got two other patches related to this same code; for > this reason, this patchset reverts all changes associated with that > specific commit. > > Rodrigo Siqueira (3): > Revert "drm/amd/display: Fix unused variable warning" > Revert "drm/amdgpu/disply: fix documentation warnings in display > manager" > Revert "drm/amd/display: Expose new CRC window property" > > Wayne Lin (1): > drm/amd/display: Fix to be able to stop crc calculation > Series is: Acked-by: Alex Deucher > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 38 - > .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 54 +-- > .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 5 +- > 4 files changed, 11 insertions(+), 228 deletions(-) > > -- > 2.25.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
On Fri, Jan 08, 2021 at 09:10:08AM +0800, Nicolas Boichat wrote: > Define a compatible string for the Mali Bifrost GPU found in > Mediatek's MT8183 SoCs. > > Signed-off-by: Nicolas Boichat > Reviewed-by: Alyssa Rosenzweig > --- > > (no changes since v6) > > Changes in v6: > - Rebased, actually tested with recent mesa driver. > - No change > > Changes in v5: > - Rename "2d" power domain to "core2" > > Changes in v4: > - Add power-domain-names description >(kept Alyssa's reviewed-by as the change is minor) > > Changes in v3: > - No change > > .../bindings/gpu/arm,mali-bifrost.yaml| 25 +++ > 1 file changed, 25 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > index 184492162e7e..71b613ee5bd7 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml > @@ -17,6 +17,7 @@ properties: > items: >- enum: >- amlogic,meson-g12a-mali > + - mediatek,mt8183-mali >- realtek,rtd1619-mali >- rockchip,px30-mali >- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully > discoverable > @@ -87,6 +88,30 @@ allOf: > then: >required: > - resets > + - if: > + properties: > +compatible: > + contains: > +const: mediatek,mt8183-mali > +then: > + properties: > +sram-supply: true This has to be defined at the top-level or there will be an error when it is present (due to additionalProperties). In this if/then you can do: else: sram-supply: false to disallow it if not 'mediatek,mt8183-mali' > +power-domains: > + description: > +List of phandle and PM domain specifier as documented in > +Documentation/devicetree/bindings/power/power_domain.txt > + minItems: 3 > + maxItems: 3 > +power-domain-names: > + items: > +- const: core0 > +- const: core1 > +- const: core2 > + > + required: > +- sram-supply > +- power-domains > +- power-domains-names > > examples: >- | > -- > 2.29.2.729.g45daf8777d-goog > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/4] dt-bindings: display: Document the Xylon LogiCVC display controller
On Wed, Dec 23, 2020 at 10:29:44PM +0100, Paul Kocialkowski wrote: > The Xylon LogiCVC is a display controller implemented as programmable > logic in Xilinx FPGAs. > > Signed-off-by: Paul Kocialkowski > Acked-by: Rob Herring > --- > .../display/xylon,logicvc-display.yaml| 313 ++ > 1 file changed, 313 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml > > diff --git > a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml > b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml > new file mode 100644 > index ..aca78334ad2c > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml > @@ -0,0 +1,313 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +# Copyright 2019 Bootlin > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#"; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > + > +title: Xylon LogiCVC display controller > + > +maintainers: > + - Paul Kocialkowski > + > +description: | > + The Xylon LogiCVC is a display controller that supports multiple layers. > + It is usually implemented as programmable logic and was optimized for use > + with Xilinx Zynq-7000 SoCs and Xilinx FPGAs. > + > + Because the controller is intended for use in a FPGA, most of the > + configuration of the controller takes place at logic configuration > bitstream > + synthesis time. As a result, many of the device-tree bindings are meant to > + reflect the synthesis configuration and must not be configured differently. > + Matching synthesis parameters are provided when applicable. > + > + Layers are declared in the "layers" sub-node and have dedicated > configuration. > + In version 3 of the controller, each layer has fixed memory offset and > address > + starting from the video memory base address for its framebuffer. In > version 4, > + framebuffers are configured with a direct memory address instead. > + > +properties: > + compatible: > +enum: > + - xylon,logicvc-3.02.a-display > + - xylon,logicvc-4.01.a-display > + > + reg: > +maxItems: 1 > + > + clocks: > +minItems: 1 > +maxItems: 4 > + > + clock-names: > +minItems: 1 > +maxItems: 4 > +items: > + # vclk is required and must be provided as first item. > + - const: vclk > + # Other clocks are optional and can be provided in any order. > + - enum: > + - vclk2 > + - lvdsclk > + - lvdsclkn > + - enum: > + - vclk2 > + - lvdsclk > + - lvdsclkn > + - enum: > + - vclk2 > + - lvdsclk > + - lvdsclkn > + > + interrupts: > +maxItems: 1 > + > + memory-region: > +maxItems: 1 > + > + xylon,display-interface: > +enum: > + # Parallel RGB interface (C_DISPLAY_INTERFACE == 0) > + - parallel-rgb > + # ITU-T BR656 interface (C_DISPLAY_INTERFACE == 1) > + - bt656 > + # 4-bit LVDS interface (C_DISPLAY_INTERFACE == 2) > + - lvds-4bits > + # 3-bit LVDS interface (C_DISPLAY_INTERFACE == 4) > + - lvds-3bits > + # DVI interface (C_DISPLAY_INTERFACE == 5) > + - dvi > +description: Display output interface (C_DISPLAY_INTERFACE). As I mentioned before, we have standard properties for these or you know the setting based on the panel/bridge attached. > + > + xylon,display-colorspace: > +enum: > + # RGB colorspace (C_DISPLAY_COLOR_SPACE == 0) > + - rgb > + # YUV 4:2:2 colorspace (C_DISPLAY_COLOR_SPACE == 1) > + - yuv422 > + # YUV 4:4:4 colorspace (C_DISPLAY_COLOR_SPACE == 2) > + - yuv444 > +description: Display output colorspace (C_DISPLAY_COLOR_SPACE). > + > + xylon,display-depth: > +$ref: "/schemas/types.yaml#/definitions/uint32" > +description: Display output depth (C_PIXEL_DATA_WIDTH). > + > + xylon,row-stride: > +$ref: "/schemas/types.yaml#/definitions/uint32" > +description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE). > + > + xylon,syscon: > +$ref: /schemas/types.yaml#/definitions/phandle > +description: | > + Syscon phandle representing the top-level logicvc instance, useful when > + the parent node is not the top-level logicvc instance. Why do you need to support both ways? Drop this and require it to be the parent node. > + > + xylon,dithering: > +$ref: "/schemas/types.yaml#/definitions/flag" > +description: Dithering module is enabled (C_XCOLOR) > + > + xylon,background-layer: > +$ref: "/schemas/types.yaml#/definitions/flag" > +description: | > + The last layer is used to display a black background > (C_USE_BACKGROUND). > + The layer must still be registered. > + > + xylon,layers-configurable: > +$ref: "/schemas/types.yaml#/definitions/flag" > +description: | > + Configuration of layers' size, posi
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
So - basically allocate the page and pass it as void* pointer to drmm_add_action with a release function which will do the free page, right ? Andrey On 1/12/21 4:10 AM, Daniel Vetter wrote: drm_add_action_or_reset (for better control flow) has both a void * data and a cleanup function (and it internally allocates the tracking structure for that for you). So should work as-is? Allocating a tracking structure for our tracking structure for a page would definitely be a bit too much. Essentiall drmm_add_action is your kcalloc_with_action function you want, as long as all you need is a single void * pointer (we could do the kzalloc_with_action though, there's enough space, just no need yet for any of the current users). -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: fbcon: remove soft scrollback code (missing Doc. patch)
On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds wrote: > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi wrote: > > > > > Could we pause this madness? Scrollback is still useful. I needed it > > > today... it was too small, so command results I was looking for > > > already scrolled away, but... life will be really painful with 0 > > > scrollback. > > > > > You'll need it, too... as soon as you get oops and will want to see > > > errors just prior to that oops. > > > > > If it means I get to maintain it... I'm not happy about it but that's > > > better than no scrollback. > > > > Amen! What self respecting admin installs a gui on servers? What do we > > have to do to get this back in? What was so buggy with this code that > > it needed to be removed? Why was it such a burden to just leave it be? > > It really was buggy, with security implications. And we have no maintainers. > > So the scroll-back code can't come back until we have a maintainer and > a cleaner and simpler implementation. > > And no, maintaining it really doesn't mean "just get it back to the > old broken state". > > So far I haven't actually seen any patches, which means that it's not > coming back. > > The good news? If you have an actual text VGA console, that should > still work just fine. Also on anything that is remotely modern (i.e. runs a drm kernel modesetting driver undearneath the fbdev/fbcon stack) there's a pile more issues on top of just the scrollback/fbcon code being a mess. Specifically the locking is somewhere between yolo and outright deadlocks. This holds even more so if the use case here is "I want scrollback for an oops". There's rough sketches for how it could be solved, but it's all very tricky work. Also, we need testcases for this, both in-kernel unit-test style stuff and uapi testcases. Especially the full interaction on a modern stack between /dev/fb/0, /dev/drm/card0, vt ioctls and the console is a pure nightmare. Altogether this is a few years of full time hacking to get this back into shape, and until that's happening and clearly getting somewhere the only reasonable thing to do is to delete features in response to syzkaller crashes. Also adding dri-devel since defacto that's the only place where display people hang out nowadays. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On 1/12/21 7:32 AM, Christian König wrote: Am 12.01.21 um 10:10 schrieb Daniel Vetter: On Mon, Jan 11, 2021 at 03:45:10PM -0500, Andrey Grodzovsky wrote: On 1/11/21 11:15 AM, Daniel Vetter wrote: On Mon, Jan 11, 2021 at 05:13:56PM +0100, Daniel Vetter wrote: On Fri, Jan 08, 2021 at 04:49:55PM +, Grodzovsky, Andrey wrote: Ok then, I guess I will proceed with the dummy pages list implementation then. Andrey From: Koenig, Christian Sent: 08 January 2021 09:52 To: Grodzovsky, Andrey ; Daniel Vetter Cc: amd-...@lists.freedesktop.org ; dri-devel@lists.freedesktop.org ; daniel.vet...@ffwll.ch ; r...@kernel.org ; l.st...@pengutronix.de ; yuq...@gmail.com ; e...@anholt.net ; Deucher, Alexander ; gre...@linuxfoundation.org ; ppaala...@gmail.com ; Wentland, Harry Subject: Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object Mhm, I'm not aware of any let over pointer between TTM and GEM and we worked quite hard on reducing the size of the amdgpu_bo, so another extra pointer just for that corner case would suck quite a bit. We have a ton of other pointers in struct amdgpu_bo (or any of it's lower things) which are fairly single-use, so I'm really not much seeing the point in making this a special case. It also means the lifetime management becomes a bit iffy, since we can't throw away the dummy page then the last reference to the bo is released (since we don't track it there), but only when the last pointer to the device is released. Potentially this means a pile of dangling pages hanging around for too long. Also if you really, really, really want to have this list, please don't reinvent it since we have it already. drmm_ is exactly meant for resources that should be freed when the final drm_device reference disappears. -Daniel I maybe was eager to early, see i need to explicitly allocate the dummy page using page_alloc so i cannot use drmm_kmalloc for this, so once again like with the list i need to wrap it with a container struct which i can then allocate using drmm_kmalloc and inside there will be page pointer. But then on release it needs to free the page and so i supposedly need to use drmm_add_action to free the page before the container struct is released but drmm_kmalloc doesn't allow to set release action on struct allocation. So I created a new drmm_kmalloc_with_action API function but then you also need to supply the optional data pointer for the release action (the struct page in this case) and so this all becomes a bit overcomplicated (but doable). Is this extra API worth adding ? Maybe it can be useful in general. drm_add_action_or_reset (for better control flow) has both a void * data and a cleanup function (and it internally allocates the tracking structure for that for you). So should work as-is? Allocating a tracking structure for our tracking structure for a page would definitely be a bit too much. Essentiall drmm_add_action is your kcalloc_with_action function you want, as long as all you need is a single void * pointer (we could do the kzalloc_with_action though, there's enough space, just no need yet for any of the current users). Yeah, but my thinking was that we should use the page LRU for this and not another container structure. Christian. Which specific list did you mean ? Andrey -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm: Extend color correction to support 3D-CLU
On Mon, Dec 21, 2020 at 03:57:29AM +0200, Laurent Pinchart wrote: > From: Kieran Bingham > > Extend the existing color management properties to support provision > of a 3D cubic look up table, allowing for color specific adjustments. > > Signed-off-by: Kieran Bingham > Co-developed-by: Laurent Pinchart > Signed-off-by: Laurent Pinchart FYI I've got a WIP 3D LUT implementation for i915 here: git://github.com/vsyrjala/linux.git 3dlut I named the prop GAMMA_LUT_3D to indicate its position in the pipeline (on our hw it's postioned after the normal gamma LUT). Alas no userspace for it yet, so can't really do anything more with it for the time being. Rudimentary tests also available here: git://github.com/vsyrjala/intel-gpu-tools.git 3dlut -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive)
Hi Sebastian, On Tue, Jan 12, 2021 at 05:24:54PM +0100, Sebastian Reichel wrote: > [dropped linux-next from Cc] > > Hi, > > On Tue, Jan 12, 2021 at 03:10:56PM +0200, Tomi Valkeinen wrote: > > >> But why is it it we need omapfb at all when we have omapdrm? > > > > > > I think there are two reasons omapfb has not been killed yet. One > > > reason was missing support for manually updated DSI panels, which > > > have been working since 1 or 2 kernel releases now. The other reason > > > is some people using it in combination with an out-of-tree PowerVR > > > kernel driver. There is currently work going on to use a more recent > > > PowerVR driver based on omapdrm driven by Maemo Leste people. > > > > omapfb also has a custom sysfs API, so applications that depend on it > > would not work anymore. I don't know if there are such applications, though. > > > > >> Can we sunset all or some parts of omap support in video/? > > >> If not, what is missing to do so. > > > > > > IDK the exact status of the PowerVR work and have not been using > > > omapfb myself for years. I don't think there is a reason to rush > > > this, so my suggestion is removing it in 3 steps giving people > > > the chance to complain: > > > > > > 1. Add 'depends on EXPERT' to 'FB_OMAP2' and add deprecation notice > > >referencing omapdrm in help text in 5.12 > > > 2. Add 'depends on BROKEN' in 5.13 > > > 3. Drop drivers/video/fbdev/omap2 afterwards > > > > I'd love to remove omapfb, but I also fear that there are still people > > using it. We can try the above sequence, but it's probably better to go > > slower, as people may not be using the latest kernels. > > I thought about this again and I think the best option is to rename > CONFIG_FB_OMAP2 to something like CONFIG_FB_OMAP2_DEPRECATED and > update the help text. That way anyone with CONFIG_FB_OMAP2 in > their .config will definitely notice the change when upgrading to > a newer kernel, but can easily fix it temporarily. Help text could > be > > "This driver will be removed in 2022, please switch to omapdrm." > > and no other intermediate steps are required that way :) The plan looks good to me. > But while looking through CONFIG_FB_OMAP2 references I noticed there > is also a V4L2 driver (CONFIG_VIDEO_OMAP2_VOUT), which seems to > only work with omapfb. IIUIC that driver provides display overlays > to V4L. I guess on omapdrm V4L can use DRM planes instead and no > driver is needed (i.e. this driver could just go away with omapfb)? One feature that the omapfb2 and the omap-vout drivers provide is rotation support with VRFB on OMAP3. I haven't moved to omapdrm on an old project for this reason. It should be possible to implement rotation support in omapdrm, but I'm not aware of any effort in that direction. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/amdgpu: Remove unused variable
Remove unused space_needed variable.
Fixes: 453f617a30a ("drm/amdgpu: Resize BAR0 to the maximum available size,
even if it doesn't cover VRAM")
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 348ac678a230..5888367b1000 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1106,7 +1106,6 @@ void amdgpu_device_wb_free(struct amdgpu_device *adev,
u32 wb)
*/
int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
{
- u64 space_needed = roundup_pow_of_two(adev->gmc.real_vram_size);
int rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
struct pci_bus *root;
struct resource *res;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/hdcp: Disable the QSES check for HDCP 1.4 over MST
Anshuman, please review.
BR,
Jani.
On Wed, 06 Jan 2021, Sean Paul wrote:
> From: Sean Paul
>
> The HDCP 1.4 spec does not require the QUERY_STREAM_ENCRYPTION_STATUS
> check, it was always a nice-to-have. After deploying this across various
> devices, we've determined that some MST bridge chips do not properly
> support this call for HDCP 1.4 (namely Synaptics and Realtek).
>
> I had considered creating a quirk for this, but I think it's more
> prudent to just disable the check entirely since I don't have an idea
> how widespread support is.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 26 +---
> 1 file changed, 1 insertion(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 03424d20e9f7..b6a9606bf09a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -640,30 +640,6 @@ intel_dp_mst_hdcp_toggle_signalling(struct
> intel_digital_port *dig_port,
> return ret;
> }
>
> -static
> -bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> - struct intel_connector *connector)
> -{
> - struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> - struct intel_dp *intel_dp = &dig_port->dp;
> - struct drm_dp_query_stream_enc_status_ack_reply reply;
> - int ret;
> -
> - if (!intel_dp_hdcp_check_link(dig_port, connector))
> - return false;
> -
> - ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
> - connector->port, &reply);
> - if (ret) {
> - drm_dbg_kms(&i915->drm,
> - "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> - connector->base.base.id, connector->base.name, ret);
> - return false;
> - }
> -
> - return reply.auth_completed && reply.encryption_enabled;
> -}
> -
> static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
> .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> .read_bksv = intel_dp_hdcp_read_bksv,
> @@ -674,7 +650,7 @@ static const struct intel_hdcp_shim
> intel_dp_mst_hdcp_shim = {
> .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
> .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
> .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
> - .check_link = intel_dp_mst_hdcp_check_link,
> + .check_link = intel_dp_hdcp_check_link,
> .hdcp_capable = intel_dp_hdcp_capable,
>
> .protocol = HDCP_PROTOCOL_DP,
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
