[PATCH 2/3] drm/amdgpu: Get DRM dev from adev by inline-f
Add a static inline adev_to_drm() to obtain
the DRM device pointer from an amdgpu_device pointer.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 6 +-
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 178
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 26 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 34 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 20 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 18 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 2 +-
.../gpu/drm/amd/amdgpu/atombios_encoders.c| 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 46 ++---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 36 ++--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 84
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 4 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +-
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 6 +-
drivers/gpu/drm/amd/pm/amdgpu_pm.c| 194 +-
33 files changed, 430 insertions(+), 425 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d75f6a29a0d2..735480cc7dcf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -993,6 +993,11 @@ static inline struct amdgpu_device *drm_to_adev(struct
drm_device *ddev)
return ddev->dev_private;
}
+static inline struct drm_device *adev_to_drm(struct amdgpu_device *adev)
+{
+ return adev->ddev;
+}
+
static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
{
return container_of(bdev, struct amdgpu_device, mman.bdev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 913c8f0513bd..4a93b880c6bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -463,11 +463,11 @@ static int amdgpu_atif_handler(struct amdgpu_device *adev,
if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
if (adev->flags & AMD_IS_PX) {
- pm_runtime_get_sync(adev->ddev->dev);
+ pm_runtime_get_sync(adev_to_drm(adev)->dev);
/* Just fire off a uevent and let userspace
tell us what to do */
- drm_helper_hpd_irq_event(adev->ddev);
- pm_runtime_mark_last_busy(adev->ddev->dev);
- pm_runtime_put_autosuspend(adev->ddev->dev);
+ drm_helper_hpd_irq_event(adev_to_drm(adev));
+
pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
+
pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
}
}
/* TODO: check other events */
@@ -817,7 +817,7 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
struct drm_encoder *tmp;
/* Find the encoder controlling the brightness */
- list_for_each_entry(tmp,
>ddev->mode_config.encoder_list,
+ list_for_each_entry(tmp,
_to_drm(adev)->mode_config.encoder_list,
head) {
struct amdgpu_encoder *enc =
to_amdgpu_encoder(tmp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index b74846fc3933..d58148f455dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -119,7 +119,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
.gpuvm_size = min(adev->vm_manager.max_pfn
<< AMDGPU_GPU_PAGE_SHIFT,
AMDGPU_GMC_HOLE_START),
-
[PATCH 0/3] Embed drm_device and eliminate use of dev_private (v2)
As per the comments in include/drm/drm_device.h, struct drm_device::dev_private seems to be obsolete and it's recommended that drivers embed struct drm_device into their larger per-device structure. This patchset embeds struct drm_device into struct amdgpu_device, adds inline functions to access both structures from one another, adds a DRM driver release callback to free the container struct amdgpu_device, and eliminates using struct drm_device::dev_private. v2: Split out patch 2/2 into two patches. Luben Tuikov (3): drm/amdgpu: drm_device to amdgpu_device by inline-f (v2) drm/amdgpu: Get DRM dev from adev by inline-f drm/amdgpu: Embed drm_device into amdgpu_device (v2) drivers/gpu/drm/amd/amdgpu/amdgpu.h | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 8 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +- .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 186 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 61 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 42 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 53 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 20 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 36 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_rap.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 6 +- drivers/gpu/drm/amd/amdgpu/atombios_crtc.c| 22 +- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 6 +- .../gpu/drm/amd/amdgpu/atombios_encoders.c| 36 +-- drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 94 +++--- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 96 +++--- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 104 +++ drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 94 +++--- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 40 +-- drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 145 + .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 3 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 8 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 4 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 8 +- drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 6 +- drivers/gpu/drm/amd/pm/amdgpu_pm.c| 274 +- 54 files changed, 774 insertions(+), 768 deletions(-) -- 2.28.0.215.g878e727637 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/amdgpu: drm_device to amdgpu_device by inline-f (v2)
Get the amdgpu_device from the DRM device by use
of an inline function, drm_to_adev(). The inline
function resolves a pointer to struct drm_device
to a pointer to struct amdgpu_device.
v2: Use a typed visible static inline function
instead of an invisible macro.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 2 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 10 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 18 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 20 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 12 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 10 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 4 +-
drivers/gpu/drm/amd/amdgpu/atombios_crtc.c| 22 ++---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 6 +-
.../gpu/drm/amd/amdgpu/atombios_encoders.c| 34
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 2 +-
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 48 +--
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 50 ++--
drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 58 +++---
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 48 +--
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 +-
drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 61 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 3 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 2 +-
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +-
drivers/gpu/drm/amd/pm/amdgpu_pm.c| 80 +--
44 files changed, 304 insertions(+), 301 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 9c6fb38ce59d..d75f6a29a0d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -988,6 +988,11 @@ struct amdgpu_device {
struct ratelimit_state throttling_logging_rs;
};
+static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
+{
+ return ddev->dev_private;
+}
+
static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
{
return container_of(bdev, struct amdgpu_device, mman.bdev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 0effc1d46824..b74846fc3933 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -483,7 +483,7 @@ int amdgpu_amdkfd_get_dmabuf_info(struct kgd_dev *kgd, int
dma_buf_fd,
/* Can't handle buffers from different drivers */
goto out_put;
- adev = obj->dev->dev_private;
+ adev = drm_to_adev(obj->dev);
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
AMDGPU_GEM_DOMAIN_GTT)))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 7e2394b50fbf..b1ce0d4e94c4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1674,7 +1674,7 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
return -EINVAL;
obj = dma_buf->priv;
- if (obj->dev->dev_private != adev)
+ if (drm_to_adev(obj->dev) != adev)
/* Can't handle buffers from other devices */
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index e33f63712b46..662cc414ceec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1882,7 +1882,7 @@ static
[PATCH 3/3] drm/amdgpu: Embed drm_device into amdgpu_device (v2)
a) Embed struct drm_device into struct amdgpu_device.
b) Modify the inline-f drm_to_adev() accordingly.
c) Modify the inline-f adev_to_drm() accordingly.
d) Eliminate the use of drm_device.dev_private,
in amdgpu.
e) Switch from using drm_dev_alloc() to
drm_dev_init().
f) Add a DRM driver release function, which frees
the container amdgpu_device after all krefs on
the contained drm_device have been released.
v2: Split out adding adev_to_drm() into its own
patch (previous commit), making this patch
more succinct and clear. More detailed commit
description.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 43 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 20 +++---
4 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 735480cc7dcf..107a6ec920f7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -724,8 +724,8 @@ struct amd_powerplay {
#define AMDGPU_MAX_DF_PERFMONS 4
struct amdgpu_device {
struct device *dev;
- struct drm_device *ddev;
struct pci_dev *pdev;
+ struct drm_device ddev;
#ifdef CONFIG_DRM_AMD_ACP
struct amdgpu_acp acp;
@@ -990,12 +990,12 @@ struct amdgpu_device {
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
{
- return ddev->dev_private;
+ return container_of(ddev, struct amdgpu_device, ddev);
}
static inline struct drm_device *adev_to_drm(struct amdgpu_device *adev)
{
- return adev->ddev;
+ return >ddev;
}
static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
@@ -1004,8 +1004,6 @@ static inline struct amdgpu_device
*amdgpu_ttm_adev(struct ttm_bo_device *bdev)
}
int amdgpu_device_init(struct amdgpu_device *adev,
- struct drm_device *ddev,
- struct pci_dev *pdev,
uint32_t flags);
void amdgpu_device_fini(struct amdgpu_device *adev);
int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
@@ -1195,7 +1193,7 @@ static inline void *amdgpu_atpx_get_dhandle(void) {
return NULL; }
extern const struct drm_ioctl_desc amdgpu_ioctls_kms[];
extern const int amdgpu_max_kms_ioctl;
-int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags);
+int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags);
void amdgpu_driver_unload_kms(struct drm_device *dev);
void amdgpu_driver_lastclose_kms(struct drm_device *dev);
int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 07012d71eeea..6e529548e708 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1216,7 +1216,8 @@ static int amdgpu_device_check_arguments(struct
amdgpu_device *adev)
* Callback for the switcheroo driver. Suspends or resumes the
* the asics before or after it is powered up using ACPI methods.
*/
-static void amdgpu_switcheroo_set_state(struct pci_dev *pdev, enum
vga_switcheroo_state state)
+static void amdgpu_switcheroo_set_state(struct pci_dev *pdev,
+ enum vga_switcheroo_state state)
{
struct drm_device *dev = pci_get_drvdata(pdev);
int r;
@@ -2977,8 +2978,6 @@ static const struct attribute *amdgpu_dev_attributes[] = {
* amdgpu_device_init - initialize the driver
*
* @adev: amdgpu_device pointer
- * @ddev: drm dev pointer
- * @pdev: pci dev pointer
* @flags: driver flags
*
* Initializes the driver info and hw (all asics).
@@ -2986,18 +2985,15 @@ static const struct attribute *amdgpu_dev_attributes[]
= {
* Called at driver startup.
*/
int amdgpu_device_init(struct amdgpu_device *adev,
- struct drm_device *ddev,
- struct pci_dev *pdev,
uint32_t flags)
{
+ struct drm_device *ddev = adev_to_drm(adev);
+ struct pci_dev *pdev = adev->pdev;
int r, i;
bool boco = false;
u32 max_MBps;
adev->shutdown = false;
- adev->dev = >dev;
- adev->ddev = ddev;
- adev->pdev = pdev;
adev->flags = flags;
if (amdgpu_force_asic_type >= 0 && amdgpu_force_asic_type < CHIP_LAST)
@@ -3451,9 +3447,8 @@ int amdgpu_device_suspend(struct drm_device *dev, bool
fbcon)
struct drm_connector_list_iter iter;
int r;
- if (dev == NULL || dev->dev_private == NULL) {
+ if (!dev)
return -ENODEV;
- }
adev = drm_to_adev(dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full
On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote: > Hello Gerd, > > I compiled a new kernel with the latest DRM misc updates today. The patch is > included in these updates. > > This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine > on my X5000. > > Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with > a resolution of 640x480. If I set a higher resolution then the guest > disables the monitor. > I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU. > > Please check the latest DRM updates. https://patchwork.freedesktop.org/patch/385980/ (tests & reviews & acks are welcome) HTH, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/qxl: Fix build errors
On Tue, 18 Aug 2020 at 15:32, Gerd Hoffmann wrote: > > Hi, > > > I guess things are never quite so easy :-). It looks like Daniel's > > patch is in drm-misc-fixes and Sidong's patch is in drm-misc-next. On > > their own they're fine, but once they are merged in drm-tip the build > > error shows up. > > Ah, ok. I've already wondered how that got past my build testing. > This explains it. > > thanks for looking into it, I've fixed this in drm-tip with a fixup. In future when we find these silent conflicts, can someone please https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html follow those instructions to fix it up. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support
On Tue, 2020-08-18 at 14:29 -0700, Navare, Manasi wrote:
> On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> > Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source
> > tests.
> >
> > v2: uniform bit names TP4a/b/c (Manasi)
> >
> > Signed-off-by: Khaled Almahallawy
>
> Looks good to me,
>
> Reviewed-by: Manasi Navare
>
> Khaled, could you also give a tested by here?
>
> Manasi
Passed all TPS4 tests on DP Compliance scope with DPoC1.4a test
specification
Tested-by: Khaled Almahallawy
>
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 14 --
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > 2 files changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6295eb20b63..4b74b2ec5665 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5371,7 +5371,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> > _dp->compliance.test_data.phytest;
> > struct intel_crtc *crtc = to_intel_crtc(dig_port-
> > >base.base.crtc);
> > enum pipe pipe = crtc->pipe;
> > - u32 pattern_val;
> > + u32 pattern_val, dp_tp_ctl;
> >
> > switch (data->phy_pattern) {
> > case DP_PHY_TEST_PATTERN_NONE:
> > @@ -5411,7 +5411,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> >DDI_DP_COMP_CTL_CUSTOM80);
> > break;
> > - case DP_PHY_TEST_PATTERN_CP2520:
> > + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> > /*
> > * FIXME: Ideally pattern should come from DPCD 0x24A.
> > As
> > * current firmware of DPR-100 could not set it, so
> > hardcoding
> > @@ -5423,6 +5423,16 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> > DDI_DP_COMP_CTL_HBR2 |
> >pattern_val);
> > break;
> > + case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> > + DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> > + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> > 0x0);
> > + dp_tp_ctl = intel_de_read(dev_priv,
> > TGL_DP_TP_CTL(pipe));
> > + dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> > + dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
> > + dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> > + dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> > + intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> > dp_tp_ctl);
> > + break;
> > default:
> > WARN(1, "Invalid Phy Test Pattern\n");
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a0d31f3bf634..c586595b9e76 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9982,6 +9982,10 @@ enum skl_power_gate {
> > #define DP_TP_CTL_MODE_SST(0 << 27)
> > #define DP_TP_CTL_MODE_MST(1 << 27)
> > #define DP_TP_CTL_FORCE_ACT (1 << 25)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
> > +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
> > #define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1 << 18)
> > #define DP_TP_CTL_FDI_AUTOTRAIN (1 << 15)
> > #define DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 14/14] drm/print: Add tracefs support to the drm logging helpers
Hi Sean,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next drm-tip/drm-tip
linus/master drm-exynos/exynos-drm-next v5.9-rc1 next-20200818]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sean-Paul/drm-trace-Mirror-DRM-debug-logs-to-tracefs/20200819-050745
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: openrisc-randconfig-s031-20200818 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-183-gaa6ede3b-dirty
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=openrisc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/drm_print.c:459:21: sparse: sparse: non-ANSI function
>> declaration of function 'drm_trace_init'
>> drivers/gpu/drm/drm_print.c:498:24: sparse: sparse: non-ANSI function
>> declaration of function 'drm_trace_cleanup'
drivers/gpu/drm/drm_print.c:467:15: sparse: sparse: undefined identifier
'trace_array_init_printk'
drivers/gpu/drm/drm_print.c: note: in included file (through
arch/openrisc/include/asm/io.h, include/linux/io.h):
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32
#
https://github.com/0day-ci/linux/commit/fe0a955028a2121ce9ab9acd1c2ab74d219cdc60
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sean-Paul/drm-trace-Mirror-DRM-debug-logs-to-tracefs/20200819-050745
git checkout fe0a955028a2121ce9ab9acd1c2ab74d219cdc60
vim +/drm_trace_init +459 drivers/gpu/drm/drm_print.c
452
453 /**
454 * drm_trace_init - initializes the drm trace array
455 *
456 * This function fetches (or creates) the drm trace array. This should
be called
457 * once on drm subsystem creation and matched with drm_trace_cleanup().
458 */
> 459 void drm_trace_init()
460 {
461 int ret;
462
463 trace_arr = trace_array_get_by_name("drm");
464 if (!trace_arr)
465 return;
466
467 ret = trace_array_init_printk(trace_arr);
468 if (ret)
469 drm_trace_cleanup();
470 }
471 EXPORT_SYMBOL(drm_trace_init);
472
473 /**
474 * drm_trace_printf - adds an entry to the drm tracefs instance
475 * @format: printf format of the message to add to the trace
476 *
477 * This function adds a new entry in the drm tracefs instance
478 */
479 void drm_trace_printf(const char *format, ...)
480 {
481 struct va_format vaf;
482 va_list args;
483
484 va_start(args, format);
485 vaf.fmt = format;
486 vaf.va =
487 trace_array_printk(trace_arr, _THIS_IP_, "%pV", );
488 va_end(args);
489 }
490
491 /**
492 * drm_trace_cleanup - destroys the drm trace array
493 *
494 * This function destroys the drm trace array created with
drm_trace_init. This
495 * should be called once on drm subsystem close and matched with
496 * drm_trace_init().
497 */
> 498 void drm_trace_cleanup()
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] Fix Kconfig dependency issue with DMAENGINES selection
Matt, Alexandre, Gentle ping. As this should be fixed in v5.9, a quick reply would be really appreciated. Otherwise I'll have to bundle the rapidio fix with the DPSUB fix, and get them both merged through the DRM/KMS tree without your ack. On Wed, Aug 12, 2020 at 01:52:04AM +0300, Laurent Pinchart wrote: > On Sun, Aug 02, 2020 at 12:14:09PM +0530, Vinod Koul wrote: > > On 31-07-20, 23:42, Laurent Pinchart wrote: > > > On Fri, Jul 31, 2020 at 10:17:44PM +0530, Vinod Koul wrote: > > > > On 31-07-20, 18:24, Laurent Pinchart wrote: > > > > > Hello, > > > > > > > > > > This small series fixes a Kconfig dependency issue with the recently > > > > > merged Xilixn DPSUB DRM/KMS driver. The fix is in patch 3/3, but > > > > > requires a separate fixes in patches 1/3 and 2/3 to avoid circular > > > > > dependencies: > > > > > > > > > > drivers/i2c/Kconfig:8:error: recursive dependency detected! > > > > > drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC > > > > > drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB > > > > > drivers/video/fbdev/Kconfig:12: symbol FB is selected by > > > > > DRM_KMS_FB_HELPER > > > > > drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER > > > > > depends on DRM_KMS_HELPER > > > > > drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is > > > > > selected by DRM_ZYNQMP_DPSUB > > > > > drivers/gpu/drm/xlnx/Kconfig:1: symbol DRM_ZYNQMP_DPSUB > > > > > depends on DMA_ENGINE > > > > > drivers/dma/Kconfig:44: symbol DMA_ENGINE depends on > > > > > DMADEVICES > > > > > drivers/dma/Kconfig:6: symbol DMADEVICES is selected by > > > > > SND_SOC_SH4_SIU > > > > > sound/soc/sh/Kconfig:30:symbol SND_SOC_SH4_SIU is > > > > > selected by SND_SIU_MIGOR > > > > > sound/soc/sh/Kconfig:60:symbol SND_SIU_MIGOR depends > > > > > on I2C > > > > > For a resolution refer to > > > > > Documentation/kbuild/kconfig-language.rst > > > > > subsection "Kconfig recursive dependency limitations" > > > > > > > > > > Due to the DPSUB driver being merged in v5.9, this is a candidate fix > > > > > for v5.9 as well. 1/3 and 2/3 can be merged independently, 3/3 depends > > > > > on the first two. What's the best course of action, can I merge this > > > > > all > > > > > in a single tree, or should the rapidio and ASoC patches be merged > > > > > independently early in the -rc cycle, and the DRM patch later on top > > > > > ? I > > > > > don't expect conflicts (especially in 2/3 and 3/3), so merging the > > > > > whole > > > > > series in one go would be simpler in my opinion. > > > > > > > > Acked-By: Vinod Koul > > > > > > Thank you. > > > > > > As Mark as queued the sound fix in his for-next branch for v5.9, could > > > you queue the dmaengine fix for v5.9 too ? > > > > Dmaengine? I see three patches none of which touch dmaengine.. > > Did I miss something? > > I'm not sure what I was thinking... It's the rapidio patch that needs to > be merged. > > Matt, Alexandre, can you either merge the patch as a v5.9 fix, or give > me an ack to get it merged through the DRM tree ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: ast: fix double __iomem sparse warning
Hi Randy,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on linus/master v5.9-rc1 next-20200818]
[cannot apply to linux/master drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Randy-Dunlap/drm-ast-fix-double-__iomem-sparse-warning/20200819-043022
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-s002-20200818 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-183-gaa6ede3b-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/ast/ast_cursor.c:42:59: sparse: sparse: incorrect type in
>> argument 2 (different address spaces) @@ expected void *vaddr @@ got
>> void [noderef] __iomem * @@
>> drivers/gpu/drm/ast/ast_cursor.c:42:59: sparse: expected void *vaddr
>> drivers/gpu/drm/ast/ast_cursor.c:42:59: sparse: got void [noderef]
>> __iomem *
>> drivers/gpu/drm/ast/ast_cursor.c:80:23: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@ expected void [noderef] __iomem
>> *vaddr @@ got void * @@
>> drivers/gpu/drm/ast/ast_cursor.c:80:23: sparse: expected void [noderef]
>> __iomem *vaddr
>> drivers/gpu/drm/ast/ast_cursor.c:80:23: sparse: got void *
drivers/gpu/drm/ast/ast_cursor.c:98:59: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void *vaddr @@ got
void [noderef] __iomem * @@
drivers/gpu/drm/ast/ast_cursor.c:98:59: sparse: expected void *vaddr
drivers/gpu/drm/ast/ast_cursor.c:98:59: sparse: got void [noderef]
__iomem *
>> drivers/gpu/drm/ast/ast_cursor.c:126:19: sparse: sparse: cast removes
>> address space '__iomem' of expression
>> drivers/gpu/drm/ast/ast_cursor.c:126:16: sparse: sparse: incorrect type in
>> assignment (different address spaces) @@ expected unsigned char
>> [noderef] [usertype] __iomem *dstxor @@ got unsigned char [usertype] * @@
>> drivers/gpu/drm/ast/ast_cursor.c:126:16: sparse: expected unsigned char
>> [noderef] [usertype] __iomem *dstxor
>> drivers/gpu/drm/ast/ast_cursor.c:126:16: sparse: got unsigned char
>> [usertype] *
#
https://github.com/0day-ci/linux/commit/7e1ff39fdb33febec4c542a6be21c28b352eb588
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Randy-Dunlap/drm-ast-fix-double-__iomem-sparse-warning/20200819-043022
git checkout 7e1ff39fdb33febec4c542a6be21c28b352eb588
vim +42 drivers/gpu/drm/ast/ast_cursor.c
2ccebf561e4a902 Thomas Zimmermann 2020-07-02 34
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 35 static void
ast_cursor_fini(struct ast_private *ast)
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 36 {
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 37 size_t i;
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 38 struct
drm_gem_vram_object *gbo;
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 39
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 40 for (i = 0; i <
ARRAY_SIZE(ast->cursor.gbo); ++i) {
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 41 gbo =
ast->cursor.gbo[i];
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 @42
drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 43
drm_gem_vram_unpin(gbo);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 44
drm_gem_vram_put(gbo);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 45 }
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 46 }
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 47
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 48 static void
ast_cursor_release(struct drm_device *dev, void *ptr)
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 49 {
365c0e70da83a52 Thomas Zimmermann 2020-07-30 50 struct ast_private *ast
= to_ast_private(dev);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 51
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 52 ast_cursor_fini(ast);
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 53 }
3e9d787371eaa84 Thomas Zimmermann 2020-07-02 54
2ccebf561e4a902 Thomas Zimmermann 2020-07-02 55 /*
2ccebf561e4a902 Thomas Zimmermann 2020-07-02 56 * Allocate cursor BOs and
pins them at the end of VRAM.
2ccebf561e4a902 Thomas Zimmermann 2020-07-02 57 */
beb2355eecbf67d Thoma
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #7 from Coleman Kane (ck...@colemankane.org) --- Thanks for the tip - I think I understand how this works now, so I will go through the cycles of bisecting and follow up with what it finds, or a patch if I think I'm able to address it myself. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/14] drm/mst: Convert debug printers to debug category printers
Reviewed-by: Lyude Paul
On Tue, 2020-08-18 at 17:05 -0400, Sean Paul wrote:
> From: Sean Paul
>
> The printers in dp_mst are meant to be gated on DRM_UT_DP, so use the
> debug category printer to avoid dumping mst transactions to the wrong
> place.
>
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-12-s...@poorly.run
> #v5
>
> Changes in v5:
> -Added to the set
> Changes in v6:
> -None
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 67dd72ea200e..127120b60580 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1242,7 +1242,8 @@ static int drm_dp_mst_wait_tx_reply(struct
> drm_dp_mst_branch *mstb,
> }
> out:
> if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> + DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> }
> @@ -2781,7 +2782,8 @@ static int process_single_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr,
>
> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
> if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> + DBG_PREFIX);
>
> drm_printf(, "sideband msg failed to send\n");
> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> @@ -2825,7 +2827,8 @@ static void drm_dp_queue_down_tx(struct
> drm_dp_mst_topology_mgr *mgr,
> list_add_tail(>next, >tx_msg_downq);
>
> if (drm_debug_enabled(DRM_UT_DP)) {
> - struct drm_printer p = drm_debug_printer(DBG_PREFIX);
> + struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
> + DBG_PREFIX);
>
> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
> }
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
Just one small comment
On Tue, 2020-08-18 at 11:39 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Used to query whether an MST stream is encrypted or not.
>
> Cc: Lyude Paul
> Reviewed-by: Anshuman Gupta
> Signed-off-by: Sean Paul
>
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
> #v5
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
> #v6
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-s...@poorly.run
> #v7
>
> Changes in v4:
> -Added to the set
> Changes in v5:
> -None
> Changes in v6:
> -Use FIELD_PREP to generate request buffer bitfields (Lyude)
> -Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
> Changes in v7:
> -None
> Changes in v8:
> -Reverse the parsing on the hdcp_*x_device_present bits and leave
> breadcrumb in case this is incorrect (Anshuman)
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
> .../drm/selftests/test-drm_dp_mst_helper.c| 17 ++
> include/drm/drm_dp_helper.h | 3 +
> include/drm/drm_dp_mst_helper.h | 44 +
> 4 files changed, 214 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 67dd72ea200e..f2b77ef40281 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -20,11 +20,13 @@
> * OF THIS SOFTWARE.
> */
>
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -423,6 +425,22 @@ drm_dp_encode_sideband_req(const struct
> drm_dp_sideband_msg_req_body *req,
> memcpy([idx], req->u.i2c_write.bytes, req-
> >u.i2c_write.num_bytes);
> idx += req->u.i2c_write.num_bytes;
> break;
> + case DP_QUERY_STREAM_ENC_STATUS: {
> + const struct drm_dp_query_stream_enc_status *msg;
> +
> + msg = >u.enc_status;
> + buf[idx] = msg->stream_id;
> + idx++;
> + memcpy([idx], msg->client_id, sizeof(msg->client_id));
> + idx += sizeof(msg->client_id);
> + buf[idx] = 0;
> + buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
> + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> + buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
> + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> + idx++;
> + }
> + break;
> }
> raw->cur_len = idx;
> }
> @@ -551,6 +569,20 @@ drm_dp_decode_sideband_req(const struct
> drm_dp_sideband_msg_tx *raw,
> return -ENOMEM;
> }
> break;
> + case DP_QUERY_STREAM_ENC_STATUS:
> + req->u.enc_status.stream_id = buf[idx++];
> + for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
> + req->u.enc_status.client_id[i] = buf[idx++];
> +
> + req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
> +buf[idx]);
> + req->u.enc_status.valid_stream_event = FIELD_GET(BIT(2),
> + buf[idx]);
> + req->u.enc_status.stream_behavior = FIELD_GET(GENMASK(4, 3),
> + buf[idx]);
> + req->u.enc_status.valid_stream_behavior = FIELD_GET(BIT(5),
> + buf[idx]);
> + break;
> }
>
> return 0;
> @@ -629,6 +661,16 @@ drm_dp_dump_sideband_msg_req_body(const struct
> drm_dp_sideband_msg_req_body *req
> req->u.i2c_write.num_bytes, req->u.i2c_write.num_bytes,
> req->u.i2c_write.bytes);
> break;
> + case DP_QUERY_STREAM_ENC_STATUS:
> + P("stream_id=%u client_id=%*ph stream_event=%x "
> + "valid_event=%d stream_behavior=%x valid_behavior=%d",
> + req->u.enc_status.stream_id,
> + (int)ARRAY_SIZE(req->u.enc_status.client_id),
> + req->u.enc_status.client_id, req->u.enc_status.stream_event,
> + req->u.enc_status.valid_stream_event,
> + req->u.enc_status.stream_behavior,
> + req->u.enc_status.valid_stream_behavior);
> + break;
> default:
> P("???\n");
> break;
> @@ -936,6 +978,42 @@ static bool
> drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
> return true;
> }
>
> +static bool
> +drm_dp_sideband_parse_query_stream_enc_status(
> + struct drm_dp_sideband_msg_rx *raw,
> +
Re: [PATCH v2 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support
On Wed, Jul 22, 2020 at 05:36:27PM -0700, Khaled Almahallawy wrote:
> Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
>
> v2: uniform bit names TP4a/b/c (Manasi)
>
> Signed-off-by: Khaled Almahallawy
Looks good to me,
Reviewed-by: Manasi Navare
Khaled, could you also give a tested by here?
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 14 --
> drivers/gpu/drm/i915/i915_reg.h | 4
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d6295eb20b63..4b74b2ec5665 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5371,7 +5371,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp
> *intel_dp)
> _dp->compliance.test_data.phytest;
> struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
> enum pipe pipe = crtc->pipe;
> - u32 pattern_val;
> + u32 pattern_val, dp_tp_ctl;
>
> switch (data->phy_pattern) {
> case DP_PHY_TEST_PATTERN_NONE:
> @@ -5411,7 +5411,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp
> *intel_dp)
> DDI_DP_COMP_CTL_ENABLE |
> DDI_DP_COMP_CTL_CUSTOM80);
> break;
> - case DP_PHY_TEST_PATTERN_CP2520:
> + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> /*
>* FIXME: Ideally pattern should come from DPCD 0x24A. As
>* current firmware of DPR-100 could not set it, so hardcoding
> @@ -5423,6 +5423,16 @@ static void intel_dp_phy_pattern_update(struct
> intel_dp *intel_dp)
> DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
> pattern_val);
> break;
> + case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> + DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
> + dp_tp_ctl = intel_de_read(dev_priv,
> TGL_DP_TP_CTL(pipe));
> + dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> + dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TP4a;
> + dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> + dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> + intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> dp_tp_ctl);
> + break;
> default:
> WARN(1, "Invalid Phy Test Pattern\n");
> }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a0d31f3bf634..c586595b9e76 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9982,6 +9982,10 @@ enum skl_power_gate {
> #define DP_TP_CTL_MODE_SST (0 << 27)
> #define DP_TP_CTL_MODE_MST (1 << 27)
> #define DP_TP_CTL_FORCE_ACT (1 << 25)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4a (0 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
> +#define DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
> #define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1 << 18)
> #define DP_TP_CTL_FDI_AUTOTRAIN (1 << 15)
> #define DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 03/14] drm/i915/utils: Replace dev_printk with drm helpers
From: Sean Paul Use drm logging helpers to add support for the upcoming tracefs implementation. Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-4-s...@poorly.run #v5 Changes in v5: -Added to the set Changes in v6: -None --- drivers/gpu/drm/i915/i915_utils.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_utils.c b/drivers/gpu/drm/i915/i915_utils.c index 4c305d838016..f16a75b165a3 100644 --- a/drivers/gpu/drm/i915/i915_utils.c +++ b/drivers/gpu/drm/i915/i915_utils.c @@ -30,10 +30,9 @@ __i915_printk(struct drm_i915_private *dev_priv, const char *level, vaf.va = if (is_error) - dev_printk(level, kdev, "%pV", ); + drm_dev_printk(kdev, level, "%pV", ); else - dev_printk(level, kdev, "[" DRM_NAME ":%ps] %pV", - __builtin_return_address(0), ); + drm_err(_priv->drm, "%pV", ); va_end(args); -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 04/14] drm/msm/dpu: Replace definitions for dpu debug macros
From: Sean Paul
The debug messages shouldn't be logged as errors when debug categories
are enabled. Use the drm logging helpers to do the right thing
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-5-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index e140cd633071..b1e9c529d3b5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -29,27 +29,15 @@
* DPU_DEBUG - macro for kms/plane/crtc/encoder/connector logs
* @fmt: Pointer to format string
*/
-#define DPU_DEBUG(fmt, ...)\
- do { \
- if (drm_debug_enabled(DRM_UT_KMS)) \
- DRM_DEBUG(fmt, ##__VA_ARGS__); \
- else \
- pr_debug(fmt, ##__VA_ARGS__); \
- } while (0)
+#define DPU_DEBUG(fmt, ...) DRM_DEBUG_KMS(fmt, ##__VA_ARGS__)
/**
* DPU_DEBUG_DRIVER - macro for hardware driver logging
* @fmt: Pointer to format string
*/
-#define DPU_DEBUG_DRIVER(fmt, ...) \
- do { \
- if (drm_debug_enabled(DRM_UT_DRIVER)) \
- DRM_ERROR(fmt, ##__VA_ARGS__); \
- else \
- pr_debug(fmt, ##__VA_ARGS__); \
- } while (0)
-
-#define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__)
+#define DPU_DEBUG_DRIVER(fmt, ...) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__)
+
+#define DPU_ERROR(fmt, ...) DRM_ERROR(fmt, ##__VA_ARGS__)
/**
* ktime_compare_safe - compare two ktime structures
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 13/14] drm/atomic: Use debug category printer for atomic state printer
From: Sean Paul
The atomic state is printed if the DRM_UT_STATE is active, but it's
printed at INFO level. This patch converts it to use the debug
category printer so:
a- it's consistent with other DRM_UT_STATE logging
b- it's properly routed through drm_trace when introduced
Signed-off-by: Sean Paul
Changes in v6:
-Added to the set
---
drivers/gpu/drm/drm_atomic.c| 5 +++--
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_crtc_internal.h | 3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..96b804e85903 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1543,9 +1543,10 @@ int __drm_atomic_helper_set_config(struct drm_mode_set
*set,
}
EXPORT_SYMBOL(__drm_atomic_helper_set_config);
-void drm_atomic_print_state(const struct drm_atomic_state *state)
+void drm_atomic_print_state(const struct drm_atomic_state *state,
+ const char *prefix)
{
- struct drm_printer p = drm_info_printer(state->dev->dev);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_STATE, prefix);
struct drm_plane *plane;
struct drm_plane_state *plane_state;
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 25c269bc4681..c6f3c652f47c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1413,7 +1413,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
ret = drm_atomic_nonblocking_commit(state);
} else {
if (drm_debug_enabled(DRM_UT_STATE))
- drm_atomic_print_state(state);
+ drm_atomic_print_state(state, "commit_state");
ret = drm_atomic_commit(state);
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index da96b2f64d7e..077ea92fb12a 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -233,7 +233,8 @@ int __drm_atomic_helper_disable_plane(struct drm_plane
*plane,
int __drm_atomic_helper_set_config(struct drm_mode_set *set,
struct drm_atomic_state *state);
-void drm_atomic_print_state(const struct drm_atomic_state *state);
+void drm_atomic_print_state(const struct drm_atomic_state *state,
+ const char *prefix);
/* drm_atomic_uapi.c */
int drm_atomic_connector_commit_dpms(struct drm_atomic_state *state,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 12/14] drm/i915: Use debug category printer for welcome message
From: Sean Paul
The welcome printer is meant to be gated on DRM_UT_DRIVER, so use the
debug category printer to avoid dumping the message in the wrong
place.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-13-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 00292a849c34..0206be123b28 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -872,7 +872,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
static void i915_welcome_messages(struct drm_i915_private *dev_priv)
{
if (drm_debug_enabled(DRM_UT_DRIVER)) {
- struct drm_printer p = drm_debug_printer("i915 device info:");
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DRIVER,
+ "i915 device info:");
drm_printf(, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 07/14] drm/etnaviv: Change buffer dump checks to target syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-8-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 76d38561c910..7713474800e8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -353,7 +353,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
lockdep_assert_held(>lock);
- if (drm_debug_enabled(DRM_UT_DRIVER))
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
link_target = etnaviv_cmdbuf_get_va(cmdbuf,
@@ -509,13 +509,13 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
etnaviv_cmdbuf_get_va(buffer,
>mmu_context->cmdbuf_mapping)
+ buffer->user_size - 4);
- if (drm_debug_enabled(DRM_UT_DRIVER))
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
pr_info("stream link to 0x%08x @ 0x%08x %p\n",
return_target,
etnaviv_cmdbuf_get_va(cmdbuf,
>mmu_context->cmdbuf_mapping),
cmdbuf->vaddr);
- if (drm_debug_enabled(DRM_UT_DRIVER)) {
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
cmdbuf->vaddr, cmdbuf->size, 0);
@@ -534,6 +534,6 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
VIV_FE_LINK_HEADER_PREFETCH(link_dwords),
link_target);
- if (drm_debug_enabled(DRM_UT_DRIVER))
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 06/14] drm/amd: Gate i2c transaction logs on drm_debug_syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Acked-by: Christian König
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-7-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
index d55bf64770c4..1600a007344b 100644
--- a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
@@ -232,7 +232,7 @@ static uint32_t smu_v11_0_i2c_transmit(struct i2c_adapter
*control,
DRM_DEBUG_DRIVER("I2C_Transmit(), address = %x, bytes = %d , data: ",
(uint16_t)address, numbytes);
- if (drm_debug_enabled(DRM_UT_DRIVER)) {
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
16, 1, data, numbytes, false);
}
@@ -386,7 +386,7 @@ static uint32_t smu_v11_0_i2c_receive(struct i2c_adapter
*control,
DRM_DEBUG_DRIVER("I2C_Receive(), address = %x, bytes = %d, data :",
(uint16_t)address, bytes_received);
- if (drm_debug_enabled(DRM_UT_DRIVER)) {
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER)) {
print_hex_dump(KERN_INFO, "data: ", DUMP_PREFIX_NONE,
16, 1, data, bytes_received, false);
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 00/14] drm/trace: Mirror DRM debug logs to tracefs
From: Sean Paul Mostly a rebase on drm-tip. New changes: - Use the new trace_array_init_printk() call init the global trace buffers. - Add patch 13 to the set to pipe atomic state logging through trace v5 is available here: https://patchwork.freedesktop.org/series/78133/ Sean Paul (14): drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER drm/sil164: Convert dev_printk to drm_dev_dbg drm/i915/utils: Replace dev_printk with drm helpers drm/msm/dpu: Replace definitions for dpu debug macros drm/print: rename drm_debug* to be more syslog-centric drm/amd: Gate i2c transaction logs on drm_debug_syslog drm/etnaviv: Change buffer dump checks to target syslog drm/nouveau: Change debug checks to specifically target syslog drm/i915: Change infoframe debug checks to specify syslog drm/print: Add drm_debug_category_printer drm/mst: Convert debug printers to debug category printers drm/i915: Use debug category printer for welcome message drm/atomic: Use debug category printer for atomic state printer drm/print: Add tracefs support to the drm logging helpers Documentation/gpu/drm-uapi.rst | 6 + drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 4 +- drivers/gpu/drm/drm_atomic.c | 5 +- drivers/gpu/drm/drm_atomic_uapi.c| 2 +- drivers/gpu/drm/drm_crtc_internal.h | 3 +- drivers/gpu/drm/drm_dp_mst_topology.c| 9 +- drivers/gpu/drm/drm_drv.c| 3 + drivers/gpu/drm/drm_mipi_dbi.c | 8 +- drivers/gpu/drm/drm_print.c | 235 --- drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 8 +- drivers/gpu/drm/i2c/sil164_drv.c | 12 +- drivers/gpu/drm/i915/display/intel_display.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_utils.c| 5 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 20 +- drivers/gpu/drm/nouveau/nouveau_drv.h| 4 +- include/drm/drm_print.h | 96 +++- 17 files changed, 329 insertions(+), 98 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 09/14] drm/i915: Change infoframe debug checks to specify syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-10-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2ddabf92adde..30dcc8a2daa7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12908,7 +12908,7 @@ static void
intel_dump_infoframe(struct drm_i915_private *dev_priv,
const union hdmi_infoframe *frame)
{
- if (!drm_debug_enabled(DRM_UT_KMS))
+ if (!drm_debug_syslog_enabled(DRM_UT_KMS))
return;
hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, frame);
@@ -13551,7 +13551,7 @@ pipe_config_infoframe_mismatch(struct drm_i915_private
*dev_priv,
const union hdmi_infoframe *b)
{
if (fastset) {
- if (!drm_debug_enabled(DRM_UT_KMS))
+ if (!drm_debug_syslog_enabled(DRM_UT_KMS))
return;
drm_dbg_kms(_priv->drm,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 01/14] drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER
From: Sean Paul
Use the drm logging helpers to output these messages to ensure they'll
be included by the drm tracefs instance.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-2-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_mipi_dbi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 230c4fd7131c..e233b6da7cca 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -764,9 +764,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi,
int dc,
int i, ret;
u8 *dst;
- if (drm_debug_enabled(DRM_UT_DRIVER))
- pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
-__func__, dc, max_chunk);
+ DRM_DEBUG_DRIVER("dc=%d, max_chunk=%zu, transfers:\n", dc, max_chunk);
tr.speed_hz = mipi_dbi_spi_cmd_max_speed(spi, len);
spi_message_init_with_transfers(, , 1);
@@ -888,9 +886,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, int
dc,
max_chunk = dbi->tx_buf9_len;
dst16 = dbi->tx_buf9;
- if (drm_debug_enabled(DRM_UT_DRIVER))
- pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
-__func__, dc, max_chunk);
+ DRM_DEBUG_DRIVER("dc=%d, max_chunk=%zu, transfers:\n", dc, max_chunk);
max_chunk = min(max_chunk / 2, len);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 10/14] drm/print: Add drm_debug_category_printer
From: Sean Paul
This patch adds a new printer which will select the appropriate output
for a given debug category. Currently there is only one output target,
which is syslog. However in the future we'll have tracefs and it will be
useful to print to syslog, tracefs, or both. Drivers just need to create
the printer for the appropriate category and the printer will decide
where to send the output.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-11-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_print.c | 5 +
include/drm/drm_print.h | 28
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 2ff7a6ecc632..4d984a01b3a3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -172,6 +172,11 @@ void __drm_printfn_err(struct drm_printer *p, struct
va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_err);
+void __drm_printfn_noop(struct drm_printer *p, struct va_format *vaf)
+{
+}
+EXPORT_SYMBOL(__drm_printfn_noop);
+
/**
* drm_puts - print a const string to a _printer stream
* @p: the printer
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index ce7675bf0d2b..8987b98bbfda 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -87,6 +87,7 @@ void __drm_puts_seq_file(struct drm_printer *p, const char
*str);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_debug_syslog(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
+void __drm_printfn_noop(struct drm_printer *p, struct va_format *vaf);
__printf(2, 3)
void drm_printf(struct drm_printer *p, const char *f, ...);
@@ -329,6 +330,33 @@ static inline bool drm_debug_enabled(enum
drm_debug_category category)
return drm_debug_syslog_enabled(category);
}
+/**
+ * drm_debug_category_printer - construct a _printer that outputs to
+ * pr_debug() if enabled for the given category.
+ * @category: the DRM_UT_* message category this message belongs to
+ * @prefix: trace output prefix
+ *
+ * RETURNS:
+ * The _printer object
+ */
+static inline struct drm_printer
+drm_debug_category_printer(enum drm_debug_category category,
+ const char *prefix)
+{
+ struct drm_printer p = {
+ .prefix = prefix
+ };
+
+ if (drm_debug_syslog_enabled(category)) {
+ p.printfn = __drm_printfn_debug_syslog;
+ } else {
+ WARN(1, "Debug category %d is inactive.", category);
+ p.printfn = __drm_printfn_noop;
+ }
+
+ return p;
+}
+
/*
* struct device based logging
*
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 14/14] drm/print: Add tracefs support to the drm logging helpers
From: Sean Paul
This patch adds a new module parameter called drm.trace which accepts
the same mask as drm.debug. When a debug category is enabled, log
messages will be put in a new tracefs instance called drm for
consumption.
Using the new tracefs instance will allow distros to enable drm logging
in production without impacting performance or spamming the system
logs.
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Pekka Paalanen
Cc: Rob Clark
Cc: Steven Rostedt
Cc: Thomas Zimmermann
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Steven Rostedt
Acked-by: Pekka Paalanen
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191010204823.195540-1-s...@poorly.run
#v1
Link:
https://lists.freedesktop.org/archives/dri-devel/2019-November/243230.html #v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212203301.142437-1-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200114172155.215463-1-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-14-s...@poorly.run
#v5
Changes in v5:
-Re-write to use trace_array and the tracefs instance support
Changes in v6:
-Use the new trace_array_init_printk() to initialize global trace
buffers
---
Documentation/gpu/drm-uapi.rst | 6 +
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_print.c| 216 -
include/drm/drm_print.h| 63 --
4 files changed, 248 insertions(+), 40 deletions(-)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 7dce175f6d75..0297ff71f8f8 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -424,6 +424,12 @@ Debugfs Support
.. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
:export:
+DRM Tracing
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_print.c
+ :doc: DRM Tracing
+
Sysfs Support
=
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 13068fdf4331..555b40580497 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1107,12 +1107,15 @@ static void drm_core_exit(void)
drm_sysfs_destroy();
idr_destroy(_minors_idr);
drm_connector_ida_destroy();
+ drm_trace_cleanup();
}
static int __init drm_core_init(void)
{
int ret;
+ drm_trace_init();
+
drm_connector_ida_init();
idr_init(_minors_idr);
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 4d984a01b3a3..6b11143d1ab2 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,17 +44,34 @@
unsigned int __drm_debug_syslog;
EXPORT_SYMBOL(__drm_debug_syslog);
-MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
category.\n"
-"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
-"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
-"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
-"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
-"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
-"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
-"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
-"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
+/*
+ * __drm_debug_trace: Enable debug output in drm tracing instance.
+ * Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
+ */
+unsigned int __drm_debug_trace;
+EXPORT_SYMBOL(__drm_debug_trace);
+
+#define DEBUG_PARM_DESC(dst) \
+"Enable debug output to " dst ", where each bit enables a debug category.\n" \
+"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n" \
+"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n" \
+"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n" \
+"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n" \
+"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n" \
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n" \
+"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n" \
+"\t\tBit 8 (0x100) will enable DP messages (displayport code)"
+
+MODULE_PARM_DESC(debug, DEBUG_PARM_DESC("syslog"));
module_param_named(debug, __drm_debug_syslog, int, 0600);
+MODULE_PARM_DESC(trace, DEBUG_PARM_DESC("tracefs"));
+module_param_named(trace, __drm_debug_trace, int, 0600);
+
+#ifdef CONFIG_TRACING
+struct trace_array *trace_arr;
+#endif
+
void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
struct drm_print_iterator *iterator = p->arg;
@@ -166,6 +184,20 @@ void __drm_printfn_debug_syslog(struct drm_printer *p,
struct va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_debug_syslog);
+void __drm_printfn_trace(struct drm_printer *p, struct va_format *vaf)
+{
+ drm_trace_printf("%s %pV",
[PATCH v6 02/14] drm/sil164: Convert dev_printk to drm_dev_dbg
From: Sean Paul
Use the drm debug helper instead of dev_printk in order to leverage the
upcoming tracefs support
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-3-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/i2c/sil164_drv.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index 741886b54419..b315a789fca2 100644
--- a/drivers/gpu/drm/i2c/sil164_drv.c
+++ b/drivers/gpu/drm/i2c/sil164_drv.c
@@ -43,11 +43,6 @@ struct sil164_priv {
#define to_sil164_priv(x) \
((struct sil164_priv *)to_encoder_slave(x)->slave_priv)
-#define sil164_dbg(client, format, ...) do { \
- if (drm_debug_enabled(DRM_UT_KMS)) \
- dev_printk(KERN_DEBUG, >dev,\
- "%s: " format, __func__, ## __VA_ARGS__); \
- } while (0)
#define sil164_info(client, format, ...) \
dev_info(>dev, format, __VA_ARGS__)
#define sil164_err(client, format, ...)\
@@ -359,8 +354,8 @@ sil164_probe(struct i2c_client *client, const struct
i2c_device_id *id)
int rev = sil164_read(client, SIL164_REVISION);
if (vendor != 0x1 || device != 0x6) {
- sil164_dbg(client, "Unknown device %x:%x.%x\n",
- vendor, device, rev);
+ drm_dev_dbg(>dev, DRM_UT_KMS,
+ "Unknown device %x:%x.%x\n", vendor, device, rev);
return -ENODEV;
}
@@ -389,7 +384,8 @@ sil164_detect_slave(struct i2c_client *client)
};
if (i2c_transfer(adap, , 1) != 1) {
- sil164_dbg(adap, "No dual-link slave found.");
+ drm_dev_dbg(>dev, DRM_UT_KMS,
+ "No dual-link slave found.");
return NULL;
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 05/14] drm/print: rename drm_debug* to be more syslog-centric
From: Sean Paul
In preparation for tracefs support, rename drm_debug related functions
to reflect that it targets the syslog. This will allow us to selectively
target syslog and/or tracefs.
No functional changes here.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-6-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_print.c | 12 ++--
include/drm/drm_print.h | 13 +
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 111b932cf2a9..2ff7a6ecc632 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -37,11 +37,11 @@
#include
/*
- * __drm_debug: Enable debug output.
+ * __drm_debug_syslog: Enable debug output to system logs
* Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
*/
-unsigned int __drm_debug;
-EXPORT_SYMBOL(__drm_debug);
+unsigned int __drm_debug_syslog;
+EXPORT_SYMBOL(__drm_debug_syslog);
MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
category.\n"
"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
@@ -52,7 +52,7 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables a debug cat
"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)\n"
"\t\tBit 8 (0x100) will enable DP messages (displayport code)");
-module_param_named(debug, __drm_debug, int, 0600);
+module_param_named(debug, __drm_debug_syslog, int, 0600);
void __drm_puts_coredump(struct drm_printer *p, const char *str)
{
@@ -160,11 +160,11 @@ void __drm_printfn_info(struct drm_printer *p, struct
va_format *vaf)
}
EXPORT_SYMBOL(__drm_printfn_info);
-void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf)
+void __drm_printfn_debug_syslog(struct drm_printer *p, struct va_format *vaf)
{
pr_debug("%s %pV", p->prefix, vaf);
}
-EXPORT_SYMBOL(__drm_printfn_debug);
+EXPORT_SYMBOL(__drm_printfn_debug_syslog);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf)
{
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 1c9417430d08..ce7675bf0d2b 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -35,7 +35,7 @@
#include
/* Do *not* use outside of drm_print.[ch]! */
-extern unsigned int __drm_debug;
+extern unsigned int __drm_debug_syslog;
/**
* DOC: print
@@ -85,7 +85,7 @@ void __drm_puts_coredump(struct drm_printer *p, const char
*str);
void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
void __drm_puts_seq_file(struct drm_printer *p, const char *str);
void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
-void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
+void __drm_printfn_debug_syslog(struct drm_printer *p, struct va_format *vaf);
void __drm_printfn_err(struct drm_printer *p, struct va_format *vaf);
__printf(2, 3)
@@ -227,7 +227,7 @@ static inline struct drm_printer drm_info_printer(struct
device *dev)
static inline struct drm_printer drm_debug_printer(const char *prefix)
{
struct drm_printer p = {
- .printfn = __drm_printfn_debug,
+ .printfn = __drm_printfn_debug_syslog,
.prefix = prefix
};
return p;
@@ -319,9 +319,14 @@ enum drm_debug_category {
DRM_UT_DRMRES = 0x200,
};
+static inline bool drm_debug_syslog_enabled(enum drm_debug_category category)
+{
+ return unlikely(__drm_debug_syslog & category);
+}
+
static inline bool drm_debug_enabled(enum drm_debug_category category)
{
- return unlikely(__drm_debug & category);
+ return drm_debug_syslog_enabled(category);
}
/*
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 08/14] drm/nouveau: Change debug checks to specifically target syslog
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-9-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-Rebased on drm-tip, changes in dispnv50/disp.h were rebased out
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index f63ac72aa556..70be12038b0c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -258,11 +258,11 @@ void nouveau_drm_device_remove(struct drm_device *dev);
#define NV_INFO(drm,f,a...) NV_PRINTK(info, &(drm)->client, f, ##a)
#define NV_DEBUG(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_DRIVER)) \
+ if (drm_debug_syslog_enabled(DRM_UT_DRIVER))
\
NV_PRINTK(info, &(drm)->client, f, ##a); \
} while(0)
#define NV_ATOMIC(drm,f,a...) do {
\
- if (drm_debug_enabled(DRM_UT_ATOMIC)) \
+ if (drm_debug_syslog_enabled(DRM_UT_ATOMIC))
\
NV_PRINTK(info, &(drm)->client, f, ##a); \
} while(0)
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 11/14] drm/mst: Convert debug printers to debug category printers
From: Sean Paul
The printers in dp_mst are meant to be gated on DRM_UT_DP, so use the
debug category printer to avoid dumping mst transactions to the wrong
place.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-12-s...@poorly.run
#v5
Changes in v5:
-Added to the set
Changes in v6:
-None
---
drivers/gpu/drm/drm_dp_mst_topology.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..127120b60580 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1242,7 +1242,8 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
}
out:
if (unlikely(ret == -EIO) && drm_debug_enabled(DRM_UT_DP)) {
- struct drm_printer p = drm_debug_printer(DBG_PREFIX);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
+ DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(, txmsg);
}
@@ -2781,7 +2782,8 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
if (unlikely(ret) && drm_debug_enabled(DRM_UT_DP)) {
- struct drm_printer p = drm_debug_printer(DBG_PREFIX);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
+ DBG_PREFIX);
drm_printf(, "sideband msg failed to send\n");
drm_dp_mst_dump_sideband_msg_tx(, txmsg);
@@ -2825,7 +2827,8 @@ static void drm_dp_queue_down_tx(struct
drm_dp_mst_topology_mgr *mgr,
list_add_tail(>next, >tx_msg_downq);
if (drm_debug_enabled(DRM_UT_DP)) {
- struct drm_printer p = drm_debug_printer(DBG_PREFIX);
+ struct drm_printer p = drm_debug_category_printer(DRM_UT_DP,
+ DBG_PREFIX);
drm_dp_mst_dump_sideband_msg_tx(, txmsg);
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote: > On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote: > > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > > > On 8/17/20 12:48 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > > > From: Allen Pais > > > > > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > > > and from_tasklet() to pass the tasklet pointer > > > > > > > > explicitly. > > > > > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' > > > > > > > that > > > > > > > is just container_of? container_of in the code would be > > > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > > > from_tasklet is doing. > > > > > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > > > > > As I mentioned in the other thread, I think this makes > > > > > > things > > > > > > much more readable. It's the same thing that the > > > > > > timer_struct > > > > > > conversion did (added a container_of wrapper) to avoid the > > > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > > > > > But then it should use a generic name, instead of each sub- > > > > > system > > > > > using some random name that makes people look up exactly what > > > > > it > > > > > does. I'm not huge fan of the container_of() redundancy, but > > > > > adding private variants of this doesn't seem like the best > > > > > way > > > > > forward. Let's have a generic helper that does this, and use > > > > > it > > > > > everywhere. > > > > > > > > I'm open to suggestions, but as things stand, these kinds of > > > > treewide > > > > > > On naming? Implementation is just as it stands, from_tasklet() is > > > totally generic which is why I objected to it. from_member()? Not > > > great with naming... But I can see this going further and then > > > we'll > > > suddenly have tons of these. It's not good for readability. > > > > Since both threads seem to have petered out, let me suggest in > > kernel.h: > > > > #define cast_out(ptr, container, member) \ > > container_of(ptr, typeof(*container), member) > > > > It does what you want, the argument order is the same as > > container_of with the only difference being you name the containing > > structure instead of having to specify its type. > > I like this! Shall I send this to Linus to see if this can land in > -rc2 for use going forward? Sure ... he's probably been lurking on this thread anyway ... it's about time he got off his arse^Wthe fence and made an executive decision ... James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
On Tue, Aug 18, 2020 at 12:45 AM Hyesoo Yu wrote: > > These patch series to introduce a new dma heap, chunk heap. > That heap is needed for special HW that requires bulk allocation of > fixed high order pages. For example, 64MB dma-buf pages are made up > to fixed order-4 pages * 1024. > > The chunk heap uses alloc_pages_bulk to allocate high order page. > https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minc...@kernel.org > > The chunk heap is registered by device tree with alignment and memory node > of contiguous memory allocator(CMA). Alignment defines chunk page size. > For example, alignment 0x1_ means chunk page size is 64KB. > The phandle to memory node indicates contiguous memory allocator(CMA). > If device node doesn't have cma, the registration of chunk heap fails. > > The patchset includes the following: > - export dma-heap API to register kernel module dma heap. > - add chunk heap implementation. > - document of device tree to register chunk heap > > Hyesoo Yu (3): > dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps > dma-buf: heaps: add chunk heap to dmabuf heaps > dma-heap: Devicetree binding for chunk heap Hey! Thanks so much for sending this out! I'm really excited to see these heaps be submitted and reviewed on the list! The first general concern I have with your series is that it adds a dt binding for the chunk heap, which we've gotten a fair amount of pushback on. A possible alternative might be something like what Kunihiko Hayashi proposed for non-default CMA heaps: https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih...@socionext.com/ This approach would insteal allow a driver to register a CMA area with the chunk heap implementation. However, (and this was the catch Kunihiko Hayashi's patch) this requires that the driver also be upstream, as we need an in-tree user of such code. Also, it might be good to provide some further rationale on why this heap is beneficial over the existing CMA heap? In general focusing the commit messages more on the why we might want the patch, rather than what the patch does, is helpful. "Special hardware" that doesn't have upstream drivers isn't very compelling for most maintainers. That said, I'm very excited to see these sorts of submissions, as I know lots of vendors have historically had very custom out of tree ION heaps, and I think it would be a great benefit to the community to better understand the experience vendors have in optimizing performance on their devices, so we can create good common solutions upstream. So I look forward to your insights on future revisions of this patch series! thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/5] drm/panel: Use dev_ based logging
On Sat, Aug 15, 2020 at 02:54:01PM +0200, Sam Ravnborg wrote: > The drm/panel drivers uses a mixture of DRM_ and dev_ based logging. > With this patchset all panel drivers are migrated to use dev_ based > logging as the DRM_ based logging did not add any extra info. > > Drop the now unused include of drm_print.h. > > With this change new panel drivers will be requires to change to dev_ > based logging - so some of the in-flight panel drivers will need trivial > updates before they are accepted. > > Patch divided in smaller bites to ease review. There is no dependencies > between the patches. > > Copied a few people that may have input to the move away from DRM_ based > logging (Daniel (presumeably on vacation), Jani). > > Sam > > Sam Ravnborg (5): > drm/panel: samsung: Use dev_ based logging > drm/panel: leadtek: Use dev_ based logging > drm/panel: raydium: Use dev_ based logging > drm/panel: sitronix: Use dev_ based logging > drm/panel: Use dev_ based logging Thanks for the reviews from Linus and Guido. Series is now applied to drm-misc-next. Sam > > drivers/gpu/drm/panel/panel-boe-himax8279d.c | 44 > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 51 +- > drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 19 +++-- > .../gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 21 +++--- > drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 +- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 31 +++-- > drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c | 33 - > drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 58 ++-- > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 49 + > drivers/gpu/drm/panel/panel-novatek-nt35510.c | 40 --- > drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 13 ++-- > drivers/gpu/drm/panel/panel-raydium-rm67191.c | 33 - > drivers/gpu/drm/panel/panel-raydium-rm68200.c | 18 +++-- > drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 16 ++--- > drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 23 +++--- > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 22 +++--- > drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 +- > drivers/gpu/drm/panel/panel-sitronix-st7701.c | 10 ++- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 61 ++-- > drivers/gpu/drm/panel/panel-sony-acx424akp.c | 81 > -- > drivers/gpu/drm/panel/panel-tpo-tpg110.c | 38 +- > drivers/gpu/drm/panel/panel-truly-nt35597.c| 63 ++--- > drivers/gpu/drm/panel/panel-visionox-rm69299.c | 41 --- > drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 51 +- > 27 files changed, 308 insertions(+), 523 deletions(-) > > > > ___ > 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] block: convert tasklets to use new tasklet_setup() API
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > On 8/17/20 12:48 PM, Kees Cook wrote: > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > From: Allen Pais > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > and from_tasklet() to pass the tasklet pointer explicitly. > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' that > > > > > is just container_of? container_of in the code would be > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > from_tasklet is doing. > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > As I mentioned in the other thread, I think this makes things > > > > much more readable. It's the same thing that the timer_struct > > > > conversion did (added a container_of wrapper) to avoid the > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > But then it should use a generic name, instead of each sub-system > > > using some random name that makes people look up exactly what it > > > does. I'm not huge fan of the container_of() redundancy, but > > > adding private variants of this doesn't seem like the best way > > > forward. Let's have a generic helper that does this, and use it > > > everywhere. > > > > I'm open to suggestions, but as things stand, these kinds of > > treewide > > On naming? Implementation is just as it stands, from_tasklet() is > totally generic which is why I objected to it. from_member()? Not > great with naming... But I can see this going further and then we'll > suddenly have tons of these. It's not good for readability. Since both threads seem to have petered out, let me suggest in kernel.h: #define cast_out(ptr, container, member) \ container_of(ptr, typeof(*container), member) It does what you want, the argument order is the same as container_of with the only difference being you name the containing structure instead of having to specify its type. James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote: > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote: > > On 8/17/20 12:48 PM, Kees Cook wrote: > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote: > > > > On 8/17/20 12:29 PM, Kees Cook wrote: > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote: > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote: > > > > > > > From: Allen Pais > > > > > > > > > > > > > > In preparation for unconditionally passing the > > > > > > > struct tasklet_struct pointer to all tasklet > > > > > > > callbacks, switch to using the new tasklet_setup() > > > > > > > and from_tasklet() to pass the tasklet pointer explicitly. > > > > > > > > > > > > Who came up with the idea to add a macro 'from_tasklet' that > > > > > > is just container_of? container_of in the code would be > > > > > > _much_ more readable, and not leave anyone guessing wtf > > > > > > from_tasklet is doing. > > > > > > > > > > > > I'd fix that up now before everything else goes in... > > > > > > > > > > As I mentioned in the other thread, I think this makes things > > > > > much more readable. It's the same thing that the timer_struct > > > > > conversion did (added a container_of wrapper) to avoid the > > > > > ever-repeating use of typeof(), long lines, etc. > > > > > > > > But then it should use a generic name, instead of each sub-system > > > > using some random name that makes people look up exactly what it > > > > does. I'm not huge fan of the container_of() redundancy, but > > > > adding private variants of this doesn't seem like the best way > > > > forward. Let's have a generic helper that does this, and use it > > > > everywhere. > > > > > > I'm open to suggestions, but as things stand, these kinds of > > > treewide > > > > On naming? Implementation is just as it stands, from_tasklet() is > > totally generic which is why I objected to it. from_member()? Not > > great with naming... But I can see this going further and then we'll > > suddenly have tons of these. It's not good for readability. > > Since both threads seem to have petered out, let me suggest in > kernel.h: > > #define cast_out(ptr, container, member) \ > container_of(ptr, typeof(*container), member) > > It does what you want, the argument order is the same as container_of > with the only difference being you name the containing structure > instead of having to specify its type. I like this! Shall I send this to Linus to see if this can land in -rc2 for use going forward? -- Kees Cook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208115] amdgpu (likely) - power management and display connection problems with an RX590 card
https://bugzilla.kernel.org/show_bug.cgi?id=208115 --- Comment #1 from Adarion from userland (h_mailingli...@posteo.de) --- Sadly I did not yet find the time for long time tests in my productive systems. a quick check: RX 590 in my FX-6300 based box (Asus M5A78L-M PLUS/USB3) I did one successful return from DPMS, but that was just one, and different (newly purchased) monitor (Asus PA24A) hooked up via HDMI. Kernel was 5.7.x. idle KDE session: ~69 W (wall, "empty system" just mainboard, CPU, fans, RAM and one SSD to boot from) early DPMS off: 66 W BACO(?): jumps between 62...77 W (there shouldn't have been much of a system activity, I wonder what's caused the alterations) "sensors" readings still high, show something around 30W idle. (The RX 560 however, is down to 56 W in idle KDE, but also shows some variance during DPMS off/BACO.) Expected: The RX 590 should be roughly 9-12 W idle, like it's smaller brethren. Currently running the Zen+ with some old HD 5450, the RX 590 is gathering dust. (Can't risk crashing my productive system every 10 minutes.) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #6 from Coleman Kane (ck...@colemankane.org) --- Thanks Alex - I have added the four attachments you requested. I haven't done a git bisect before, but I am very familiar with using git and understand the concept of a bisect, so I could probably figure it out using some documentation such as https://www.kernel.org/doc/html/latest/admin-guide/bug-bisect.html. Now is as good a time as any to learn! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #5 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292017 --> https://bugzilla.kernel.org/attachment.cgi?id=292017=edit Xorg log from failure case (same 5.9-next kernel) Xorg.log from trying to run Xorg under kernel that fails to set resolutions properly. The DisplayPort-0 displays at 1024x768, and I can not set the resolution any higher than that from within Xorg (using the enlightenment "screen" settings panel). You can see from the following line that it boots into 1024x768: [38.608] (II) AMDGPU(0): Output DisplayPort-0 using initial mode 1024x768 +0+0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #4 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292015 --> https://bugzilla.kernel.org/attachment.cgi?id=292015=edit Xorg.log from working case (Arch 5.8.1-1 kernel) Xorg from working case on Arch 5.8.1-1 kernel package. You can see from the following line that it is booting to 3840x2160 resolution: [25.694] (II) AMDGPU(0): Output DisplayPort-0 using initial mode 3840x2160 +1920+0 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #3 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292013 --> https://bugzilla.kernel.org/attachment.cgi?id=292013=edit dmesg on faliure case from linux-next.git as of 2020-08-18 00:00:00 (pending-fixes branch) I built a bootable kernel from the linux-next "pending-fixes" based upon sources synchronized with upstream git repo as of 2020-08-18 morning. Did this to verify that there is no pending fix to this issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 --- Comment #2 from Coleman Kane (ck...@colemankane.org) --- Created attachment 292011 --> https://bugzilla.kernel.org/attachment.cgi?id=292011=edit Working dmesg from Arch "linux" kernel 5.8.1-1 Working dmesg from Arch "linux" kernel 5.8.1-1 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: s6e63m0: Order enable/disable sequence
Hi Linus. On Mon, Aug 17, 2020 at 11:39:06PM +0200, Linus Walleij wrote: > The upstream S6E63M0 driver has some pecularities around > the prepare/enable disable/unprepare sequence: the screen > is taken out of sleep in prepare() as part of > s6e63m0_init() the put to on with MIPI_DCS_SET_DISPLAY_ON > in enable(). > > However it is just put into sleep mode directly in > disable(). As disable()/enable() can be called without > unprepare()/prepare() being called, this is unbalanced, > we should take the display out of sleep in enable() > then turn it off(). > > Further MIPI_DCS_SET_DISPLAY_OFF is never called > balanced with MIPI_DCS_SET_DISPLAY_ON. > > The vendor driver for Samsung GT-I8190 (Golden) does all > of these things in strict order. > > Augment the driver to do exit sleep/set display on in > enable() and set display off/enter sleep in disable(). > > Further send an explict reset pulse in power_on() so we > come up in a known state, and issue the MCS_ERROR_CHECK > command after setting display on like the vendor driver > does. Also use the timings from the vendor driver in > the sequence. > > Doing all of these things makes the display much more > stable on the Samsung GT-I8190 when enabling/disabling > the display pipeline. > > Cc: Paweł Chmiel > Cc: Stephan Gerhold > Signed-off-by: Linus Walleij Browsed through this patch - looks fine. Acked-by: Sam Ravnborg Sam > --- > This is based on top of the earlier patches for s6e63m0. > --- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 18 +++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > index f1d96ec3b57f..49b0470bcccd 100644 > --- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c > @@ -26,6 +26,7 @@ > #define MCS_ELVSS_ON0xb1 > #define MCS_MIECTL10xc0 > #define MCS_BCMODE 0xc1 > +#define MCS_ERROR_CHECK 0xd5 > #define MCS_READ_ID1 0xda > #define MCS_READ_ID2 0xdb > #define MCS_READ_ID3 0xdc > @@ -281,8 +282,6 @@ static void s6e63m0_init(struct s6e63m0 *ctx) > > s6e63m0_dcs_write_seq_static(ctx, MCS_ELVSS_ON, >0x0b); > - > - s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE); > } > > static int s6e63m0_power_on(struct s6e63m0 *ctx) > @@ -295,6 +294,9 @@ static int s6e63m0_power_on(struct s6e63m0 *ctx) > > msleep(25); > > + /* Be sure to send a reset pulse */ > + gpiod_set_value(ctx->reset_gpio, 1); > + msleep(5); > gpiod_set_value(ctx->reset_gpio, 0); > msleep(120); > > @@ -324,8 +326,10 @@ static int s6e63m0_disable(struct drm_panel *panel) > > backlight_disable(ctx->bl_dev); > > + s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF); > + msleep(10); > s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE); > - msleep(200); > + msleep(120); > > ctx->enabled = false; > > @@ -391,7 +395,15 @@ static int s6e63m0_enable(struct drm_panel *panel) > if (ctx->enabled) > return 0; > > + s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE); > + msleep(120); > s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON); > + msleep(10); > + > + s6e63m0_dcs_write_seq_static(ctx, MCS_ERROR_CHECK, > + 0xE7, 0x14, 0x60, 0x17, 0x0A, 0x49, 0xC3, > + 0x8F, 0x19, 0x64, 0x91, 0x84, 0x76, 0x20, > + 0x0F, 0x00); > > backlight_enable(ctx->bl_dev); > > -- > 2.26.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam,
On Tue, Aug 18, 2020 at 07:05:56PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Mon, Aug 17, 2020 at 10:14:33AM +0200, Guido Günther wrote:
> >
> > The panel uses a Focaltech FT8006p, the touch part is handled by the already
> > existing edt-ft5x06. It can be found in e.g. the Librem 5.
> >
> > Changes from v2:
> > - Due to review comments by Sam Ravnborg, thanks!
> > https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> > - Drop unused header
> > - Use newline before comment
> > - Add Reviewed/Acked-by by Sam Ravnborg, thanks!
> > https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> > https://lore.kernel.org/lkml/20200815212750.gb1244...@ravnborg.org/
> > https://lore.kernel.org/lkml/20200815212840.gc1244...@ravnborg.org/
> >
> > Changes from v1:
> > - Due to review comments by Sam Ravnborg, thanks!
> > https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
> > - Don't preserve newlines with '|' in description
> > - Use reset-gpios and backlight from panel-common.yaml
> > - Reindent example
> > https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
> > - Drop unused includes
> > - Use dev_* instead of DRM_* for printing
> > - Turn off regulators in reverse order from enable
> > - Silence errors in mantix_{shutdown,remove}
> > - Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
> > https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
> > - Use dev_err_probe()
> > - Add delays when turning off panel as suggested by the data sheet
> >
> > This series is against next-20200814.
> >
> > Guido Günther (3):
> > dt-bindings: vendor-prefixes: Add mantix vendor prefix
> > dt-bindings: Add Mantix MLAF057WE51-X panel bindings
> > drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
>
> Maxime Ripard backmerged -rc1 to drm-misc-next so I went ahead and applied
> this series to drm-misc-next, forgetting you got commit rights. As they are
> already pushed out too late for you to do push them - sorry!
On the contrary: Thanks a lot for handling this so promptly!
-- Guido
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/panel: s6e63m0: Add DSI transport
Hi Linus. On Sun, Aug 09, 2020 at 11:51:00PM +0200, Linus Walleij wrote: > This begins to modify the Samsung S6E63M0 driver to provide > DSI support. > > After these initial changes the driver can already be used > with the Samsung GT-I8190 (Golden) phone. > > After this initial support we will make more changes to > support more gammas (more levels of backlight), special > biasing on different display types and handling of the > ESD IRQ. > > But let's begin with this. How does this patchset relate to the patchset posted by Paul? https://lore.kernel.org/dri-devel/20200727164613.19744-1-p...@crapouillou.net/ Seems that two different approcahes are used for the same type of problem. Is it possible to find a common solution? Sam > > Linus Walleij (4): > drm/panel: s6e63m0: Break out SPI transport > drm/panel: s6e63m0: Add DSI transport > drm/panel: s6e63m0: Add reading functionality > drm/panel: s6e63m0: Add code to identify panel > > drivers/gpu/drm/panel/Kconfig | 23 ++- > drivers/gpu/drm/panel/Makefile| 2 + > .../gpu/drm/panel/panel-samsung-s6e63m0-dsi.c | 145 + > .../gpu/drm/panel/panel-samsung-s6e63m0-spi.c | 101 > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 146 ++ > drivers/gpu/drm/panel/panel-samsung-s6e63m0.h | 13 ++ > 6 files changed, 363 insertions(+), 67 deletions(-) > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0-spi.c > create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.h > > -- > 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/malidp: Use struct drm_gem_object_funcs.get_sg_table internally
On Thu, Aug 13, 2020 at 02:01:19PM +0200, Daniel Vetter wrote:
> On Thu, Aug 13, 2020 at 12:39 PM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 13.08.20 um 12:31 schrieb Daniel Vetter:
> > > On Thu, Aug 13, 2020 at 12:28:55PM +0200, Thomas Zimmermann wrote:
> > >>
> > >>
> > >> Am 13.08.20 um 11:48 schrieb Daniel Vetter:
> > >>> On Thu, Aug 13, 2020 at 11:19:31AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 07.08.20 um 18:10 schrieb Daniel Vetter:
> > > On Fri, Aug 7, 2020 at 4:02 PM Thomas Zimmermann
> > > wrote:
> > >>
> > >> Hi
> > >>
> > >> Am 07.08.20 um 15:12 schrieb Daniel Vetter:
> > >>> On Fri, Aug 07, 2020 at 01:10:22PM +0200, Thomas Zimmermann wrote:
> > The malidp driver uses GEM object functions for callbacks. Fix it
> > to
> > use them internally as well.
> >
> > Signed-off-by: Thomas Zimmermann
> > Fixes: ecdd6474644f ("drm/malidp: Use GEM CMA object functions")
> > Cc: Thomas Zimmermann
> > Cc: Emil Velikov
> > Cc: Liviu Dudau
> > Cc: Brian Starkey
> > ---
> > drivers/gpu/drm/arm/malidp_planes.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> > b/drivers/gpu/drm/arm/malidp_planes.c
> > index ab45ac445045..351a85088d0e 100644
> > --- a/drivers/gpu/drm/arm/malidp_planes.c
> > +++ b/drivers/gpu/drm/arm/malidp_planes.c
> > @@ -346,7 +346,7 @@ static bool
> > malidp_check_pages_threshold(struct malidp_plane_state *ms,
> > if (cma_obj->sgt)
> > sgt = cma_obj->sgt;
> > else
> > -sgt =
> > obj->dev->driver->gem_prime_get_sg_table(obj);
> > +sgt = obj->funcs->get_sg_table(obj);
> > >>>
> > >>> Uh if there's not a switch somewhere I'd just call the right
> > >>> function
> > >>> directly. Or call the right wrapper for this, this feels a bit
> > >>> fishy ...
> > >>
> > >> The driver initializes the pointer via CMA helper macro to an
> > >> CMA-internal default. Calling the actual function here is fragile if
> > >> the
> > >> CMA-internal default ever changes.
> > >>
> > >> But I have no strong feelings. I'll go with whatever the driver's
> > >> maintainer prefers.
Hi,
Sorry for the silence, I was on holiday.
> > >
> > > What I meant is: There should be an exported helper to get at the sgt.
> > > Drivers using helpers shouldn't need to do this kind of stuff here.
> > >
> > > Also the entire code is fairly suspect, getting at the sgt from
> > > plane_check is a bit iffy. But that's a different kind of problem.
> >
> > I tried to somehow move the code to CMA, but it's not easy. There's no
> > good place to put the look-up code of sgt. And sgt is later being freed
> > iff it came from the callback (and not freed if it was stored in the
> > object). AFIACT the best options are to either keep the code here or
> > move the entire function to CMA helpers.
> > >>>
> > >>> Ok I read some code ... I'm confused. From the control flow it looks
> > >>> like
> > >>> malidp is using cma helpers. Otherwise why does the upcasting not blow
> > >>> up
> > >>> sometimes.
> > >>>
> > >>> But cma helpers already check at import time that any imported dma-buf
> > >>> is
> > >>> contiguous, and they guarantee to fill out the cma_obj->sgt.
> > >>>
> > >>> So really no idea what this code is doing here.
> > >>>
> > >>> It's also not correct, since it doesn't coalesce sgt entries, since a
> > >>> range might be split up, but still mapped into a contiguous dma_addr_t
> > >>> range when you take it all together. The code in
> > >>> drm_gem_cma_prime_import_sg_table() gets this more right.
> > >>>
> > >>> So maybe right fix is to just ditch this all, and use cma helpers fully?
> > >>
> > >> The driver already does use CMA, including
> > >> drm_gem_cma_prime_import_sg_table().
> > >>
> > >> The patched code is not about importing/exporting sg tables. It
> > >> configures the MMU's prefetching pattern by looking at some of the page
> > >> sizes. I don't feel confident enough with this code to alter it. I'd
> > >> expect to break the heuristics.
That's right, this piece of code has nothing to do with importing dma-buf or
checking if things are contiguous. Mali DP hardware has a prefetcher block that
can generate some fake requests during vblank to get the MMU pagetables cached
so that reads from the buffers can be done without waiting for page walks. The
block supports two modes, a full page or partial page request (to cater for the
ends of the buffer that might not be a full page).
The patch proposed looks good to me, so:
Acked-by: Liviu Dudau
I will push the
Re: [PATCH v3 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Guido.
On Mon, Aug 17, 2020 at 10:14:33AM +0200, Guido Günther wrote:
>
> The panel uses a Focaltech FT8006p, the touch part is handled by the already
> existing edt-ft5x06. It can be found in e.g. the Librem 5.
>
> Changes from v2:
> - Due to review comments by Sam Ravnborg, thanks!
> https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> - Drop unused header
> - Use newline before comment
> - Add Reviewed/Acked-by by Sam Ravnborg, thanks!
> https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> https://lore.kernel.org/lkml/20200815212750.gb1244...@ravnborg.org/
> https://lore.kernel.org/lkml/20200815212840.gc1244...@ravnborg.org/
>
> Changes from v1:
> - Due to review comments by Sam Ravnborg, thanks!
> https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
> - Don't preserve newlines with '|' in description
> - Use reset-gpios and backlight from panel-common.yaml
> - Reindent example
> https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
> - Drop unused includes
> - Use dev_* instead of DRM_* for printing
> - Turn off regulators in reverse order from enable
> - Silence errors in mantix_{shutdown,remove}
> - Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
> https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
> - Use dev_err_probe()
> - Add delays when turning off panel as suggested by the data sheet
>
> This series is against next-20200814.
>
> Guido Günther (3):
> dt-bindings: vendor-prefixes: Add mantix vendor prefix
> dt-bindings: Add Mantix MLAF057WE51-X panel bindings
> drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Maxime Ripard backmerged -rc1 to drm-misc-next so I went ahead and applied
this series to drm-misc-next, forgetting you got commit rights. As they are
already pushed out too late for you to do push them - sorry!
Sam
>
> .../display/panel/mantix,mlaf057we51-x.yaml | 70
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 7 +
> drivers/gpu/drm/panel/Kconfig | 11 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
> 6 files changed, 419 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
>
> --
> 2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Add DT bindings for RaspberryPi 7" display ATTINY88-based regulator/backlight controller
On Sun, 9 Aug 2020 12:59:37 +0200, Marek Vasut wrote: > Add DT bindings for RaspberryPi 7" display ATTINY88-based > regulator/backlight controller, this one is used in the > Raspberry Pi 7" touchscreen display unit. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/2] regulator: Add DT bindings for RaspberryPi 7" display ATTINY88-based regulator/backlight controller commit: 9c535960891470eaec5664eed2a56dbb2b6a205b [2/2] regulator: rpi-panel: Add regulator/backlight driver for RPi panel commit: 38573472278da49e2ab588062d88bc2f0c11a325 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] dma-heap: Devicetree binding for chunk heap
On Tue, 18 Aug 2020 17:04:15 +0900, Hyesoo Yu wrote: > Document devicetree binding for chunk heap on dma heap framework > > Signed-off-by: Hyesoo Yu > --- > .../devicetree/bindings/dma-buf/chunk_heap.yaml| 46 > ++ > 1 file changed, 46 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/dma-buf/chunk_heap.example.dt.yaml: chunk_default_heap: 'alignment', 'memory-region' do not match any of the regexes: 'pinctrl-[0-9]+' See https://patchwork.ozlabs.org/patch/1346687 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: enable vblank during atomic commits
From: Rob Clark
This has roughly the same effect as drm_atomic_helper_wait_for_vblanks(),
basically just ensuring that vblank accounting is enabled so that we get
valid timestamp/seqn on pageflip events.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_atomic.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 5ccfad794c6a..561bfa48841c 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -27,6 +27,34 @@ int msm_atomic_prepare_fb(struct drm_plane *plane,
return msm_framebuffer_prepare(new_state->fb, kms->aspace);
}
+/*
+ * Helpers to control vblanks while we flush.. basically just to ensure
+ * that vblank accounting is switched on, so we get valid seqn/timestamp
+ * on pageflip events (if requested)
+ */
+
+static void vblank_get(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_get(crtc);
+ }
+}
+
+static void vblank_put(struct msm_kms *kms, unsigned crtc_mask)
+{
+ struct drm_crtc *crtc;
+
+ for_each_crtc_mask(kms->dev, crtc, crtc_mask) {
+ if (!crtc->state->active)
+ continue;
+ drm_crtc_vblank_put(crtc);
+ }
+}
+
static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
@@ -44,6 +72,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->enable_commit(kms);
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -58,6 +88,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
@@ -221,6 +253,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
*/
kms->pending_crtc_mask &= ~crtc_mask;
+ vblank_get(kms, crtc_mask);
+
/*
* Flush hardware updates:
*/
@@ -235,6 +269,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state *state)
kms->funcs->wait_flush(kms, crtc_mask);
trace_msm_atomic_wait_flush_finish(crtc_mask);
+ vblank_put(kms, crtc_mask);
+
mutex_lock(>commit_lock);
kms->funcs->complete_commit(kms, crtc_mask);
mutex_unlock(>commit_lock);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Use alpha value to blend values.
I wrote this patch for TODO list in vkms documentation.
Use alpha value to blend source value and destination value Instead of
just overwrite with source value.
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Signed-off-by: Sidong Yang
---
drivers/gpu/drm/vkms/vkms_composer.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4f3b07a32b60..e3230e2a99af 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -77,6 +77,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
+ u8 *src, *dst;
+ u32 alpha, inv_alpha;
+
offset_dst = dest_composer->offset
+ (i_dst * dest_composer->pitch)
+ (j_dst++ * dest_composer->cpp);
@@ -84,8 +87,15 @@ static void blend(void *vaddr_dst, void *vaddr_src,
+ (i * src_composer->pitch)
+ (j * src_composer->cpp);
- memcpy(vaddr_dst + offset_dst,
- vaddr_src + offset_src, sizeof(u32));
+ src = vaddr_src + offset_src;
+ dst = vaddr_dst + offset_dst;
+ alpha = src[3] + 1;
+ inv_alpha = 256 - src[3];
+ dst[0] = (alpha * src[0] + inv_alpha * dst[0]) >> 8;
+ dst[1] = (alpha * src[1] + inv_alpha * dst[1]) >> 8;
+ dst[2] = (alpha * src[2] + inv_alpha * dst[2]) >> 8;
+ dst[3] = 0xff;
+
}
i_dst++;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-s...@poorly.run
#v7
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-Use FIELD_PREP to generate request buffer bitfields (Lyude)
-Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
Changes in v7:
-None
Changes in v8:
-Reverse the parsing on the hdcp_*x_device_present bits and leave
breadcrumb in case this is incorrect (Anshuman)
---
drivers/gpu/drm/drm_dp_mst_topology.c | 150 ++
.../drm/selftests/test-drm_dp_mst_helper.c| 17 ++
include/drm/drm_dp_helper.h | 3 +
include/drm/drm_dp_mst_helper.h | 44 +
4 files changed, 214 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 67dd72ea200e..f2b77ef40281 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -20,11 +20,13 @@
* OF THIS SOFTWARE.
*/
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -423,6 +425,22 @@ drm_dp_encode_sideband_req(const struct
drm_dp_sideband_msg_req_body *req,
memcpy([idx], req->u.i2c_write.bytes,
req->u.i2c_write.num_bytes);
idx += req->u.i2c_write.num_bytes;
break;
+ case DP_QUERY_STREAM_ENC_STATUS: {
+ const struct drm_dp_query_stream_enc_status *msg;
+
+ msg = >u.enc_status;
+ buf[idx] = msg->stream_id;
+ idx++;
+ memcpy([idx], msg->client_id, sizeof(msg->client_id));
+ idx += sizeof(msg->client_id);
+ buf[idx] = 0;
+ buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
+ buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
+ buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
+ buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
+ idx++;
+ }
+ break;
}
raw->cur_len = idx;
}
@@ -551,6 +569,20 @@ drm_dp_decode_sideband_req(const struct
drm_dp_sideband_msg_tx *raw,
return -ENOMEM;
}
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ req->u.enc_status.stream_id = buf[idx++];
+ for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
+ req->u.enc_status.client_id[i] = buf[idx++];
+
+ req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
+ buf[idx]);
+ req->u.enc_status.valid_stream_event = FIELD_GET(BIT(2),
+buf[idx]);
+ req->u.enc_status.stream_behavior = FIELD_GET(GENMASK(4, 3),
+ buf[idx]);
+ req->u.enc_status.valid_stream_behavior = FIELD_GET(BIT(5),
+ buf[idx]);
+ break;
}
return 0;
@@ -629,6 +661,16 @@ drm_dp_dump_sideband_msg_req_body(const struct
drm_dp_sideband_msg_req_body *req
req->u.i2c_write.num_bytes, req->u.i2c_write.num_bytes,
req->u.i2c_write.bytes);
break;
+ case DP_QUERY_STREAM_ENC_STATUS:
+ P("stream_id=%u client_id=%*ph stream_event=%x "
+ "valid_event=%d stream_behavior=%x valid_behavior=%d",
+ req->u.enc_status.stream_id,
+ (int)ARRAY_SIZE(req->u.enc_status.client_id),
+ req->u.enc_status.client_id, req->u.enc_status.stream_event,
+ req->u.enc_status.valid_stream_event,
+ req->u.enc_status.stream_behavior,
+ req->u.enc_status.valid_stream_behavior);
+ break;
default:
P("???\n");
break;
@@ -936,6 +978,42 @@ static bool
drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
return true;
}
+static bool
+drm_dp_sideband_parse_query_stream_enc_status(
+ struct drm_dp_sideband_msg_rx *raw,
+ struct drm_dp_sideband_msg_reply_body *repmsg)
+{
+ struct drm_dp_query_stream_enc_status_ack_reply *reply;
+
+ reply = >u.enc_status;
+
+ reply->stream_id = raw->msg[3];
+
+
[PATCH v8 16/17] drm/i915: Print HDCP version info for all connectors
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-16-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-16-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-17-s...@poorly.run
#v7
Changes in v4:
- Added to the set
Changes in v5:
-Print "No connector support" for hdcp sink capability as well (Ram)
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
.../drm/i915/display/intel_display_debugfs.c | 21 ---
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index f549381048b3..58c26a5afc49 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -601,6 +601,11 @@ static void intel_hdcp_info(struct seq_file *m,
{
bool hdcp_cap, hdcp2_cap;
+ if (!intel_connector->hdcp.shim) {
+ seq_puts(m, "No Connector Support");
+ goto out;
+ }
+
hdcp_cap = intel_hdcp_capable(intel_connector);
hdcp2_cap = intel_hdcp2_capable(intel_connector);
@@ -612,6 +617,7 @@ static void intel_hdcp_info(struct seq_file *m,
if (!hdcp_cap && !hdcp2_cap)
seq_puts(m, "None");
+out:
seq_puts(m, "\n");
}
@@ -628,10 +634,6 @@ static void intel_dp_info(struct seq_file *m,
drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
_dp->aux);
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_dp_mst_info(struct seq_file *m,
@@ -649,10 +651,6 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(intel_encoder);
seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_lvds_info(struct seq_file *m,
@@ -708,6 +706,9 @@ static void intel_connector_info(struct seq_file *m,
break;
}
+ seq_puts(m, "\tHDCP version: ");
+ intel_hdcp_info(m, intel_connector);
+
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, >modes, head)
intel_seq_print_mode(m, 2, mode);
@@ -2029,10 +2030,6 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
if (connector->status != connector_status_connected)
return -ENODEV;
- /* HDCP is supported by connector */
- if (!intel_connector->hdcp.shim)
- return -EINVAL;
-
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
intel_hdcp_info(m, intel_connector);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 17/17] drm/i915: Add HDCP 1.4 support for MST connectors
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Reviewed-by: Anshuman Gupta
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-18-s...@poorly.run
#v7
Changes in v2:
-Toggle HDCP from encoder disable/enable
-Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
-Place the shim in the new intel_dp_hdcp.c file (Ville)
Changes in v4:
-Actually use the mst shim for mst connections (Juston)
-Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
Changes in v5:
-Add sleep on disable signalling to match hdmi delay
Changes in v6:
-Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
don't have hardware to test it
Changes in v7:
-Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++
drivers/gpu/drm/i915/display/intel_hdcp.c| 2 +-
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index b744253a5924..03424d20e9f7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include "intel_display_types.h"
+#include "intel_ddi.h"
#include "intel_dp.h"
#include "intel_hdcp.h"
@@ -619,6 +621,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.protocol = HDCP_PROTOCOL_DP,
};
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *dig_port,
+ enum transcoder cpu_transcoder,
+ bool enable)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ int ret;
+
+ if (!enable)
+ usleep_range(6, 60); /* Bspec says >= 6us */
+
+ ret = intel_ddi_toggle_hdcp_signalling(_port->base,
+ cpu_transcoder, enable);
+ if (ret)
+ drm_dbg_kms(>drm, "%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+ 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 = _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(_dp->mst_mgr,
+ connector->port, );
+ if (ret) {
+ drm_dbg_kms(>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,
+ .read_bstatus = intel_dp_hdcp_read_bstatus,
+ .repeater_present = intel_dp_hdcp_repeater_present,
+ .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+ .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+ .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,
+ .hdcp_capable = intel_dp_hdcp_capable,
+
+ .protocol = HDCP_PROTOCOL_DP,
+};
+
int intel_dp_init_hdcp(struct intel_digital_port *dig_port,
struct intel_connector *intel_connector)
{
@@ -631,7 +692,10 @@ int intel_dp_init_hdcp(struct intel_digital_port
[PATCH v8 14/17] drm/i915: Add connector to hdcp_shim->check_link()
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-s...@poorly.run
#v7
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e01f2f840c9..413b60337a0b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -318,7 +318,8 @@ struct intel_hdcp_shim {
bool enable);
/* Ensures the link is still protected */
- bool (*check_link)(struct intel_digital_port *dig_port);
+ bool (*check_link)(struct intel_digital_port *dig_port,
+ struct intel_connector *connector);
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *dig_port,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index c164ad11e617..b744253a5924 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -224,7 +224,8 @@ int intel_dp_hdcp_toggle_signalling(struct
intel_digital_port *dig_port,
}
static
-bool intel_dp_hdcp_check_link(struct intel_digital_port *dig_port)
+bool intel_dp_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);
ssize_t ret;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index f25cfb7a9565..028cf3ac548f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -952,7 +952,7 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- if (hdcp->shim->check_link(dig_port)) {
+ if (hdcp->shim->check_link(dig_port, connector)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c0ea16dae3b3..0978b0d8f4c6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1546,11 +1546,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *dig_port,
}
static
-bool intel_hdmi_hdcp_check_link_once(struct intel_digital_port *dig_port)
+bool intel_hdmi_hdcp_check_link_once(struct intel_digital_port *dig_port,
+struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_connector *connector =
- dig_port->hdmi.attached_connector;
enum port port = dig_port->base.port;
enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
int ret;
@@ -1578,13 +1577,14 @@ bool intel_hdmi_hdcp_check_link_once(struct
intel_digital_port *dig_port)
}
static
-bool intel_hdmi_hdcp_check_link(struct intel_digital_port *dig_port)
+bool intel_hdmi_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);
int retry;
for (retry = 0; retry < 3; retry++)
- if (intel_hdmi_hdcp_check_link_once(dig_port))
+ if (intel_hdmi_hdcp_check_link_once(dig_port, connector))
return true;
drm_err(>drm, "Link check failed\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
[PATCH v8 08/17] drm/i915: Clean up intel_hdcp_disable
From: Sean Paul
Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-9-s...@poorly.run
#v7
Changes in v7:
-Split into separate patch (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fe9377a6e4d5..4de87012659b 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2112,16 +2112,17 @@ int intel_hdcp_disable(struct intel_connector
*connector)
mutex_lock(>mutex);
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- intel_hdcp_update_value(connector,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
- false);
- if (hdcp->hdcp2_encrypted)
- ret = _intel_hdcp2_disable(connector);
- else if (hdcp->hdcp_encrypted)
- ret = _intel_hdcp_disable(connector);
- }
+ if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ goto out;
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED, false);
+ if (hdcp->hdcp2_encrypted)
+ ret = _intel_hdcp2_disable(connector);
+ else if (hdcp->hdcp_encrypted)
+ ret = _intel_hdcp_disable(connector);
+
+out:
mutex_unlock(>mutex);
cancel_delayed_work_sync(>check_work);
return ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 12/17] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-12-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-12-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-13-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-Created intel_dp_hdcp.c for the shared functions to live (Ville)
Changes in v4:
-Rebased on new drm logging change
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-Rebased patch
Changes in v8:
-None
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 607 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 637 +++
4 files changed, 642 insertions(+), 606 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bda4c0e408f8..e5574e506a5c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -234,6 +234,7 @@ i915-y += \
display/intel_ddi.o \
display/intel_dp.o \
display/intel_dp_aux_backlight.o \
+ display/intel_dp_hdcp.o \
display/intel_dp_link_training.o \
display/intel_dp_mst.o \
display/intel_dsi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b54577a04ccf..41d76df7423e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -38,7 +38,6 @@
#include
#include
#include
-#include
#include
#include "i915_debugfs.h"
@@ -6401,610 +6400,6 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
-static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
-{
- long ret;
-
-#define C (hdcp->cp_irq_count_cached != atomic_read(>cp_irq_count))
- ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
- msecs_to_jiffies(timeout));
-
- if (!ret)
- DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
-}
-
-static
-int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *dig_port,
- u8 *an)
-{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- u8 aksv[DRM_HDCP_KSV_LEN] = {};
- ssize_t dpcd_ret;
-
- /* Output An first, that's easy */
- dpcd_ret = drm_dp_dpcd_write(_port->dp.aux, DP_AUX_HDCP_AN,
-an, DRM_HDCP_AN_LEN);
- if (dpcd_ret != DRM_HDCP_AN_LEN) {
- drm_dbg_kms(>drm,
- "Failed to write An over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
-
- /*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So we
-* send an empty buffer of the correct length through the DP helpers. On
-* the other side, in the transfer hook, we'll generate a flag based on
-* the destination address which will tickle the hardware to output the
-* Aksv on our behalf after the header is sent.
-*/
- dpcd_ret = drm_dp_dpcd_write(_port->dp.aux, DP_AUX_HDCP_AKSV,
-aksv, DRM_HDCP_KSV_LEN);
- if (dpcd_ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(>drm,
- "Failed to write Aksv over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *dig_port,
- u8 *bksv)
-{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- ssize_t ret;
-
- ret = drm_dp_dpcd_read(_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
- DRM_HDCP_KSV_LEN);
- if (ret != DRM_HDCP_KSV_LEN) {
- drm_dbg_kms(>drm,
- "Read Bksv from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bstatus(struct intel_digital_port *dig_port,
-
[PATCH v8 05/17] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 +++--
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 15 ---
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b02cd36647d6..2feec47a48e0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1820,12 +1820,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -1834,19 +1834,12 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (drm_WARN_ON(dev, !wakeref))
return -ENXIO;
- if (drm_WARN_ON(dev,
- !intel_encoder->get_hw_state(intel_encoder, ))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(pipe));
+ tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 077e9dbbe367..f5fb62fc9400 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -16,6 +16,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_atomic_state *state,
struct intel_encoder *intel_encoder,
@@ -43,6 +44,7 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
u32 bxt_signal_levels(struct intel_dp *intel_dp);
u32 ddi_signal_levels(struct intel_dp *intel_dp);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9349b15afff6..d30ec7728a99 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -314,6 +314,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7d1774bfbe41..adef7b508ff5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
[PATCH v8 06/17] drm/i915: Factor out hdcp->value assignments
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-7-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-7-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-7-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on top of drm_* logging changes
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index b28a351f3a98..ab2e2f9d0020 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -876,6 +876,21 @@ static struct intel_connector
*intel_hdcp_to_connector(struct intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+static void intel_hdcp_update_value(struct intel_connector *connector,
+ u64 value, bool update_property)
+{
+ struct intel_hdcp *hdcp = >hdcp;
+
+ drm_WARN_ON(connector->base.dev, !mutex_is_locked(>mutex));
+
+ if (hdcp->value == value)
+ return;
+
+ hdcp->value = value;
+ if (update_property)
+ schedule_work(>prop_work);
+}
+
/* Implements Part 3 of the HDCP authorization procedure */
static int intel_hdcp_check_link(struct intel_connector *connector)
{
@@ -903,15 +918,16 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
connector->base.name, connector->base.base.id,
intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
if (hdcp->shim->check_link(dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(>prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -923,16 +939,18 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
drm_err(_priv->drm, "Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = _intel_hdcp_enable(connector);
if (ret) {
drm_err(_priv->drm, "Failed to enable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
@@ -1768,16 +1786,18 @@ static int intel_hdcp2_check_link(struct
intel_connector *connector)
"HDCP2.2 link stopped the encryption, %x\n",
intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(>prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = hdcp->shim->check_2_2_link(dig_port);
if (ret == HDCP_LINK_PROTECTED) {
[PATCH v8 09/17] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-s...@poorly.run
#v7
Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-Split minor intel_hdcp_disable refactor into separate patch (Ramalingam)
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 +++
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 33 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 ++
5 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 2feec47a48e0..a1643588b5f9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4996,6 +4996,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
drm_encoder_init(_priv->drm, >base, _ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
+ mutex_init(_port->hdcp_mutex);
+ dig_port->num_hdcp_streams = 0;
+
encoder->hotplug = intel_ddi_hotplug;
encoder->compute_output_type = intel_ddi_compute_output_type;
encoder->compute_config = intel_ddi_compute_config;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d30ec7728a99..b6d0ad171432 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1416,6 +1416,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index adef7b508ff5..b54577a04ccf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -8285,6 +8285,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = _port->base;
encoder = _encoder->base;
+ mutex_init(_port->hdcp_mutex);
+
if (drm_encoder_init(_priv->drm, _encoder->base,
_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 4de87012659b..dc77db0a8df3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -801,6 +801,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ return ret;
+ }
+
hdcp->hdcp_encrypted = false;
[PATCH v8 07/17] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-8-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ---
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ab2e2f9d0020..fe9377a6e4d5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -887,8 +887,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(>base);
schedule_work(>prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -980,6 +982,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(>mutex);
drm_modeset_unlock(_priv->drm.mode_config.connection_mutex);
+
+ drm_connector_put(>base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1859,6 +1863,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(>base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(>check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2185,12 +2192,39 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = >hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(>hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(>hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ drm_WARN_ON(connector->base.dev,
+ connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(>check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ drm_WARN_ON(connector->base.dev, work_pending(>prop_work));
+
+ mutex_lock(>mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(>mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 13/17] drm/i915: Plumb port through hdcp init
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Reviewed-by: Anshuman Gupta
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-s...@poorly.run
#v7
Changes in v5:
-Added to the set
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c| 11 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h| 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 0b8200bed061..c164ad11e617 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -631,7 +631,8 @@ int intel_dp_init_hdcp(struct intel_digital_port *dig_port,
return 0;
if (!intel_dp_is_edp(intel_dp))
- return intel_hdcp_init(intel_connector, _dp_hdcp_shim);
+ return intel_hdcp_init(intel_connector, port,
+ _dp_hdcp_shim);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dc77db0a8df3..f25cfb7a9565 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1954,6 +1954,7 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder
cpu_transcoder)
}
static int initialize_hdcp_port_data(struct intel_connector *connector,
+enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1961,8 +1962,7 @@ static int initialize_hdcp_port_data(struct
intel_connector *connector,
struct hdcp_port_data *data = >port_data;
if (INTEL_GEN(dev_priv) < 12)
- data->fw_ddi =
-
intel_get_mei_fw_ddi_index(intel_attached_encoder(connector)->port);
+ data->fw_ddi = intel_get_mei_fw_ddi_index(port);
else
/*
* As per ME FW API expectation, for GEN 12+, fw_ddi is filled
@@ -2032,14 +2032,14 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector,
+static void intel_hdcp2_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector, shim);
+ ret = initialize_hdcp_port_data(connector, port, shim);
if (ret) {
drm_dbg_kms(>drm, "Mei hdcp data init failed\n");
return;
@@ -2049,6 +2049,7 @@ static void intel_hdcp2_init(struct intel_connector
*connector,
}
int intel_hdcp_init(struct intel_connector *connector,
+ enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -2059,7 +2060,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return -EINVAL;
if (is_hdcp2_supported(dev_priv))
- intel_hdcp2_init(connector, shim);
+ intel_hdcp2_init(connector, port, shim);
ret =
drm_connector_attach_content_protection_property(>base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 86bbaec120cc..1bbf5b67ed0a 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -22,7 +22,7 @@ enum transcoder;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
-int intel_hdcp_init(struct intel_connector *connector,
+int intel_hdcp_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *hdcp_shim);
int intel_hdcp_enable(struct intel_connector *connector,
enum transcoder cpu_transcoder, u8 content_type);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9c3b1ae2cd2b..c0ea16dae3b3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++
[PATCH v8 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-11-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-11-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-12-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 11 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 6 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a1643588b5f9..36022281d7e0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4012,13 +4012,14 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_panel_update_backlight(state, encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_atomic_state *state,
- struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(state, encoder, crtc_state,
conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index b901ab850cbd..d13b45151a3f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -17,6 +17,7 @@ struct drm_encoder;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct drm_dp_vsc_sdp;
+struct intel_atomic_state;
struct intel_connector;
struct intel_crtc_state;
struct intel_digital_port;
@@ -128,4 +129,9 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_atomic_state *state,
+ struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index a2d91a499700..b97b2918d802 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -865,6 +865,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*dig_port, enum pipe
intel_encoder->compute_config_late = intel_dp_mst_compute_config_late;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 10/17] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-10-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-10-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-11-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b6d0ad171432..5e01f2f840c9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1531,6 +1531,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(>base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1539,6 +1551,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(>base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1549,13 +1563,6 @@ intel_attached_dig_port(struct intel_connector
*connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(>base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return _to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 04/17] drm/i915: Intercept Aksv writes in the aux hooks
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-5-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-5-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-5-s...@poorly.run
#v7
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_dp.c | 62 -
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 79c27f91f42c..7d1774bfbe41 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1563,6 +1563,20 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
}
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+ /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+ msg->address == DP_AUX_HDCP_AKSV)
+ return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+ return 0;
+}
+
static ssize_t
intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
@@ -1570,6 +1584,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+ u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
intel_dp_aux_header(txbuf, msg);
@@ -1590,7 +1605,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
@@ -1613,7 +1628,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -6403,15 +6418,8 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *dig_port,
u8 *an)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_dp *intel_dp =
enc_to_intel_dp(to_intel_encoder(_port->base.base));
- static const struct drm_dp_aux_msg msg = {
- .request = DP_AUX_NATIVE_WRITE,
- .address = DP_AUX_HDCP_AKSV,
- .size = DRM_HDCP_KSV_LEN,
- };
- u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+ u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
- int ret;
/* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(_port->dp.aux, DP_AUX_HDCP_AN,
@@ -6424,31 +6432,19 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *dig_port,
}
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-* we were
[PATCH v8 02/17] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-s...@poorly.run
#v7
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6189b7583277..1a0d49af2a08 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -795,6 +795,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_hdcp *hdcp = >hdcp;
enum port port = dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
drm_dbg_kms(_priv->drm, "[%s:%d] HDCP is being disabled...\n",
@@ -810,6 +811,11 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(dig_port, false);
if (ret) {
drm_err(_priv->drm, "Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 01/17] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-s...@poorly.run
#v5
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-s...@poorly.run
#v6
Link:
https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-2-s...@poorly.run
#v7
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 89a4d294822d..6189b7583277 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -336,8 +336,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -435,7 +437,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Write 32 bits of text */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -450,17 +452,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
intel_de_write(dev_priv, HDCP_REP_CTL,
[PATCH v8 03/17] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul HDCP signalling should not be left on, WARN if it is Cc: Ville Syrjälä Cc: Daniel Vetter Reviewed-by: Ramalingam C Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-s...@poorly.run #v3 Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-s...@poorly.run #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-4-s...@poorly.run #v5 Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-4-s...@poorly.run #v6 Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-4-s...@poorly.run #v7 Changes in v2: -Added to the set in lieu of just clearing the bit Changes in v3: -None Changes in v4: -None Changes in v5: -Change WARN_ON to drm_WARN_ON Changes in v6: -None Changes in v7: -Rebased, variable name changed from 'ctl' to 'val' Changes in v8: -None --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index de5b216561d8..b02cd36647d6 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -1791,6 +1791,8 @@ void intel_ddi_disable_transcoder_func(const struct intel_crtc_state *crtc_state ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder)); + drm_WARN_ON(crtc->base.dev, ctl & TRANS_DDI_HDCP_SIGNALLING); + ctl &= ~TRANS_DDI_FUNC_ENABLE; if (IS_GEN_RANGE(dev_priv, 8, 10)) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 00/17] drm/i915: Add support for HDCP 1.4 over MST
From: Sean Paul Only one functional change, reversed the hdcp_1x/2x_present bits in the QUERY_STREAM_ENCRYPTION_STATUS parsing with a comment explaining my confusion. Other than that, lots of rebasing, the most notable being the s/intel_dig_port/dig_port/ rename. Every patch now has a Reviewed-by tag now, I've done build tests on each patch and tested the set as a whole. Hopefully we can get this landed. Sean Sean Paul (17): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Clean up intel_hdcp_disable drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Plumb port through hdcp init drm/i915: Add connector to hdcp_shim->check_link() drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message drm/i915: Print HDCP version info for all connectors drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/drm_dp_mst_topology.c | 150 drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 30 +- drivers/gpu/drm/i915/display/intel_dp.c | 646 +--- drivers/gpu/drm/i915/display/intel_dp.h | 9 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 703 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 19 + drivers/gpu/drm/i915/display/intel_hdcp.c | 217 -- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 30 +- .../drm/selftests/test-drm_dp_mst_helper.c| 17 + include/drm/drm_dp_helper.h | 3 + include/drm/drm_dp_mst_helper.h | 44 ++ include/drm/drm_hdcp.h| 3 + 17 files changed, 1202 insertions(+), 724 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] drm/msm: add shutdown support for display platform_driver
On Tue, Aug 18, 2020 at 3:03 AM Sai Prakash Ranjan
wrote:
>
> Hi,
>
> On 2020-06-01 16:33, Krishna Manikandan wrote:
> > Define shutdown callback for display drm driver,
> > so as to disable all the CRTCS when shutdown
> > notification is received by the driver.
> >
> > This change will turn off the timing engine so
> > that no display transactions are requested
> > while mmu translations are getting disabled
> > during reboot sequence.
> >
> > Signed-off-by: Krishna Manikandan
> >
> > Changes in v2:
> > - Remove NULL check from msm_pdev_shutdown (Stephen Boyd)
> > - Change commit text to reflect when this issue
> > was uncovered (Sai Prakash Ranjan)
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c
> > b/drivers/gpu/drm/msm/msm_drv.c
> > index e4b750b..94e3963 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -1322,6 +1322,13 @@ static int msm_pdev_remove(struct
> > platform_device *pdev)
> > return 0;
> > }
> >
> > +static void msm_pdev_shutdown(struct platform_device *pdev)
> > +{
> > + struct drm_device *drm = platform_get_drvdata(pdev);
> > +
> > + drm_atomic_helper_shutdown(drm);
> > +}
> > +
> > static const struct of_device_id dt_match[] = {
> > { .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
> > { .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
> > @@ -1334,6 +1341,7 @@ static int msm_pdev_remove(struct platform_device
> > *pdev)
> > static struct platform_driver msm_platform_driver = {
> > .probe = msm_pdev_probe,
> > .remove = msm_pdev_remove,
> > + .shutdown = msm_pdev_shutdown,
> > .driver = {
> > .name = "msm",
> > .of_match_table = dt_match,
>
> Any more comments on this patch?
sorry, I managed to overlook this earlier.. I've pulled it in to msm-next
BR,
-R
> Thanks,
> Sai
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: should check error using DC_OK
On Mon, Aug 17, 2020 at 3:08 AM Tong Zhang wrote: > > core_link_read_dpcd returns only DC_OK(1) and DC_ERROR_UNEXPECTED(-1), > the caller should check error using DC_OK instead of checking against 0 > > Signed-off-by: Tong Zhang Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > index 5cb7b834e459..a60a457fcc8f 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c > @@ -4376,9 +4376,9 @@ bool dc_link_get_backlight_level_nits(struct dc_link > *link, > link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT)) > return false; > > - if (!core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_CURRENT_PEAK, > + if (core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_CURRENT_PEAK, > dpcd_backlight_get.raw, > - sizeof(union dpcd_source_backlight_get))) > + sizeof(union dpcd_source_backlight_get)) != DC_OK) > return false; > > *backlight_millinits_avg = > @@ -4417,9 +4417,9 @@ bool dc_link_read_default_bl_aux(struct dc_link *link, > uint32_t *backlight_milli > link->connector_signal != SIGNAL_TYPE_DISPLAY_PORT)) > return false; > > - if (!core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_LEVEL, > + if (core_link_read_dpcd(link, DP_SOURCE_BACKLIGHT_LEVEL, > (uint8_t *) backlight_millinits, > - sizeof(uint32_t))) > + sizeof(uint32_t)) != DC_OK) > return false; > > return true; > -- > 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 v2] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp
Hi, Jitao:
Jitao Shi 於 2020年8月18日 週二 上午10:41寫道：
>
> On Tue, 2020-08-18 at 07:42 +0800, Chun-Kuang Hu wrote:
> > Hi, Jitao:
> >
> > Jitao Shi 於 2020年8月17日 週一 下午9:07寫道：
> > >
> > > horizontal_backporch_byte should be hbp * bpp - hbp extra bytes.
> > > So remove the wrong subtraction 10.
> > >
> > > Signed-off-by: Jitao Shi
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_dsi.c | 9 -
> > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > index 270bf22c98fe..5d031e634571 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > > @@ -473,14 +473,13 @@ static void mtk_dsi_config_vdo_timing(struct
> > > mtk_dsi *dsi)
> > > horizontal_sync_active_byte = (vm->hsync_len * dsi_tmp_buf_bpp -
> > > 10);
> >
> > So this subtraction 10 is correct?
> >
> > Regards,
> > Chun-Kuang.
> >
>
> Yes, It is right.
>
> In the cea861 and dmt spec the mini hsync is 40 pixels.
> So the vm->hsync_len * dsi_tmp_buf_bpp >= 120 > 10
>
OK, so
Reviewed-by: Chun-Kuang Hu
> Best Regards
> jitao
> > >
> > > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > > - horizontal_backporch_byte =
> > > - (vm->hback_porch * dsi_tmp_buf_bpp - 10);
> > > + horizontal_backporch_byte = vm->hback_porch *
> > > dsi_tmp_buf_bpp;
> > > else
> > > - horizontal_backporch_byte = ((vm->hback_porch +
> > > vm->hsync_len) *
> > > - dsi_tmp_buf_bpp - 10);
> > > + horizontal_backporch_byte = (vm->hback_porch +
> > > vm->hsync_len) *
> > > + dsi_tmp_buf_bpp;
> > >
> > > data_phy_cycles = timing->lpx + timing->da_hs_prepare +
> > > - timing->da_hs_zero + timing->da_hs_exit + 3;
> > > + timing->da_hs_zero + timing->da_hs_exit;
> > >
> > > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > > if ((vm->hfront_porch + vm->hback_porch) *
> > > dsi_tmp_buf_bpp >
> > > --
> > > 2.12.5
> > > ___
> > > Linux-mediatek mailing list
> > > linux-media...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amd/display: fix potential integer overflow when shifting 32 bit variable bl_pwm
On Tue, Aug 18, 2020 at 8:09 AM Colin King wrote:
>
> From: Colin Ian King
>
> The 32 bit unsigned integer bl_pwm is being shifted using 32 bit arithmetic
> and then being assigned to a 64 bit unsigned integer. There is a potential
> for a 32 bit overflow so cast bl_pwm to enforce a 64 bit shift operation
> to avoid this.
>
> Addresses-Coverity: ("unintentional integer overflow")
> Fixes: 3ba01817365c ("drm/amd/display: Move panel_cntl specific register from
> abm to panel_cntl.")
> Signed-off-by: Colin Ian King
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
> index a6d73d30837c..df7f826eebd8 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
> @@ -76,7 +76,7 @@ static unsigned int
> dce_get_16_bit_backlight_from_pwm(struct panel_cntl *panel_c
> else
> bl_pwm &= 0x;
>
> - current_backlight = bl_pwm << (1 + bl_int_count);
> + current_backlight = (uint64_t)bl_pwm << (1 + bl_int_count);
>
> if (bl_period == 0)
> bl_period = 0x;
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.8-rc1
On Fri, Aug 14, 2020 at 07:25:17PM +0200, Daniel Vetter wrote: > On Fri, Aug 14, 2020 at 7:17 PM Daniel Stone wrote: > > > > Hi, > > > > On Fri, 14 Aug 2020 at 17:22, Thierry Reding > > wrote: > > > I suspect that the reason why this works in X but not in Wayland is > > > because X passes the right usage flags, whereas Weston may not. But I'll > > > have to investigate more in order to be sure. > > > > Weston allocates its own buffers for displaying the result of > > composition through GBM with USE_SCANOUT, which is definitely correct. > > > > Wayland clients (common to all compositors, in Mesa's > > src/egl/drivers/dri2/platform_wayland.c) allocate with USE_SHARED but > > _not_ USE_SCANOUT, which is correct in that they are guaranteed to be > > shared, but not guaranteed to be scanned out. The expectation is that > > non-scanout-compatible buffers would be rejected by gbm_bo_import if > > not drmModeAddFB2. > > > > One difference between Weston and all other compositors (GNOME Shell, > > KWin, Sway, etc) is that Weston uses KMS planes for composition when > > it can (i.e. when gbm_bo_import from dmabuf + drmModeAddFB2 from > > gbm_bo handle + atomic check succeed), but the other compositors only > > use the GPU. So if you have different assumptions about the layout of > > imported buffers between the GPU and KMS, that would explain a fair > > bit. > > Yeah non-modifiered multi-gpu (of any kind) is pretty much hopeless I > think. I guess the only option is if the tegra mesa driver forces > linear and an extra copy on everything that's USE_SHARED or > USE_SCANOUT. I ended up trying this, but this fails for the X case, unfortunately, because there doesn't seem to be a good synchronization point at which the de-tiling blit could be done. Weston and kmscube end up calling a gallium driver's ->flush_resource() implementation, but that never happens for X and glamor. But after looking into this some more, I don't think that's even the problem that we're facing here. The root of the problem that causes the glxgears crash that Karol was originally reporting is because we end up allocating the glxgears pixmaps using the dri3 loader from Mesa. But the dri3 loader will unconditionally pass both __DRI_IMAGE_USE_SHARE and __DRI_IMAGE_USE_SCANOUT, irrespective of whether the buffer will end up being scanned out directly or whether it will be composited onto the root window. What exactly happens depends on whether I run glxgears in fullscreen mode or windowed mode. In windowed mode, the glxgears buffers will be composited onto the root window, so there's no need for the buffers to be scanout-capable. If I modify the dri3 loader to not pass those flags I can make this work just fine. When I run glxgears in fullscreen mode, the modesetting driver ends up wanting to display the glxgears buffer directly on screen, without compositing it onto the root window. This ends up working if I leave out the _USE_SHARE and _USE_SCANOUT flags, but I notice that the kernel then complains about being unable to create a framebuffer, which in turn is caused by the fact that those buffers are not exported (the Tegra Mesa driver only exports/imports buffers that are meant for scanout, under the assumption that those are the only ones that will ever need to be used by KMS) and therefore Tegra DRM doesn't have a valid handle for them. So I think an ideal solution would probably be for glxgears to somehow pass better usage information when allocating buffers, but I suspect that that's just not possible, or would be way too much work and require additional protocol at the DRI level, so it's not really a good option when all we want to fix is backwards-compatibility with pre-modifiers userspace. Given that glamor also doesn't have any synchronization points, I don't see how I can implement the de-tiling blit reliably. I was wondering if it shouldn't be possible to flush the framebuffer resource (and perform the blit) at presentation time, but I couldn't find a good entry point to do this. One other solution that occurred to me was to reintroduce an old IOCTL that we used to have in the Tegra DRM driver. That IOCTL was meant to attach tiling meta data to an imported buffer and was basically a simplified, driver-specific way of doing framebuffer modifiers. That's a very ugly solution, but it would allow us to be backwards-compatible with pre-modifiers userspace and even use an optimal path for rendering and scanning out. The only prerequisite would be that the driver IOCTL was implemented and that a recent enough Mesa was used to make use of it. I don't like this very much because framebuffer modifiers are a much more generic solution, but all of the other options above are pretty much just as ugly. One other idea that I haven't explored yet is to be a little more clever about the export/import dance that we do for buffers. Currently we export/import at allocation time, and that seems to cause a bit of a problem, like the lack of valid
Re: [PATCH v2 1/4] staging: android: Replace BUG_ON with WARN_ON
On Tue, Aug 18, 2020 at 05:19:40PM +0300, Tomer Samara wrote: > On Tue, Aug 18, 2020 at 04:11:06PM +0200, Greg Kroah-Hartman wrote: > > On Sun, Aug 16, 2020 at 10:23:25PM +0300, Tomer Samara wrote: > > > BUG_ON() is replaced with WARN_ON at ion_page_pool.c > > > > Why? > > > > > Fixes the following issue: > > > Avoid crashing the kernel - try using WARN_ON & recovery code ratherthan > > > BUG() or BUG_ON(). > > > > Ideally you can get rid of WARN_ON() too, right? > > > > Many systems run in panic-on-warn mode, so this really does not change > > anything. Try fixing this up properly to not crash at all. > > > You mean by that to just remove the WARN_ON and leave the condition the > same? Or fix the problem that could ever cause this check to fire. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] staging: android: Add error handling to order_to_index callers
On Sun, Aug 16, 2020 at 10:31:22PM +0300, Tomer Samara wrote: > Add error check to: > - free_buffer_page > - alloc_buffer_page > after calling order_to_index, due to converting BUG to WARN at > order_to_index. You are fixing a bug you caused in a previous patch, not good :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] staging: android: Replace BUG_ON with WARN_ON
On Sun, Aug 16, 2020 at 10:23:25PM +0300, Tomer Samara wrote:
> BUG_ON() is replaced with WARN_ON at ion_page_pool.c
Why?
> Fixes the following issue:
> Avoid crashing the kernel - try using WARN_ON & recovery code ratherthan
> BUG() or BUG_ON().
Ideally you can get rid of WARN_ON() too, right?
Many systems run in panic-on-warn mode, so this really does not change
anything. Try fixing this up properly to not crash at all.
>
> Signed-off-by: Tomer Samara
> ---
> drivers/staging/android/ion/ion_page_pool.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion_page_pool.c
> b/drivers/staging/android/ion/ion_page_pool.c
> index 0198b886d906..c1b9eda35c96 100644
> --- a/drivers/staging/android/ion/ion_page_pool.c
> +++ b/drivers/staging/android/ion/ion_page_pool.c
> @@ -46,11 +46,13 @@ static struct page *ion_page_pool_remove(struct
> ion_page_pool *pool, bool high)
> struct page *page;
>
> if (high) {
> - BUG_ON(!pool->high_count);
> + if (WARN_ON(!pool->high_count))
> + return NULL;
And can you test this that it works properly?
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] staging: android: Convert BUG to WARN
On Sun, Aug 16, 2020 at 10:30:10PM +0300, Tomer Samara wrote: > replace BUG() with WARN() at ion_sytem_heap.c, this > fix the following checkpatch issue: > Avoid crashing the kernel - try using WARN_ON & > recovery code ratherthan BUG() or BUG_ON(). > > Signed-off-by: Tomer Samara > --- > drivers/staging/android/ion/ion_system_heap.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/staging/android/ion/ion_system_heap.c > b/drivers/staging/android/ion/ion_system_heap.c > index eac0632ab4e8..37065a59ca69 100644 > --- a/drivers/staging/android/ion/ion_system_heap.c > +++ b/drivers/staging/android/ion/ion_system_heap.c > @@ -30,7 +30,8 @@ static int order_to_index(unsigned int order) > for (i = 0; i < NUM_ORDERS; i++) > if (order == orders[i]) > return i; > - BUG(); > + > + WARN(1, "%s: Did not found index to order %d", __FUNCTION__, order); Same question as before, I think this didn't really change anything :( ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] staging: android: Add error handling to ion_page_pool_shrink
On Sun, Aug 16, 2020 at 10:24:22PM +0300, Tomer Samara wrote: > Add error check to ion_page_pool_shrink after calling > ion_page_pool_remove, due to converting BUG_ON to WARN_ON. > > Signed-off-by: Tomer Samara So this fixes a previous patch? That's not good, please merge them together so you do not cause a bug and then fix it up later on. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208909] amdgpu Ryzen 7 4700U NULL pointer dereference multi monitor with rotation
https://bugzilla.kernel.org/show_bug.cgi?id=208909 --- Comment #7 from ker...@890.at --- FullHD -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208909] amdgpu Ryzen 7 4700U NULL pointer dereference multi monitor with rotation
https://bugzilla.kernel.org/show_bug.cgi?id=208909 --- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) --- What resolutions are your displays? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208947] amdgpu DisplayPort won't recognize all display modes after 5.9 merges
https://bugzilla.kernel.org/show_bug.cgi?id=208947 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your dmesg output and xorg log (if using X) in both the working and non-working cases. Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: fbdevdrm
(cc'ing dri-devel. It's public information that others should be able to find.) Hi Mark, generally speaking, what you try to do should be possible with fbconv/fbdevdrm. Am 17.08.20 um 21:12 schrieb Nnext unnnext: > Hey Thomas! > > I am working on postmarketOS, mobile Alpine Linux distribution, and I > got really excited when saw your fbdevdrm project. While pmOS encourage > mainlining, most mobile devices often use old kernels(3.*-4.*), and so > can't run any modern compositor which uses drm. Most of them utilize > fbdev though. So if it's possible to run drm on top of fbdev, that would > be really cool! However, I have some questions about the project. First, > can it be brought to downstream devices? Second, is it in working state? It works for all the desktop graphics cards that I was able to get my hands on. I'd expect that other hardware works as well. The latest snapshot is at https://gitlab.freedesktop.org/tzimmermann/linux/-/commits/fbconv/ for Linux v5.4. It should be possible to back-port it to earlier kernels. The code depends on fbdev (which hasn't changed in a decade), simple-kms helpers and SHMEM. The latter are DRM helper libraries that you may need to backport as well. In the commit history, you'll find that I created each DRM driver from the fbdev driver and a DRM skeleton driver. That gives a basic driver without HW acceleration. I guess if you use Android you cannot always copy around fbdev drivers easily. If you still can build your own kernel, you may want to take a look at an earlier approach available at https://lists.freedesktop.org/archives/dri-devel/2019-March/211970.html It hooks into the fbdev device registering and creates a DRM device whenever an fbdev device becomes available; all without having to copy the fbdev driver into DRM. Let me know if you have more detailed questions on either option. > Third, is it upstreamed somewhere? Nope and won't be. It's meant as a helper for porting fbdev drivers to DRM. The expectation is that only the converted driver is merged in its final state. If none of this works, you could attempt to back-port the whole DRM subsystem to these old kernels. A lot of mobile hardware has DRM drivers these days. Best regards Thomas > > Thank you for your contribution! > > Sincerely, > Mark. -- 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 signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amd/display: fix potential integer overflow when shifting 32 bit variable bl_pwm
From: Colin Ian King
The 32 bit unsigned integer bl_pwm is being shifted using 32 bit arithmetic
and then being assigned to a 64 bit unsigned integer. There is a potential
for a 32 bit overflow so cast bl_pwm to enforce a 64 bit shift operation
to avoid this.
Addresses-Coverity: ("unintentional integer overflow")
Fixes: 3ba01817365c ("drm/amd/display: Move panel_cntl specific register from
abm to panel_cntl.")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
index a6d73d30837c..df7f826eebd8 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_panel_cntl.c
@@ -76,7 +76,7 @@ static unsigned int dce_get_16_bit_backlight_from_pwm(struct
panel_cntl *panel_c
else
bl_pwm &= 0x;
- current_backlight = bl_pwm << (1 + bl_int_count);
+ current_backlight = (uint64_t)bl_pwm << (1 + bl_int_count);
if (bl_period == 0)
bl_period = 0x;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND v10 00/11] PCI: brcmstb: enable PCIe for STB chips
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v10:
Commit: "device-mapping: Introduce DMA range map, supplanting ..."
-- change title of commit; "bus core:" => "device-mapping:"
-- instead of allocating the DMA map with devm, use kcalloc
and call kfree() during device_release(). (RobH) Also,
for three cases that want to use the same DMA map, copy
the dma_range_map using a helper function.
-- added a missing 'return = 0;' to of_dma_get_range(). (Nicolas)
-- removed dma_range_overlaps(); instead return error if there
is an existing DMA map. (Christoph).
Commit: "PCI: brcmstb: Set additional internal memory DMA ..."
-- Changed constant 1 to 1ULL. (Nicolas)
Commit: "ata: ahci_brcm: Fix use of BCM7216 reset controller"
This commit has been removed from this patchset and will be
submitted on its own.
v9:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- A number of code improvements were implemented as suggested by
ChristophH. Unfortunately, some of these changes reversed the
implemented suggestions of other reviewers; for example, the new
macros PFN_DMA_ADDR(), DMA_ADDR_PFN() have been pulled.
v8:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- To satisfy a specific m68 compile configuration, I moved the 'struct
bus_dma_region; definition out of #ifdef CONFIG_HAS_DMA and also defined
three inline functions for !CONFIG_HAS_DMA (kernel test robot).
-- The sunXi drivers -- suc4i_csi, sun6i_csi, cedrus_hw -- set
a pfn_offset outside of_dma_configure() but the code offers no
insight on the size of the translation window. V7 had me using
SIZE_MAX as the size. I have since contacted the sunXi maintainer and
he said that using a size of SZ_4G would cover sunXi configurations.
v7:
Commit: "device core: Introduce DMA range map, supplanting ..."
-- remove second kcalloc/copy in device.c (AndyS)
-- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS)
-- indentation, sizeof(struct ...) => sizeof(*r) (AndyS)
-- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS)
-- Fixed compile error in "sun6i_csi.c" (kernel test robot)
Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller"
-- correct name of function in the commit msg (SergeiS)
v6:
Commit "device core: Introduce DMA range map":
-- of_dma_get_range() now takes a single argument and returns either
NULL, a valid map, or an ERR_PTR. (Robin)
-- offsets are no longer a PFN value but an actual address. (Robin)
-- the bus_dma_region struct stores the range size instead of
the cpu_end and pci_end values. (Robin)
-- devices that were setting a single offset with no boundaries
have been modified to have boundaries; in a few places
where this information was unavilable a /* FIXME: ... */
comment was added. (Robin)
-- dma_attach_offset_range() can be called when an offset
map already exists; if it's range is already present
nothing is done and success is returned. (Robin)
All commits:
-- Man name/style/corrections/etc changed (Bjorn)
-- rebase to Torvalds master
v5:
Commit "device core: Introduce multiple dma pfn offsets"
-- in of/address.c: "map_size = 0" => "*map_size = 0"
-- use kcalloc instead of kzalloc (AndyS)
-- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
Commit "PCI: brcmstb: Set internal memory viewport sizes"
-- now gives error on missing dma-ranges property.
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- removed "Allof:" from brcm,scb-sizes definition (RobH)
All Commits:
-- indentation style, use max chars 100 (AndyS)
-- rebased to torvalds master
v4:
Commit "device core: Introduce multiple dma pfn offsets"
-- of_dma_get_range() does not take a dev param but instead
takes two "out" params: map and map_size. We do this so
that the code that parses dma-ranges is separate from
the code that modifies 'dev'. (Nicolas)
-- the separate case of having a single pfn offset has
been removed and is now processed by going through the
map array. (Nicolas)
-- move attach_uniform_dma_pfn_offset() from of/address.c to
dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
-- devm_kcalloc => devm_kzalloc (DanC)
-- add/fix assignment to dev->dma_pfn_offset_map for func
attach_uniform_dma_pfn_offset() (DanC, Nicolas)
-- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
-- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
-- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
-- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
Commit "of: Include a dev param in of_dma_get_range()"
-- this commit was sqaushed with "device core: Introduce ..."
v3:
[PATCH RESEND v10 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.
of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code. These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
---
arch/arm/include/asm/dma-mapping.h| 10 +--
arch/arm/mach-keystone/keystone.c | 17 +++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 +--
arch/sh/kernel/dma-coherent.c | 15 ++--
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 5 +-
drivers/base/core.c | 2 +
drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 4 +-
drivers/of/address.c | 72 +--
drivers/of/device.c | 43 ++-
drivers/of/of_private.h | 10 +--
drivers/of/unittest.c | 31 +---
drivers/remoteproc/remoteproc_core.c | 8 ++-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 7 +-
drivers/usb/core/message.c| 9 ++-
drivers/usb/core/usb.c| 7 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 8 +--
include/linux/dma-mapping.h | 36 ++
kernel/dma/coherent.c | 10 +--
kernel/dma/mapping.c | 65 +
24 files changed, 269 insertions(+), 122 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..2405afeb7957 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,11 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev) {
+ phys_addr_t paddr = PFN_PHYS(pfn);
+
+ pfn -= (dma_offset_from_phys_addr(dev, paddr) >> PAGE_SHIFT);
+ }
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -45,8 +48,7 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
unsigned long pfn = __bus_to_pfn(addr);
if (dev)
- pfn += dev->dma_pfn_offset;
-
+ pfn += (dma_offset_from_dma_addr(dev, addr) >> PAGE_SHIFT);
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..78808942ad1c 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,6 @@
#include "keystone.h"
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
static int keystone_platform_notifier(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_set_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+ dev_err(dev, "set dma_offset%08llx%s\n",
+ KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
@@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
static void __init keystone_init(void)
{
- if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
- keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
- KEYSTONE_LOW_PHYS_START);
+ if
[PATCH v3 0/2] Add configurable handler to execute a compound action
This is a follow-up of this thread: https://www.spinics.net/lists/linux-input/msg68446.html It only touches DRM (dri-devel) in such a way that it changes the help message of sysrq_drm_fb_helper_restore_op, otherwise it is unrelated to DRM. Patch 2/2 adds a configurable handler to execute a compound action. Userland might want to execute e.g. 'w' (show blocked tasks), followed by 's' (sync), followed by 1000 ms delay and then followed by 'c' (crash) upon a single magic SysRq. Or one might want to execute the famous "Raising Elephants Is So Utterly Boring" action. This patch adds a configurable handler, triggered with 'C', for this exact purpose. The user specifies the composition of the compound action using syntax similar to getopt, where each letter corresponds to an individual action and a colon followed by a number corresponds to a delay of that many milliseconds, e.g.: ws:1000c or r:100eis:1000ub An example of userspace that wants to perform a compound action is Chrome OS, where SysRq-X (pressed for the second time within a certain time period from the first time) causes showing the locked tasks, syncing, waiting a 1000 ms delay and crashing the system. Since all the slots in the sysrq_key_table[] are already taken or reserved, patch 1/2 extends it to cover also capital letter versions. v2..v3: - eliminated compile error in !CONFIG_INPUT case (kernel test robot) v1..v2: - used toupper() instead of opencoding it (Jiri Slaby) - updated help message of sysrq_drm_fb_helper_restore_op (Jiri Slaby) - used unsigned int for specifying delays (Jiri Slaby) - improved printed messages formatting (Jiri Slaby) Andrzej Pietrasiewicz (2): tty/sysrq: Extend the sysrq_key_table to cover capital letters tty/sysrq: Add configurable handler to execute a compound action Documentation/admin-guide/sysrq.rst | 11 +++ drivers/gpu/drm/drm_fb_helper.c | 2 +- drivers/tty/sysrq.c | 129 +++- include/linux/sysrq.h | 1 + 4 files changed, 140 insertions(+), 3 deletions(-) base-commit: 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5 -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] tty/sysrq: Add configurable handler to execute a compound action
Userland might want to execute e.g. 'w' (show blocked tasks), followed
by 's' (sync), followed by 1000 ms delay and then followed by 'c' (crash)
upon a single magic SysRq. Or one might want to execute the famous "Raising
Elephants Is So Utterly Boring" action. This patch adds a configurable
handler, triggered with 'C', for this exact purpose. The user specifies the
composition of the compound action using syntax similar to getopt, where
each letter corresponds to an individual action and a colon followed by a
number corresponds to a delay of that many milliseconds, e.g.:
ws:1000c
or
r:100eis:1000ub
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/admin-guide/sysrq.rst | 9
drivers/tty/sysrq.c | 82 -
include/linux/sysrq.h | 1 +
3 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/sysrq.rst
b/Documentation/admin-guide/sysrq.rst
index 67dfa4c29093..80bdd8bf9636 100644
--- a/Documentation/admin-guide/sysrq.rst
+++ b/Documentation/admin-guide/sysrq.rst
@@ -32,6 +32,7 @@ to 1. Here is the list of possible values in
/proc/sys/kernel/sysrq:
64 = 0x40 - enable signalling of processes (term, kill, oom-kill)
128 = 0x80 - allow reboot/poweroff
256 = 0x100 - allow nicing of all RT tasks
+512 = 0x200 - allow compound action
You can set the value in the file by the following command::
@@ -148,6 +149,14 @@ CommandFunction
``z`` Dump the ftrace buffer
+``C`` Execute a predefined, compound action. The action is defined with
+ sysrq.sysrq_compound_action module parameter, whose value contains
known
+ command keys (except ``C`` to prevent recursion). The command keys
can
+ be optionally followed by a colon and a number of milliseconds to
wait
+ after executing the last action. For example:
+
+ sysrq.sysrq_compound_action=r:100eis:1000ub
+
``0``-``9`` Sets the console log level, controlling which kernel messages
will be printed to your console. (``0``, for example would make
it so that only emergency messages like PANICs or OOPSes would
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 959f9e121cc6..e4ddea87c6db 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -438,6 +439,15 @@ static const struct sysrq_key_op sysrq_unrt_op = {
.enable_mask= SYSRQ_ENABLE_RTNICE,
};
+static void sysrq_action_compound(int key);
+
+static struct sysrq_key_op sysrq_action_compound_op = {
+ .handler= sysrq_action_compound,
+ .help_msg = "execute-compound-action(C)",
+ .action_msg = "Execute compound action",
+ .enable_mask= SYSRQ_ENABLE_COMPOUND,
+};
+
/* Key Operations table and lock */
static DEFINE_SPINLOCK(sysrq_key_table_lock);
@@ -500,7 +510,7 @@ static const struct sysrq_key_op *sysrq_key_table[62] = {
_ftrace_dump_op, /* z */
NULL, /* A */
NULL, /* B */
- NULL, /* C */
+ _action_compound_op, /* C */
NULL, /* D */
NULL, /* E */
NULL, /* F */
@@ -633,6 +643,7 @@ EXPORT_SYMBOL(handle_sysrq);
#ifdef CONFIG_INPUT
static int sysrq_reset_downtime_ms;
+static char *sysrq_compound_action;
/* Simple translation table for the SysRq keys */
static const unsigned char sysrq_xlate[KEY_CNT] =
@@ -786,6 +797,62 @@ static void sysrq_of_get_keyreset_config(void)
{
}
#endif
+#define SYSRQ_COMPOUND_ACTION_VALIDATE 0
+#define SYSRQ_COMPOUND_ACTION_RUN 1
+
+static int sysrq_process_compound_action(int pass)
+{
+ const char *action = sysrq_compound_action;
+ const struct sysrq_key_op *op_p;
+ int ret;
+ unsigned int delay;
+
+ while (*action) {
+ op_p = __sysrq_get_key_op(*action);
+ if (!op_p)
+ return -EINVAL;
+
+ /* Don't allow calling ourselves recursively */
+ if (op_p == _action_compound_op)
+ return -EINVAL;
+
+ if (pass == SYSRQ_COMPOUND_ACTION_RUN)
+ __handle_sysrq(*action, false);
+
+ if (*++action == ':') {
+ ret = sscanf(action++, ":%u", );
+ if (ret < 1) /* we want at least ":[0-9]" => 1 item */
+ return -EINVAL;
+
+ while (*action >= '0' && *action <= '9')
+ ++action;
+ if (pass == SYSRQ_COMPOUND_ACTION_RUN)
+ mdelay(delay);
+ }
+ }
+
+ return 0;
+}
+
+static void sysrq_action_compound(int
[PATCH v3 1/2] tty/sysrq: Extend the sysrq_key_table to cover capital letters
All slots in sysrq_key_table[] are either used, reserved or at least
commented with their intended use. This patch adds capital letter versions
available, which means adding 26 more entries.
For already existing SysRq operations the user presses Alt-SysRq-, and
for the newly added ones Alt-Shift-SysRq-.
Signed-off-by: Andrzej Pietrasiewicz
---
Documentation/admin-guide/sysrq.rst | 2 ++
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/tty/sysrq.c | 49 +++--
3 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/sysrq.rst
b/Documentation/admin-guide/sysrq.rst
index e6424d8c5846..67dfa4c29093 100644
--- a/Documentation/admin-guide/sysrq.rst
+++ b/Documentation/admin-guide/sysrq.rst
@@ -79,6 +79,8 @@ On all
echo t > /proc/sysrq-trigger
+The :kbd:`` is case sensitive.
+
What are the 'command' keys?
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8697554ccd41..1543d9d10970 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -325,7 +325,7 @@ static void drm_fb_helper_sysrq(int dummy1)
static const struct sysrq_key_op sysrq_drm_fb_helper_restore_op = {
.handler = drm_fb_helper_sysrq,
- .help_msg = "force-fb(V)",
+ .help_msg = "force-fb(v)",
.action_msg = "Restore framebuffer console",
};
#else
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index a8e39b2cdd55..959f9e121cc6 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -440,7 +441,7 @@ static const struct sysrq_key_op sysrq_unrt_op = {
/* Key Operations table and lock */
static DEFINE_SPINLOCK(sysrq_key_table_lock);
-static const struct sysrq_key_op *sysrq_key_table[36] = {
+static const struct sysrq_key_op *sysrq_key_table[62] = {
_loglevel_op, /* 0 */
_loglevel_op, /* 1 */
_loglevel_op, /* 2 */
@@ -497,6 +498,32 @@ static const struct sysrq_key_op *sysrq_key_table[36] = {
/* y: May be registered on sparc64 for global register dump */
NULL, /* y */
_ftrace_dump_op, /* z */
+ NULL, /* A */
+ NULL, /* B */
+ NULL, /* C */
+ NULL, /* D */
+ NULL, /* E */
+ NULL, /* F */
+ NULL, /* G */
+ NULL, /* H */
+ NULL, /* I */
+ NULL, /* J */
+ NULL, /* K */
+ NULL, /* L */
+ NULL, /* M */
+ NULL, /* N */
+ NULL, /* O */
+ NULL, /* P */
+ NULL, /* Q */
+ NULL, /* R */
+ NULL, /* S */
+ NULL, /* T */
+ NULL, /* U */
+ NULL, /* V */
+ NULL, /* W */
+ NULL, /* X */
+ NULL, /* Y */
+ NULL, /* Z */
};
/* key2index calculation, -1 on invalid index */
@@ -508,6 +535,8 @@ static int sysrq_key_table_key2index(int key)
retval = key - '0';
else if ((key >= 'a') && (key <= 'z'))
retval = key + 10 - 'a';
+ else if ((key >= 'A') && (key <= 'Z'))
+ retval = key + 36 - 'A';
else
retval = -1;
return retval;
@@ -621,6 +650,8 @@ struct sysrq_state {
unsigned long key_down[BITS_TO_LONGS(KEY_CNT)];
unsigned int alt;
unsigned int alt_use;
+ unsigned int shift;
+ unsigned int shift_use;
bool active;
bool need_reinject;
bool reinjecting;
@@ -805,10 +836,20 @@ static bool sysrq_handle_keypress(struct sysrq_state
*sysrq,
}
break;
+ case KEY_LEFTSHIFT:
+ case KEY_RIGHTSHIFT:
+ if (!value)
+ sysrq->shift = KEY_RESERVED;
+ else if (value != 2)
+ sysrq->shift = code;
+ break;
+
case KEY_SYSRQ:
if (value == 1 && sysrq->alt != KEY_RESERVED) {
sysrq->active = true;
sysrq->alt_use = sysrq->alt;
+ /* either RESERVED (for released) or actual code */
+ sysrq->shift_use = sysrq->shift;
/*
Re: [PATCH 0/3] Chunk Heap Support on DMA-HEAP
Hi, On Tue, Aug 18, 2020 at 05:04:12PM +0900, Hyesoo Yu wrote: > These patch series to introduce a new dma heap, chunk heap. > That heap is needed for special HW that requires bulk allocation of > fixed high order pages. For example, 64MB dma-buf pages are made up > to fixed order-4 pages * 1024. > > The chunk heap uses alloc_pages_bulk to allocate high order page. > https://lore.kernel.org/linux-mm/20200814173131.2803002-1-minc...@kernel.org > > The chunk heap is registered by device tree with alignment and memory node > of contiguous memory allocator(CMA). Alignment defines chunk page size. > For example, alignment 0x1_ means chunk page size is 64KB. > The phandle to memory node indicates contiguous memory allocator(CMA). > If device node doesn't have cma, the registration of chunk heap fails. This reminds me of an ion heap developed at Arm several years ago: https://git.linaro.org/landing-teams/working/arm/kernel.git/tree/drivers/staging/android/ion/ion_compound_page.c Some more descriptive text here: https://github.com/ARM-software/CPA It maintains a pool of high-order pages with a worker thread to attempt compaction and allocation to keep the pool filled, with high and low watermarks to trigger freeing/allocating of chunks. It implements a shrinker to allow the system to reclaim the pool under high memory pressure. Is maintaining a pool something you considered? From the alloc_pages_bulk thread it sounds like you want to allocate 300M at a time, so I expect if you tuned the pool size to match that it could work quite well. That implementation isn't using a CMA region, but a similar approach could definitely be applied. Thanks, -Brian > > The patchset includes the following: > - export dma-heap API to register kernel module dma heap. > - add chunk heap implementation. > - document of device tree to register chunk heap > > Hyesoo Yu (3): > dma-buf: add missing EXPORT_SYMBOL_GPL() for dma heaps > dma-buf: heaps: add chunk heap to dmabuf heaps > dma-heap: Devicetree binding for chunk heap > > .../devicetree/bindings/dma-buf/chunk_heap.yaml| 46 + > drivers/dma-buf/dma-heap.c | 2 + > drivers/dma-buf/heaps/Kconfig | 9 + > drivers/dma-buf/heaps/Makefile | 1 + > drivers/dma-buf/heaps/chunk_heap.c | 222 > + > drivers/dma-buf/heaps/heap-helpers.c | 2 + > 6 files changed, 282 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma-buf/chunk_heap.yaml > create mode 100644 drivers/dma-buf/heaps/chunk_heap.c > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon 0/4] Use drv_err instead of DRM_ERROR in hibmc driver
On Tue, Aug 18, 2020 at 02:51:40PM +0800, Tian Tao wrote: > patch #1 is using the drv_err instead of DRM_ERROR in hibmc_ttm.c > patch #2 is using the drv_err instead of DRM_ERROR in hibmc_drm_vdac.c > patch #3 is using the drv_err and drm_dbg_atomic instead of DRM_ERROR > and DRM_DEBUG_ATOMIC in hibmc_drm_de.c > patch #4 is using the drv_err and drm_warn instead of DRM_ERROR and > DRM_WARN in hibmc_drm_drv.c > > Tian Tao (4): > drm/hisilicon: Use drv_err instead of DRM_ERROR in hibmc_ttm > drm/hisilicon: Use drv_err instead of DRM_ERROR in hibmc_drm_vdac > drm/hisilicon: Use drv_err instead of DRM_ERROR in hibmc_drm_de > drm/hisilicon: Use drv_err instead of DRM_ERROR in hibmc_drm_drv Hi Tian. Code looks fine, but subjects says "drv_err", where code uses "drm_err". This confused me, mind fixing the $subject before applying Sam > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 14 +++--- > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 24 > > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 4 ++-- > drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +- > 4 files changed, 22 insertions(+), 22 deletions(-) > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dma-buf: heaps: add chunk heap to dmabuf heaps
On 18.08.20 10:04, Hyesoo Yu wrote:
> This patch adds support for a chunk heap that allows for buffers
> that are made up of a list of fixed size chunks taken from a CMA.
> Chunk sizes are configuratd when the heaps are created.
>
> Signed-off-by: Hyesoo Yu
> ---
> drivers/dma-buf/heaps/Kconfig | 9 ++
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/chunk_heap.c | 222
> +
> 3 files changed, 232 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/chunk_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06..98552fa 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -12,3 +12,12 @@ config DMABUF_HEAPS_CMA
> Choose this option to enable dma-buf CMA heap. This heap is backed
> by the Contiguous Memory Allocator (CMA). If your system has these
> regions, you should say Y here.
> +
> +config DMABUF_HEAPS_CHUNK
> + tristate "DMA-BUF CHUNK Heap"
> + depends on DMABUF_HEAPS && DMA_CMA
> + help
> + Choose this option to enable dma-buf CHUNK heap. This heap is backed
> + by the Contiguous Memory Allocator (CMA) and allocate the buffers that
> + are made up to a list of fixed size chunks tasken from CMA. Chunk
> sizes
> + are configurated when the heaps are created.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 6e54cde..3b2a0986 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -2,3 +2,4 @@
> obj-y+= heap-helpers.o
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_CHUNK) += chunk_heap.o
> diff --git a/drivers/dma-buf/heaps/chunk_heap.c
> b/drivers/dma-buf/heaps/chunk_heap.c
> new file mode 100644
> index 000..1eefaec
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/chunk_heap.c
> @@ -0,0 +1,222 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ION Memory Allocator chunk heap exporter
> + *
> + * Copyright (c) 2020 Samsung Electronics Co., Ltd.
> + * Author: for Samsung Electronics.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "heap-helpers.h"
> +
> +struct chunk_heap {
> + struct dma_heap *heap;
> + phys_addr_t base;
> + phys_addr_t size;
> + atomic_t cur_pageblock_idx;
> + unsigned int max_num_pageblocks;
> + unsigned int order;
> +};
> +
> +static void chunk_heap_free(struct heap_helper_buffer *buffer)
> +{
> + struct chunk_heap *chunk_heap = dma_heap_get_drvdata(buffer->heap);
> + pgoff_t pg;
> +
> + for (pg = 0; pg < buffer->pagecount; pg++)
> + __free_pages(buffer->pages[pg], chunk_heap->order);
> + kvfree(buffer->pages);
> + kfree(buffer);
> +}
> +
> +static inline unsigned long chunk_get_next_pfn(struct chunk_heap *chunk_heap)
> +{
> + unsigned long i = atomic_inc_return(_heap->cur_pageblock_idx) %
> + chunk_heap->max_num_pageblocks;
> +
> + return PHYS_PFN(chunk_heap->base) + i * pageblock_nr_pages;
> +}
> +
> +static int chunk_alloc_pages(struct chunk_heap *chunk_heap, struct page
> **pages,
> + unsigned int order, unsigned int count)
> +{
> + unsigned long base;
> + unsigned int i = 0, nr_block = 0, nr_elem, ret;
> +
> + while (count) {
> + /*
> + * If the number of scanned page block is the same as max block,
> + * the tries of allocation fails.
> + */
> + if (nr_block++ == chunk_heap->max_num_pageblocks) {
> + ret = -ENOMEM;
> + goto err_bulk;
> + }
> + base = chunk_get_next_pfn(chunk_heap);
> + nr_elem = min_t(unsigned int, count, pageblock_nr_pages >>
> order);
> + ret = alloc_pages_bulk(base, base + pageblock_nr_pages,
> MIGRATE_CMA,
> +GFP_KERNEL, order, nr_elem, pages + i);
So you are bypassing the complete cma allocator here. This all smells
like a complete hack to me. No, I don't think this is the right way to
support (or rather speed up allocations for) special, weird hardware.
--
Thanks,
David / dhildenb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/20] drm/msm/a6xx: Add support for per-instance pagetables
Reviewed-by: Akhil P Oommen
On 8/18/2020 3:31 AM, Rob Clark wrote:
From: Jordan Crouse
Add support for using per-instance pagetables if all the dependencies are
available.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 63 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
3 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 5eabb0109577..d7ad6c78d787 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -81,6 +81,49 @@ static void get_stats_counter(struct msm_ringbuffer *ring,
u32 counter,
OUT_RING(ring, upper_32_bits(iova));
}
+static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
+ struct msm_ringbuffer *ring, struct msm_file_private *ctx)
+{
+ phys_addr_t ttbr;
+ u32 asid;
+ u64 memptr = rbmemptr(ring, ttbr0);
+
+ if (ctx == a6xx_gpu->cur_ctx)
+ return;
+
+ if (msm_iommu_pagetable_params(ctx->aspace->mmu, , ))
+ return;
+
+ /* Execute the table update */
+ OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
+ OUT_RING(ring, CP_SMMU_TABLE_UPDATE_0_TTBR0_LO(lower_32_bits(ttbr)));
+
+ OUT_RING(ring,
+ CP_SMMU_TABLE_UPDATE_1_TTBR0_HI(upper_32_bits(ttbr)) |
+ CP_SMMU_TABLE_UPDATE_1_ASID(asid));
+ OUT_RING(ring, CP_SMMU_TABLE_UPDATE_2_CONTEXTIDR(0));
+ OUT_RING(ring, CP_SMMU_TABLE_UPDATE_3_CONTEXTBANK(0));
+
+ /*
+* Write the new TTBR0 to the memstore. This is good for debugging.
+*/
+ OUT_PKT7(ring, CP_MEM_WRITE, 4);
+ OUT_RING(ring, CP_MEM_WRITE_0_ADDR_LO(lower_32_bits(memptr)));
+ OUT_RING(ring, CP_MEM_WRITE_1_ADDR_HI(upper_32_bits(memptr)));
+ OUT_RING(ring, lower_32_bits(ttbr));
+ OUT_RING(ring, (asid << 16) | upper_32_bits(ttbr));
+
+ /*
+* And finally, trigger a uche flush to be sure there isn't anything
+* lingering in that part of the GPU
+*/
+
+ OUT_PKT7(ring, CP_EVENT_WRITE, 1);
+ OUT_RING(ring, 0x31);
+
+ a6xx_gpu->cur_ctx = ctx;
+}
+
static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
{
unsigned int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
@@ -90,6 +133,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
struct msm_ringbuffer *ring = submit->ring;
unsigned int i;
+ a6xx_set_pagetable(a6xx_gpu, ring, submit->queue->ctx);
+
get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
rbmemptr_stats(ring, index, cpcycles_start));
@@ -696,6 +741,8 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
/* Always come up on rb 0 */
a6xx_gpu->cur_ring = gpu->rb[0];
+ a6xx_gpu->cur_ctx = NULL;
+
/* Enable the SQE_to start the CP engine */
gpu_write(gpu, REG_A6XX_CP_SQE_CNTL, 1);
@@ -1008,6 +1055,21 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
return (unsigned long)busy_time;
}
+static struct msm_gem_address_space *
+a6xx_create_private_address_space(struct msm_gpu *gpu)
+{
+ struct msm_gem_address_space *aspace = NULL;
+ struct msm_mmu *mmu;
+
+ mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
+
+ if (!IS_ERR(mmu))
+ aspace = msm_gem_address_space_create(mmu,
+ "gpu", 0x1ULL, 0x1ULL);
+
+ return aspace;
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -1031,6 +1093,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_state_put = a6xx_gpu_state_put,
#endif
.create_address_space = adreno_iommu_create_address_space,
+ .create_private_address_space =
a6xx_create_private_address_space,
},
.get_timestamp = a6xx_get_timestamp,
};
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 03ba60d5b07f..da22d7549d9b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -19,6 +19,7 @@ struct a6xx_gpu {
uint64_t sqe_iova;
struct msm_ringbuffer *cur_ring;
+ struct msm_file_private *cur_ctx;
struct a6xx_gmu gmu;
};
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h
b/drivers/gpu/drm/msm/msm_ringbuffer.h
index 7764373d0ed2..0987d6bf848c 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.h
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
@@ -31,6 +31,7 @@ struct msm_rbmemptrs {
volatile uint32_t fence;
volatile struct msm_gpu_submit_stats stats[MSM_GPU_SUBMIT_STATS_COUNT];
+ volatile u64 ttbr0;
};
struct msm_ringbuffer {
___
dri-devel mailing list
Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hi Laurent,
On Fri, Jun 12, 2020 at 5:51 PM Laurent Pinchart
wrote:
> On Fri, Jun 12, 2020 at 05:36:07PM +0200, Eugeniu Rosca wrote:
> > On Fri, Jun 12, 2020 at 06:10:05PM +0300, Laurent Pinchart wrote:
> > > On Fri, Jun 12, 2020 at 05:00:32PM +0200, Jacopo Mondi wrote:
> > > > On Tue, Jun 09, 2020 at 04:29:59PM +0200, Eugeniu Rosca wrote:
> > > > > On Sun, Jun 07, 2020 at 05:41:58AM +0300, Laurent Pinchart wrote:
> > > > > > Note that the CMM driver is controlled by the DU driver. As the DU
> > > > > > driver will reenable the display during resume, it will call
> > > > > > rcar_du_cmm_setup() at resume time, which will reprogram the CMM.
> > > > > > There
> > > > > > should thus be no need for manual suspend/resume handling in the
> > > > > > CMM as
> > > > > > far as I can tell, but we need to ensure that the CMM is suspended
> > > > > > before and resumed after the DU. I believe this could be implemented
> > > > > > using device links.
> > > > >
> > > > > Based on below quote [*] from Jacopo's commit [**], isn't the device
> > > > > link relationship already in place?
> > > >
> > > > Yes, it's in place already.
> > > >
> > > > I added pm_ops to cmm just to be able to printout when suspend/resume
> > > > happens and the sequence is what comment [*] reports
> > > >
> > > > [ 222.909002] rcar_du_pm_suspend:505
> > > > [ 223.145497] rcar_cmm_pm_suspend:193
> > > >
> > > > [ 223.208053] rcar_cmm_pm_resume:200
> > > > [ 223.460094] rcar_du_pm_resume:513
> > > >
> > > > However, Laurent mentioned that in his comment here that he expects
> > > > the opposite sequence to happen (CMM to suspend before and resume after
> > > > DU).
> > > >
> > > > I still think what is implemented is correct:
> > > > - CMM is suspended after DU: when CMM is suspended, DU is not feeding
> > > > it with data
> > > > - CMM is resumed before: once DU restart operations CMM is ready to
> > > > receive data.
> > > >
> > > > Laurent, what do you think ?
> > >
> > > I think I shouldn't have written the previous e-mail in the middle of
> > > the night :-) Suspending CMM after DU is obviously correct.
> >
> > Thanks to Renesas team (kudos to Gotthard and Michael), we've
> > figured out that below sequence of clock handling (happening during
> > concurrent suspend and HDMI display unplug) leads to SoC lockup:
> >
> > cmm1 OFF (caused by HDMI unplug)
> > x21-clock OFF (caused by HDMI unplug)
> > du1 OFF (caused by HDMI unplug)
> > cmm1 ON (caused by suspend to ram, as preparation for CMM register save)
> > # Freeze happens
> >
> > That seems to be explained by Chapter 35A.4.3 "Restriction of enabling
> > clock signal of the CMM" of HW User's manual (Rev.2.00 Jul 2019):
> >
> > -8<-
> > When the clock signal of the CMM is enabled (RMSTPCR7.CMMn or
> > SMSTPCR7.CMMn = 0), the clock signal of the DU should be also enabled
> > (RMSTPCR7.DUn or SMSTPCR7.DUn = 0).
> > -8<-
> >
> > So, the lesson learned from the above is: do not enable the CMMi clock
> > while the DUi clock is disabled. I expect this to also potentially
> > give some input w.r.t. what to suspend/resume first, CMM or DU.
>
> This may be an ugly one. The DU driver needs to disable the CMM when
> suspending, and enabling the CMM when resuming. To do so, it calls
> functions of the CMM driver, and those functions access CMM registers.
> We can't do so while the CMM is suspended, so the DU has to suspend
> before the CMM, and resume after the CMM.
>
> On the other hand, as you state here, we need to make sure the CMM clock
> is disabled first. The CMM thus needs to suspend before the DU, and
> resume after the DU.
>
> Those are conflicting requirements.
>
> One option could be to use the .suspend_late() and .resume_early() PM
> operations for the DU, to turn the DU clock off late and turn it back on
> early. Integrating it with the DRM suspend/resume helpers will likely be
> complicated though. I wonder if we could find a more elegant solution.
>
> I the above sequence, you list "cmm1 ON" as a preparation for CMM
> register save. We don't need to save any register, the CMM driver has no
> .suspend() handler. The PM core should really skip waking up the device
> at that point (I recall complaining about the spurious wake ups at
> suspend time a while ago, but that neevr got addressed). Geert, any
> opinion on that ?
If there are issues with the PM core, please bring it up with the PM people.
If there's a (too) close integration of the CMM and the DU, perhaps the
CMM should list the DU module clock in its clocks property, too?
We have a similar construction for USB (module clocks 703 and 704).
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
Re: [PATCH 0/4] *** SUBJECT HERE ***
On Tue, Aug 18, 2020 at 12:17:08PM +0300, Tomer Samara wrote: > *** BLURB HERE *** Really? And your subject line could use some work too :( ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/virtio: set max_segment
When initializing call virtio_max_dma_size() to figure the scatter list limit. Needed to make virtio-gpu work properly with SEV. v2: place max_segment in drm driver not gem object. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_kms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index bf060c69850f..5a4364c00fae 100644 --- a/drivers/gpu/drm/virtio/virtgpu_kms.c +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c @@ -114,6 +114,7 @@ int virtio_gpu_init(struct drm_device *dev) vgdev->ddev = dev; dev->dev_private = vgdev; + dev->max_segment = virtio_max_dma_size(vgdev->vdev); vgdev->vdev = dev_to_virtio(dev->dev); vgdev->dev = dev->dev; -- 2.18.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm: allow limiting the scatter list size.
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to drm driver and pass it to
drm_prime_pages_to_sg() calls in drivers and helpers.
v2: place max_segment in drm driver not gem object.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_device.h| 8
include/drm/drm_prime.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++-
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
drivers/gpu/drm/drm_prime.c | 10 +++---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++-
drivers/gpu/drm/msm/msm_gem.c | 3 ++-
drivers/gpu/drm/msm/msm_gem_prime.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_prime.c | 3 ++-
drivers/gpu/drm/radeon/radeon_prime.c | 3 ++-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 6 --
drivers/gpu/drm/tegra/gem.c | 3 ++-
drivers/gpu/drm/vgem/vgem_drv.c | 3 ++-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++-
15 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 0988351d743c..47cb547a8115 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -329,6 +329,14 @@ struct drm_device {
*/
struct drm_fb_helper *fb_helper;
+ /**
+* @max_segment:
+*
+* Max size for scatter list segments. When unset the default
+* (SCATTERLIST_MAX_SEGMENT) is used.
+*/
+ size_t max_segment;
+
/* Everything below here is for legacy driver, never use! */
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 9af7422b44cf..2c3689435cb4 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -88,7 +88,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr);
int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
-struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
nr_pages);
+struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
nr_pages,
+ size_t max_segment);
struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
int flags);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 519ce4427fce..8f6a647757e7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -303,7 +303,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
switch (bo->tbo.mem.mem_type) {
case TTM_PL_TT:
sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
- bo->tbo.num_pages);
+ bo->tbo.num_pages,
+ obj->dev->max_segment);
if (IS_ERR(sgt))
return sgt;
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4b7cfbac4daa..8f47b41b0b2f 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -656,7 +656,8 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct
drm_gem_object *obj)
WARN_ON(shmem->base.import_attach);
- return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
+ return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT,
+obj->dev->max_segment);
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7c14b5..27c783fd6633 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -802,7 +802,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
*
* This is useful for implementing _gem_object_funcs.get_sg_table.
*/
-struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
nr_pages)
+struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int
nr_pages,
+ size_t max_segment)
{
struct sg_table *sg = NULL;
int ret;
@@ -813,8 +814,11 @@ struct sg_table *drm_prime_pages_to_sg(struct page
**pages, unsigned int nr_page
goto out;
}
- ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
- nr_pages << PAGE_SHIFT, GFP_KERNEL);
+ if (max_segment == 0 || max_segment > SCATTERLIST_MAX_SEGMENT)
+ max_segment = SCATTERLIST_MAX_SEGMENT;
+ ret
[PATCH v2 0/2] drm: fix virtio-gpu + sev
virtio-gpu must make sure scatter list segments are not too big. Gerd Hoffmann (2): drm: allow limiting the scatter list size. drm/virtio: set max_segment include/drm/drm_device.h| 8 include/drm/drm_prime.h | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 3 ++- drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++- drivers/gpu/drm/drm_prime.c | 10 +++--- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++- drivers/gpu/drm/msm/msm_gem.c | 3 ++- drivers/gpu/drm/msm/msm_gem_prime.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_prime.c | 3 ++- drivers/gpu/drm/radeon/radeon_prime.c | 3 ++- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 6 -- drivers/gpu/drm/tegra/gem.c | 3 ++- drivers/gpu/drm/vgem/vgem_drv.c | 3 ++- drivers/gpu/drm/virtio/virtgpu_kms.c| 1 + drivers/gpu/drm/xen/xen_drm_front_gem.c | 3 ++- 16 files changed, 44 insertions(+), 17 deletions(-) -- 2.18.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: allow limiting the scatter list size.
Hi, > > > I'm missing an explanation why this should be useful (it certainly is). > > virtio-gpu needs this to work properly with SEV (see patch 2/2 of this > > series). > > Yeah, that's the problem patch 2/2 never showed up here :) The list should have everything. Your inbox probably has 1/2 only because 2/2 doesn't touch amd code and 'git send-email' evaluates sendemail.cccmd (pointing to get_maintainer.pl) for each patch individually. I've found this behavior confusing at times before. Is there some way to send the whole series to everybody? Or at least the cover letter? The git-send-email manpage doesn't give a clue :( > > Placing it in drm_device instead would indeed work for virtio-gpu, so I > > guess you are suggesting that instead? > > That is probably the best approach, yes. Ok, I'll go that route then. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] newport_con: make module's init & exit static using module_driver
The compiler complains that newport_console_init and
newport_console_exit are not declared:
drivers/video/console/newport_con.c:745:12: warning: no previous prototype
for 'newport_console_init'
drivers/video/console/newport_con.c:750:13: warning: no previous prototype
for 'newport_console_exit'
Here, it translates into: they should be marked static. Do so by
converting the simple un/registration to module_driver().
Signed-off-by: Jiri Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
---
drivers/video/console/newport_con.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/video/console/newport_con.c
b/drivers/video/console/newport_con.c
index 4d9110393479..0d0989040c58 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -751,18 +751,6 @@ static struct gio_driver newport_driver = {
.probe = newport_probe,
.remove = newport_remove,
};
-
-int __init newport_console_init(void)
-{
- return gio_register_driver(_driver);
-}
-
-void __exit newport_console_exit(void)
-{
- gio_unregister_driver(_driver);
-}
-
-module_init(newport_console_init);
-module_exit(newport_console_exit);
+module_driver(newport_driver, gio_register_driver, gio_unregister_driver);
MODULE_LICENSE("GPL");
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] newport_con: fix no return statement in newport_show_logo
When CONFIG_LOGO_SGI_CLUT224 is unset, newport_show_logo contains no return, despite it should return a pointer. Add one returning NULL to fix a compiler warning: drivers/video/console/newport_con.c: In function 'newport_show_logo': drivers/video/console/newport_con.c:132:1: warning: no return statement in function returning non-void Note that the caller expects NULL from the function already. Signed-off-by: Jiri Slaby Cc: Bartlomiej Zolnierkiewicz Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: linux-m...@vger.kernel.org --- drivers/video/console/newport_con.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/console/newport_con.c b/drivers/video/console/newport_con.c index 72f146d047d9..4d9110393479 100644 --- a/drivers/video/console/newport_con.c +++ b/drivers/video/console/newport_con.c @@ -131,6 +131,8 @@ static const struct linux_logo *newport_show_logo(void) npregs->go.hostrw0 = *data++ << 24; return logo; +#else + return NULL; #endif /* CONFIG_LOGO_SGI_CLUT224 */ } -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: allow limiting the scatter list size.
Am 18.08.20 um 10:27 schrieb Gerd Hoffmann: On Tue, Aug 18, 2020 at 09:57:59AM +0200, Christian König wrote: Am 18.08.20 um 09:48 schrieb Gerd Hoffmann: Add max_segment argument to drm_prime_pages_to_sg(). When set pass it through to the __sg_alloc_table_from_pages() call, otherwise use SCATTERLIST_MAX_SEGMENT. Also add max_segment field to gem objects and pass it to drm_prime_pages_to_sg() calls in drivers and helpers. Signed-off-by: Gerd Hoffmann I'm missing an explanation why this should be useful (it certainly is). virtio-gpu needs this to work properly with SEV (see patch 2/2 of this series). Yeah, that's the problem patch 2/2 never showed up here :) And the maximum segment size seems misplaced in the GEM object. This is usually a property of the device or even completely constant. Placing it in drm_device instead would indeed work for virtio-gpu, so I guess you are suggesting that instead? That is probably the best approach, yes. For Intel and AMD it could even be global/constant, but it certainly doesn't needs to be kept around for each buffer. Christian. take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
