[PATCH v2] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()
Some MIPI DSI panel drivers like 'raydium,rm68200' send
MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which
requires the MIPI DSI controller and PHY to be ready beforehand.
Without this patch, the nwl-dsi driver gets the MIPI DSI controller
and PHY ready in bridge_funcs->pre_enable(), which happens after
the panel_funcs->prepare(). So, this patch shifts the bridge operation
ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set().
This way, more MIPI DSI panels can connect to this nwl-dsi bridge.
Care is taken to make sure bridge_funcs->mode_set()/atomic_disable()
are called in pairs, which includes removing a check on unchanged HS
clock rate and forcing a full modeset when only connector's DPMS is
brought out of "Off" status.
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Cc: David Airlie
Cc: Daniel Vetter
Cc: Guido Günther
Cc: Robert Chiras
Cc: NXP Linux Team
Signed-off-by: Liu Ying
---
v1->v2:
* Fix commit message typo - s/unchange/unchanged/
drivers/gpu/drm/bridge/nwl-dsi.c | 86 +---
1 file changed, 46 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index be6bfc5..229f0b1 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
#include
@@ -661,7 +662,7 @@ static irqreturn_t nwl_dsi_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
-static int nwl_dsi_enable(struct nwl_dsi *dsi)
+static int nwl_dsi_mode_set(struct nwl_dsi *dsi)
{
struct device *dev = dsi->dev;
union phy_configure_opts *phy_cfg = >phy_cfg;
@@ -748,7 +749,9 @@ static int nwl_dsi_disable(struct nwl_dsi *dsi)
return 0;
}
-static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
+static void
+nwl_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
int ret;
@@ -809,17 +812,6 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi,
return 0;
}
-static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- /* At least LCDIF + NWL needs active high sync */
- adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
- adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
-
- return true;
-}
-
static enum drm_mode_status
nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_info *info,
@@ -837,6 +829,29 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
return MODE_OK;
}
+static int nwl_dsi_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
+
+ /* At least LCDIF + NWL needs active high sync */
+ adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
+ adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
+
+ /*
+* Do a full modeset if crtc_state->active is changed to be true.
+* This ensures our ->mode_set() is called to get the DSI controller
+* and the PHY ready to send DCS commands, when only the connector's
+* DPMS is brought out of "Off" status.
+*/
+ if (crtc_state->active_changed && crtc_state->active)
+ crtc_state->mode_changed = true;
+
+ return 0;
+}
+
static void
nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
@@ -852,13 +867,6 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
if (ret < 0)
return;
- /*
-* If hs clock is unchanged, we're all good - all parameters are
-* derived from it atm.
-*/
- if (new_cfg.mipi_dphy.hs_clk_rate == dsi->phy_cfg.mipi_dphy.hs_clk_rate)
- return;
-
phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n", phy_ref_rate);
/* Save the new desired phy config */
@@ -866,14 +874,8 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
memcpy(>mode, adjusted_mode, sizeof(dsi->mode));
drm_mode_debug_printmodeline(adjusted_mode);
-}
-static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge)
-{
- struct nwl_dsi *dsi = bridge_to_dsi(bridge);
- int ret;
-
-
RE: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe
On 2021/04/22 Lucas Stach wrote: > > But the timer of runtime_auto_suspend decide when enter runtime > > suspend rather than hardware, while transfer data size and transfer > > rate on IP bus decide when the dma interrupt happen. > > > But it isn't the hardware that decides to drop the rpm refcount to 0 and > starting the autosuspend timer, it's the driver. Yes, driver should keep rpm refcount never to 0 in such case. But I think that case Is a common case in dma cyclic with runtime_auto_suspend, so some dma driver also add pm_runtime_get_sync/ pm_runtime_put_autosuspend in interrupt handler like qcom/bam_dma.c for safe rather than only pm_runtime_mark_last_busy(). > > > Generally, we can call pm_runtime_get_sync(fsl_chan->dev)/ > > pm_runtime_mark_last_busy in interrupt handler to hope the > > runtime_auto_suspend timer expiry later than interrupt coming, but if > > the transfer data size is larger in cyclic and transfer rate is very > > slow like 115200 or lower on uart, the fix autosuspend timer > > 100ms/200ms maybe not enough, hence, runtime suspend may execute > > meanwhile the dma interrupt maybe triggered and caught by GIC(but > > interrupt handler prevent by spin_lock_irqsave in pm_suspend_timer_fn() ), > and then interrupt handler start to run after runtime suspend. > > If your driver code drops the rpm refcount to 0 and starts the autosuspend > timer while a cyclic transfer is still in flight this is clearly a bug. > Autosuspend is > not there to paper over driver bugs, but to amortize cost of actually > suspending and resuming the hardware. Your driver code must still work even > if the timeout is 0, i.e. the hardware is immediately suspended after you drop > the rpm refcount to 0. > > If you still have transfers queued/in-flight the driver code must keep a rpm > reference. Yes, that's what I said for fix before as below. 'I have a simple workaround that disable runtime suspend in issue_pending worker by calling pm_runtime_forbid() and then enable runtime auto suspend in dmaengine_terminate_all so that we could easily regard that edma channel is always in runtime resume between issue_pending and channel terminated and ignore the above interrupt handler/scu-pd limitation' ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/10] drm/amdgpu: Move kfd_mem_attach outside reservation
This is needed to avoid deadlocks with DMA buf import in the next patch.
Also move PT/PD validation out of kfd_mem_attach, that way the caller
can bo this unconditionally.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 75 +++
1 file changed, 44 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 7d25d886b98c..9eeedd0c7920 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -577,6 +577,34 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
}
}
+static int
+kfd_mem_attach_userptr(struct amdgpu_device *adev, struct kgd_mem *mem,
+ struct amdgpu_bo **bo)
+{
+ unsigned long bo_size = mem->bo->tbo.base.size;
+ struct drm_gem_object *gobj;
+ int ret;
+
+ ret = amdgpu_bo_reserve(mem->bo, false);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_gem_object_create(adev, bo_size, 1,
+ AMDGPU_GEM_DOMAIN_CPU,
+ 0, ttm_bo_type_sg,
+ mem->bo->tbo.base.resv,
+ );
+ if (ret)
+ return ret;
+
+ amdgpu_bo_unreserve(mem->bo);
+
+ *bo = gem_to_amdgpu_bo(gobj);
+ (*bo)->parent = amdgpu_bo_ref(mem->bo);
+
+ return 0;
+}
+
/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
@@ -598,7 +626,6 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
uint64_t va = mem->va;
struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
struct amdgpu_bo *bo[2] = {NULL, NULL};
- struct drm_gem_object *gobj;
int i, ret;
if (!va) {
@@ -632,15 +659,9 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
} else if (amdgpu_ttm_tt_get_usermm(mem->bo->tbo.ttm)) {
/* Create an SG BO to DMA-map userptrs on other GPUs */
attachment[i]->type = KFD_MEM_ATT_USERPTR;
- ret = amdgpu_gem_object_create(adev, bo_size, 1,
- AMDGPU_GEM_DOMAIN_CPU,
- 0, ttm_bo_type_sg,
- mem->bo->tbo.base.resv,
- );
+ ret = kfd_mem_attach_userptr(adev, mem, [i]);
if (ret)
goto unwind;
- bo[i] = gem_to_amdgpu_bo(gobj);
- bo[i]->parent = amdgpu_bo_ref(mem->bo);
} else {
/* FIXME: Need to DMA-map other BO types */
attachment[i]->type = KFD_MEM_ATT_SHARED;
@@ -665,13 +686,6 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
va += bo_size;
}
- /* Allocate validate page tables if needed */
- ret = vm_validate_pt_pd_bos(vm);
- if (unlikely(ret)) {
- pr_err("validate_pt_pd_bos() failed\n");
- goto unwind;
- }
-
return 0;
unwind:
@@ -1478,12 +1492,12 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
pr_debug("Release VA 0x%llx - 0x%llx\n", mem->va,
mem->va + bo_size * (1 + mem->aql_queue));
+ ret = unreserve_bo_and_vms(, false, false);
+
/* Remove from VM internal data structures */
list_for_each_entry_safe(entry, tmp, >attachments, list)
kfd_mem_detach(entry);
- ret = unreserve_bo_and_vms(, false, false);
-
/* Free the sync object */
amdgpu_sync_free(>sync);
@@ -1560,6 +1574,12 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
mem->va + bo_size * (1 + mem->aql_queue),
avm, domain_string(domain));
+ if (!kfd_mem_is_attached(avm, mem)) {
+ ret = kfd_mem_attach(adev, mem, avm, mem->aql_queue);
+ if (ret)
+ goto out;
+ }
+
ret = reserve_bo_and_vm(mem, avm, );
if (unlikely(ret))
goto out;
@@ -1573,15 +1593,9 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
is_invalid_userptr = true;
- if (!kfd_mem_is_attached(avm, mem)) {
- ret = kfd_mem_attach(adev, mem, avm, mem->aql_queue);
- if (ret)
- goto attach_failed;
- } else {
- ret = vm_validate_pt_pd_bos(avm);
- if (unlikely(ret))
- goto attach_failed;
- }
+ ret = vm_validate_pt_pd_bos(avm);
+ if
[PATCH v2 02/10] drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment
This name is more fitting, especially for the changes coming next to
support multi-GPU systems with proper DMA mappings. Cleaned up the code
and renamed some related functions and variables to improve readability.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 8 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 209 +-
2 files changed, 104 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 313ee49b9f17..c24b2478f445 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -38,10 +38,10 @@ extern uint64_t amdgpu_amdkfd_total_mem_size;
struct amdgpu_device;
-struct kfd_bo_va_list {
- struct list_head bo_list;
+struct kfd_mem_attachment {
+ struct list_head list;
struct amdgpu_bo_va *bo_va;
- void *kgd_dev;
+ struct amdgpu_device *adev;
bool is_mapped;
uint64_t va;
uint64_t pte_flags;
@@ -50,7 +50,7 @@ struct kfd_bo_va_list {
struct kgd_mem {
struct mutex lock;
struct amdgpu_bo *bo;
- struct list_head bo_va_list;
+ struct list_head attachments;
/* protected by amdkfd_process_info.lock */
struct ttm_validate_buffer validate_list;
struct ttm_validate_buffer resv_list;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index dfa025d694f8..fee4c64dd051 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -72,16 +72,16 @@ static inline struct amdgpu_device
*get_amdgpu_device(struct kgd_dev *kgd)
return (struct amdgpu_device *)kgd;
}
-static bool check_if_add_bo_to_vm(struct amdgpu_vm *avm,
+static bool kfd_mem_is_attached(struct amdgpu_vm *avm,
struct kgd_mem *mem)
{
- struct kfd_bo_va_list *entry;
+ struct kfd_mem_attachment *entry;
- list_for_each_entry(entry, >bo_va_list, bo_list)
+ list_for_each_entry(entry, >attachments, list)
if (entry->bo_va->base.vm == avm)
- return false;
+ return true;
- return true;
+ return false;
}
/* Set memory usage limits. Current, limits are
@@ -473,7 +473,7 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
return pte_flags;
}
-/* add_bo_to_vm - Add a BO to a VM
+/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
* to a VM. It can later be mapped and unmapped many times without
@@ -485,15 +485,14 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
* 4. Alloc page tables and directories if needed
* 4a. Validate new page tables and directories
*/
-static int add_bo_to_vm(struct amdgpu_device *adev, struct kgd_mem *mem,
+static int kfd_mem_attach(struct amdgpu_device *adev, struct kgd_mem *mem,
struct amdgpu_vm *vm, bool is_aql,
- struct kfd_bo_va_list **p_bo_va_entry)
+ struct kfd_mem_attachment **p_attachment)
{
int ret;
- struct kfd_bo_va_list *bo_va_entry;
+ struct kfd_mem_attachment *attachment;
struct amdgpu_bo *bo = mem->bo;
uint64_t va = mem->va;
- struct list_head *list_bo_va = >bo_va_list;
unsigned long bo_size = bo->tbo.base.size;
if (!va) {
@@ -504,29 +503,29 @@ static int add_bo_to_vm(struct amdgpu_device *adev,
struct kgd_mem *mem,
if (is_aql)
va += bo_size;
- bo_va_entry = kzalloc(sizeof(*bo_va_entry), GFP_KERNEL);
- if (!bo_va_entry)
+ attachment = kzalloc(sizeof(*attachment), GFP_KERNEL);
+ if (!attachment)
return -ENOMEM;
pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
va + bo_size, vm);
/* Add BO to VM internal data structures*/
- bo_va_entry->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
- if (!bo_va_entry->bo_va) {
+ attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
+ if (!attachment->bo_va) {
ret = -EINVAL;
pr_err("Failed to add BO object to VM. ret == %d\n",
ret);
goto err_vmadd;
}
- bo_va_entry->va = va;
- bo_va_entry->pte_flags = get_pte_flags(adev, mem);
- bo_va_entry->kgd_dev = (void *)adev;
- list_add(_va_entry->bo_list, list_bo_va);
+ attachment->va = va;
+ attachment->pte_flags = get_pte_flags(adev, mem);
+ attachment->adev = adev;
+ list_add(>list, >attachments);
- if (p_bo_va_entry)
- *p_bo_va_entry = bo_va_entry;
+ if (p_attachment)
+ *p_attachment = attachment;
/* Allocate validate page tables if needed */
ret
[PATCH v2 09/10] drm/ttm: Don't count pages in SG BOs against pages_limit
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, _pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, _dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, _pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ _dma32_pages_allocated);
+ }
while (atomic_long_read(_pages_allocated) > ttm_pages_limit ||
atomic_long_read(_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, _pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, _dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, _pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ _dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(>pool, ttm);
- atomic_long_sub(ttm->num_pages, _pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, _dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, _pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ _dma32_pages_allocated);
+ }
ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/10] drm/amdgpu: Add DMA mapping of GTT BOs
Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 76 ++-
2 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 63668433f5a6..b706e5a54782 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -41,6 +41,7 @@ struct amdgpu_device;
enum kfd_mem_attachment_type {
KFD_MEM_ATT_SHARED, /* Share kgd_mem->bo or another attachment's */
KFD_MEM_ATT_USERPTR,/* SG bo to DMA map pages from a userptr bo */
+ KFD_MEM_ATT_DMABUF, /* DMAbuf to DMA map TTM BOs */
};
struct kfd_mem_attachment {
@@ -56,6 +57,7 @@ struct kfd_mem_attachment {
struct kgd_mem {
struct mutex lock;
struct amdgpu_bo *bo;
+ struct dma_buf *dmabuf;
struct list_head attachments;
/* protected by amdkfd_process_info.lock */
struct ttm_validate_buffer validate_list;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9eeedd0c7920..18a1f9222a59 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -524,6 +524,16 @@ kfd_mem_dmamap_userptr(struct kgd_mem *mem,
return ret;
}
+static int
+kfd_mem_dmamap_dmabuf(struct kfd_mem_attachment *attachment)
+{
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ return ttm_bo_validate(>tbo, >placement, );
+}
+
static int
kfd_mem_dmamap_attachment(struct kgd_mem *mem,
struct kfd_mem_attachment *attachment)
@@ -533,6 +543,8 @@ kfd_mem_dmamap_attachment(struct kgd_mem *mem,
return 0;
case KFD_MEM_ATT_USERPTR:
return kfd_mem_dmamap_userptr(mem, attachment);
+ case KFD_MEM_ATT_DMABUF:
+ return kfd_mem_dmamap_dmabuf(attachment);
default:
WARN_ON_ONCE(1);
}
@@ -562,6 +574,19 @@ kfd_mem_dmaunmap_userptr(struct kgd_mem *mem,
ttm->sg = NULL;
}
+static void
+kfd_mem_dmaunmap_dmabuf(struct kfd_mem_attachment *attachment)
+{
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
+ ttm_bo_validate(>tbo, >placement, );
+ /* FIXME: This does not guarantee that amdgpu_ttm_tt_unpopulate is
+* called
+*/
+}
+
static void
kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
struct kfd_mem_attachment *attachment)
@@ -572,6 +597,9 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
case KFD_MEM_ATT_USERPTR:
kfd_mem_dmaunmap_userptr(mem, attachment);
break;
+ case KFD_MEM_ATT_DMABUF:
+ kfd_mem_dmaunmap_dmabuf(attachment);
+ break;
default:
WARN_ON_ONCE(1);
}
@@ -605,6 +633,38 @@ kfd_mem_attach_userptr(struct amdgpu_device *adev, struct
kgd_mem *mem,
return 0;
}
+static int
+kfd_mem_attach_dmabuf(struct amdgpu_device *adev, struct kgd_mem *mem,
+ struct amdgpu_bo **bo)
+{
+ struct drm_gem_object *gobj;
+
+ if (!mem->dmabuf) {
+ mem->dmabuf = amdgpu_gem_prime_export(>bo->tbo.base,
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DRM_RDWR : 0);
+ if (IS_ERR(mem->dmabuf)) {
+ mem->dmabuf = NULL;
+ return PTR_ERR(mem->dmabuf);
+ }
+ }
+
+ gobj = amdgpu_gem_prime_import(>ddev, mem->dmabuf);
+ if (IS_ERR(gobj))
+ return PTR_ERR(gobj);
+
+ /* Import takes an extra reference on the dmabuf. Drop it now to
+* avoid leaking it. We only need the one reference in
+* kgd_mem->dmabuf.
+*/
+ dma_buf_put(mem->dmabuf);
+
+ *bo = gem_to_amdgpu_bo(gobj);
+ (*bo)->parent = amdgpu_bo_ref(mem->bo);
+
+ return 0;
+}
+
/* kfd_mem_attach - Add a BO to a VM
*
* Everything that needs to bo done only once when a BO is first added
@@ -662,8 +722,20 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
ret = kfd_mem_attach_userptr(adev, mem, [i]);
if (ret)
goto unwind;
+ } else if (mem->domain == AMDGPU_GEM_DOMAIN_GTT &&
+ mem->bo->tbo.type != ttm_bo_type_sg) {
+ /* GTT BOs use DMA-mapping ability of
[PATCH v2 04/10] drm/amdgpu: Simplify AQL queue mapping
Do AQL queue double-mapping with a single attach call. That will make it
easier to create per-GPU BOs later, to be shared between the two BO VA
mappings on the same GPU.
Freeing the attachments is not necessary if map_to_gpu fails. These will be
cleaned up when the kdg_mem object is destroyed in
amdgpu_amdkfd_gpuvm_free_memory_of_gpu.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 103 --
1 file changed, 48 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 34c9a2d0028e..fbd7e786b54e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -486,70 +486,76 @@ static uint64_t get_pte_flags(struct amdgpu_device *adev,
struct kgd_mem *mem)
* 4a. Validate new page tables and directories
*/
static int kfd_mem_attach(struct amdgpu_device *adev, struct kgd_mem *mem,
- struct amdgpu_vm *vm, bool is_aql,
- struct kfd_mem_attachment **p_attachment)
+ struct amdgpu_vm *vm, bool is_aql)
{
unsigned long bo_size = mem->bo->tbo.base.size;
uint64_t va = mem->va;
- struct kfd_mem_attachment *attachment;
- struct amdgpu_bo *bo;
- int ret;
+ struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
+ struct amdgpu_bo *bo[2] = {NULL, NULL};
+ int i, ret;
if (!va) {
pr_err("Invalid VA when adding BO to VM\n");
return -EINVAL;
}
- if (is_aql)
- va += bo_size;
-
- attachment = kzalloc(sizeof(*attachment), GFP_KERNEL);
- if (!attachment)
- return -ENOMEM;
+ for (i = 0; i <= is_aql; i++) {
+ attachment[i] = kzalloc(sizeof(*attachment[i]), GFP_KERNEL);
+ if (unlikely(!attachment[i])) {
+ ret = -ENOMEM;
+ goto unwind;
+ }
- pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
- va + bo_size, vm);
+ pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
+va + bo_size, vm);
- /* FIXME: For now all attachments use the same BO. This is incorrect
-* because one BO can only have one DMA mapping for one GPU. We need
-* one BO per GPU, e.g. a DMABuf import with dynamic attachment. This
-* will be addressed one BO-type at a time in subsequent patches.
-*/
- bo = mem->bo;
- drm_gem_object_get(>tbo.base);
+ /* FIXME: For now all attachments use the same BO. This is
+* incorrect because one BO can only have one DMA mapping
+* for one GPU. We need one BO per GPU, e.g. a DMABuf
+* import with dynamic attachment. This will be addressed
+* one BO-type at a time in subsequent patches.
+*/
+ bo[i] = mem->bo;
+ drm_gem_object_get([i]->tbo.base);
- /* Add BO to VM internal data structures*/
- attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
- if (!attachment->bo_va) {
- ret = -EINVAL;
- pr_err("Failed to add BO object to VM. ret == %d\n",
- ret);
- goto err_vmadd;
- }
+ /* Add BO to VM internal data structures */
+ attachment[i]->bo_va = amdgpu_vm_bo_add(adev, vm, bo[i]);
+ if (unlikely(!attachment[i]->bo_va)) {
+ ret = -ENOMEM;
+ pr_err("Failed to add BO object to VM. ret == %d\n",
+ ret);
+ goto unwind;
+ }
- attachment->va = va;
- attachment->pte_flags = get_pte_flags(adev, mem);
- attachment->adev = adev;
- list_add(>list, >attachments);
+ attachment[i]->va = va;
+ attachment[i]->pte_flags = get_pte_flags(adev, mem);
+ attachment[i]->adev = adev;
+ list_add([i]->list, >attachments);
- if (p_attachment)
- *p_attachment = attachment;
+ va += bo_size;
+ }
/* Allocate validate page tables if needed */
ret = vm_validate_pt_pd_bos(vm);
if (unlikely(ret)) {
pr_err("validate_pt_pd_bos() failed\n");
- goto err_alloc_pts;
+ goto unwind;
}
return 0;
-err_alloc_pts:
- amdgpu_vm_bo_rmv(adev, attachment->bo_va);
- list_del(>list);
-err_vmadd:
- drm_gem_object_put(>tbo.base);
- kfree(attachment);
+unwind:
+ for (; i >= 0; i--) {
+ if (!attachment[i])
+ continue;
+ if (attachment[i]->bo_va) {
+ amdgpu_vm_bo_rmv(adev, attachment[i]->bo_va);
+
[PATCH v2 00/10] Implement multi-GPU DMA mappings for KFD
This patch series fixes DMA-mappings of system memory (GTT and userptr) for KFD running on multi-GPU systems with IOMMU enabled. One SG-BO per GPU is needed to maintain the DMA mappings of each BO. Changes in v2: - Made the original BO parent of the SG BO to fix bo destruction order - Removed individualiation hack that is, not needed with parent BO - Removed resv locking hace in amdgpu_ttm_unpopulate, not needed without the individualization hack - Added a patch to enable the Intel IOMMU driver in rock-dbg_defconfig - Added a patch to move dmabuf attach/detach into backend_(un)bind I'm still seeing some IOMMU access faults in the eviction test. They seem to be related to userptr handling. They happen even without this patch series on a single-GPU system, where this patch series is not needed. I believe this is an old problem in KFD or amdgpu that is being exposed by device isolation from the IOMMU. I'm debugging it, but it should not hold up this patch series. "drm/ttm: Don't count pages in SG BOs against pages_limit" was already applied to drm-misc (I think). I'm still including it here because my patches depend on it. Without that, the SG BOs created for DMA mappings cause many tests fail because TTM incorrectly thinks it's out of memory. Felix Kuehling (10): rock-dbg_defconfig: Enable Intel IOMMU drm/amdgpu: Rename kfd_bo_va_list to kfd_mem_attachment drm/amdgpu: Keep a bo-reference per-attachment drm/amdgpu: Simplify AQL queue mapping drm/amdgpu: Add multi-GPU DMA mapping helpers drm/amdgpu: DMA map/unmap when updating GPU mappings drm/amdgpu: Move kfd_mem_attach outside reservation drm/amdgpu: Add DMA mapping of GTT BOs drm/ttm: Don't count pages in SG BOs against pages_limit drm/amdgpu: Move dmabuf attach/detach to backend_(un)bind arch/x86/configs/rock-dbg_defconfig | 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 18 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 530 -- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 51 +- drivers/gpu/drm/ttm/ttm_tt.c | 27 +- 5 files changed, 437 insertions(+), 200 deletions(-) -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/10] drm/amdgpu: DMA map/unmap when updating GPU mappings
DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
with the BO and page tables reserved, so we can safely update the DMA
mapping.
DMA unmap when a BO is unmapped from a GPU and before updating mappings
in restore workers.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 56 ++-
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 49d1af4aa5f1..7d25d886b98c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -961,11 +961,12 @@ static int unreserve_bo_and_vms(struct
bo_vm_reservation_context *ctx,
return ret;
}
-static int unmap_bo_from_gpuvm(struct amdgpu_device *adev,
+static void unmap_bo_from_gpuvm(struct kgd_mem *mem,
struct kfd_mem_attachment *entry,
struct amdgpu_sync *sync)
{
struct amdgpu_bo_va *bo_va = entry->bo_va;
+ struct amdgpu_device *adev = entry->adev;
struct amdgpu_vm *vm = bo_va->base.vm;
amdgpu_vm_bo_unmap(adev, bo_va, entry->va);
@@ -974,15 +975,20 @@ static int unmap_bo_from_gpuvm(struct amdgpu_device *adev,
amdgpu_sync_fence(sync, bo_va->last_pt_update);
- return 0;
+ kfd_mem_dmaunmap_attachment(mem, entry);
}
-static int update_gpuvm_pte(struct amdgpu_device *adev,
- struct kfd_mem_attachment *entry,
- struct amdgpu_sync *sync)
+static int update_gpuvm_pte(struct kgd_mem *mem,
+ struct kfd_mem_attachment *entry,
+ struct amdgpu_sync *sync)
{
- int ret;
struct amdgpu_bo_va *bo_va = entry->bo_va;
+ struct amdgpu_device *adev = entry->adev;
+ int ret;
+
+ ret = kfd_mem_dmamap_attachment(mem, entry);
+ if (ret)
+ return ret;
/* Update the page tables */
ret = amdgpu_vm_bo_update(adev, bo_va, false);
@@ -994,14 +1000,15 @@ static int update_gpuvm_pte(struct amdgpu_device *adev,
return amdgpu_sync_fence(sync, bo_va->last_pt_update);
}
-static int map_bo_to_gpuvm(struct amdgpu_device *adev,
- struct kfd_mem_attachment *entry, struct amdgpu_sync *sync,
- bool no_update_pte)
+static int map_bo_to_gpuvm(struct kgd_mem *mem,
+ struct kfd_mem_attachment *entry,
+ struct amdgpu_sync *sync,
+ bool no_update_pte)
{
int ret;
/* Set virtual address for the allocation */
- ret = amdgpu_vm_bo_map(adev, entry->bo_va, entry->va, 0,
+ ret = amdgpu_vm_bo_map(entry->adev, entry->bo_va, entry->va, 0,
amdgpu_bo_size(entry->bo_va->base.bo),
entry->pte_flags);
if (ret) {
@@ -1013,7 +1020,7 @@ static int map_bo_to_gpuvm(struct amdgpu_device *adev,
if (no_update_pte)
return 0;
- ret = update_gpuvm_pte(adev, entry, sync);
+ ret = update_gpuvm_pte(mem, entry, sync);
if (ret) {
pr_err("update_gpuvm_pte() failed\n");
goto update_gpuvm_pte_failed;
@@ -1022,7 +1029,7 @@ static int map_bo_to_gpuvm(struct amdgpu_device *adev,
return 0;
update_gpuvm_pte_failed:
- unmap_bo_from_gpuvm(adev, entry, sync);
+ unmap_bo_from_gpuvm(mem, entry, sync);
return ret;
}
@@ -1596,7 +1603,7 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
pr_debug("\t map VA 0x%llx - 0x%llx in entry %p\n",
entry->va, entry->va + bo_size, entry);
- ret = map_bo_to_gpuvm(adev, entry, ctx.sync,
+ ret = map_bo_to_gpuvm(mem, entry, ctx.sync,
is_invalid_userptr);
if (ret) {
pr_err("Failed to map bo to gpuvm\n");
@@ -1635,7 +1642,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv)
{
- struct amdgpu_device *adev = get_amdgpu_device(kgd);
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
struct amdkfd_process_info *process_info = avm->process_info;
unsigned long bo_size = mem->bo->tbo.base.size;
@@ -1670,13 +1676,8 @@ int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
pr_debug("\t unmap VA 0x%llx - 0x%llx from entry %p\n",
entry->va, entry->va + bo_size, entry);
- ret = unmap_bo_from_gpuvm(adev, entry, ctx.sync);
- if (ret == 0) {
- entry->is_mapped = false;
- } else {
- pr_err("failed to unmap VA 0x%llx\n", mem->va);
- goto unreserve_out;
- }
+
[PATCH v2 01/10] rock-dbg_defconfig: Enable Intel IOMMU
Enable the Intel IOMMU driver in the rock-dbg_defconfig. This enables testing of DMA mappings on systems with an Intel IOMMU. Signed-off-by: Felix Kuehling --- arch/x86/configs/rock-dbg_defconfig | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/configs/rock-dbg_defconfig b/arch/x86/configs/rock-dbg_defconfig index 54688993d6e2..9f7d93307754 100644 --- a/arch/x86/configs/rock-dbg_defconfig +++ b/arch/x86/configs/rock-dbg_defconfig @@ -296,6 +296,7 @@ CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y +CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y @@ -3112,6 +3113,7 @@ CONFIG_DRM_AMD_DC_DCN=y # end of Display Engine Configuration CONFIG_HSA_AMD=y +CONFIG_HSA_AMD_SVM=y # CONFIG_DRM_NOUVEAU is not set # CONFIG_DRM_I915 is not set # CONFIG_DRM_VGEM is not set @@ -3770,6 +3772,7 @@ CONFIG_MAILBOX=y CONFIG_PCC=y # CONFIG_ALTERA_MBOX is not set CONFIG_IOMMU_IOVA=y +CONFIG_IOASID=y CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y @@ -3783,7 +3786,12 @@ CONFIG_IOMMU_SUPPORT=y CONFIG_IOMMU_DMA=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_V2=m -# CONFIG_INTEL_IOMMU is not set +CONFIG_DMAR_TABLE=y +CONFIG_INTEL_IOMMU=y +# CONFIG_INTEL_IOMMU_SVM is not set +CONFIG_INTEL_IOMMU_DEFAULT_ON=y +CONFIG_INTEL_IOMMU_FLOPPY_WA=y +# CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON is not set # CONFIG_IRQ_REMAP is not set # @@ -4184,6 +4192,7 @@ CONFIG_SECURITY_NETWORK=y CONFIG_PAGE_TABLE_ISOLATION=y # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_PATH is not set +# CONFIG_INTEL_TXT is not set CONFIG_LSM_MMAP_MIN_ADDR=65536 CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y # CONFIG_HARDENED_USERCOPY is not set -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] drm/amdgpu: Add multi-GPU DMA mapping helpers
Add BO-type specific helpers functions to DMA-map and unmap
kfd_mem_attachments. Implement this functionality for userptrs by creating
one SG BO per GPU and filling it with a DMA mapping of the pages from the
original mem->bo.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 8 +-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 146 +-
2 files changed, 145 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index c24b2478f445..63668433f5a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -38,11 +38,17 @@ extern uint64_t amdgpu_amdkfd_total_mem_size;
struct amdgpu_device;
+enum kfd_mem_attachment_type {
+ KFD_MEM_ATT_SHARED, /* Share kgd_mem->bo or another attachment's */
+ KFD_MEM_ATT_USERPTR,/* SG bo to DMA map pages from a userptr bo */
+};
+
struct kfd_mem_attachment {
struct list_head list;
+ enum kfd_mem_attachment_type type;
+ bool is_mapped;
struct amdgpu_bo_va *bo_va;
struct amdgpu_device *adev;
- bool is_mapped;
uint64_t va;
uint64_t pte_flags;
};
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index fbd7e786b54e..49d1af4aa5f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -473,12 +473,117 @@ static uint64_t get_pte_flags(struct amdgpu_device
*adev, struct kgd_mem *mem)
return pte_flags;
}
+static int
+kfd_mem_dmamap_userptr(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ enum dma_data_direction direction =
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
+ struct ttm_operation_ctx ctx = {.interruptible = true};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+ struct amdgpu_device *adev = attachment->adev;
+ struct ttm_tt *src_ttm = mem->bo->tbo.ttm;
+ struct ttm_tt *ttm = bo->tbo.ttm;
+ int ret;
+
+ ttm->sg = kmalloc(sizeof(*ttm->sg), GFP_KERNEL);
+ if (unlikely(!ttm->sg))
+ return -ENOMEM;
+
+ if (WARN_ON(ttm->num_pages != src_ttm->num_pages))
+ return -EINVAL;
+
+ /* Same sequence as in amdgpu_ttm_tt_pin_userptr */
+ ret = sg_alloc_table_from_pages(ttm->sg, src_ttm->pages,
+ ttm->num_pages, 0,
+ (u64)ttm->num_pages << PAGE_SHIFT,
+ GFP_KERNEL);
+ if (unlikely(ret))
+ goto release_sg;
+
+ ret = dma_map_sgtable(adev->dev, ttm->sg, direction, 0);
+ if (unlikely(ret))
+ goto release_sg;
+
+ drm_prime_sg_to_dma_addr_array(ttm->sg, ttm->dma_address,
+ ttm->num_pages);
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ ret = ttm_bo_validate(>tbo, >placement, );
+ if (ret)
+ goto release_sg;
+
+ return 0;
+
+release_sg:
+ pr_err("DMA map userptr failed: %d\n", ret);
+ sg_free_table(ttm->sg);
+ kfree(ttm->sg);
+ ttm->sg = NULL;
+ return ret;
+}
+
+static int
+kfd_mem_dmamap_attachment(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ switch (attachment->type) {
+ case KFD_MEM_ATT_SHARED:
+ return 0;
+ case KFD_MEM_ATT_USERPTR:
+ return kfd_mem_dmamap_userptr(mem, attachment);
+ default:
+ WARN_ON_ONCE(1);
+ }
+ return -EINVAL;
+}
+
+static void
+kfd_mem_dmaunmap_userptr(struct kgd_mem *mem,
+struct kfd_mem_attachment *attachment)
+{
+ enum dma_data_direction direction =
+ mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
+ DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
+ struct ttm_operation_ctx ctx = {.interruptible = false};
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+ struct amdgpu_device *adev = attachment->adev;
+ struct ttm_tt *ttm = bo->tbo.ttm;
+
+ if (unlikely(!ttm->sg))
+ return;
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
+ ttm_bo_validate(>tbo, >placement, );
+
+ dma_unmap_sgtable(adev->dev, ttm->sg, direction, 0);
+ sg_free_table(ttm->sg);
+ ttm->sg = NULL;
+}
+
+static void
+kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
+ struct kfd_mem_attachment *attachment)
+{
+ switch (attachment->type) {
+ case KFD_MEM_ATT_SHARED:
+ break;
+ case KFD_MEM_ATT_USERPTR:
+ kfd_mem_dmaunmap_userptr(mem, attachment);
+ break;
+
[PATCH v2 03/10] drm/amdgpu: Keep a bo-reference per-attachment
For now they all reference the same BO. For correct DMA mappings they will
refer to different BOs per-GPU.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index fee4c64dd051..34c9a2d0028e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -489,11 +489,11 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
struct amdgpu_vm *vm, bool is_aql,
struct kfd_mem_attachment **p_attachment)
{
- int ret;
- struct kfd_mem_attachment *attachment;
- struct amdgpu_bo *bo = mem->bo;
+ unsigned long bo_size = mem->bo->tbo.base.size;
uint64_t va = mem->va;
- unsigned long bo_size = bo->tbo.base.size;
+ struct kfd_mem_attachment *attachment;
+ struct amdgpu_bo *bo;
+ int ret;
if (!va) {
pr_err("Invalid VA when adding BO to VM\n");
@@ -510,6 +510,14 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
pr_debug("\t add VA 0x%llx - 0x%llx to vm %p\n", va,
va + bo_size, vm);
+ /* FIXME: For now all attachments use the same BO. This is incorrect
+* because one BO can only have one DMA mapping for one GPU. We need
+* one BO per GPU, e.g. a DMABuf import with dynamic attachment. This
+* will be addressed one BO-type at a time in subsequent patches.
+*/
+ bo = mem->bo;
+ drm_gem_object_get(>tbo.base);
+
/* Add BO to VM internal data structures*/
attachment->bo_va = amdgpu_vm_bo_add(adev, vm, bo);
if (!attachment->bo_va) {
@@ -529,7 +537,7 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
/* Allocate validate page tables if needed */
ret = vm_validate_pt_pd_bos(vm);
- if (ret) {
+ if (unlikely(ret)) {
pr_err("validate_pt_pd_bos() failed\n");
goto err_alloc_pts;
}
@@ -540,15 +548,19 @@ static int kfd_mem_attach(struct amdgpu_device *adev,
struct kgd_mem *mem,
amdgpu_vm_bo_rmv(adev, attachment->bo_va);
list_del(>list);
err_vmadd:
+ drm_gem_object_put(>tbo.base);
kfree(attachment);
return ret;
}
static void kfd_mem_detach(struct kfd_mem_attachment *attachment)
{
+ struct amdgpu_bo *bo = attachment->bo_va->base.bo;
+
pr_debug("\t remove VA 0x%llx in entry %p\n",
attachment->va, attachment);
amdgpu_vm_bo_rmv(attachment->adev, attachment->bo_va);
+ drm_gem_object_put(>tbo.base);
list_del(>list);
kfree(attachment);
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/10] drm/amdgpu: Move dmabuf attach/detach to backend_(un)bind
The dmabuf attachment should be updated by moving the SG BO to DOMAIN_CPU
and back to DOMAIN_GTT. This does not necessarily invoke the
populate/unpopulate callbacks. Do this in backend_bind/unbind instead.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 51 +--
2 files changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 18a1f9222a59..68e6ce8dcf33 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -582,9 +582,6 @@ kfd_mem_dmaunmap_dmabuf(struct kfd_mem_attachment
*attachment)
amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_CPU);
ttm_bo_validate(>tbo, >placement, );
- /* FIXME: This does not guarantee that amdgpu_ttm_tt_unpopulate is
-* called
-*/
}
static void
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7e7d8330d64b..fc2a8d681dbc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -910,7 +910,23 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
DRM_ERROR("failed to pin userptr\n");
return r;
}
+ } else if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+ if (!ttm->sg) {
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+
+ attach = gtt->gobj->import_attach;
+ sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt))
+ return PTR_ERR(sgt);
+
+ ttm->sg = sgt;
+ }
+
+ drm_prime_sg_to_dma_addr_array(ttm->sg, gtt->ttm.dma_address,
+ ttm->num_pages);
}
+
if (!ttm->num_pages) {
WARN(1, "nothing to bind %u pages for mreg %p back %p!\n",
ttm->num_pages, bo_mem, ttm);
@@ -1037,8 +1053,15 @@ static void amdgpu_ttm_backend_unbind(struct ttm_device
*bdev,
int r;
/* if the pages have userptr pinning then clear that first */
- if (gtt->userptr)
+ if (gtt->userptr) {
amdgpu_ttm_tt_unpin_userptr(bdev, ttm);
+ } else if (ttm->sg && gtt->gobj->import_attach) {
+ struct dma_buf_attachment *attach;
+
+ attach = gtt->gobj->import_attach;
+ dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
+ ttm->sg = NULL;
+ }
if (!gtt->bound)
return;
@@ -1125,23 +1148,8 @@ static int amdgpu_ttm_tt_populate(struct ttm_device
*bdev,
return 0;
}
- if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
- if (!ttm->sg) {
- struct dma_buf_attachment *attach;
- struct sg_table *sgt;
-
- attach = gtt->gobj->import_attach;
- sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR(sgt))
- return PTR_ERR(sgt);
-
- ttm->sg = sgt;
- }
-
- drm_prime_sg_to_dma_addr_array(ttm->sg, gtt->ttm.dma_address,
- ttm->num_pages);
+ if (ttm->page_flags & TTM_PAGE_FLAG_SG)
return 0;
- }
return ttm_pool_alloc(>mman.bdev.pool, ttm, ctx);
}
@@ -1165,15 +1173,6 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device
*bdev,
return;
}
- if (ttm->sg && gtt->gobj->import_attach) {
- struct dma_buf_attachment *attach;
-
- attach = gtt->gobj->import_attach;
- dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
- ttm->sg = NULL;
- return;
- }
-
if (ttm->page_flags & TTM_PAGE_FLAG_SG)
return;
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/4] drm/msm/dp: initialize audio_comp when audio starts
Initialize audio_comp when audio starts and wait for audio_comp at
dp_display_disable(). This will take care of both dongle unplugged
and display off (suspend) cases.
Changes in v2:
-- add dp_display_signal_audio_start()
Changes in v3:
-- restore dp_display_handle_plugged_change() at dp_hpd_unplug_handle().
Changes in v4:
-- none
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_audio.c | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 11 +--
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index 82a8673..d7e4a39 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -527,6 +527,7 @@ int dp_audio_hw_params(struct device *dev,
dp_audio_setup_acr(audio);
dp_audio_safe_to_exit_level(audio);
dp_audio_enable(audio, true);
+ dp_display_signal_audio_start(dp_display);
dp_display->audio_enabled = true;
end:
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0ba71c7..1784e11 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -178,6 +178,15 @@ static int dp_del_event(struct dp_display_private
*dp_priv, u32 event)
return 0;
}
+void dp_display_signal_audio_start(struct msm_dp *dp_display)
+{
+ struct dp_display_private *dp;
+
+ dp = container_of(dp_display, struct dp_display_private, dp_display);
+
+ reinit_completion(>audio_comp);
+}
+
void dp_display_signal_audio_complete(struct msm_dp *dp_display)
{
struct dp_display_private *dp;
@@ -649,7 +658,6 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0, DP_TIMEOUT_5_SECOND);
/* signal the disconnect event early to ensure proper teardown */
- reinit_completion(>audio_comp);
dp_display_handle_plugged_change(g_dp_display, false);
dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK |
@@ -894,7 +902,6 @@ static int dp_display_disable(struct dp_display_private
*dp, u32 data)
/* wait only if audio was enabled */
if (dp_display->audio_enabled) {
/* signal the disconnect event */
- reinit_completion(>audio_comp);
dp_display_handle_plugged_change(dp_display, false);
if (!wait_for_completion_timeout(>audio_comp,
HZ * 5))
diff --git a/drivers/gpu/drm/msm/dp/dp_display.h
b/drivers/gpu/drm/msm/dp/dp_display.h
index 6092ba1..5173c89 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.h
+++ b/drivers/gpu/drm/msm/dp/dp_display.h
@@ -34,6 +34,7 @@ int dp_display_get_modes(struct msm_dp *dp_display,
int dp_display_request_irq(struct msm_dp *dp_display);
bool dp_display_check_video_test(struct msm_dp *dp_display);
int dp_display_get_test_bpp(struct msm_dp *dp_display);
+void dp_display_signal_audio_start(struct msm_dp *dp_display);
void dp_display_signal_audio_complete(struct msm_dp *dp_display);
#endif /* _DP_DISPLAY_H_ */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/4] drm/msm/dp: check sink_count before update is_connected status
Link status is different from display connected status in the case
of something like an Apple dongle where the type-c plug can be
connected, and therefore the link is connected, but no sink is
connected until an HDMI cable is plugged into the dongle.
The sink_count of DPCD of dongle will increase to 1 once an HDMI
cable is plugged into the dongle so that display connected status
will become true. This checking also apply at pm_resume.
Changes in v4:
-- none
Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and
pm_resume")
Reported-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6..0ba71c7 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -586,10 +586,8 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_CONNECT_PENDING) {
- dp_display_enable(dp, 0);
+ if (state == ST_CONNECT_PENDING)
dp->hpd_state = ST_CONNECTED;
- }
mutex_unlock(>event_mutex);
@@ -669,10 +667,8 @@ static int dp_disconnect_pending_timeout(struct
dp_display_private *dp, u32 data
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_DISCONNECT_PENDING) {
- dp_display_disable(dp, 0);
+ if (state == ST_DISCONNECT_PENDING)
dp->hpd_state = ST_DISCONNECTED;
- }
mutex_unlock(>event_mutex);
@@ -1272,7 +1268,12 @@ static int dp_pm_resume(struct device *dev)
status = dp_catalog_link_is_connected(dp->catalog);
- if (status)
+ /*
+* can not declared display is connected unless
+* HDMI cable is plugged in and sink_count of
+* dongle become 1
+*/
+ if (status && dp->link->sink_count)
dp->dp_display.is_connected = true;
else
dp->dp_display.is_connected = false;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/4] drm/msm/dp: check main link status before start aux read
Maybe when the cable is disconnected the DP phy should be shutdown and
some bit in the phy could effectively "cut off" the aux channel and then
NAKs would start coming through here in the DP controller I/O register
space. This patch have DP aux channel read/write to return NAK immediately
if DP controller connection status is in unplugged state.
Changes in V4:
-- split this patch as stand alone patch
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 7c22bfe..fae3806 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
mutex_lock(>mutex);
+ if (!dp_catalog_link_is_connected(aux->catalog)) {
+ ret = -ETIMEDOUT;
+ goto unlock_exit;
+ }
+
aux->native = msg->request & (DP_AUX_NATIVE_WRITE & DP_AUX_NATIVE_READ);
/* Ignore address only message */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read failed
Add checking aux read/write status at both dp_link_parse_sink_count()
and dp_link_parse_sink_status_filed() to avoid long timeout delay if
dp aux read/write failed at timeout due to cable unplugged.
Changes in V4:
-- split this patch as stand alone patch
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 12 +---
drivers/gpu/drm/msm/dp/dp_link.c| 20 +++-
2 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 1784e11..d1319b5 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -711,9 +711,15 @@ static int dp_irq_hpd_handle(struct dp_display_private
*dp, u32 data)
return 0;
}
- ret = dp_display_usbpd_attention_cb(>pdev->dev);
- if (ret == -ECONNRESET) { /* cable unplugged */
- dp->core_initialized = false;
+ /*
+* dp core (ahb/aux clks) must be initialized before
+* irq_hpd be handled
+*/
+ if (dp->core_initialized) {
+ ret = dp_display_usbpd_attention_cb(>pdev->dev);
+ if (ret == -ECONNRESET) { /* cable unplugged */
+ dp->core_initialized = false;
+ }
}
mutex_unlock(>event_mutex);
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index be986da..53ecae6 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -737,18 +737,25 @@ static int dp_link_parse_sink_count(struct dp_link
*dp_link)
return 0;
}
-static void dp_link_parse_sink_status_field(struct dp_link_private *link)
+static int dp_link_parse_sink_status_field(struct dp_link_private *link)
{
int len = 0;
link->prev_sink_count = link->dp_link.sink_count;
- dp_link_parse_sink_count(>dp_link);
+ len = dp_link_parse_sink_count(>dp_link);
+ if (len < 0) {
+ DRM_ERROR("DP parse sink count failed\n");
+ return len;
+ }
len = drm_dp_dpcd_read_link_status(link->aux,
link->link_status);
- if (len < DP_LINK_STATUS_SIZE)
+ if (len < DP_LINK_STATUS_SIZE) {
DRM_ERROR("DP link status read failed\n");
- dp_link_parse_request(link);
+ return len;
+ }
+
+ return dp_link_parse_request(link);
}
/**
@@ -1032,7 +1039,10 @@ int dp_link_process_request(struct dp_link *dp_link)
dp_link_reset_data(link);
- dp_link_parse_sink_status_field(link);
+ ret = dp_link_parse_sink_status_field(link);
+ if (ret) {
+ return ret;
+ }
if (link->request.test_requested == DP_TEST_LINK_EDID_READ) {
dp_link->sink_request |= DP_TEST_LINK_EDID_READ;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/4] check sink_count before update is_connected status
1) check sink_count before update is_connected status 2) initialize audio_comp when audio starts 3) check main link status before start aux read 4) dp_link_parse_sink_count() return immediately if aux read failed Kuogee Hsieh (4): drm/msm/dp: check sink_count before update is_connected status drm/msm/dp: initialize audio_comp when audio starts drm/msm/dp: check main link status before start aux read drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read failed drivers/gpu/drm/msm/dp/dp_audio.c | 1 + drivers/gpu/drm/msm/dp/dp_aux.c | 5 + drivers/gpu/drm/msm/dp/dp_display.c | 38 + drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dp/dp_link.c| 20 ++- 5 files changed, 48 insertions(+), 17 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/todo: Add link to old debugfs RFC
On Wed, Apr 21, 2021 at 12:59:18PM -0300, Melissa Wen wrote: > On 04/21, Daniel Vetter wrote: > > I always forget where it was, store it until this gets picked up by an > > internship again. > > > > Cc: Wambui Karuga > > Cc: Melissa Wen > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/todo.rst | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index 7ff9fac10d8b..12e61869939e 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -546,6 +546,8 @@ There's a bunch of issues with it: > >this (together with the drm_minor->drm_device move) would allow us to > > remove > >debugfs_init. > > > > +Previous RFC that hasn't landed yet: > > https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/ > > + > > Acked-by: Melissa Wen Pushed to drm-misc-next, thanks for taking a look. -Daniel > > > Contact: Daniel Vetter > > > > Level: Intermediate > > -- > > 2.31.0 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: Add E Ink to vendor bindings
On Mon, 19 Apr 2021 07:09:55 +1000, Alistair Francis wrote: > Add the E Ink Corporation to the vendor bindings. > > Signed-off-by: Alistair Francis > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add support for E Ink VB3300-KCA
On Mon, Apr 19, 2021 at 07:09:56AM +1000, Alistair Francis wrote:
> Add support for the 10.3" E Ink panel described at:
> https://www.eink.com/product.html?type=productdetail=7
>
> Signed-off-by: Alistair Francis
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 4e2dad314c79..f1f6fd2517f6 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1964,6 +1964,32 @@ static const struct panel_desc edt_etm0700g0bdh6 = {
> .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> };
>
> +static const struct display_timing eink_vb3300_kca_timing = {
> + .pixelclock = { 4000, 4000, 4000 },
> + .hactive = { 334, 334, 334 },
> + .hfront_porch = { 1, 1, 1 },
> + .hback_porch = { 1, 1, 1 },
> + .hsync_len = { 1, 1, 1 },
> + .vactive = { 1405, 1405, 1405 },
> + .vfront_porch = { 1, 1, 1 },
> + .vback_porch = { 1, 1, 1 },
> + .vsync_len = { 1, 1, 1 },
> + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
> + DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
> +};
> +
> +static const struct panel_desc eink_vb3300_kca = {
> + .modes = _etm0700g0dh6_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 157,
> + .height = 209,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> +};
> +
> static const struct display_timing evervision_vgg804821_timing = {
> .pixelclock = { 2760, 3330, 5000 },
> .hactive = { 800, 800, 800 },
> @@ -4232,6 +4258,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "edt,etm0700g0dh6",
> .data = _etm0700g0dh6,
> + }, {
> + .compatible = "eink,vb3300-kca",
You have to document this string too.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
Hi Marek,
Thank you for the patch.
On Thu, Apr 22, 2021 at 12:31:21AM +0200, Marek Vasut wrote:
> Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
>
> Signed-off-by: Marek Vasut
> Cc: Douglas Anderson
> Cc: Jagan Teki
> Cc: Laurent Pinchart
> Cc: Linus Walleij
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: Stephen Boyd
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
> V2: Add compatible string for SN65DSI84, since this is now tested on it
> ---
> .../bindings/display/bridge/ti,sn65dsi83.yaml | 134 ++
> 1 file changed, 134 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> new file mode 100644
> index ..42d11b46a1eb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> @@ -0,0 +1,134 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
> +
> +maintainers:
> + - Marek Vasut
> +
> +description: |
> + Texas Instruments SN65DSI83 1x Single-link MIPI DSI
> + to 1x Single-link LVDS
> + https://www.ti.com/lit/gpn/sn65dsi83
> + Texas Instruments SN65DSI84 1x Single-link MIPI DSI
> + to 1x Dual-link or 2x Single-link LVDS
> + https://www.ti.com/lit/gpn/sn65dsi84
> +
> +properties:
> + compatible:
> +oneOf:
> + - const: ti,sn65dsi83
> + - const: ti,sn65dsi84
> +
> + reg:
> +const: 0x2d
> +
> + enable-gpios:
> +maxItems: 1
> +description: GPIO specifier for bridge_en pin (active high).
> +
> + ports:
> +type: object
Could you use the OF graph schema, now that it is available ? There
should be plenty of examples in bindings, both in display and in media.
You will be able to drop quite a bit of boilerplate.
> +additionalProperties: false
> +
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +additionalProperties: false
> +
> +description:
> + Video port for MIPI DSI input
> +
> +properties:
> + reg:
> +const: 0
> +
> + endpoint:
> +type: object
> +additionalProperties: false
> +properties:
> + remote-endpoint: true
> + data-lanes:
> +description: array of physical DSI data lane indexes.
> +
> +required:
> + - reg
> +
> + port@1:
> +type: object
> +additionalProperties: false
> +
> +description:
> + Video port for LVDS output (panel or bridge).
> +
> +properties:
> + reg:
> +const: 1
> +
> + endpoint:
> +type: object
> +additionalProperties: false
> +properties:
> + remote-endpoint: true
> +
> +required:
> + - reg
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - enable-gpios
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
While not a hard rule, it's customary to indent DT examples with 4
spaces. I find it to increase readability, but if you feel otherwise,
that's OK.
> +
> + bridge@2d {
> +compatible = "ti,sn65dsi83";
> +reg = <0x2d>;
> +
> +enable-gpios = < 1 GPIO_ACTIVE_HIGH>;
> +
> +ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> +reg = <0>;
> +endpoint {
> + remote-endpoint = <_out>;
> + data-lanes = <1 2 3 4>;
> +};
> + };
> +
> + port@1 {
> +reg = <1>;
> +endpoint {
> + remote-endpoint = <_in_lvds>;
> +};
> + };
> +};
> + };
> +};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add bindings for SN65DSI83/84/85
On 4/8/21 4:45 PM, Jagan Teki wrote: On Wed, Mar 24, 2021 at 7:26 PM Claudius Heine wrote: Hi Jagan, On 2021-02-14 18:44, Jagan Teki wrote: SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge controller IC's from Texas Instruments. SN65DSI83 - Single Channel DSI to Single-link LVDS bridge SN65DSI84 - Single Channel DSI to Dual-link LVDS bridge SN65DSI85 - Dual Channel DSI to Dual-link LVDS bridge Right now the bridge driver is supporting Channel A with single link, so dt-bindings documented according to it. Do you know when we can expect a v4 for this? I am currently working on top of your patch set to setup a dual-link LVDS bridge of SN65DSI84. Yes, I'm planning to send v4 this week. will keep you in CC. thanks! I haven't seen any activity here for over two weeks, so I decided to send V2 of the driver I wrote, now tested on both DSI83 and DSI84. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, but easy to add. The driver operates the chip via I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation. Support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed. Signed-off-by: Marek Vasut Cc: Douglas Anderson Cc: Jagan Teki Cc: Laurent Pinchart Cc: Linus Walleij Cc: Philippe Schenker Cc: Sam Ravnborg Cc: Stephen Boyd Cc: Valentin Raevsky To: dri-devel@lists.freedesktop.org --- V2: - Use dev_err_probe() - Set REG_RC_RESET as volatile - Wait for PLL stabilization by polling REG_RC_LVDS_PLL - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set - Add tested DSI84 support in dual-link mode - Correctly set VCOM - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 datasheets, with that all the reserved bits make far more sense as the DSI83 and DSI84 seems to be reduced version of DSI85 --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 617 ++ 3 files changed, 628 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index cc401786962a..4cd2712f90fd 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -234,6 +234,16 @@ config DRM_TI_TFP410 help Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI83 + tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + select DRM_MIPI_DSI + help + Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver + config DRM_TI_SN65DSI86 tristate "TI SN65DSI86 DSI to eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 21ea8fe09992..e11415db0a31 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c new file mode 100644 index ..2471ee4c77b6 --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -0,0 +1,617 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * TI SN65DSI83,84,85 driver + * + * Currently supported: + * - SN65DSI83 + * = 1x Single-link DSI ~ 1x Single-link LVDS + * - Supported + * - Single-link LVDS mode tested + * - SN65DSI84 + * = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS + * - Supported + * - Dual-link LVDS mode tested + * - 2x Single-link LVDS mode unsupported + * (should be easy to add by someone who has the HW) + * - SN65DSI85 + * = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS + * - Unsupported + * (should be easy to add by someone who has the HW) + * + * Copyright (C) 2021 Marek Vasut + * + * Based on previous work of: + * Valentin Raevsky + * Philippe Schenker + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +/* ID registers */ +#define REG_ID(n) (0x00 + (n)) +/* Reset and clock registers */ +#define REG_RC_RESET 0x09 +#define REG_RC_RESET_SOFT_RESET BIT(0) +#define REG_RC_LVDS_PLL0x0a +#define REG_RC_LVDS_PLL_PLL_EN_STAT BIT(7) +#define REG_RC_LVDS_PLL_LVDS_CLK_RANGE(n) (((n) & 0x7) << 1) +#define REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY BIT(0) +#define REG_RC_DSI_CLK 0x0b +#define REG_RC_DSI_CLK_DSI_CLK_DIVIDER(n) (((n) & 0x1f) << 3) +#define REG_RC_DSI_CLK_REFCLK_MULTIPLIER(n) ((n) & 0x3) +#define REG_RC_PLL_EN 0x0d +#define REG_RC_PLL_EN_PLL_EN BIT(0) +/* DSI registers */ +#define REG_DSI_LANE 0x10 +#define REG_DSI_LANE_LVDS_LINK_CFG_DUAL BIT(5) /* dual or 2x single */ +#define REG_DSI_LANE_CHA_DSI_LANES(n) (((n) & 0x3) << 3) +#define
[PATCH V2 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
Signed-off-by: Marek Vasut
Cc: Douglas Anderson
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Stephen Boyd
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: Add compatible string for SN65DSI84, since this is now tested on it
---
.../bindings/display/bridge/ti,sn65dsi83.yaml | 134 ++
1 file changed, 134 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
new file mode 100644
index ..42d11b46a1eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
+
+maintainers:
+ - Marek Vasut
+
+description: |
+ Texas Instruments SN65DSI83 1x Single-link MIPI DSI
+ to 1x Single-link LVDS
+ https://www.ti.com/lit/gpn/sn65dsi83
+ Texas Instruments SN65DSI84 1x Single-link MIPI DSI
+ to 1x Dual-link or 2x Single-link LVDS
+ https://www.ti.com/lit/gpn/sn65dsi84
+
+properties:
+ compatible:
+oneOf:
+ - const: ti,sn65dsi83
+ - const: ti,sn65dsi84
+
+ reg:
+const: 0x2d
+
+ enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge_en pin (active high).
+
+ ports:
+type: object
+additionalProperties: false
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+additionalProperties: false
+
+description:
+ Video port for MIPI DSI input
+
+properties:
+ reg:
+const: 0
+
+ endpoint:
+type: object
+additionalProperties: false
+properties:
+ remote-endpoint: true
+ data-lanes:
+description: array of physical DSI data lane indexes.
+
+required:
+ - reg
+
+ port@1:
+type: object
+additionalProperties: false
+
+description:
+ Video port for LVDS output (panel or bridge).
+
+properties:
+ reg:
+const: 1
+
+ endpoint:
+type: object
+additionalProperties: false
+properties:
+ remote-endpoint: true
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2d {
+compatible = "ti,sn65dsi83";
+reg = <0x2d>;
+
+enable-gpios = < 1 GPIO_ACTIVE_HIGH>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+endpoint {
+ remote-endpoint = <_out>;
+ data-lanes = <1 2 3 4>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+endpoint {
+ remote-endpoint = <_in_lvds>;
+};
+ };
+};
+ };
+};
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: umn experiment patches fallout in drm
On Wed, Apr 21, 2021 at 2:58 PM Dave Airlie wrote: > > Looking at the umn.edu patches for drm in the last while, all the > refcount ones look bogus, > > 2020-06-13 20:48 -0500 Aditya Pakki o drm/nouveau: fix reference count > leak in nouveau_debugfs_strap_peek > 2020-06-13 20:22 -0500 Aditya Pakki o drm/nouveau: Fix reference count > leak in nouveau_connector_detect > 2020-06-13 20:29 -0500 Aditya Pakki o drm/nouveau: fix reference count > leak in nv50_disp_atomic_commit > 2020-06-13 20:41 -0500 Aditya Pakki o drm/nouveau: fix multiple > instances of reference count leaks > 2020-06-13 20:33 -0500 Aditya Pakki o drm/nouveau/drm/noveau: fix > reference count leak in nouveau_fbcon_open > 2020-06-13 21:21 -0500 Aditya Pakki │ o drm/radeon: Fix reference > count leaks caused by pm_runtime_get_sync > 2020-06-13 20:55 -0500 Aditya Pakki │ │ o drm/radeon: fix multiple > reference count leak For these two, I don't think there's any harm to them. Other drivers in the kernel seem to be inconsistent with respect to checking the return value of pm_runtime_get_sync(). The documentation says that the function increments the use count even if the function returns an error, so we should in theory be decrementing it again if it fails. It's not clear what the recommended handling of this case is in the runtime pm documentation. If the resume failed do you want to leave the device active, or attempt to suspend it again to save power? Beyond that, checking the return value of this function has since spread elsewhere in the driver where we call pm_runtime_get_sync() so removing all of that will be a bigger task. > 2020-06-13 14:32 -0500 Qiushi Wu│ │ │ o drm/amdkfd: Fix reference > count leaks. + Felix Felix took a look at this and thought it was still a legitimate fix. Alex > > These ones look sane but maybe we should revert them all anyways. > > 2019-12-15 13:43 -0600 Aditya Pakki │ │ │ │ o drm: remove duplicate > check on parent and avoid BUG_ON > 2019-10-17 23:41 -0500 Kangjie Lu │ │ │ │ │ o drm/gma500: fix memory > disclosures due to uninitialized bytes > 2019-10-17 23:29 -0500 Kangjie Lu │ │ │ │ │ o gma/gma500: fix a > memory disclosure bug due to uninitialized bytes > 2019-03-24 18:16 -0500 Kangjie Lu │ │ │ │ │ │ o drm/v3d: fix a > missing check of pm_runtime_get_sync > 2019-03-08 22:36 -0600 Kangjie Lu │ │ │ │ │ │ │ o drm: vkms: check > status of alloc_ordered_workqueue > > Ben, Alex can you line up reverts for next for all of the > nouveau/amdgpu/radeon ones? > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.12
Hi Dave, Daniel, A few late fixes for 5.12. The following changes since commit 796b556cbfdbe0d65b9793e63653ad24f9fa033c: Merge tag 'vmwgfx-fixes-2021-04-14' of gitlab.freedesktop.org:zack/vmwgfx into drm-fixes (2021-04-18 09:27:00 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.12-2021-04-21 for you to fetch changes up to 24d034528ef06ad94cfcf4394beac0443ab1b16d: drm/amdgpu: fix GCR_GENERAL_CNTL offset for dimgrey_cavefish (2021-04-21 11:19:26 -0400) amd-drm-fixes-5.12-2021-04-21: amdgpu: - Fix gpuvm page table update issue - Modifier fixes - Register fix for dimgrey cavefish Jiansong Chen (1): drm/amdgpu: fix GCR_GENERAL_CNTL offset for dimgrey_cavefish Philip Yang (1): drm/amdgpu: reserve fence slot to update page table Qingqing Zhuo (1): drm/amd/display: Update modifier list for gfx10_3 Simon Ser (1): amd/display: allow non-linear multi-planar formats drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 10 -- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 ++- 3 files changed, 15 insertions(+), 12 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Rename DP_PSR_SELECTIVE_UPDATE to better mach eDP spec
DP_PSR_EN_CFG bit 5 aka "Selective Update Region Scan Line Capture Indication" in eDP spec has a ambiguous name, so renaming to better match specification. While at it, replacing bit shit by BIT() macro and adding the version some registers were added to eDP specification. Cc: Cc: Rodrigo Vivi Cc: Jani Nikula Cc: Gwan-gyeong Mun Signed-off-by: José Roberto de Souza --- include/drm/drm_dp_helper.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1e85c2021f2f..d6f6a084a190 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -687,14 +687,14 @@ struct drm_device; #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ # define DP_DECOMPRESSION_EN(1 << 0) -#define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ -# define DP_PSR_ENABLE (1 << 0) -# define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) -# define DP_PSR_CRC_VERIFICATION (1 << 2) -# define DP_PSR_FRAME_CAPTURE (1 << 3) -# define DP_PSR_SELECTIVE_UPDATE (1 << 4) -# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) -# define DP_PSR_ENABLE_PSR2(1 << 6) /* eDP 1.4a */ +#define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ +# define DP_PSR_ENABLE BIT(0) +# define DP_PSR_MAIN_LINK_ACTIVE BIT(1) +# define DP_PSR_CRC_VERIFICATION BIT(2) +# define DP_PSR_FRAME_CAPTURE BIT(3) +# define DP_PSR_SU_REGION_SCANLINE_CAPTURE BIT(4) /* eDP 1.4a */ +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORSBIT(5) /* eDP 1.4a */ +# define DP_PSR_ENABLE_PSR2BIT(6) /* eDP 1.4a */ #define DP_ADAPTER_CTRL0x1a0 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 9/9] drm/i915: Add privacy-screen support
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:
for_each_new_connector_in_state(>base, connector, ...
drm_connector_update_privacy_screen(connector, state);
It may seem more logical to instead take care of updating the
privacy-screen state by marking the crtc as needing a modeset and then
do this in both the encoder update_pipe (for fast-sets) and enable
(for full modesets) callbacks. But ATM these callbacks only get passed
the new connector_state and these callbacks are all called after
drm_atomic_helper_swap_state() at which point there is no way to get
the old state from the new state.
Without access to the old state, we do not know if the sw_state of
the privacy-screen has changes so we would need to call
drm_privacy_screen_set_sw_state() unconditionally. This is undesirable
since all current known privacy-screen providers use ACPI calls which
are somewhat expensive to make.
Also, as all providers use ACPI calls, rather then poking GPU registers,
there is no need to order this together with other encoder operations.
Since no GPU poking is involved having this as a separate step of the
commit process actually is the logical thing to do.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
drivers/gpu/drm/i915/i915_pci.c | 12
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a10e26380ef3..b11fcc660446 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10159,6 +10159,8 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
struct drm_device *dev = state->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
+ struct drm_connector_state *new_connector_state;
+ struct drm_connector *connector;
struct intel_crtc *crtc;
u64 put_domains[I915_MAX_PIPES] = {};
intel_wakeref_t wakeref = 0;
@@ -10256,6 +10258,9 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_color_load_luts(new_crtc_state);
}
+ for_each_new_connector_in_state(>base, connector,
new_connector_state, i)
+ drm_connector_update_privacy_screen(connector, >base);
+
/*
* Now that the vblank has passed, we can go ahead and program the
* optimal watermarks on platforms that need two-step watermark
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 52ea09fc5e70..57864782d922 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include "g4x_dp.h"
@@ -5178,6 +5179,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
struct drm_connector *connector = _connector->base;
struct drm_display_mode *fixed_mode = NULL;
struct drm_display_mode *downclock_mode = NULL;
+ struct drm_privacy_screen *privacy_screen;
bool has_dpcd;
enum pipe pipe = INVALID_PIPE;
struct edid *edid;
@@ -5268,6 +5270,14 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
fixed_mode->hdisplay, fixed_mode->vdisplay);
}
+ privacy_screen = drm_privacy_screen_get(>pdev->dev, NULL);
+ if (!IS_ERR(privacy_screen)) {
+ drm_connector_attach_privacy_screen_provider(connector,
+privacy_screen);
+ } else if (PTR_ERR(privacy_screen) != -ENODEV) {
+ drm_warn(_priv->drm, "Error getting privacy-screen\n");
+ }
+
return true;
out_vdd_off:
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7786217638ed..09d52ecc3713 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include "display/intel_fbdev.h"
@@ -1067,6 +1068,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
{
struct intel_device_info *intel_info =
(struct intel_device_info *) ent->driver_data;
+ struct drm_privacy_screen *privacy_screen;
int err;
if (intel_info->require_force_probe &&
@@ -1095,7 +1097,17 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
+ /*
+* We do not handle
[PATCH v2 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also allow the GPU driver to get a handle to it and export
the privacy-screen setting as a property on the DRM connector object
for the LCD panel. This DRM connector property is news standardized
interface which all user-space code should use to query and control
the privacy-screen.
Signed-off-by: Hans de Goede
---
Changes in v2:
- Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
lcdshadow_ops symbols static
- Update state and call drm_privacy_screen_call_notifier_chain()
when the state is changed by pressing the Fn + D hotkey combo
---
drivers/platform/x86/Kconfig | 2 +
drivers/platform/x86/thinkpad_acpi.c | 91
2 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 461ec61530eb..ae49f1658aba 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -484,7 +484,9 @@ config THINKPAD_ACPI
depends on RFKILL || RFKILL = n
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on BACKLIGHT_CLASS_DEVICE
+ depends on DRM
select ACPI_PLATFORM_PROFILE
+ select DRM_PRIVACY_SCREEN
select HWMON
select NVRAM
select NEW_LEDS
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index fe919700b8ae..766c6d64b0fb 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -73,6 +73,7 @@
#include
#include
#include
+#include
/* ThinkPad CMOS commands */
#define TP_CMOS_VOLUME_DOWN0
@@ -156,6 +157,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute */
TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
+ TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */
/* Reasons for waking up from S3/S4 */
TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
@@ -3882,6 +3884,12 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
{
unsigned int scancode;
+ switch (hkey) {
+ case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
+ tpacpi_driver_event(hkey);
+ return true;
+ }
+
/* Extended keycodes start at 0x300 and our offset into the map
* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
* will be positive, but might not be in the correct range.
@@ -9759,30 +9767,40 @@ static struct ibm_struct battery_driver_data = {
* LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
*/
+static struct drm_privacy_screen *lcdshadow_dev;
static acpi_handle lcdshadow_get_handle;
static acpi_handle lcdshadow_set_handle;
-static int lcdshadow_state;
-static int lcdshadow_on_off(bool state)
+static int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
+ enum drm_privacy_screen_status state)
{
int output;
+ if (WARN_ON(!mutex_is_locked(>lock)))
+ return -EIO;
+
if (!acpi_evalf(lcdshadow_set_handle, , NULL, "dd", (int)state))
return -EIO;
- lcdshadow_state = state;
+ priv->hw_state = priv->sw_state = state;
return 0;
}
-static int lcdshadow_set(bool on)
+static void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
{
- if (lcdshadow_state < 0)
- return lcdshadow_state;
- if (lcdshadow_state == on)
- return 0;
- return lcdshadow_on_off(on);
+ int output;
+
+ if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0))
+ return;
+
+ priv->hw_state = priv->sw_state = output & 0x1;
}
+static const struct drm_privacy_screen_ops lcdshadow_ops = {
+ .set_sw_state = lcdshadow_set_sw_state,
+ .get_hw_state = lcdshadow_get_hw_state,
+};
+
static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
{
acpi_status status1, status2;
@@ -9790,36 +9808,44 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct
*iibm)
status1 = acpi_get_handle(hkey_handle, "GSSS", _get_handle);
status2 = acpi_get_handle(hkey_handle, "", _set_handle);
- if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
- lcdshadow_state = -ENODEV;
+ if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2))
return 0;
- }
- if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0)) {
- lcdshadow_state = -EIO;
+ if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0))
return -EIO;
-
[PATCH v2 5/9] drm/connector: Add a drm_connector privacy-screen helper functions
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen status.
2. drm_connector_update_privacy_screen(), Check if the passed in atomic
state contains a privacy-screen sw_state change for the connector and if
it does, call drm_privacy_screen_set_sw_state() with the new sw_state.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 113
include/drm/drm_connector.h | 12
2 files changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ca8a76decd4c..958a332374af 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -20,6 +20,7 @@
* OF THIS SOFTWARE.
*/
+#include
#include
#include
#include
@@ -27,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -451,6 +453,11 @@ void drm_connector_cleanup(struct drm_connector *connector)
DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
+ if (connector->privacy_screen) {
+ drm_privacy_screen_put(connector->privacy_screen);
+ connector->privacy_screen = NULL;
+ }
+
if (connector->tile_group) {
drm_mode_put_tile_group(dev, connector->tile_group);
connector->tile_group = NULL;
@@ -530,6 +537,10 @@ int drm_connector_register(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(connector->dev);
+ if (connector->privacy_screen)
+ drm_privacy_screen_register_notifier(connector->privacy_screen,
+ >privacy_screen_notifier);
+
goto unlock;
err_debugfs:
@@ -558,6 +569,11 @@ void drm_connector_unregister(struct drm_connector
*connector)
return;
}
+ if (connector->privacy_screen)
+ drm_privacy_screen_unregister_notifier(
+ connector->privacy_screen,
+ >privacy_screen_notifier);
+
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
@@ -2353,6 +2369,103 @@ drm_connector_attach_privacy_screen_properties(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
+static void drm_connector_update_privacy_screen_properties(
+ struct drm_connector *connector)
+{
+ enum drm_privacy_screen_status sw_state, hw_state;
+
+ drm_privacy_screen_get_state(connector->privacy_screen,
+_state, _state);
+
+ connector->state->privacy_screen_sw_state = sw_state;
+ drm_object_property_set_value(>base,
+ connector->privacy_screen_hw_state_property, hw_state);
+}
+
+static int drm_connector_privacy_screen_notifier(
+ struct notifier_block *nb, unsigned long action, void *data)
+{
+ struct drm_connector *connector =
+ container_of(nb, struct drm_connector, privacy_screen_notifier);
+ struct drm_device *dev = connector->dev;
+
+ drm_modeset_lock(>mode_config.connection_mutex, NULL);
+ drm_connector_update_privacy_screen_properties(connector);
+ drm_modeset_unlock(>mode_config.connection_mutex);
+
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_sw_state_property);
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_hw_state_property);
+
+ return NOTIFY_DONE;
+}
+
+/**
+ * drm_connector_attach_privacy_screen_provider - attach a privacy-screen to
+ *the connector
+ * @connector: connector to attach the privacy-screen to
+ * @priv: drm_privacy_screen to attach
+ *
+ * Create and attach the standard privacy-screen properties and register
+ * a generic notifier for generating sysfs-connector-status-events
+ * on external changes to the privacy-screen status.
+ * This function takes ownership of the passed in drm_privacy_screen and will
+ * call drm_privacy_screen_put() on it when the connector is destroyed.
+ */
+void drm_connector_attach_privacy_screen_provider(
+ struct drm_connector *connector, struct drm_privacy_screen *priv)
+{
+ connector->privacy_screen = priv;
+ connector->privacy_screen_notifier.notifier_call =
+ drm_connector_privacy_screen_notifier;
+
+ drm_connector_create_privacy_screen_properties(connector);
+ drm_connector_update_privacy_screen_properties(connector);
+ drm_connector_attach_privacy_screen_properties(connector);
+}
[PATCH v2 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 683c175cc28a..fe919700b8ae 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9759,19 +9759,15 @@ static struct ibm_struct battery_driver_data = {
* LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
*/
+static acpi_handle lcdshadow_get_handle;
+static acpi_handle lcdshadow_set_handle;
static int lcdshadow_state;
static int lcdshadow_on_off(bool state)
{
- acpi_handle set_shadow_handle;
int output;
- if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "",
_shadow_handle))) {
- pr_warn("Thinkpad ACPI has no %s interface.\n", "");
- return -EIO;
- }
-
- if (!acpi_evalf(set_shadow_handle, , NULL, "dd", (int)state))
+ if (!acpi_evalf(lcdshadow_set_handle, , NULL, "dd", (int)state))
return -EIO;
lcdshadow_state = state;
@@ -9789,15 +9785,17 @@ static int lcdshadow_set(bool on)
static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
{
- acpi_handle get_shadow_handle;
+ acpi_status status1, status2;
int output;
- if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "GSSS",
_shadow_handle))) {
+ status1 = acpi_get_handle(hkey_handle, "GSSS", _get_handle);
+ status2 = acpi_get_handle(hkey_handle, "", _set_handle);
+ if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
lcdshadow_state = -ENODEV;
return 0;
}
- if (!acpi_evalf(get_shadow_handle, , NULL, "dd", 0)) {
+ if (!acpi_evalf(lcdshadow_get_handle, , NULL, "dd", 0)) {
lcdshadow_state = -EIO;
return -EIO;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 30 ++--
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 0d9e2ddbf904..683c175cc28a 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3878,6 +3878,24 @@ static bool
adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
}
}
+static bool hotkey_notify_extended_hotkey(const u32 hkey)
+{
+ unsigned int scancode;
+
+ /* Extended keycodes start at 0x300 and our offset into the map
+* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
+* will be positive, but might not be in the correct range.
+*/
+ scancode = (hkey & 0xfff) - (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
+ if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
+ scancode < TPACPI_HOTKEY_MAP_LEN) {
+ tpacpi_input_send_key(scancode);
+ return true;
+ }
+
+ return false;
+}
+
static bool hotkey_notify_hotkey(const u32 hkey,
bool *send_acpi_ev,
bool *ignore_acpi_ev)
@@ -3912,17 +3930,7 @@ static bool hotkey_notify_hotkey(const u32 hkey,
return adaptive_keyboard_hotkey_notify_hotkey(scancode);
case 3:
- /* Extended keycodes start at 0x300 and our offset into the map
-* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
-* will be positive, but might not be in the correct range.
-*/
- scancode -= (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
- if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
- scancode < TPACPI_HOTKEY_MAP_LEN) {
- tpacpi_input_send_key(scancode);
- return true;
- }
- break;
+ return hotkey_notify_extended_hotkey(hkey);
}
return false;
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/9] drm/privacy-screen: Add notifier support
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++
include/drm/drm_privacy_screen_consumer.h | 15 +
include/drm/drm_privacy_screen_driver.h | 4 ++
3 files changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/drm_privacy_screen.c
b/drivers/gpu/drm/drm_privacy_screen.c
index 294a09194bfb..7a5f878c3171 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -255,6 +255,49 @@ void drm_privacy_screen_get_state(struct
drm_privacy_screen *priv,
}
EXPORT_SYMBOL(drm_privacy_screen_get_state);
+/**
+ * drm_privacy_screen_register_notifier - register a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Register a notifier with the privacy-screen to be notified of changes made
+ * to the privacy-screen state from outside of the privacy-screen class.
+ * E.g. the state may be changed by the hardware itself in response to a
+ * hotkey press.
+ *
+ * The notifier is called with no locks held. The new hw_state and sw_state
+ * can be retrieved using the drm_privacy_screen_get_state() function.
+ * A pointer to the drm_privacy_screen's struct is passed as the void *data
+ * argument of the notifier_block's notifier_call.
+ *
+ * The notifier will NOT be called when changes are made through
+ * drm_privacy_screen_set_sw_state(). It is only called for external changes.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(>notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_register_notifier);
+
+/**
+ * drm_privacy_screen_unregister_notifier - unregister a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Unregister a notifier registered with
drm_privacy_screen_register_notifier().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+ struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(>notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister_notifier);
+
/*** drm_privacy_screen_driver.h functions ***/
static ssize_t sw_state_show(struct device *dev,
@@ -352,6 +395,7 @@ struct drm_privacy_screen *drm_privacy_screen_register(
return ERR_PTR(-ENOMEM);
mutex_init(>lock);
+ BLOCKING_INIT_NOTIFIER_HEAD(>notifier_head);
priv->dev.class = drm_class;
priv->dev.type = _privacy_screen_type;
@@ -399,3 +443,26 @@ void drm_privacy_screen_unregister(struct
drm_privacy_screen *priv)
device_unregister(>dev);
}
EXPORT_SYMBOL(drm_privacy_screen_unregister);
+
+/**
+ * drm_privacy_screen_call_notifier_chain - notify consumers of state change
+ * @priv: Privacy screen to register the notifier with
+ *
+ * A privacy-screen provider driver can call this functions upon external
+ * changes to the privacy-screen state. E.g. the state may be changed by the
+ * hardware itself in response to a hotkey press.
+ * This function must be called without holding the privacy-screen lock.
+ * the driver must update sw_state and hw_state to reflect the new state before
+ * calling this function.
+ * The expected behavior from the driver upon receiving an external state
+ * change event is: 1. Take the lock; 2. Update sw_state and hw_state;
+ * 3. Release the lock. 4. Call drm_privacy_screen_call_notifier_chain().
+ */
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv)
+{
+ if (WARN_ON(mutex_is_locked(>lock)))
+ return;
+
+ blocking_notifier_call_chain(>notifier_head, 0, priv);
+}
+EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
diff --git a/include/drm/drm_privacy_screen_consumer.h
b/include/drm/drm_privacy_screen_consumer.h
index 941c88b46889..31746a745439 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
drm_privacy_screen *priv,
void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
enum drm_privacy_screen_status *sw_state_ret,
enum drm_privacy_screen_status *hw_state_ret);
+
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+struct notifier_block *nb);
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+ struct
[PATCH v2 3/9] drm/privacy-screen: Add X86 specific arch init code
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_privacy_screen_x86.c | 86
include/drm/drm_privacy_screen_machine.h | 5 ++
3 files changed, 92 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 578853d18a3d..2e226b57de24 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,7 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
drm_privacy_screen_x86.o
drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c
b/drivers/gpu/drm/drm_privacy_screen_x86.c
new file mode 100644
index ..a2cafb294ca6
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede
+ */
+
+#include
+#include
+
+#ifdef CONFIG_X86
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+ struct drm_privacy_screen_lookup lookup;
+ bool (*detect)(void);
+};
+
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
+ void *context, void **return_value)
+{
+ *(acpi_handle *)return_value = handle;
+ return AE_CTRL_TERMINATE;
+}
+
+static bool __init detect_thinkpad_privacy_screen(void)
+{
+ union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
+ struct acpi_object_list args = { .count = 1, .pointer = , };
+ acpi_handle ec_handle = NULL;
+ unsigned long long output;
+ acpi_status status;
+
+ /* Get embedded-controller handle */
+ status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL, _handle);
+ if (ACPI_FAILURE(status) || !ec_handle)
+ return false;
+
+ /* And call the privacy-screen get-status method */
+ status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", , );
+ if (ACPI_FAILURE(status))
+ return false;
+
+ return (output & 0x1) ? true : false;
+}
+#endif
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+ {
+ .lookup = {
+ .dev_id = NULL,
+ .con_id = NULL,
+ .provider = "privacy_screen-thinkpad_acpi",
+ },
+ .detect = detect_thinkpad_privacy_screen,
+ },
+#endif
+};
+
+void __init drm_privacy_screen_lookup_init(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(arch_init_data); i++) {
+ if (!arch_init_data[i].detect())
+ continue;
+
+ pr_info("Found '%s' privacy-screen provider\n",
+ arch_init_data[i].lookup.provider);
+
+ /* Make a copy because arch_init_data is __initconst */
+ arch_lookup = arch_init_data[i].lookup;
+ drm_privacy_screen_lookup_add(_lookup);
+ break;
+ }
+}
+
+void drm_privacy_screen_lookup_exit(void)
+{
+ if (arch_lookup.provider)
+ drm_privacy_screen_lookup_remove(_lookup);
+}
+#endif /* ifdef CONFIG_X86 */
diff --git a/include/drm/drm_privacy_screen_machine.h
b/include/drm/drm_privacy_screen_machine.h
index aaa0d38cce92..02e5371904d3 100644
--- a/include/drm/drm_privacy_screen_machine.h
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -31,11 +31,16 @@ struct drm_privacy_screen_lookup {
void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup
*lookup);
+#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
+void drm_privacy_screen_lookup_init(void);
+void drm_privacy_screen_lookup_exit(void);
+#else
static inline void drm_privacy_screen_lookup_init(void)
{
}
static inline void drm_privacy_screen_lookup_exit(void)
{
}
+#endif
#endif
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/9] drm/connector: Add support for privacy-screen properties (v4)
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
locked out of making state changes
- Write kerneldoc explaining how the 2 properties work together, what
happens when changes to the state are made outside of the DRM code's
control, etc.
Changes in v3 (Hans de Goede)
- Some small tweaks to the kerneldoc describing the 2 properties
Changes in v4 (Hans de Goede)
- Change the "Enabled, locked" and "Disabled, locked" hw-state enum value
names to "Enabled-locked" and "Disabled-locked". The xrandr command shows
all possible enum values separated by commas in its output, so having a
comma in an enum name is not a good idea.
- Do not add a privacy_screen_hw_state member to drm_connector_state
since this property is immutable its value must be directly stored in the
obj->properties->values array
Signed-off-by: Rajat Jain
Co-authored-by: Hans de Goede
Acked-by: Pekka Paalanen
Reviewed-by: Mario Limonciello
Signed-off-by: Hans de Goede
---
Documentation/gpu/drm-kms.rst | 2 +
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 101 ++
include/drm/drm_connector.h | 44 +
4 files changed, 151 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..36943f2b0c5d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -475,6 +475,8 @@ Property Types and Blob Property Support
.. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:
+.. _standard_connector_properties:
+
Standard Connector Properties
-
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..d5339b683156 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+ } else if (property == connector->privacy_screen_sw_state_property) {
+ state->privacy_screen_sw_state = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -873,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == connector->privacy_screen_sw_state_property) {
+ *val = state->privacy_screen_sw_state;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..ca8a76decd4c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1244,6 +1244,46 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* For DVI-I and TVout there is also a matching property "select
subconnector"
* allowing to switch between signal types.
* DP subconnector corresponds to a downstream port.
+ *
+ * privacy-screen sw-state, privacy-screen hw-state:
+ * These 2 optional properties can be used to query the state of the
+ * electronic privacy screen that is available on some displays; and in
+ * some cases also control the state. If a driver implements these
+ * properties then both properties must be present.
+ *
+ * "privacy-screen hw-state" is read-only and reflects the actual state
+ * of the privacy-screen, possible values: "Enabled", "Disabled,
+ * "Enabled-locked", "Disabled-locked". The locked states indicate
+ * that the state cannot be changed through the DRM API. E.g. there
+ * might be devices where the firmware-setup options, or a hardware
+ * slider-switch, offer always on / off modes.
+ *
+ * "privacy-screen sw-state" can be set to change the privacy-screen state
+ * when not locked. In this case the driver must update the hw-state
+ * property to reflect the new state on completion of the commit of the
+ * sw-state property. Setting the sw-state property when the hw-state is
+ * locked must be interpreted by the driver as a request to change the
+ * state to the set state when the hw-state becomes unlocked. E.g. if
+ * "privacy-screen hw-state" is "Enabled-locked" and the sw-state
+ * gets set
[PATCH v2 2/9] drm: Add privacy-screen class (v2)
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the driver for these
other devices to register themselves as a privacy-screen provider; and
allowing the drm/kms code to get a privacy-screen provider associated
with a specific GPU/connector combo.
Changes in v2:
- Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
code gets built as part of the main drm module rather then making it
a tristate which builds its own module.
- Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
drm_privacy_screen_consumer.h and define stubs when the check fails.
Together these 2 changes fix several dependency issues.
- Remove module related code now that this is part of the main drm.ko
- Use drm_class as class for the privacy-screen devices instead of
adding a separate class for this
Signed-off-by: Hans de Goede
---
Documentation/gpu/drm-kms-helpers.rst | 15 +
MAINTAINERS | 8 +
drivers/gpu/drm/Kconfig | 4 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_drv.c | 4 +
drivers/gpu/drm/drm_privacy_screen.c | 401 ++
include/drm/drm_privacy_screen_consumer.h | 48 +++
include/drm/drm_privacy_screen_driver.h | 80 +
include/drm/drm_privacy_screen_machine.h | 41 +++
9 files changed, 602 insertions(+)
create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
create mode 100644 include/drm/drm_privacy_screen_consumer.h
create mode 100644 include/drm/drm_privacy_screen_driver.h
create mode 100644 include/drm/drm_privacy_screen_machine.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 389892f36185..5d8715d2f998 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
+
+Privacy-screen class
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_privacy_screen_driver.h
+ :internal:
+
+.. kernel-doc:: include/drm/drm_privacy_screen_machine.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+ :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index 0c91cd07db3a..5d3e7729e57c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6131,6 +6131,14 @@ F: drivers/gpu/drm/drm_panel.c
F: drivers/gpu/drm/panel/
F: include/drm/drm_panel.h
+DRM PRIVACY-SCREEN CLASS
+M: Hans de Goede
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/drm_privacy_screen*
+F: include/drm/drm_privacy_screen*
+
DRM TTM SUBSYSTEM
M: Christian Koenig
M: Huang Rui
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3c16bd1afd87..698ea8a32b2a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -474,3 +474,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
config DRM_LIB_RANDOM
bool
default n
+
+config DRM_PRIVACY_SCREEN
+ bool
+ default n
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 89e747fedc00..578853d18a3d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
drm_vram_helper-y := drm_gem_vram_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c2f78dee9f2d..b33baa888be4 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -1030,6 +1031,7 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
+ drm_privacy_screen_lookup_exit();
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+ drm_privacy_screen_lookup_init();
+
drm_core_init_complete = true;
DRM_DEBUG("Initialized\n");
diff --git a/drivers/gpu/drm/drm_privacy_screen.c
b/drivers/gpu/drm/drm_privacy_screen.c
new file mode 100644
index ..294a09194bfb
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -0,0 +1,401 @@
+//
[PATCH v2 0/9] drm: Add privacy-screen class and connector properties
Hi All, Here is v2 of my series to add a privacy-screen class and connector properties. The only significantly changed patch in this v2 is: [2/9] drm: Add privacy-screen class (v2) which was modified to fix the dependency issues which the lkp kernel test robot, see the patches changelog for details. Here is the v1 cover-letter which is still up2date: Here is the privacy-screen related code which I last posted in August of last year. To the best of my knowledge there is consensus about / everyone is in agreement with the new userspace API (2 connector properties) this patch-set add (patch 1 of the series). The blocker the last time was that there were no userspace users of the new properties and as a rule we don't add new drm userspace API without users. There now is GNOME userspace code using the new properties: https://hackmd.io/@3v1n0/rkyIy3BOw The new API works as designed for this userspace user and the branches mentioned at the above link add the following features to GNOME: 1. Showing an OSD notification when the privacy-screen is toggled on/off through hotkeys handled by the embedded-controller 2. Allowing control of the privacy-screen from the GNOME control-panel, including the on/off slider shown there updating to match the hw-setting when the setting is changed with the control-panel open. 3. Restoring the last user-setting at login This series consists of a number of different parts: 1. A new version of Rajat's privacy-screen connector properties patch, this adds new userspace API in the form of new properties 2. Since on most devices the privacy screen is actually controlled by some vendor specific ACPI/WMI interface which has a driver under drivers/platform/x86, we need some "glue" code to make this functionality available to KMS drivers. Patches 2-4 add a new privacy-screen class for this, which allows non KMS drivers (and possibly KMS drivers too) to register a privacy-screen device and also adds an interface for KMS drivers to get access to the privacy-screen associated with a specific connector. This is modelled similar to how we deal with e.g. PWMs and GPIOs in the kernel, including separate includes for consumers and providers(drivers). 3. Some drm_connector helper functions to keep the actual changes needed for this in individual KMS drivers as small as possible (patch 5). 4. Make the thinkpad_acpi code register a privacy-screen device on ThinkPads with a privacy-screen (patches 6-8) 5. Make the i915 driver export the privacy-screen functionality through the connector properties on the eDP connector. I believe that it would be best to merge the entire series, including the thinkpad_acpi changes through drm-misc in one go. As the pdx86 subsys maintainer I hereby give my ack for merging the thinkpad_acpi changes through drm-misc. There is one small caveat with this series, which it is good to be aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads with an eprivacy screen, until the thinkpad_acpi driver is loaded. This means that initrd generation tools will need to be updated to include thinkpad_acpi when the i915 driver is added to the initrd. Without this the loading of the i915 driver will be delayed to after the switch to real rootfs. Regards, Hans Hans de Goede (8): drm: Add privacy-screen class (v2) drm/privacy-screen: Add X86 specific arch init code drm/privacy-screen: Add notifier support drm/connector: Add a drm_connector privacy-screen helper functions platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once platform/x86: thinkpad_acpi: Register a privacy-screen device drm/i915: Add privacy-screen support Rajat Jain (1): drm/connector: Add support for privacy-screen properties (v4) Documentation/gpu/drm-kms-helpers.rst| 15 + Documentation/gpu/drm-kms.rst| 2 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 4 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_atomic_uapi.c| 4 + drivers/gpu/drm/drm_connector.c | 214 + drivers/gpu/drm/drm_drv.c| 4 + drivers/gpu/drm/drm_privacy_screen.c | 468 +++ drivers/gpu/drm/drm_privacy_screen_x86.c | 86 drivers/gpu/drm/i915/display/intel_display.c | 5 + drivers/gpu/drm/i915/display/intel_dp.c | 10 + drivers/gpu/drm/i915/i915_pci.c | 12 + drivers/platform/x86/Kconfig | 2 + drivers/platform/x86/thinkpad_acpi.c | 131 -- include/drm/drm_connector.h | 56 +++ include/drm/drm_privacy_screen_consumer.h| 63 +++ include/drm/drm_privacy_screen_driver.h | 84 include/drm/drm_privacy_screen_machine.h | 46 ++ 19 files changed, 1173 insertions(+), 42 deletions(-) create mode 100644
[PATCH v2] drm/msm/dp: service only one irq_hpd if there are multiple irq_hpd pending
irq_hpd is an asynchronous event generated by panel to bring up attention
of host. It could only be generated at run time of normal operation and
it is not possible to be generated while main link is down. Therefore no
need to handle irq_hpd if main link is down, such as cable unplug or system
suspended. To handle irq_hpd, host has to read DPCD out of panel to figure
out what action requested and perform that action accordingly. Also only
handle the latest irq_hpd if there are multiple irq_hpd pending at the time
of service since panel contains only the latest irq_hpd request status.
Changes in v2:
-- re wording of commit test
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6..1107c4e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -707,6 +707,12 @@ static int dp_irq_hpd_handle(struct dp_display_private
*dp, u32 data)
return 0;
}
+ /*
+* handle only one irq_hpd in case of multiple irq_hpd pending
+* since panel contains the lateset request at this time
+*/
+ dp_del_event(dp, EV_IRQ_HPD_INT);
+
ret = dp_display_usbpd_attention_cb(>pdev->dev);
if (ret == -ECONNRESET) { /* cable unplugged */
dp->core_initialized = false;
@@ -1300,6 +1306,9 @@ static int dp_pm_suspend(struct device *dev)
/* host_init will be called at pm_resume */
dp->core_initialized = false;
+ /* suspending, no need to handle pending irq_hdps */
+ dp_del_event(dp, EV_IRQ_HPD_INT);
+
mutex_unlock(>event_mutex);
return 0;
@@ -1496,6 +1505,9 @@ int msm_dp_display_disable(struct msm_dp *dp, struct
drm_encoder *encoder)
/* stop sentinel checking */
dp_del_event(dp_display, EV_DISCONNECT_PENDING_TIMEOUT);
+ /* link is teared down, no need to handle pending irq_hdps */
+ dp_del_event(dp_display, EV_IRQ_HPD_INT);
+
dp_display_disable(dp_display, 0);
rc = dp_display_unprepare(dp);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm: drm_context.c: Adjust end of block comment
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by: Beatriz Martins de Carvalho --- drivers/gpu/drm/drm_context.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c index c99be950bf17..54e3c513d6a5 100644 --- a/drivers/gpu/drm/drm_context.c +++ b/drivers/gpu/drm/drm_context.c @@ -312,7 +312,8 @@ static int drm_context_switch_complete(struct drm_device *dev, /* If a context switch is ever initiated when the kernel holds the lock, release - that lock here. */ + that lock here. +*/ clear_bit(0, >context_flag); return 0; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm: drm_connector.c: Adjust end of block comment
Add a new line with */ on the last line of a block comment to follow the
Linux kernel coding conventions.
Problem found by checkpatch.
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/gpu/drm/drm_connector.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..8714f2d021f9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -279,7 +279,8 @@ int drm_connector_init(struct drm_device *dev,
drm_connector_get_cmdline_mode(connector);
/* We should add connectors at the end to avoid upsetting the connector
-* index too much. */
+* index too much.
+*/
spin_lock_irq(>connector_list_lock);
list_add_tail(>head, >connector_list);
config->num_connector++;
@@ -2288,7 +2289,8 @@ int drm_connector_property_set_ioctl(struct drm_device
*dev,
static struct drm_encoder *drm_connector_get_encoder(struct drm_connector
*connector)
{
/* For atomic drivers only state objects are synchronously updated and
-* protected by modeset locks, so check those first. */
+* protected by modeset locks, so check those first.
+*/
if (connector->state)
return connector->state->best_encoder;
return connector->encoder;
@@ -2450,7 +2452,8 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp->encoder_id = 0;
/* Only grab properties after probing, to make sure EDID and other
-* properties reflect the latest status. */
+* properties reflect the latest status.
+*/
ret = drm_mode_object_get_properties(>base,
file_priv->atomic,
(uint32_t __user *)(unsigned long)(out_resp->props_ptr),
(uint64_t __user *)(unsigned
long)(out_resp->prop_values_ptr),
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: drm_auth.c: Adjust end of block comment
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by: Beatriz Martins de Carvalho --- drivers/gpu/drm/drm_auth.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c index f2d46b7ac6f9..f00e5abdbbf4 100644 --- a/drivers/gpu/drm/drm_auth.c +++ b/drivers/gpu/drm/drm_auth.c @@ -300,7 +300,8 @@ int drm_master_open(struct drm_file *file_priv) int ret = 0; /* if there is no current master make this fd it, but do not create -* any master object for render clients */ +* any master object for render clients +*/ mutex_lock(>master_mutex); if (!dev->master) ret = drm_new_set_master(dev, file_priv); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: drm_bufs.c: Adjust end of block comment
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. Signed-off-by: Beatriz Martins de Carvalho --- drivers/gpu/drm/drm_bufs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index e3d77dfefb0a..731a42a31c44 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -325,7 +325,8 @@ static int drm_addmap_core(struct drm_device *dev, resource_size_t offset, /* dma_addr_t is 64bit on i386 with CONFIG_HIGHMEM64G, * As we're limiting the address to 2^32-1 (or less), * casting it down to 32 bits is no problem, but we -* need to point to a 64bit variable first. */ +* need to point to a 64bit variable first. +*/ map->handle = dma_alloc_coherent(dev->dev, map->size, >offset, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm: drm_atomic.c: Adjust end of block comment
Add a new line with */ on the last line of a block comment to follow the
Linux kernel coding conventions.
Problem found by checkpatch.
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/gpu/drm/drm_atomic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 46dceb51c90f..e42d9fc5d9ff 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -385,7 +385,8 @@ static int drm_atomic_crtc_check(const struct
drm_crtc_state *old_crtc_state,
/* The state->enable vs. state->mode_blob checks can be WARN_ON,
* as this is a kernel-internal detail that userspace should never
-* be able to trigger. */
+* be able to trigger.
+*/
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(new_crtc_state->enable && !new_crtc_state->mode_blob)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm: Adjust end of block comment
Add a new line with */ on the last line of a block comment to follow the Linux kernel coding conventions. Problem found by checkpatch. in tree dpu/drm Beatriz Martins de Carvalho (5): drm: drm_atomic.c: Adjust end of block comment drm: drm_auth.c: Adjust end of block comment drm: drm_bufs.c: Adjust end of block comment drm: drm_connector.c: Adjust end of block comment drm: drm_context.c: Adjust end of block comment drivers/gpu/drm/drm_atomic.c| 3 ++- drivers/gpu/drm/drm_auth.c | 3 ++- drivers/gpu/drm/drm_bufs.c | 3 ++- drivers/gpu/drm/drm_connector.c | 9 ++--- drivers/gpu/drm/drm_context.c | 3 ++- 5 files changed, 14 insertions(+), 7 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: drm_connector.c: Use tabs for code indents
Remove space and use tabs for indent the code to follow the
Linux kernel coding conventions.
Problem found by checkpatch
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/gpu/drm/drm_connector.c | 38 -
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..38600c3a6ab2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1958,11 +1958,11 @@ int drm_connector_set_path_property(struct
drm_connector *connector,
int ret;
ret = drm_property_replace_global_blob(dev,
- >path_blob_ptr,
- strlen(path) + 1,
- path,
- >base,
- dev->mode_config.path_property);
+ >path_blob_ptr,
+ strlen(path) + 1,
+ path,
+ >base,
+ dev->mode_config.path_property);
return ret;
}
EXPORT_SYMBOL(drm_connector_set_path_property);
@@ -1988,11 +1988,11 @@ int drm_connector_set_tile_property(struct
drm_connector *connector)
if (!connector->has_tile) {
ret = drm_property_replace_global_blob(dev,
-
>tile_blob_ptr,
- 0,
- NULL,
- >base,
-
dev->mode_config.tile_property);
+
>tile_blob_ptr,
+ 0,
+ NULL,
+ >base,
+
dev->mode_config.tile_property);
return ret;
}
@@ -2003,11 +2003,11 @@ int drm_connector_set_tile_property(struct
drm_connector *connector)
connector->tile_h_size, connector->tile_v_size);
ret = drm_property_replace_global_blob(dev,
- >tile_blob_ptr,
- strlen(tile) + 1,
- tile,
- >base,
- dev->mode_config.tile_property);
+ >tile_blob_ptr,
+ strlen(tile) + 1,
+ tile,
+ >base,
+ dev->mode_config.tile_property);
return ret;
}
EXPORT_SYMBOL(drm_connector_set_tile_property);
@@ -2076,10 +2076,10 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
ret = drm_property_replace_global_blob(dev,
>edid_blob_ptr,
- size,
- edid,
- >base,
- dev->mode_config.edid_property);
+ size,
+ edid,
+ >base,
+ dev->mode_config.edid_property);
if (ret)
return ret;
return drm_connector_set_tile_property(connector);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: drm_blend.c: Use tabs for code indents
Remove space and use tabs for indent the code to follow the
Linux kernel coding conventions.
Problem found by checkpatch.
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/gpu/drm/drm_blend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 26e2f2ffd255..ec37cbfabb50 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -328,8 +328,8 @@ unsigned int drm_rotation_simplify(unsigned int rotation,
if (rotation & ~supported_rotations) {
rotation ^= DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
rotation = (rotation & DRM_MODE_REFLECT_MASK) |
- BIT((ffs(rotation & DRM_MODE_ROTATE_MASK) + 1)
- % 4);
+ BIT((ffs(rotation & DRM_MODE_ROTATE_MASK) + 1)
+ % 4);
}
return rotation;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: drm_atomic_uapi.c: Use tabs for code indents
Remove space and use tabs for indent the code to follow the
Linux kernel coding conventions.
Problem found by checkpatch.
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/gpu/drm/drm_atomic_uapi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..438e9585b225 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -78,8 +78,8 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
drm_mode_convert_to_umode(, mode);
state->mode_blob =
drm_property_create_blob(state->crtc->dev,
-sizeof(umode),
-);
+sizeof(umode),
+);
if (IS_ERR(state->mode_blob))
return PTR_ERR(state->mode_blob);
@@ -114,7 +114,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
* Zero on success, error code on failure. Cannot return -EDEADLK.
*/
int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
- struct drm_property_blob *blob)
+ struct drm_property_blob *blob)
{
struct drm_crtc *crtc = state->crtc;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm: Use tabs for code indents
Remove space and use tabs for indent the code to follow the Linux kernel coding conventions. Problem found by checkpatch Beatriz Martins de Carvalho (3): drm: drm_atomic_uapi.c: Use tabs for code indents drm: drm_blend.c: Use tabs for code indents drm: drm_connector.c: Use tabs for code indents drivers/gpu/drm/drm_atomic_uapi.c | 6 ++--- drivers/gpu/drm/drm_blend.c | 4 ++-- drivers/gpu/drm/drm_connector.c | 38 +++ 3 files changed, 24 insertions(+), 24 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/1] video: hyperv_fb: Add ratelimit on error message
From: Joe Perches Sent: Tuesday, April 20, 2021 12:59 PM
>
> On Tue, 2021-04-20 at 08:44 -0700, Michael Kelley wrote:
> > Due to a full ring buffer, the driver may be unable to send updates to
> > the Hyper-V host. But outputing the error message can make the problem
> > worse because console output is also typically written to the frame
> > buffer. As a result, in some circumstances the error message is output
> > continuously.
> >
> > Break the cycle by rate limiting the error message. Also output
> > the error code for additional diagnosability.
> >
> > Signed-off-by: Michael Kelley
>
> None of the callers of this function ever check the return status.
> Why is important/useful to emit this message at all?
>
Except during device initialization, the messages tell Hyper-V
about updates to the frame buffer contents. The fbdev
framework functions (such as fillrect) that eventually call synthvid_send()
are void functions. So the message is the only alert that something
has gone wrong in the communication with Hyper-V, which makes
it useful for diagnostic purposes.
Michael
> > ---
> > drivers/video/fbdev/hyperv_fb.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/fbdev/hyperv_fb.c
> > b/drivers/video/fbdev/hyperv_fb.c
> > index 4dc9077..a7e6eea 100644
> > --- a/drivers/video/fbdev/hyperv_fb.c
> > +++ b/drivers/video/fbdev/hyperv_fb.c
> > @@ -308,7 +308,7 @@ static inline int synthvid_send(struct hv_device *hdev,
> > VM_PKT_DATA_INBAND, 0);
> >
> >
> > if (ret)
> > - pr_err("Unable to send packet via vmbus\n");
> > + pr_err_ratelimited("Unable to send packet via vmbus; error
> > %d\n", ret);
> >
> >
> > return ret;
> > }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI
On Wed, Apr 21, 2021 at 8:28 PM Tvrtko Ursulin wrote: > On 21/04/2021 18:17, Jason Ekstrand wrote: > > On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin > > wrote: > >> On 21/04/2021 14:54, Jason Ekstrand wrote: > >>> On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin > >>> wrote: > On 20/04/2021 18:00, Jason Ekstrand wrote: > I am not claiming to know memory region query will end up the same, and > I definitely agree we cannot guess the future. I am just saying rsvd > fields are inconsequential really in terms of maintenance burden and > have been proven useful in the past. So I disagree with the drive to > kick them all out. > >>> > >>> Sure, it doesn't cost anything to have extra zeros in the struct. > >>> However, if/when the API grows using rsvd fields, we end up with "if > >>> CAP_FOO is set, rsvd[5] means blah" which makes for a horribly > >>> confusing API. As a userspace person who has to remember how to use > >>> this stuff, I'd rather make another call or chain in a struct than try > >>> to remember and/or figure out what all 8 rsvd fields mean. > >> > >> Well it's not called rsvd in the uapi which is aware of the new field > >> but has a new name. > > > > Are we allowed to do that? This is a genuine question. When I've > > tried in the past (cliprects), I was told we couldn't rename it even > > though literally no one had used it in code for years. > > Well we did the union for pad_to_size so I thought we are allowed that > trick at least. From my experience backward source level compatibility > is not always there even with things like glibc. Despite that, are we > generally required to stay backward source compatible I will not claim > either way. I think the anonymous union with exactly same sized field is ok. We also try hard to be source compatible, but we have screwed up in the past and shrugged it off. The one example that comes to mind is extended structures at the bottom with new field, which the kernel automatically zero-extends for old userspace. But when you recompile, your new-old userspace might no longer clear the new fields because the ioctl code didn't start out by memset()ing the entire struct. But by we managed to not botch things up on source compat, but it's definitely a lot tricker than ABI compat. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping
On Wed, 21 Apr 2021 at 16:41, Tvrtko Ursulin
wrote:
>
>
> On 21/04/2021 12:42, Matthew Auld wrote:
> > On 19/04/2021 16:01, Tvrtko Ursulin wrote:
> >>
> >> On 19/04/2021 15:37, Matthew Auld wrote:
> >>> On 19/04/2021 15:07, Tvrtko Ursulin wrote:
>
> On 19/04/2021 12:30, Matthew Auld wrote:
> > On 15/04/2021 12:05, Tvrtko Ursulin wrote:
> >>
> >> On 15/04/2021 10:23, Matthew Auld wrote:
> >>> On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
> >>> wrote:
>
>
> On 14/04/2021 17:20, Matthew Auld wrote:
> > On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 12/04/2021 10:05, Matthew Auld wrote:
> >>> From: Venkata Sandeep Dhanalakota
> >>>
> >>>
> >>> Determine the possible coherent map type based on object
> >>> location,
> >>> and if target has llc or if user requires an always coherent
> >>> mapping.
> >>>
> >>> Cc: Matthew Auld
> >>> Cc: CQ Tang
> >>> Suggested-by: Michal Wajdeczko
> >>> Signed-off-by: Venkata Sandeep Dhanalakota
> >>>
> >>> ---
> >>> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ++-
> >>> drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 +-
> >>> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
> >>> drivers/gpu/drm/i915/gt/intel_ring.c | 9 ++---
> >>> drivers/gpu/drm/i915/gt/selftest_context.c | 3 ++-
> >>> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> >>> drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 +++-
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +++-
> >>> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 +++-
> >>> drivers/gpu/drm/i915/i915_drv.h | 11
> >>> +--
> >>> drivers/gpu/drm/i915/selftests/igt_spinner.c | 4 ++--
> >>> 11 files changed, 36 insertions(+), 16 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >>> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >>> index efe935f80c1a..b79568d370f5 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >>> @@ -664,7 +664,8 @@ static int init_status_page(struct
> >>> intel_engine_cs *engine)
> >>> if (ret)
> >>> goto err;
> >>>
> >>> - vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
> >>> + vaddr = i915_gem_object_pin_map(obj,
> >>> + i915_coherent_map_type(engine->i915, obj, true));
> >>> if (IS_ERR(vaddr)) {
> >>> ret = PTR_ERR(vaddr);
> >>> goto err_unpin;
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> >>> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> >>> index 7c9af86fdb1e..47f4397095e5 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> >>> @@ -23,7 +23,7 @@ static void dbg_poison_ce(struct
> >>> intel_context *ce)
> >>>
> >>> if (ce->state) {
> >>> struct drm_i915_gem_object *obj =
> >>> ce->state->obj;
> >>> - int type =
> >>> i915_coherent_map_type(ce->engine->i915);
> >>> + int type =
> >>> i915_coherent_map_type(ce->engine->i915, obj, true);
> >>> void *map;
> >>>
> >>> if (!i915_gem_object_trylock(obj))
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> index e86897cde984..aafe2a4df496 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> @@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
> >>> GEM_BUG_ON(!i915_vma_is_pinned(ce->state));
> >>>
> >>> *vaddr = i915_gem_object_pin_map(ce->state->obj,
> >>> - i915_coherent_map_type(ce->engine->i915) |
> >>> + i915_coherent_map_type(ce->engine->i915,
> >>> + ce->state->obj,
> >>> + false) |
> >>> I915_MAP_OVERRIDE);
> >>>
> >>> return PTR_ERR_OR_ZERO(*vaddr);
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
> >>> b/drivers/gpu/drm/i915/gt/intel_ring.c
> >>> index aee0a77c77e0..3cf6c7e68108 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> >>> @@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring
> >>>
Re: [git pull] drm/vmwgfx fixes for 5.12-rc8
On Wed, Apr 21, 2021 at 7:00 PM Zack Rusin wrote: > > On 4/17/21 7:02 PM, Dave Airlie wrote: > > Hi Zack, > > > > Please make sure to always cc dri-devel and/or Daniel on these so if > > I'm away they don't get lost, but also so that they make it into > > patchwork for processing. > > > > If you have a chance can you resend it, I'll see if we can process > > this out of band and get it to Linus before release. > Hi, Dave. > > Thank you! I just noticed that you've sent it out. Would you still like me to > resend it through dri-devel? The patches all went through dri-devel already, > I just assumed that from dri-misc docs that drm-misc-fixes wouldn't be merged > again until after 5.13 was out which is why I went directly. drm-misc-fixes will get pulled into the merge window when it misses the last release (which would be 5.12). drm-misc-next-fixes is the special branch which is for fixes during the merge window time, for issues in drm-next (so for 5.13). I know that ideally maintainters would just cherry-pick bugfixes to the right release branch (like on mesa or xserver or well any other reasonable project), but since drm-misc is volunteer run committers need to pick the right branch. But aside from that drm-misc is always open for bugfixes (and also always open for feature work). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
umn experiment patches fallout in drm
Looking at the umn.edu patches for drm in the last while, all the refcount ones look bogus, 2020-06-13 20:48 -0500 Aditya Pakki o drm/nouveau: fix reference count leak in nouveau_debugfs_strap_peek 2020-06-13 20:22 -0500 Aditya Pakki o drm/nouveau: Fix reference count leak in nouveau_connector_detect 2020-06-13 20:29 -0500 Aditya Pakki o drm/nouveau: fix reference count leak in nv50_disp_atomic_commit 2020-06-13 20:41 -0500 Aditya Pakki o drm/nouveau: fix multiple instances of reference count leaks 2020-06-13 20:33 -0500 Aditya Pakki o drm/nouveau/drm/noveau: fix reference count leak in nouveau_fbcon_open 2020-06-13 21:21 -0500 Aditya Pakki │ o drm/radeon: Fix reference count leaks caused by pm_runtime_get_sync 2020-06-13 20:55 -0500 Aditya Pakki │ │ o drm/radeon: fix multiple reference count leak 2020-06-13 14:32 -0500 Qiushi Wu│ │ │ o drm/amdkfd: Fix reference count leaks. These ones look sane but maybe we should revert them all anyways. 2019-12-15 13:43 -0600 Aditya Pakki │ │ │ │ o drm: remove duplicate check on parent and avoid BUG_ON 2019-10-17 23:41 -0500 Kangjie Lu │ │ │ │ │ o drm/gma500: fix memory disclosures due to uninitialized bytes 2019-10-17 23:29 -0500 Kangjie Lu │ │ │ │ │ o gma/gma500: fix a memory disclosure bug due to uninitialized bytes 2019-03-24 18:16 -0500 Kangjie Lu │ │ │ │ │ │ o drm/v3d: fix a missing check of pm_runtime_get_sync 2019-03-08 22:36 -0600 Kangjie Lu │ │ │ │ │ │ │ o drm: vkms: check status of alloc_ordered_workqueue Ben, Alex can you line up reverts for next for all of the nouveau/amdgpu/radeon ones? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Use slow and wide link training for everything
On Wed, Apr 21, 2021 at 01:20:31PM +0800, Kai-Heng Feng wrote:
> Screen flickers on Innolux eDP 1.3 panel when clock rate 54 is in use.
>
> According to the panel vendor, though clock rate 54 is advertised,
> but the max clock rate it really supports is 27.
>
> Ville Syrjälä mentioned that fast and narrow also breaks some eDP 1.4
> panel, so use slow and wide training for all panels to resolve the
> issue.
>
> User also confirmed that the new strategy doesn't introduce any
> regression on XPS 9380.
>
> v2:
> - Use slow and wide for everything.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3384
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/272
> Signed-off-by: Kai-Heng Feng
Thanks. Pushed to drm-intel-next.
I did a quick scan of a few CI logs and noticed that at least cml-u2
changed behaviour:
- [CONNECTOR:95:eDP-1] Link Training passed at link rate = 432000, lane count =
1, at DPRX
+ [CONNECTOR:95:eDP-1] Link Training passed at link rate = 216000, lane count =
2, at DPRX
But it still appears to work, and 2.16Gbps is also the link rate chosen
by the BIOS, which is reassuring.
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1095,44 +1095,6 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> return -EINVAL;
> }
>
> -/* Optimize link config in order: max bpp, min lanes, min clock */
> -static int
> -intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> - struct intel_crtc_state *pipe_config,
> - const struct link_config_limits *limits)
> -{
> - const struct drm_display_mode *adjusted_mode =
> _config->hw.adjusted_mode;
> - int bpp, clock, lane_count;
> - int mode_rate, link_clock, link_avail;
> -
> - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> - int output_bpp =
> intel_dp_output_bpp(pipe_config->output_format, bpp);
> -
> - mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> -output_bpp);
> -
> - for (lane_count = limits->min_lane_count;
> - lane_count <= limits->max_lane_count;
> - lane_count <<= 1) {
> - for (clock = limits->min_clock; clock <=
> limits->max_clock; clock++) {
> - link_clock = intel_dp->common_rates[clock];
> - link_avail = intel_dp_max_data_rate(link_clock,
> - lane_count);
> -
> - if (mode_rate <= link_avail) {
> - pipe_config->lane_count = lane_count;
> - pipe_config->pipe_bpp = bpp;
> - pipe_config->port_clock = link_clock;
> -
> - return 0;
> - }
> - }
> - }
> - }
> -
> - return -EINVAL;
> -}
> -
> static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8
> dsc_max_bpc)
> {
> int i, num_bpc;
> @@ -1382,22 +1344,11 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> intel_dp_can_bigjoiner(intel_dp))
> pipe_config->bigjoiner = true;
>
> - if (intel_dp_is_edp(intel_dp))
> - /*
> - * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
> - * section A.1: "It is recommended that the minimum number of
> - * lanes be used, using the minimum link rate allowed for that
> - * lane configuration."
> - *
> - * Note that we fall back to the max clock and lane count for
> eDP
> - * panels that fail with the fast optimal settings (see
> - * intel_dp->use_max_params), in which case the fast vs. wide
> - * choice doesn't matter.
> - */
> - ret = intel_dp_compute_link_config_fast(intel_dp, pipe_config,
> );
> - else
> - /* Optimize for slow and wide. */
> - ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config,
> );
> + /*
> + * Optimize for slow and wide for everything, because there are some
> + * eDP 1.3 and 1.4 panels don't work well with fast and narrow.
> + */
> + ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config, );
>
> /* enable compression if the mode doesn't fit available BW */
> drm_dbg_kms(>drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
> --
> 2.30.2
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI
On 21/04/2021 18:17, Jason Ekstrand wrote:
On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
wrote:
On 21/04/2021 14:54, Jason Ekstrand wrote:
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
On 20/04/2021 18:00, Jason Ekstrand wrote:
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
wrote:
On 19/04/2021 16:19, Jason Ekstrand wrote:
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
On 16/04/2021 17:38, Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
v3:
(Daniel)
- add a note for set/get caching stuff
- add some more docs for existing query and extensions stuff
- add an actual code example for regions query
- bunch of other stuff
(Jason)
- uAPI change(!):
- try a simpler design with the placements extension
- rather than have a generic setparam which can cover multiple
use cases, have each extension be responsible for one thing
only
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_gem_lmem.h | 255
Documentation/gpu/rfc/i915_gem_lmem.rst | 139 +
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 398 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
b/Documentation/gpu/rfc/i915_gem_lmem.h
new file mode 100644
index ..2a82a452e9f2
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_gem_lmem.h
@@ -0,0 +1,255 @@
+/*
+ * Note that drm_i915_query_item and drm_i915_query are existing bits of uAPI.
+ * For the regions query we are just adding a new query id, so no actual new
+ * ioctl or anything, but including it here for reference.
+ */
+struct drm_i915_query_item {
+#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
+
+__u64 query_id;
+
+/*
+ * When set to zero by userspace, this is filled with the size of the
+ * data to be written at the data_ptr pointer. The kernel sets this
+ * value to a negative value to signal an error on a particular query
+ * item.
+ */
+__s32 length;
+
+__u32 flags;
+/*
+ * Data will be written at the location pointed by data_ptr when the
+ * value of length matches the length of the data to be written by the
+ * kernel.
+ */
+__u64 data_ptr;
+};
+
+struct drm_i915_query {
+__u32 num_items;
+/*
+ * Unused for now. Must be cleared to zero.
+ */
+__u32 flags;
+/*
+ * This points to an array of num_items drm_i915_query_item structures.
+ */
+__u64 items_ptr;
+};
+
+#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_QUERY,
struct drm_i915_query)
+
+/**
+ * enum drm_i915_gem_memory_class
+ */
+enum drm_i915_gem_memory_class {
+ /** @I915_MEMORY_CLASS_SYSTEM: system memory */
+ I915_MEMORY_CLASS_SYSTEM = 0,
+ /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
+ I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance
+ */
+struct drm_i915_gem_memory_class_instance {
+ /** @memory_class: see enum drm_i915_gem_memory_class */
+ __u16 memory_class;
+
+ /** @memory_instance: which instance */
+ __u16 memory_instance;
+};
+
+/**
+ * struct drm_i915_memory_region_info
+ *
+ * Describes one region as known to the driver.
+ *
+ * Note that we reserve quite a lot of stuff here for potential future work. As
+ * an example we might want expose the capabilities(see caps) for a given
+ * region, which could include things like if the region is CPU
+ * mappable/accessible etc.
I get caps but I'm seriously at a loss as to what the rest of this
would be used for. Why are caps and flags both there and separate?
Flags are typically something you set, not query. Also, what's with
rsvd1 at the end? This smells of substantial over-building to me.
I thought to myself, "maybe I'm missing a future use-case" so I looked
at the internal tree and none of this is being used there either.
This indicates to me that either I'm missing something and there's
code somewhere I don't know about or, with three years of building on
internal branches, we still haven't proven that any of this is needed.
If it's the latter, which I strongly suspect, maybe we should drop the
unnecessary bits and only add them back in if and when we have
Re: [PATCH v3 3/3] drm/msm/dp: check main link status before start aux read
On 2021-04-20 16:38, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-04-16 10:38:51)
Maybe when the cable is disconnected the DP phy should be shutdown and
some bit in the phy could effectively "cut off" the aux channel and
then
NAKs would start coming through here in the DP controller I/O register
space. This patch have DP aux channel read/write to return NAK
immediately
if DP controller connection status is in unplugged state.
Changes in V3:
-- check core_initialized before handle irq_hpd
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
drivers/gpu/drm/msm/dp/dp_display.c | 14 ++
drivers/gpu/drm/msm/dp/dp_link.c| 20 +++-
3 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c
b/drivers/gpu/drm/msm/dp/dp_aux.c
index 7c22bfe..fae3806 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux
*dp_aux,
mutex_lock(>mutex);
+ if (!dp_catalog_link_is_connected(aux->catalog)) {
+ ret = -ETIMEDOUT;
+ goto unlock_exit;
+ }
+
This still makes me concerned. Any possibility to not do this and have
the phy cut the connection off and have this transfer timeout
immediately?
no, we have to wait hardware AUX_NACK timeout.
only this or the abort flag used last time.
Last time you have kernel crash because of service irq_hpd while clock
is turned off.
I have add core_initialized checking wiinin irq_hpd to prevent this.
I think abort flag approach is safer.
aux->native = msg->request & (DP_AUX_NATIVE_WRITE &
DP_AUX_NATIVE_READ);
/* Ignore address only message */
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 1784e11..db3f45e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -571,7 +571,7 @@ static int dp_hpd_plug_handle(struct
dp_display_private *dp, u32 data)
dp->hpd_state = ST_DISCONNECTED;
if (ret == -ECONNRESET) { /* cable unplugged */
- dp->core_initialized = false;
+ DRM_ERROR("dongle unplugged = %d\n", ret);
Is this a debug message?
}
} else {
@@ -711,9 +711,15 @@ static int dp_irq_hpd_handle(struct
dp_display_private *dp, u32 data)
return 0;
}
- ret = dp_display_usbpd_attention_cb(>pdev->dev);
- if (ret == -ECONNRESET) { /* cable unplugged */
- dp->core_initialized = false;
+ /*
+* dp core (ahb/aux clks) must be initialized before
+* irq_hpd be handled
+*/
+ if (dp->core_initialized) {
+ ret = dp_display_usbpd_attention_cb(>pdev->dev);
+ if (ret == -ECONNRESET) { /* cable unplugged */
+ DRM_ERROR("dongle unplugged = %d\n", ret);
Another debug message?
+ }
}
mutex_unlock(>event_mutex);
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c
b/drivers/gpu/drm/msm/dp/dp_link.c
index be986da..53ecae6 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -737,18 +737,25 @@ static int dp_link_parse_sink_count(struct
dp_link *dp_link)
return 0;
}
-static void dp_link_parse_sink_status_field(struct dp_link_private
*link)
+static int dp_link_parse_sink_status_field(struct dp_link_private
*link)
{
int len = 0;
link->prev_sink_count = link->dp_link.sink_count;
- dp_link_parse_sink_count(>dp_link);
+ len = dp_link_parse_sink_count(>dp_link);
+ if (len < 0) {
+ DRM_ERROR("DP parse sink count failed\n");
+ return len;
+ }
len = drm_dp_dpcd_read_link_status(link->aux,
link->link_status);
- if (len < DP_LINK_STATUS_SIZE)
+ if (len < DP_LINK_STATUS_SIZE) {
DRM_ERROR("DP link status read failed\n");
- dp_link_parse_request(link);
+ return len;
+ }
+
+ return dp_link_parse_request(link);
}
/**
@@ -1032,7 +1039,10 @@ int dp_link_process_request(struct dp_link
*dp_link)
dp_link_reset_data(link);
- dp_link_parse_sink_status_field(link);
+ ret = dp_link_parse_sink_status_field(link);
+ if (ret) {
+ return ret;
+ }
if (link->request.test_requested == DP_TEST_LINK_EDID_READ) {
dp_link->sink_request |= DP_TEST_LINK_EDID_READ;
--
Can you split this part off into another patch? It seems to stand on
its
own as it makes the code more robust to transfer errors in the sink
parsing code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Register VGA clients after init can no longer fail
When an amdgpu device fails to init, it makes another VGA device cause
kernel splat:
kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
kernel: amdgpu: probe of :08:00.0 failed with error -110
...
kernel: amdgpu :01:00.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=none:owns=none
kernel: BUG: kernel NULL pointer dereference, address: 0018
kernel: #PF: supervisor read access in kernel mode
kernel: #PF: error_code(0x) - not-present page
kernel: PGD 0 P4D 0
kernel: Oops: [#1] SMP NOPTI
kernel: CPU: 6 PID: 1080 Comm: Xorg Tainted: GW 5.12.0-rc8+ #12
kernel: Hardware name: HP HP EliteDesk 805 G6/872B, BIOS S09 Ver. 02.02.00
12/30/2020
kernel: RIP: 0010:amdgpu_device_vga_set_decode+0x13/0x30 [amdgpu]
kernel: Code: 06 31 c0 c3 b8 ea ff ff ff 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66
90 0f 1f 44 00 00 55 48 8b 87 90 06 00 00 48 89 e5 53 89 f3 <48> 8b 40 18 40 0f
b6 f6 e8 40 58 39 fd 80 fb 01 5b 5d 19 c0 83 e0
kernel: RSP: 0018:ae3c0246bd68 EFLAGS: 00010002
kernel: RAX: RBX: RCX:
kernel: RDX: 8dd1af5a8560 RSI: RDI: 8dce8c16
kernel: RBP: ae3c0246bd70 R08: 8dd1af5985c0 R09: ae3c0246ba38
kernel: R10: 0001 R11: 0001 R12: 0246
kernel: R13: R14: 0003 R15: 8dce8149
kernel: FS: 7f9303d8fa40() GS:8dd1af58()
knlGS:
kernel: CS: 0010 DS: ES: CR0: 80050033
kernel: CR2: 0018 CR3: 000103cfa000 CR4: 00350ee0
kernel: Call Trace:
kernel: vga_arbiter_notify_clients.part.0+0x4a/0x80
kernel: vga_get+0x17f/0x1c0
kernel: vga_arb_write+0x121/0x6a0
kernel: ? apparmor_file_permission+0x1c/0x20
kernel: ? security_file_permission+0x30/0x180
kernel: vfs_write+0xca/0x280
kernel: ksys_write+0x67/0xe0
kernel: __x64_sys_write+0x1a/0x20
kernel: do_syscall_64+0x38/0x90
kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae
kernel: RIP: 0033:0x7f93041e02f7
kernel: Code: 75 05 48 83 c4 58 c3 e8 f7 33 ff ff 0f 1f 80 00 00 00 00 f3 0f 1e
fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff
77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
kernel: RSP: 002b:7fff60e49b28 EFLAGS: 0246 ORIG_RAX: 0001
kernel: RAX: ffda RBX: 000b RCX: 7f93041e02f7
kernel: RDX: 000b RSI: 7fff60e49b40 RDI: 000f
kernel: RBP: 7fff60e49b40 R08: R09: 7fff60e499d0
kernel: R10: 7f93049350b5 R11: 0246 R12: 56111d45e808
kernel: R13: R14: 56111d45e7f8 R15: 56111d46c980
kernel: Modules linked in: nls_iso8859_1 snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel
snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq
input_leds snd_seq_device snd_timer snd soundcore joydev kvm_amd serio_raw
k10temp mac_hid hp_wmi ccp kvm sparse_keymap wmi_bmof ucsi_acpi efi_pstore
typec_ucsi rapl typec video wmi sch_fq_codel parport_pc ppdev lp parport
ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor
raid6_pq raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log
hid_generic usbhid hid amdgpu drm_ttm_helper ttm iommu_v2 gpu_sched
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect crct10dif_pclmul sysimgblt
crc32_pclmul fb_sys_fops ghash_clmulni_intel cec rc_core aesni_intel
crypto_simd psmouse cryptd r8169 i2c_piix4 drm ahci xhci_pci realtek libahci
xhci_pci_renesas gpio_amdpt gpio_generic
kernel: CR2: 0018
kernel: ---[ end trace 76d04313d4214c51 ]---
Commit 4192f7b57689 ("drm/amdgpu: unmap register bar on device init
failure") makes amdgpu_driver_unload_kms() skips amdgpu_device_fini(),
so the VGA clients remain registered. So when
vga_arbiter_notify_clients() iterates over registered clients, it causes
NULL pointer dereference.
Since there's no reason to register VGA clients that early, so solve
the issue by putting them after all the goto cleanups.
Fixes: 4192f7b57689 ("drm/amdgpu: unmap register bar on device init failure")
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 +++---
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b4ad1c055c70..115a7699e11e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3410,19 +3410,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* doorbell bar mapping and doorbell index init*/
amdgpu_device_doorbell_init(adev);
- /* if we have > 1 VGA cards, then disable the amdgpu VGA resources
Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo
On 4/21/21 5:31 PM, Mike Rapoport wrote: > On Wed, Apr 21, 2021 at 10:37:11AM +, peter.enderb...@sony.com wrote: >> On 4/21/21 11:15 AM, Daniel Vetter wrote: >>> We need to understand what the "correct" value is. Not in terms of kernel >>> code, but in terms of semantics. Like if userspace allocates a GL texture, >>> is this supposed to show up in your metric or not. Stuff like that. >> That it like that would like to only one pointer type. You need to know what >> >> you pointing at to know what it is. it might be a hardware or a other >> pointer. >> >> If there is a limitation on your pointers it is a good metric to count them >> even if you don't know what they are. Same goes for dma-buf, they >> are generic, but they consume some resources that are counted in pages. >> >> It would be very good if there a sub division where you could measure >> all possible types separately. We have the detailed in debugfs, but nothing >> for the user. A summary in meminfo seems to be the best place for such >> metric. > > Let me try to summarize my understanding of the problem, maybe it'll help > others as well. Thanks! > A device driver allocates memory and exports this memory via dma-buf so > that this memory will be accessible for userspace via a file descriptor. > > The allocated memory can be either allocated with alloc_page() from system > RAM or by other means from dedicated VRAM (that is not managed by Linux mm) > or even from on-device memory. > > The dma-buf driver tracks the amount of the memory it was requested to > export and the size it sees is available at debugfs and fdinfo. > > The debugfs is not available to user and maybe entirely disabled in > production systems. > > There could be quite a few open dma-bufs so there is no overall summary, > plus fdinfo in production systems your refer to is also unavailable to the > user because of selinux policy. > > And there are a few details that are not clear to me: > > * Since DRM device drivers seem to be the major user of dma-buf exports, > why cannot we add information about their memory consumption to, say, > /sys/class/graphics/drm/cardX/memory-usage? Android is using it for binder that connect more or less everything internally. > * How exactly user generates reports that would include the new counters? > From my (mostly outdated) experience Android users won't open a terminal > and type 'cat /proc/meminfo' there. I'd presume there is a vendor agent > that collects the data and sends it for analysis. In this case what is > the reason the vendor is unable to adjust selinix policy so that the > agent will be able to access fdinfo? When you turn on developer mode on android you can use usb with a program called adb. And there you get a normal shell. (not root though) There is applications that non developers can use to get information. It is very limited though and there are API's provide it. > > * And, as others already mentioned, it is not clear what are the problems > that can be detected by examining DmaBufTotal except saying "oh, there is > too much/too little memory exported via dma-buf". What would be user > visible effects of these problems? What are the next steps to investigate > them? What other data will be probably required to identify root cause? > When you debug thousands of devices it is quite nice to have ways to classify what the problem it is not. The normal user does not see anything of this. However they can generate bug-reports that collect information about as much they can. Then the user have to provide this bug-report to the manufacture or mostly the application developer. And when the problem is system related we need to reproduce the issue on a full debug enabled unit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/190] Revertion of all of the umn.edu commits
On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman wrote: > > I have been meaning to do this for a while, but recent events have > finally forced me to do so. > > Commits from @umn.edu addresses have been found to be submitted in "bad > faith" to try to test the kernel community's ability to review "known > malicious" changes. The result of these submissions can be found in a > paper published at the 42nd IEEE Symposium on Security and Privacy > entitled, "Open Source Insecurity: Stealthily Introducing > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University > of Minnesota) and Kangjie Lu (University of Minnesota). > > Because of this, all submissions from this group must be reverted from > the kernel tree and will need to be re-reviewed again to determine if > they actually are a valid fix. Until that work is complete, remove this > change to ensure that no problems are being introduced into the > codebase. > > This patchset has the "easy" reverts, there are 68 remaining ones that > need to be manually reviewed. Some of them are not able to be reverted > as they already have been reverted, or fixed up with follow-on patches > as they were determined to be invalid. Proof that these submissions > were almost universally wrong. Will you take care of these remaining ones in subsequent patches too? > I will be working with some other kernel developers to determine if any > of these reverts were actually valid changes, were actually valid, and > if so, will resubmit them properly later. For now, it's better to be > safe. > > I'll take this through my tree, so no need for any maintainer to worry > about this, but they should be aware that future submissions from anyone > with a umn.edu address should be by default-rejected unless otherwise > determined to actually be a valid fix (i.e. they provide proof and you > can verify it, but really, why waste your time doing that extra work?) > > thanks, > > greg k-h > > Greg Kroah-Hartman (190): > Revert "net/rds: Avoid potential use after free in > rds_send_remove_from_sock" > Revert "media: st-delta: Fix reference count leak in delta_run_work" > Revert "media: sti: Fix reference count leaks" > Revert "media: exynos4-is: Fix several reference count leaks due to > pm_runtime_get_sync" > Revert "media: exynos4-is: Fix a reference count leak due to > pm_runtime_get_sync" > Revert "media: exynos4-is: Fix a reference count leak" > Revert "media: ti-vpe: Fix a missing check and reference count leak" > Revert "media: stm32-dcmi: Fix a reference count leak" > Revert "media: s5p-mfc: Fix a reference count leak" > Revert "media: camss: Fix a reference count leak." > Revert "media: platform: fcp: Fix a reference count leak." > Revert "media: rockchip/rga: Fix a reference count leak." > Revert "media: rcar-vin: Fix a reference count leak." > Revert "media: rcar-vin: Fix a reference count leak." > Revert "firmware: Fix a reference count leak." > Revert "drm/nouveau: fix reference count leak in > nouveau_debugfs_strap_peek" > Revert "drm/nouveau: fix reference count leak in > nv50_disp_atomic_commit" > Revert "drm/nouveau: fix multiple instances of reference count leaks" > Revert "drm/nouveau/drm/noveau: fix reference count leak in > nouveau_fbcon_open" > Revert "PCI: Fix pci_create_slot() reference count leak" > Revert "omapfb: fix multiple reference count leaks due to > pm_runtime_get_sync" > Revert "drm/radeon: Fix reference count leaks caused by > pm_runtime_get_sync" > Revert "drm/radeon: fix multiple reference count leak" > Revert "drm/amdkfd: Fix reference count leaks." I didn't review these carefully, but from a quick look they all seem rather inconsequental. Either error paths that are very unlikely, or drivers which are very dead (looking at the entire list, not just what you reverted here). Acked-by: Daniel Vetter Also adding drm maintainers/lists, those aren't all on your cc it seems. I will also forward this to fd.o sitewranglers as abuse of our infrastructure, it's for community collaboration, not for inflicting experiments on unconsenting subjects. I'me dropping non-drm people here so not everyone gets spammed too badly. -Daniel > Revert "platform/chrome: cros_ec_ishtp: Fix a double-unlock issue" > Revert "usb: dwc3: pci: Fix reference count leak in > dwc3_pci_resume_work" > Revert "ASoC: rockchip: Fix a reference count leak." > Revert "RDMA/rvt: Fix potential memory leak caused by rvt_alloc_rq" > Revert "EDAC: Fix reference count leaks" > Revert "ASoC: tegra: Fix reference count leaks." > Revert "test_objagg: Fix potential memory leak in error handling" > Revert "ASoC: img-parallel-out: Fix a reference count leak" > Revert "ASoC: img: Fix a reference count leak in img_i2s_in_set_fmt" > Revert "efi/esrt: Fix reference count leak in > esre_create_sysfs_entry." > Revert "scsi: iscsi: Fix reference count leak in >
Re: [PATCH 1/2] drm/msm/dp: service only one irq_hpd if there are multiple irq_hpd pending
On 2021-04-20 15:01, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-04-16 13:27:57)
Some dongle may generate more than one irq_hpd events in a short
period of
time. This patch will treat those irq_hpd events as single one and
service
only one irq_hpd event.
Why is it bad to get multiple irq_hpd events in a short period of time?
Please tell us here in the commit text.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6..0a7d383 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -707,6 +707,9 @@ static int dp_irq_hpd_handle(struct
dp_display_private *dp, u32 data)
return 0;
}
+ /* only handle first irq_hpd in case of multiple irs_hpd
pending */
+ dp_del_event(dp, EV_IRQ_HPD_INT);
+
ret = dp_display_usbpd_attention_cb(>pdev->dev);
if (ret == -ECONNRESET) { /* cable unplugged */
dp->core_initialized = false;
@@ -1300,6 +1303,9 @@ static int dp_pm_suspend(struct device *dev)
/* host_init will be called at pm_resume */
dp->core_initialized = false;
+ /* system suspended, delete pending irq_hdps */
+ dp_del_event(dp, EV_IRQ_HPD_INT);
What happens if I suspend my device and when this function is running I
toggle my monitor to use the HDMI input that is connected instead of
some
other input, maybe the second HDMI input? Wouldn't that generate an HPD
interrupt to grab the attention of this device?
no,
At this time display is off. this mean dp controller is off and mainlink
has teared down.
it will start with plug in interrupt to bring dp controller up and start
link training.
irq_hpd can be generated only panel is at run time of operation mode and
need attention from host.
If host is shutting down, then no need to service pending irq_hpd.
+
mutex_unlock(>event_mutex);
return 0;
@@ -1496,6 +1502,9 @@ int msm_dp_display_disable(struct msm_dp *dp,
struct drm_encoder *encoder)
/* stop sentinel checking */
dp_del_event(dp_display, EV_DISCONNECT_PENDING_TIMEOUT);
+ /* link is down, delete pending irq_hdps */
+ dp_del_event(dp_display, EV_IRQ_HPD_INT);
+
I'm becoming convinced that the whole kthread design and event queue is
broken. These sorts of patches are working around the larger problem
that the kthread is running independently of the driver and irqs can
come in at any time but the event queue is not checked from the irq
handler to debounce the irq event. Is the event queue necessary at all?
I wonder if it would be simpler to just use an irq thread and process
the hpd signal from there. Then we're guaranteed to not get an irq
again
until the irq thread is done processing the event. This would naturally
debounce the irq hpd event that way.
event q just like bottom half of irq handler. it turns irq into event
and handle them sequentially.
irq_hpd is asynchronous event from panel to bring up attention of hsot
during run time of operation.
Here, the dongle is unplugged and main link had teared down so that no
need to service pending irq_hpd if any.
dp_display_disable(dp_display, 0);
rc = dp_display_unprepare(dp);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI
On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
wrote:
>
>
> On 21/04/2021 14:54, Jason Ekstrand wrote:
> > On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
> > wrote:
> >>
> >> On 20/04/2021 18:00, Jason Ekstrand wrote:
> >>> On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
> >>> wrote:
>
>
> On 19/04/2021 16:19, Jason Ekstrand wrote:
> > On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld
> > wrote:
> >>
> >> On 16/04/2021 17:38, Jason Ekstrand wrote:
> >>> On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld
> >>> wrote:
>
> Add an entry for the new uAPI needed for DG1.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here for TTM vs
> i915
> - bunch of other suggestions from Daniel
> v3:
> (Daniel)
> - add a note for set/get caching stuff
> - add some more docs for existing query and extensions stuff
> - add an actual code example for regions query
> - bunch of other stuff
> (Jason)
> - uAPI change(!):
> - try a simpler design with the placements extension
> - rather than have a generic setparam which can cover
> multiple
> use cases, have each extension be responsible for one
> thing
> only
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc: mesa-...@lists.freedesktop.org
> ---
> Documentation/gpu/rfc/i915_gem_lmem.h | 255
>
> Documentation/gpu/rfc/i915_gem_lmem.rst | 139 +
> Documentation/gpu/rfc/index.rst | 4 +
> 3 files changed, 398 insertions(+)
> create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
> create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
>
> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
> b/Documentation/gpu/rfc/i915_gem_lmem.h
> new file mode 100644
> index ..2a82a452e9f2
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_gem_lmem.h
> @@ -0,0 +1,255 @@
> +/*
> + * Note that drm_i915_query_item and drm_i915_query are existing
> bits of uAPI.
> + * For the regions query we are just adding a new query id, so no
> actual new
> + * ioctl or anything, but including it here for reference.
> + */
> +struct drm_i915_query_item {
> +#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
> +
> +__u64 query_id;
> +
> +/*
> + * When set to zero by userspace, this is filled with the
> size of the
> + * data to be written at the data_ptr pointer. The kernel
> sets this
> + * value to a negative value to signal an error on a
> particular query
> + * item.
> + */
> +__s32 length;
> +
> +__u32 flags;
> +/*
> + * Data will be written at the location pointed by data_ptr
> when the
> + * value of length matches the length of the data to be
> written by the
> + * kernel.
> + */
> +__u64 data_ptr;
> +};
> +
> +struct drm_i915_query {
> +__u32 num_items;
> +/*
> + * Unused for now. Must be cleared to zero.
> + */
> +__u32 flags;
> +/*
> + * This points to an array of num_items drm_i915_query_item
> structures.
> + */
> +__u64 items_ptr;
> +};
> +
> +#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_QUERY, struct drm_i915_query)
> +
> +/**
> + * enum drm_i915_gem_memory_class
> + */
> +enum drm_i915_gem_memory_class {
> + /** @I915_MEMORY_CLASS_SYSTEM: system memory */
> + I915_MEMORY_CLASS_SYSTEM = 0,
> + /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
> + I915_MEMORY_CLASS_DEVICE,
> +};
> +
> +/**
> + * struct drm_i915_gem_memory_class_instance
> + */
> +struct drm_i915_gem_memory_class_instance {
> +
[PATCH] drm/ast: Fix missing conversions to managed API
The commit 7cbb93d89838 ("drm/ast: Use managed pci functions")
converted a few PCI accessors to the managed API and dropped the
manual pci_iounmap() calls, but it seems to have forgotten converting
pci_iomap() to the managed one. It resulted in the leftover resources
after the driver unbind. Let's fix them.
Fixes: 7cbb93d89838 ("drm/ast: Use managed pci functions")
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/ast/ast_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 0ac3c2039c4b..c29cc7f19863 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -413,7 +413,7 @@ struct ast_private *ast_device_create(const struct
drm_driver *drv,
pci_set_drvdata(pdev, dev);
- ast->regs = pci_iomap(pdev, 1, 0);
+ ast->regs = pcim_iomap(pdev, 1, 0);
if (!ast->regs)
return ERR_PTR(-EIO);
@@ -429,7 +429,7 @@ struct ast_private *ast_device_create(const struct
drm_driver *drv,
/* "map" IO regs if the above hasn't done so already */
if (!ast->ioregs) {
- ast->ioregs = pci_iomap(pdev, 2, 0);
+ ast->ioregs = pcim_iomap(pdev, 2, 0);
if (!ast->ioregs)
return ERR_PTR(-EIO);
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm/vmwgfx fixes for 5.12-rc8
On 4/17/21 7:02 PM, Dave Airlie wrote: Hi Zack, Please make sure to always cc dri-devel and/or Daniel on these so if I'm away they don't get lost, but also so that they make it into patchwork for processing. If you have a chance can you resend it, I'll see if we can process this out of band and get it to Linus before release. Hi, Dave. Thank you! I just noticed that you've sent it out. Would you still like me to resend it through dri-devel? The patches all went through dri-devel already, I just assumed that from dri-misc docs that drm-misc-fixes wouldn't be merged again until after 5.13 was out which is why I went directly. z ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
On Wed, 21 Apr 2021 13:28:52 +0800, Nicolas Boichat wrote: > Define a compatible string for the Mali Bifrost GPU found in > Mediatek's MT8183 SoCs. > > Signed-off-by: Nicolas Boichat > --- > > (no changes since v12) > > Changes in v12: > - binding: Fix min/maxItems logic (Rob Herring) > > Changes in v11: > - binding: power-domain-names not power-domainS-names > > Changes in v10: > - Fix the binding to make sure sram-supply property can be provided. > > Changes in v6: > - Rebased, actually tested with recent mesa driver. > > Changes in v5: > - Rename "2d" power domain to "core2" > > Changes in v4: > - Add power-domain-names description >(kept Alyssa's reviewed-by as the change is minor) > > .../bindings/gpu/arm,mali-bifrost.yaml| 30 ++- > 1 file changed, 29 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 7/7] drm/hx8357d: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/hx8357d.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index c6525cd02bc2..17b2a3cb4918 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -234,10 +234,8 @@ static int hx8357d_probe(struct spi_device *spi)
drm = >drm;
dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_LOW);
- if (IS_ERR(dc)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
- return PTR_ERR(dc);
- }
+ if (IS_ERR(dc))
+ return dev_err_probe(dev, PTR_ERR(dc), "Failed to get GPIO
'dc'\n");
dbidev->backlight = devm_of_find_backlight(dev);
if (IS_ERR(dbidev->backlight))
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/7] drm/mi0283qt: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/mi0283qt.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c
index ff77f983f803..c90b5dee7761 100644
--- a/drivers/gpu/drm/tiny/mi0283qt.c
+++ b/drivers/gpu/drm/tiny/mi0283qt.c
@@ -196,16 +196,12 @@ static int mi0283qt_probe(struct spi_device *spi)
drm = >drm;
dbi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(dbi->reset)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
- return PTR_ERR(dbi->reset);
- }
+ if (IS_ERR(dbi->reset))
+ return dev_err_probe(dev, PTR_ERR(dbi->reset), "Failed to get
GPIO 'reset'\n");
dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
- if (IS_ERR(dc)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
- return PTR_ERR(dc);
- }
+ if (IS_ERR(dc))
+ return dev_err_probe(dev, PTR_ERR(dc), "Failed to get GPIO
'dc'\n");
dbidev->regulator = devm_regulator_get(dev, "power");
if (IS_ERR(dbidev->regulator))
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/7] drm/st7586: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/st7586.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
index ff5cf60f4bd7..fdd823e6ed44 100644
--- a/drivers/gpu/drm/tiny/st7586.c
+++ b/drivers/gpu/drm/tiny/st7586.c
@@ -323,16 +323,12 @@ static int st7586_probe(struct spi_device *spi)
bufsize = (st7586_mode.vdisplay + 2) / 3 * st7586_mode.hdisplay;
dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(dbi->reset)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
- return PTR_ERR(dbi->reset);
- }
+ if (IS_ERR(dbi->reset))
+ return dev_err_probe(dev, PTR_ERR(dbi->reset), "Failed to get
GPIO 'reset'\n");
a0 = devm_gpiod_get(dev, "a0", GPIOD_OUT_LOW);
- if (IS_ERR(a0)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'a0'\n");
- return PTR_ERR(a0);
- }
+ if (IS_ERR(a0))
+ return dev_err_probe(dev, PTR_ERR(a0), "Failed to get GPIO
'a0'\n");
device_property_read_u32(dev, "rotation", );
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 6/7] drm/ili9225: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/ili9225.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index 8e98962db5a2..db89cced67df 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -379,16 +379,12 @@ static int ili9225_probe(struct spi_device *spi)
drm = >drm;
dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(dbi->reset)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
- return PTR_ERR(dbi->reset);
- }
+ if (IS_ERR(dbi->reset))
+ return dev_err_probe(dev, PTR_ERR(dbi->reset), "Failed to get
GPIO 'reset'\n");
rs = devm_gpiod_get(dev, "rs", GPIOD_OUT_LOW);
- if (IS_ERR(rs)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'rs'\n");
- return PTR_ERR(rs);
- }
+ if (IS_ERR(rs))
+ return dev_err_probe(dev, PTR_ERR(rs), "Failed to get GPIO
'rs'\n");
device_property_read_u32(dev, "rotation", );
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/7] drm/st7735r: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/st7735r.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
index faaba0a033ea..e3cbaa846e2b 100644
--- a/drivers/gpu/drm/tiny/st7735r.c
+++ b/drivers/gpu/drm/tiny/st7735r.c
@@ -207,16 +207,12 @@ static int st7735r_probe(struct spi_device *spi)
drm = >drm;
dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(dbi->reset)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
- return PTR_ERR(dbi->reset);
- }
+ if (IS_ERR(dbi->reset))
+ return dev_err_probe(dev, PTR_ERR(dbi->reset), "Failed to get
GPIO 'reset'\n");
dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_LOW);
- if (IS_ERR(dc)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
- return PTR_ERR(dc);
- }
+ if (IS_ERR(dc))
+ return dev_err_probe(dev, PTR_ERR(dc), "Failed to get GPIO
'dc'\n");
dbidev->backlight = devm_of_find_backlight(dev);
if (IS_ERR(dbidev->backlight))
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 4/7] drm/ili9486: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/ili9486.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index d7ce40eb166a..8d8dd6347b09 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -206,16 +206,12 @@ static int ili9486_probe(struct spi_device *spi)
drm = >drm;
dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(dbi->reset)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
- return PTR_ERR(dbi->reset);
- }
+ if (IS_ERR(dbi->reset))
+ return dev_err_probe(dev, PTR_ERR(dbi->reset), "Failed to get
GPIO 'reset'\n");
dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_LOW);
- if (IS_ERR(dc)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
- return PTR_ERR(dc);
- }
+ if (IS_ERR(dc))
+ return dev_err_probe(dev, PTR_ERR(dc), "Failed to get GPIO
'dc'\n");
dbidev->backlight = devm_of_find_backlight(dev);
if (IS_ERR(dbidev->backlight))
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 5/7] drm/ili9341: Avoid spamming logs if probe is deferred
The GPIO request can fail and probe may be deferred. Thus,
the error message may be printed again and again. Avoid
this by replacing DRM_DEV_ERROR() by dev_err_probe().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/ili9341.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
index 6ce97f0698eb..43418b0f8be3 100644
--- a/drivers/gpu/drm/tiny/ili9341.c
+++ b/drivers/gpu/drm/tiny/ili9341.c
@@ -192,16 +192,12 @@ static int ili9341_probe(struct spi_device *spi)
drm = >drm;
dbi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(dbi->reset)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
- return PTR_ERR(dbi->reset);
- }
+ if (IS_ERR(dbi->reset))
+ return dev_err_probe(dev, PTR_ERR(dbi->reset), "Failed to get
GPIO 'reset'\n");
dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
- if (IS_ERR(dc)) {
- DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
- return PTR_ERR(dc);
- }
+ if (IS_ERR(dc))
+ return dev_err_probe(dev, PTR_ERR(dc), "Failed to get GPIO
'dc'\n");
dbidev->backlight = devm_of_find_backlight(dev);
if (IS_ERR(dbidev->backlight))
--
2.30.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Fix build warnings
Fix the following build warnings.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:
In function ‘dm_update_mst_vcpi_slots_for_dsc’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6242:46:
warning: variable ‘old_con_state’ set but not used
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:
In function ‘amdgpu_dm_commit_cursors’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7709:44:
warning: variable ‘new_plane_state’ set but not used
The variables were introduced to be used in iterators, but not used.
Use other iterators which don't require the unused variables.
Fixes: 8ad278062de4e ("drm/amd/display: Disable cursors before disabling
planes")
Fixes: 29b9ba74f6384 ("drm/amd/display: Recalculate VCPI slots for new DSC
connectors")
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 573cf17262da..f9b87f1f424b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6239,13 +6239,13 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct
drm_atomic_state *state,
{
struct dc_stream_state *stream = NULL;
struct drm_connector *connector;
- struct drm_connector_state *new_con_state, *old_con_state;
+ struct drm_connector_state *new_con_state;
struct amdgpu_dm_connector *aconnector;
struct dm_connector_state *dm_conn_state;
int i, j, clock, bpp;
int vcpi, pbn_div, pbn = 0;
- for_each_oldnew_connector_in_state(state, connector, old_con_state,
new_con_state, i) {
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
aconnector = to_amdgpu_dm_connector(connector);
@@ -7706,15 +7706,14 @@ static void amdgpu_dm_handle_vrr_transition(struct
dm_crtc_state *old_state,
static void amdgpu_dm_commit_cursors(struct drm_atomic_state *state)
{
struct drm_plane *plane;
- struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane_state *old_plane_state;
int i;
/*
* TODO: Make this per-stream so we don't issue redundant updates for
* commits with multiple streams.
*/
- for_each_oldnew_plane_in_state(state, plane, old_plane_state,
- new_plane_state, i)
+ for_each_old_plane_in_state(state, plane, old_plane_state, i)
if (plane->type == DRM_PLANE_TYPE_CURSOR)
handle_cursor_update(plane, old_plane_state);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/todo: Add link to old debugfs RFC
On 04/21, Daniel Vetter wrote: > I always forget where it was, store it until this gets picked up by an > internship again. > > Cc: Wambui Karuga > Cc: Melissa Wen > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 7ff9fac10d8b..12e61869939e 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -546,6 +546,8 @@ There's a bunch of issues with it: >this (together with the drm_minor->drm_device move) would allow us to > remove >debugfs_init. > > +Previous RFC that hasn't landed yet: > https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/ > + Acked-by: Melissa Wen > Contact: Daniel Vetter > > Level: Intermediate > -- > 2.31.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping
On 21/04/2021 12:42, Matthew Auld wrote:
On 19/04/2021 16:01, Tvrtko Ursulin wrote:
On 19/04/2021 15:37, Matthew Auld wrote:
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object
location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
drivers/gpu/drm/i915/gt/intel_ring.c | 9 ++---
drivers/gpu/drm/i915/gt/selftest_context.c | 3 ++-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 +++-
drivers/gpu/drm/i915/i915_drv.h | 11
+--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 4 ++--
11 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index efe935f80c1a..b79568d370f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -664,7 +664,8 @@ static int init_status_page(struct
intel_engine_cs *engine)
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj,
+ i915_coherent_map_type(engine->i915, obj, true));
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto err_unpin;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 7c9af86fdb1e..47f4397095e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -23,7 +23,7 @@ static void dbg_poison_ce(struct
intel_context *ce)
if (ce->state) {
struct drm_i915_gem_object *obj =
ce->state->obj;
- int type =
i915_coherent_map_type(ce->engine->i915);
+ int type =
i915_coherent_map_type(ce->engine->i915, obj, true);
void *map;
if (!i915_gem_object_trylock(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e86897cde984..aafe2a4df496 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
GEM_BUG_ON(!i915_vma_is_pinned(ce->state));
*vaddr = i915_gem_object_pin_map(ce->state->obj,
- i915_coherent_map_type(ce->engine->i915) |
+ i915_coherent_map_type(ce->engine->i915,
+ ce->state->obj,
+ false) |
I915_MAP_OVERRIDE);
return PTR_ERR_OR_ZERO(*vaddr);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index aee0a77c77e0..3cf6c7e68108 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring
*ring, struct i915_gem_ww_ctx *ww)
if (i915_vma_is_map_and_fenceable(vma))
addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
- i915_coherent_map_type(vma->vm->i915));
+ else {
+ int type =
i915_coherent_map_type(vma->vm->i915, vma->obj, false);
+
+ addr = i915_gem_object_pin_map(vma->obj, type);
+ }
+
if (IS_ERR(addr)) {
ret = PTR_ERR(addr);
goto err_ring;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index b9bdd1d23243..26685b927169 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -88,7 +88,8 @@ static int __live_context_size(struct
intel_engine_cs *engine)
goto err;
vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
- i915_coherent_map_type(engine->i915));
+ i915_coherent_map_type(engine->i915,
+ ce->state->obj, false));
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
intel_context_unpin(ce);
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 746985971c3a..5b63d4df8c93 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++
[PATCH 4/4] drm/i915: Rewrite CL/CTG L-shaped memory detection
From: Ville Syrjälä
Currently we try to detect a symmetric memory configurations
using a magic DCC2_MODIFIED_ENHANCED_DISABLE bit. That bit is
either only set on a very specific subset of machines or it
just does not exist (it's not mentioned in any public chipset
datasheets I've found). As it happens my CL/CTG machines never
set said bit, even if I populate the channels with identical
sticks.
So let's do the L-shaped memory detection the same way as the
desktop variants, ie. just look at the DRAM rank boundary
registers to see if both channels have an identical size.
With this my CL/CTG no longer claim L-shaped memory when I use
identical sticks. Also tested with non-matching sticks just to
make sure the L-shaped memory is still properly detected.
And for completeness let's update the debugfs code to dump
the correct set of registers on each platform.
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 15 ---
drivers/gpu/drm/i915/i915_debugfs.c | 16
drivers/gpu/drm/i915/i915_reg.h | 4
3 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 0fa6c38893f7..754f20768de5 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -693,14 +693,15 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
swizzle_x = I915_BIT_6_SWIZZLE_9_10_17;
swizzle_y = I915_BIT_6_SWIZZLE_9_17;
}
- break;
- }
- /* check for L-shaped memory aka modified enhanced addressing */
- if (IS_GEN(i915, 4) &&
- !(intel_uncore_read(uncore, DCC2) &
DCC2_MODIFIED_ENHANCED_DISABLE)) {
- swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
- swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
+ /* check for L-shaped memory aka modified enhanced
addressing */
+ if (IS_GEN(i915, 4) &&
+ intel_uncore_read16(uncore, C0DRB3_CL) !=
+ intel_uncore_read16(uncore, C1DRB3_CL)) {
+ swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
+ swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
+ }
+ break;
}
if (dcc == 0x) {
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8dd374691102..6de11ffcde38 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -621,10 +621,18 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
intel_uncore_read(uncore, DCC));
seq_printf(m, "DDC2 = 0x%08x\n",
intel_uncore_read(uncore, DCC2));
- seq_printf(m, "C0DRB3 = 0x%04x\n",
- intel_uncore_read16(uncore, C0DRB3_BW));
- seq_printf(m, "C1DRB3 = 0x%04x\n",
- intel_uncore_read16(uncore, C1DRB3_BW));
+
+ if (IS_G45(dev_priv) || IS_I965G(dev_priv) || IS_G33(dev_priv))
{
+ seq_printf(m, "C0DRB3 = 0x%04x\n",
+ intel_uncore_read16(uncore, C0DRB3_BW));
+ seq_printf(m, "C1DRB3 = 0x%04x\n",
+ intel_uncore_read16(uncore, C1DRB3_BW));
+ } else if (IS_GEN(dev_priv, 4)) {
+ seq_printf(m, "C0DRB3 = 0x%04x\n",
+ intel_uncore_read16(uncore, C0DRB3_CL));
+ seq_printf(m, "C1DRB3 = 0x%04x\n",
+ intel_uncore_read16(uncore, C1DRB3_CL));
+ }
} else if (INTEL_GEN(dev_priv) >= 6) {
seq_printf(m, "MAD_DIMM_C0 = 0x%08x\n",
intel_uncore_read(uncore, MAD_DIMM_C0));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0587b2455ea1..055c258179a1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3790,6 +3790,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define C0DRB3_BW _MMIO(MCHBAR_MIRROR_BASE + 0x206)
#define C1DRB3_BW _MMIO(MCHBAR_MIRROR_BASE + 0x606)
+/* 965gm,ctg DRAM channel configuration */
+#define C0DRB3_CL _MMIO(MCHBAR_MIRROR_BASE + 0x1206)
+#define C1DRB3_CL _MMIO(MCHBAR_MIRROR_BASE + 0x1306)
+
/* snb MCH registers for reading the DRAM channel configuration */
#define MAD_DIMM_C0_MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5004)
#define MAD_DIMM_C1_MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5008)
--
2.26.3
[PATCH 3/4] drm/i915: Give C0DRB3/C1DRB3 a _BW suffix
From: Ville Syrjälä
These are the 965g/g45/g33 specific DRB registers. Give them
a suitable suffix so we can add their counterparts for other
platforms.
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 8a322594210c..0fa6c38893f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -653,8 +653,8 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
* banks of memory are paired and unswizzled on the
* uneven portion, so leave that as unknown.
*/
- if (intel_uncore_read16(uncore, C0DRB3) ==
- intel_uncore_read16(uncore, C1DRB3)) {
+ if (intel_uncore_read16(uncore, C0DRB3_BW) ==
+ intel_uncore_read16(uncore, C1DRB3_BW)) {
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
swizzle_y = I915_BIT_6_SWIZZLE_9;
}
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b654b7498bcd..8dd374691102 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -622,9 +622,9 @@ static int i915_swizzle_info(struct seq_file *m, void *data)
seq_printf(m, "DDC2 = 0x%08x\n",
intel_uncore_read(uncore, DCC2));
seq_printf(m, "C0DRB3 = 0x%04x\n",
- intel_uncore_read16(uncore, C0DRB3));
+ intel_uncore_read16(uncore, C0DRB3_BW));
seq_printf(m, "C1DRB3 = 0x%04x\n",
- intel_uncore_read16(uncore, C1DRB3));
+ intel_uncore_read16(uncore, C1DRB3_BW));
} else if (INTEL_GEN(dev_priv) >= 6) {
seq_printf(m, "MAD_DIMM_C0 = 0x%08x\n",
intel_uncore_read(uncore, MAD_DIMM_C0));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 66a902b3bb8e..0587b2455ea1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3787,8 +3787,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define CSHRDDR3CTL_DDR3 (1 << 2)
/* 965 MCH register controlling DRAM channel configuration */
-#define C0DRB3 _MMIO(MCHBAR_MIRROR_BASE + 0x206)
-#define C1DRB3 _MMIO(MCHBAR_MIRROR_BASE + 0x606)
+#define C0DRB3_BW _MMIO(MCHBAR_MIRROR_BASE + 0x206)
+#define C1DRB3_BW _MMIO(MCHBAR_MIRROR_BASE + 0x606)
/* snb MCH registers for reading the DRAM channel configuration */
#define MAD_DIMM_C0_MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5004)
--
2.26.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/i915: Read C0DRB3/C1DRB3 as 16 bits again
From: Ville Syrjälä
We've defined C0DRB3/C0DRB3 as 16 bit registers, so access them
as such.
Fixes: 1c8242c3a4b2 ("drm/i915: Use unchecked writes for setting up the fences")
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index e72b7a0dc316..8a322594210c 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -653,8 +653,8 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
* banks of memory are paired and unswizzled on the
* uneven portion, so leave that as unknown.
*/
- if (intel_uncore_read(uncore, C0DRB3) ==
- intel_uncore_read(uncore, C1DRB3)) {
+ if (intel_uncore_read16(uncore, C0DRB3) ==
+ intel_uncore_read16(uncore, C1DRB3)) {
swizzle_x = I915_BIT_6_SWIZZLE_9_10;
swizzle_y = I915_BIT_6_SWIZZLE_9;
}
--
2.26.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/i915: Avoid div-by-zero on gen2
From: Ville Syrjälä
Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size()
can in fact return <4KiB, which leads to div-by-zero here.
Avoid that.
Not sure i915_gem_object_get_tile_row_size() is entirely
sane anyway since it doesn't account for the different tile
layouts on i8xx/i915...
I'm not able to hit this before commit 6846895fde05 ("drm/i915:
Replace PIN_NONFAULT with calls to PIN_NOEVICT") and it looks
like I also need to run recent version of Mesa. With those in
place xonotic trips on this quite easily on my 85x.
Cc: sta...@vger.kernel.org
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2561a2f1e54f..8598a1c78a4c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -189,7 +189,7 @@ compute_partial_view(const struct drm_i915_gem_object *obj,
struct i915_ggtt_view view;
if (i915_gem_object_is_tiled(obj))
- chunk = roundup(chunk, tile_row_pages(obj));
+ chunk = roundup(chunk, tile_row_pages(obj) ?: 1);
view.type = I915_GGTT_VIEW_PARTIAL;
view.partial.offset = rounddown(page_offset, chunk);
--
2.26.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/i915: Fix older platforms
From: Ville Syrjälä Fix a div-by-zero on gen2, and make the L-shaped memory detection actually work on cl/ctg. Atm the SWIZZLE_UNKNOWN stuff just trips some GEM_BUG_ONs. This doesn't fix those but since I populate all my memory channels symmetrically I get to avoid the GEM_BUG_ONs by correctly detecting that I don't have an L-shaped memory configuration. Ville Syrjälä (4): drm/i915: Avoid div-by-zero on gen2 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again drm/i915: Give C0DRB3/C1DRB3 a _BW suffix drm/i915: Rewrite CL/CTG L-shaped memory detection drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 19 ++- drivers/gpu/drm/i915/i915_debugfs.c | 16 drivers/gpu/drm/i915/i915_reg.h | 8 ++-- 4 files changed, 29 insertions(+), 16 deletions(-) -- 2.26.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo
On Wed, Apr 21, 2021 at 10:37:11AM +, peter.enderb...@sony.com wrote: > On 4/21/21 11:15 AM, Daniel Vetter wrote: > > > > We need to understand what the "correct" value is. Not in terms of kernel > > code, but in terms of semantics. Like if userspace allocates a GL texture, > > is this supposed to show up in your metric or not. Stuff like that. > That it like that would like to only one pointer type. You need to know what > > you pointing at to know what it is. it might be a hardware or a other pointer. > > If there is a limitation on your pointers it is a good metric to count them > even if you don't know what they are. Same goes for dma-buf, they > are generic, but they consume some resources that are counted in pages. > > It would be very good if there a sub division where you could measure > all possible types separately. We have the detailed in debugfs, but nothing > for the user. A summary in meminfo seems to be the best place for such > metric. Let me try to summarize my understanding of the problem, maybe it'll help others as well. A device driver allocates memory and exports this memory via dma-buf so that this memory will be accessible for userspace via a file descriptor. The allocated memory can be either allocated with alloc_page() from system RAM or by other means from dedicated VRAM (that is not managed by Linux mm) or even from on-device memory. The dma-buf driver tracks the amount of the memory it was requested to export and the size it sees is available at debugfs and fdinfo. The debugfs is not available to user and maybe entirely disabled in production systems. There could be quite a few open dma-bufs so there is no overall summary, plus fdinfo in production systems your refer to is also unavailable to the user because of selinux policy. And there are a few details that are not clear to me: * Since DRM device drivers seem to be the major user of dma-buf exports, why cannot we add information about their memory consumption to, say, /sys/class/graphics/drm/cardX/memory-usage? * How exactly user generates reports that would include the new counters? From my (mostly outdated) experience Android users won't open a terminal and type 'cat /proc/meminfo' there. I'd presume there is a vendor agent that collects the data and sends it for analysis. In this case what is the reason the vendor is unable to adjust selinix policy so that the agent will be able to access fdinfo? * And, as others already mentioned, it is not clear what are the problems that can be detected by examining DmaBufTotal except saying "oh, there is too much/too little memory exported via dma-buf". What would be user visible effects of these problems? What are the next steps to investigate them? What other data will be probably required to identify root cause? -- Sincerely yours, Mike. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/todo: Add link to old debugfs RFC
I always forget where it was, store it until this gets picked up by an internship again. Cc: Wambui Karuga Cc: Melissa Wen Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7ff9fac10d8b..12e61869939e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -546,6 +546,8 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. +Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karu...@gmail.com/ + Contact: Daniel Vetter Level: Intermediate -- 2.31.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()
[AMD Official Use Only - Internal Distribution Only]
I'm fine with having these changes go through drm-misc.
Alex
From: Lipski, Mikita
Sent: Wednesday, April 21, 2021 10:23 AM
To: Lyude Paul ; dri-devel@lists.freedesktop.org
; intel-...@lists.freedesktop.org
; nouv...@lists.freedesktop.org
; amd-...@lists.freedesktop.org
; Ville Syrjälä ;
Jani Nikula ; Rodrigo Vivi
; Thomas Zimmermann ; Thierry
Reding
Cc: Wang, Chao-kai (Stylon) ; Lipski, Mikita
; Park, Chris ; Brol, Eryk
; Li, Sun peng (Leo) ; Lakha,
Bhawanpreet ; Lin, Wayne ;
Siqueira, Rodrigo ; open list
; Kazlauskas, Nicholas
; Somasundaram, Meenakshikumar
; David Airlie ; Pillai,
Aurabindo ; Daniel Vetter ; Bas
Nieuwenhuizen ; Deucher, Alexander
; Cornij, Nikola ; Wentland,
Harry ; Koenig, Christian
Subject: Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to
amdgpu_dm_initialize_dp_connector()
Thanks for the change!
Reviewed-by: Mikita Lipski
On 2021-04-19 6:55 p.m., Lyude Paul wrote:
> While working on moving i2c device registration into drm_dp_aux_init() - I
> realized that in order to do so we need to make sure that drivers calling
> drm_dp_aux_init() handle any errors it could possibly return. In the
> process of doing that, I noticed that the majority of AMD's code for DP
> connector creation doesn't attempt to do any real error handling.
>
> So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
> while we're at it. This way we can handle the error codes from
> drm_dp_aux_init().
>
> Signed-off-by: Lyude Paul
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++-
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 44 +++
> .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 6 +--
> 3 files changed, 45 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a0c8c41e4e57..fc5d315bbb05 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7608,10 +7608,9 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>aconnector->i2c = i2c;
>res = i2c_add_adapter(>base);
> -
>if (res) {
>DRM_ERROR("Failed to register hw i2c %d\n", link->link_index);
> - goto out_free;
> + goto fail_free;
>}
>
>connector_type = to_drm_connector_type(link->connector_signal);
> @@ -7625,8 +7624,7 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>
>if (res) {
>DRM_ERROR("connector_init failed\n");
> - aconnector->connector_id = -1;
> - goto out_free;
> + goto fail_id;
>}
>
>drm_connector_helper_add(
> @@ -7643,15 +7641,22 @@ static int amdgpu_dm_connector_init(struct
> amdgpu_display_manager *dm,
>drm_connector_attach_encoder(
>>base, >base);
>
> - if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
> - || connector_type == DRM_MODE_CONNECTOR_eDP)
> - amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> -
> -out_free:
> - if (res) {
> - kfree(i2c);
> - aconnector->i2c = NULL;
> + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector_type == DRM_MODE_CONNECTOR_eDP) {
> + res = amdgpu_dm_initialize_dp_connector(dm, aconnector,
> link->link_index);
> + if (res)
> + goto fail_cleanup;
>}
> +
> + return 0;
> +fail_cleanup:
> + drm_connector_cleanup(>base);
> +fail_id:
> + aconnector->connector_id = -1;
> +fail_free:
> + kfree(i2c);
> + aconnector->i2c = NULL;
> +
>return res;
> }
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 73cdb9fe981a..3dee9cce9c9e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -425,33 +425,39 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs
> = {
>.add_connector = dm_dp_add_mst_connector,
> };
>
> -void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
> -struct amdgpu_dm_connector *aconnector,
> -int link_index)
> +int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
> + struct amdgpu_dm_connector *aconnector,
> + int link_index)
> {
> - aconnector->dm_dp_aux.aux.name =
> - kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d",
> - link_index);
> - aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
> -
Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo
On Wed 21-04-21 10:37:11, peter.enderb...@sony.com wrote: > On 4/21/21 11:15 AM, Daniel Vetter wrote: [...] > > We need to understand what the "correct" value is. Not in terms of kernel > > code, but in terms of semantics. Like if userspace allocates a GL texture, > > is this supposed to show up in your metric or not. Stuff like that. > That it like that would like to only one pointer type. You need to know what > > you pointing at to know what it is. it might be a hardware or a other pointer. > > If there is a limitation on your pointers it is a good metric to count them > even if you don't know what they are. Same goes for dma-buf, they > are generic, but they consume some resources that are counted in pages. > > It would be very good if there a sub division where you could measure > all possible types separately. We have the detailed in debugfs, but nothing > for the user. A summary in meminfo seems to be the best place for such > metric. I strongly suspect that the main problem of this patch (and its previous versions) is that you are failing to explain the purpose of the counter to others. From what you have said so far it sounds like this is a number which is nice to have because gives us more than nothing. And while this is not really hard to agree with it doesn't really meet the justification for exporting yet another counter to the userspace with all the headache of the future maintenance. I think it would hugely help to describe a typical scenario when the counter would be useful and the conclusion you can draw from the exported value or a set of values over time. And please note that a mixed bag of different memory resources in a single counter doesn't make this any easier because then it essentially makes it impossible to know whether an excessive usage contribues to RAM or device memory depletion - hence this is completely bogus for the OOM report. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix docbook descriptions for i915_cmd_parser
Op 21-04-2021 om 16:32 schreef Daniel Vetter:
> On Wed, Apr 21, 2021 at 2:03 PM Maarten Lankhorst
> wrote:
>> Fixes the following htmldocs warnings:
>> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function
>> parameter 'trampoline' description in 'intel_engine_cmd_parser'
>> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
>> member 'jump_whitelist' not described in 'intel_engine_cmd_parser'
>> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
>> member 'shadow_map' not described in 'intel_engine_cmd_parser'
>> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
>> member 'batch_map' not described in 'intel_engine_cmd_parser'
>> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function
>> parameter 'trampoline' description in 'intel_engine_cmd_parser'
>>
>> Reported-by: Stephen Rothwell
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/i915_cmd_parser.c | 16 +++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
>> b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> index e6f1e93a..afb9b7516999 100644
>> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
>> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> @@ -1369,6 +1369,18 @@ static int check_bbstart(u32 *cmd, u32 offset, u32
>> length,
>> return 0;
>> }
>>
>> +/**
>> + * intel_engine_cmd_parser_alloc_jump_whitelist() - preallocate jump
>> whitelist for intel_engine_cmd_parser()
>> + * @batch_length: length of the commands in batch_obj
>> + * @trampoline: Whether jump trampolines are used.
>> + *
>> + * Preallocates a jump whitelist for parsing the cmd buffer in
>> intel_engine_cmd_parser().
>> + * This has to be preallocated, because the command parser runs in
>> signaling context,
>> + * and may not allocate any memory.
>> + *
>> + * Return: NULL or pointer to a jump whitelist, or ERR_PTR() on failure. Use
>> + * IS_ERR() to check for errors. Must bre freed() with kfree().
> IS_ERR_OR_NULL or needs an actual bugfix in the code since we're not
> consistent. Also s/bre/be/
We're sort of consistent, NULL is a valid return code. IS_ERR is only on
faliure. :)
> -Daniel
>
>> + */
>> unsigned long *intel_engine_cmd_parser_alloc_jump_whitelist(u32
>> batch_length,
>> bool trampoline)
>> {
>> @@ -1401,7 +1413,9 @@ unsigned long
>> *intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length,
>> * @batch_offset: byte offset in the batch at which execution starts
>> * @batch_length: length of the commands in batch_obj
>> * @shadow: validated copy of the batch buffer in question
>> - * @trampoline: whether to emit a conditional trampoline at the end of the
>> batch
>> + * @jump_whitelist: buffer preallocated with
>> intel_engine_cmd_parser_alloc_jump_whitelist()
>> + * @shadow_map: mapping to @shadow vma
>> + * @batch_map: mapping to @batch vma
>> *
>> * Parses the specified batch buffer looking for privilege violations as
>> * described in the overview.
>> --
>> 2.31.0
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/i915: Create stolen memory region from local memory
On 21/04/2021 11:46, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
- mem->type is only setup after the region probe, so setting the name
as stolen-local or stolen-system based on this value won't work. Split
system vs local stolen setup to fix this.
- kill all the region->devmem/is_devmem stuff. We already differentiate
the different types of stolen so such things shouldn't be needed
anymore.
v3:
- split stolen lmem vs smem ops(Tvrtko)
- add shortcut for stolen region in i915(Tvrtko)
- sanity check dsm base vs bar size(Xinyun)
v4(Tvrtko):
- more cleanup
- add some TODOs
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
Cc: Xinyun Liu
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 132 ++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 3 +-
drivers/gpu/drm/i915/i915_drv.h| 7 ++
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_memory_region.c | 13 +-
drivers/gpu/drm/i915/intel_memory_region.h | 5 +-
7 files changed, 140 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index b0597de206de..13a7932cfe1a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -10,6 +10,7 @@
#include
#include
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
@@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ /*
+* With stolen lmem, we don't need to check if the address range
+* overlaps with the non-stolen system memory range, since lmem is local
+* to the gpu.
+*/
+ if (HAS_LMEM(i915))
+ return 0;
+
/*
* Verify that nothing else uses this physical address. Stolen
* memory should be reserved by the BIOS and hidden from the
@@ -374,8 +383,9 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
}
}
-static int i915_gem_init_stolen(struct drm_i915_private *i915)
+static int i915_gem_init_stolen(struct intel_memory_region *mem)
{
+ struct drm_i915_private *i915 = mem->i915;
struct intel_uncore *uncore = >uncore;
resource_size_t reserved_base, stolen_top;
resource_size_t reserved_total, reserved_size;
@@ -396,10 +406,10 @@ static int i915_gem_init_stolen(struct drm_i915_private
*i915)
return 0;
}
- if (resource_size(_graphics_stolen_res) == 0)
+ if (resource_size(>region) == 0)
return 0;
- i915->dsm = intel_graphics_stolen_res;
+ i915->dsm = mem->region;
if (i915_adjust_stolen(i915, >dsm))
return 0;
@@ -688,39 +698,123 @@ struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_i915_private *i915,
resource_size_t size)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_STOLEN_SMEM],
+ return i915_gem_object_create_region(i915->mm.stolen_region,
size, I915_BO_ALLOC_CONTIGUOUS);
}
-static int init_stolen(struct intel_memory_region *mem)
+static int init_stolen_smem(struct intel_memory_region *mem)
{
- intel_memory_region_set_name(mem, "stolen");
-
/*
* Initialise stolen early so that we may reserve preallocated
* objects for the BIOS to KMS transition.
*/
- return i915_gem_init_stolen(mem->i915);
+ return i915_gem_init_stolen(mem);
}
-static void release_stolen(struct intel_memory_region *mem)
+static void release_stolen_smem(struct intel_memory_region *mem)
{
i915_gem_cleanup_stolen(mem->i915);
}
-static const struct intel_memory_region_ops i915_region_stolen_ops = {
- .init = init_stolen,
- .release = release_stolen,
+static const struct intel_memory_region_ops i915_region_stolen_smem_ops = {
+ .init = init_stolen_smem,
+ .release = release_stolen_smem,
.init_object = _i915_gem_object_stolen_init,
};
-struct intel_memory_region *i915_gem_stolen_setup(struct drm_i915_private *i915)
+static int init_stolen_lmem(struct intel_memory_region *mem)
+{
+ int err;
+
+ if (GEM_WARN_ON(resource_size(>region) == 0))
+ return -ENODEV;
+
+ if (!io_mapping_init_wc(>iomap,
+ mem->io_start,
+ resource_size(>region)))
+ return -EIO;
+
+ /*
+* TODO: For stolen lmem we mostly
Re: [PATCH] drm/i915: Fix docbook descriptions for i915_gem_shrinker
On Wed, Apr 21, 2021 at 2:09 PM Maarten Lankhorst
wrote:
>
> Fixes the following htmldocs warning:
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
> or member 'ww' not described in 'i915_gem_shrink'
>
> Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
> Reported-by: Stephen Rothwell
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index 7545ddd83659..f4fb68e8955a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -72,6 +72,7 @@ static void try_to_writeback(struct drm_i915_gem_object
> *obj,
>
> /**
> * i915_gem_shrink - Shrink buffer object caches
> + * @ww: i915 gem ww acquire ctx, or NULL
> * @i915: i915 device
> * @target: amount of memory to make available, in pages
> * @nr_scanned: optional output for number of pages scanned (incremental)
> --
> 2.31.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix docbook descriptions for i915_cmd_parser
On Wed, Apr 21, 2021 at 2:03 PM Maarten Lankhorst
wrote:
>
> Fixes the following htmldocs warnings:
> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function
> parameter 'trampoline' description in 'intel_engine_cmd_parser'
> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
> member 'jump_whitelist' not described in 'intel_engine_cmd_parser'
> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
> member 'shadow_map' not described in 'intel_engine_cmd_parser'
> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
> member 'batch_map' not described in 'intel_engine_cmd_parser'
> drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function
> parameter 'trampoline' description in 'intel_engine_cmd_parser'
>
> Reported-by: Stephen Rothwell
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index e6f1e93a..afb9b7516999 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -1369,6 +1369,18 @@ static int check_bbstart(u32 *cmd, u32 offset, u32
> length,
> return 0;
> }
>
> +/**
> + * intel_engine_cmd_parser_alloc_jump_whitelist() - preallocate jump
> whitelist for intel_engine_cmd_parser()
> + * @batch_length: length of the commands in batch_obj
> + * @trampoline: Whether jump trampolines are used.
> + *
> + * Preallocates a jump whitelist for parsing the cmd buffer in
> intel_engine_cmd_parser().
> + * This has to be preallocated, because the command parser runs in signaling
> context,
> + * and may not allocate any memory.
> + *
> + * Return: NULL or pointer to a jump whitelist, or ERR_PTR() on failure. Use
> + * IS_ERR() to check for errors. Must bre freed() with kfree().
IS_ERR_OR_NULL or needs an actual bugfix in the code since we're not
consistent. Also s/bre/be/
-Daniel
> + */
> unsigned long *intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length,
> bool trampoline)
> {
> @@ -1401,7 +1413,9 @@ unsigned long
> *intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length,
> * @batch_offset: byte offset in the batch at which execution starts
> * @batch_length: length of the commands in batch_obj
> * @shadow: validated copy of the batch buffer in question
> - * @trampoline: whether to emit a conditional trampoline at the end of the
> batch
> + * @jump_whitelist: buffer preallocated with
> intel_engine_cmd_parser_alloc_jump_whitelist()
> + * @shadow_map: mapping to @shadow vma
> + * @batch_map: mapping to @batch vma
> *
> * Parses the specified batch buffer looking for privilege violations as
> * described in the overview.
> --
> 2.31.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/4] drm/i915/stolen: actually mark as contiguous
On 21/04/2021 11:46, Matthew Auld wrote:
Stolen memory is always allocated as physically contiguous pages, so
mark the object flags as such. It looks like the flags were previously
just ignored so this had no effect. In the future we might to add the
proper plumbing for passing the flags all over the way down from the
caller, but for now we don't have a use for that.
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index b43929da8de8..c5b64b2400e8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -637,10 +637,17 @@ static int __i915_gem_object_create_stolen(struct
intel_memory_region *mem,
{
static struct lock_class_key lock_class;
unsigned int cache_level;
+ unsigned int flags;
int err;
+ /*
+* Stolen objects are always physically contiguous since we just
+* allocate one big block underneath using the drm_mm range allocator.
+*/
+ flags = I915_BO_ALLOC_CONTIGUOUS;
+
drm_gem_private_object_init(>i915->drm, >base, stolen->size);
- i915_gem_object_init(obj, _gem_object_stolen_ops, _class, 0);
+ i915_gem_object_init(obj, _gem_object_stolen_ops, _class,
flags);
obj->stolen = stolen;
obj->read_domains = I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT;
@@ -699,8 +706,7 @@ struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_i915_private *i915,
resource_size_t size)
{
- return i915_gem_object_create_region(i915->mm.stolen_region,
-size, I915_BO_ALLOC_CONTIGUOUS);
+ return i915_gem_object_create_region(i915->mm.stolen_region, size, 0);
}
static int init_stolen_smem(struct intel_memory_region *mem)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI
On 21/04/2021 14:54, Jason Ekstrand wrote:
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
On 20/04/2021 18:00, Jason Ekstrand wrote:
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
wrote:
On 19/04/2021 16:19, Jason Ekstrand wrote:
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
On 16/04/2021 17:38, Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
v3:
(Daniel)
- add a note for set/get caching stuff
- add some more docs for existing query and extensions stuff
- add an actual code example for regions query
- bunch of other stuff
(Jason)
- uAPI change(!):
- try a simpler design with the placements extension
- rather than have a generic setparam which can cover multiple
use cases, have each extension be responsible for one thing
only
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_gem_lmem.h | 255
Documentation/gpu/rfc/i915_gem_lmem.rst | 139 +
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 398 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
b/Documentation/gpu/rfc/i915_gem_lmem.h
new file mode 100644
index ..2a82a452e9f2
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_gem_lmem.h
@@ -0,0 +1,255 @@
+/*
+ * Note that drm_i915_query_item and drm_i915_query are existing bits of uAPI.
+ * For the regions query we are just adding a new query id, so no actual new
+ * ioctl or anything, but including it here for reference.
+ */
+struct drm_i915_query_item {
+#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
+
+__u64 query_id;
+
+/*
+ * When set to zero by userspace, this is filled with the size of the
+ * data to be written at the data_ptr pointer. The kernel sets this
+ * value to a negative value to signal an error on a particular query
+ * item.
+ */
+__s32 length;
+
+__u32 flags;
+/*
+ * Data will be written at the location pointed by data_ptr when the
+ * value of length matches the length of the data to be written by the
+ * kernel.
+ */
+__u64 data_ptr;
+};
+
+struct drm_i915_query {
+__u32 num_items;
+/*
+ * Unused for now. Must be cleared to zero.
+ */
+__u32 flags;
+/*
+ * This points to an array of num_items drm_i915_query_item structures.
+ */
+__u64 items_ptr;
+};
+
+#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_QUERY,
struct drm_i915_query)
+
+/**
+ * enum drm_i915_gem_memory_class
+ */
+enum drm_i915_gem_memory_class {
+ /** @I915_MEMORY_CLASS_SYSTEM: system memory */
+ I915_MEMORY_CLASS_SYSTEM = 0,
+ /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
+ I915_MEMORY_CLASS_DEVICE,
+};
+
+/**
+ * struct drm_i915_gem_memory_class_instance
+ */
+struct drm_i915_gem_memory_class_instance {
+ /** @memory_class: see enum drm_i915_gem_memory_class */
+ __u16 memory_class;
+
+ /** @memory_instance: which instance */
+ __u16 memory_instance;
+};
+
+/**
+ * struct drm_i915_memory_region_info
+ *
+ * Describes one region as known to the driver.
+ *
+ * Note that we reserve quite a lot of stuff here for potential future work. As
+ * an example we might want expose the capabilities(see caps) for a given
+ * region, which could include things like if the region is CPU
+ * mappable/accessible etc.
I get caps but I'm seriously at a loss as to what the rest of this
would be used for. Why are caps and flags both there and separate?
Flags are typically something you set, not query. Also, what's with
rsvd1 at the end? This smells of substantial over-building to me.
I thought to myself, "maybe I'm missing a future use-case" so I looked
at the internal tree and none of this is being used there either.
This indicates to me that either I'm missing something and there's
code somewhere I don't know about or, with three years of building on
internal branches, we still haven't proven that any of this is needed.
If it's the latter, which I strongly suspect, maybe we should drop the
unnecessary bits and only add them back in if and when we have proof
that they're useful.
Do you mean just drop caps/flags here, but keep/inflate rsvd0/rsvd1,
which is less opinionated
Re: [PATCH v3 01/20] drm/amdgpu: Add error handling to amdgpu_dm_initialize_dp_connector()
Thanks for the change!
Reviewed-by: Mikita Lipski
On 2021-04-19 6:55 p.m., Lyude Paul wrote:
While working on moving i2c device registration into drm_dp_aux_init() - I
realized that in order to do so we need to make sure that drivers calling
drm_dp_aux_init() handle any errors it could possibly return. In the
process of doing that, I noticed that the majority of AMD's code for DP
connector creation doesn't attempt to do any real error handling.
So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
while we're at it. This way we can handle the error codes from
drm_dp_aux_init().
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 44 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.h | 6 +--
3 files changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a0c8c41e4e57..fc5d315bbb05 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7608,10 +7608,9 @@ static int amdgpu_dm_connector_init(struct
amdgpu_display_manager *dm,
aconnector->i2c = i2c;
res = i2c_add_adapter(>base);
-
if (res) {
DRM_ERROR("Failed to register hw i2c %d\n", link->link_index);
- goto out_free;
+ goto fail_free;
}
connector_type = to_drm_connector_type(link->connector_signal);
@@ -7625,8 +7624,7 @@ static int amdgpu_dm_connector_init(struct
amdgpu_display_manager *dm,
if (res) {
DRM_ERROR("connector_init failed\n");
- aconnector->connector_id = -1;
- goto out_free;
+ goto fail_id;
}
drm_connector_helper_add(
@@ -7643,15 +7641,22 @@ static int amdgpu_dm_connector_init(struct
amdgpu_display_manager *dm,
drm_connector_attach_encoder(
>base, >base);
- if (connector_type == DRM_MODE_CONNECTOR_DisplayPort
- || connector_type == DRM_MODE_CONNECTOR_eDP)
- amdgpu_dm_initialize_dp_connector(dm, aconnector,
link->link_index);
-
-out_free:
- if (res) {
- kfree(i2c);
- aconnector->i2c = NULL;
+ if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector_type == DRM_MODE_CONNECTOR_eDP) {
+ res = amdgpu_dm_initialize_dp_connector(dm, aconnector,
link->link_index);
+ if (res)
+ goto fail_cleanup;
}
+
+ return 0;
+fail_cleanup:
+ drm_connector_cleanup(>base);
+fail_id:
+ aconnector->connector_id = -1;
+fail_free:
+ kfree(i2c);
+ aconnector->i2c = NULL;
+
return res;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 73cdb9fe981a..3dee9cce9c9e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -425,33 +425,39 @@ static const struct drm_dp_mst_topology_cbs dm_mst_cbs = {
.add_connector = dm_dp_add_mst_connector,
};
-void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
- struct amdgpu_dm_connector *aconnector,
- int link_index)
+int amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
+ struct amdgpu_dm_connector *aconnector,
+ int link_index)
{
- aconnector->dm_dp_aux.aux.name =
- kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d",
- link_index);
- aconnector->dm_dp_aux.aux.transfer = dm_dp_aux_transfer;
- aconnector->dm_dp_aux.ddc_service = aconnector->dc_link->ddc;
+ struct amdgpu_dm_dp_aux *dm_aux = >dm_dp_aux;
+ int ret;
- drm_dp_aux_init(>dm_dp_aux.aux);
- drm_dp_cec_register_connector(>dm_dp_aux.aux,
- >base);
+ dm_aux->aux.name = kasprintf(GFP_KERNEL, "AMDGPU DM aux hw bus %d",
link_index);
+ if (!dm_aux->aux.name)
+ return -ENOMEM;
+
+ dm_aux->aux.transfer = dm_dp_aux_transfer;
+ dm_aux->ddc_service = aconnector->dc_link->ddc;
+
+ drm_dp_aux_init(_aux->aux);
+ drm_dp_cec_register_connector(_aux->aux, >base);
if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
- return;
+ return 0;
aconnector->mst_mgr.cbs = _mst_cbs;
- drm_dp_mst_topology_mgr_init(
- >mst_mgr,
- adev_to_drm(dm->adev),
- >dm_dp_aux.aux,
- 16,
- 4,
- aconnector->connector_id);
+ ret =
Re: [PATCH v3 4/4] drm/doc/rfc: i915 DG1 uAPI
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
>
> On 20/04/2021 18:00, Jason Ekstrand wrote:
> > On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 19/04/2021 16:19, Jason Ekstrand wrote:
> >>> On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld
> >>> wrote:
>
> On 16/04/2021 17:38, Jason Ekstrand wrote:
> > On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld
> > wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1.
> >>
> >> v2(Daniel):
> >> - include the overall upstreaming plan
> >> - add a note for mmap, there are differences here for TTM vs i915
> >> - bunch of other suggestions from Daniel
> >> v3:
> >> (Daniel)
> >> - add a note for set/get caching stuff
> >> - add some more docs for existing query and extensions stuff
> >> - add an actual code example for regions query
> >> - bunch of other stuff
> >> (Jason)
> >> - uAPI change(!):
> >>- try a simpler design with the placements extension
> >>- rather than have a generic setparam which can cover
> >> multiple
> >> use cases, have each extension be responsible for one
> >> thing
> >> only
> >>
> >> Signed-off-by: Matthew Auld
> >> Cc: Joonas Lahtinen
> >> Cc: Jordan Justen
> >> Cc: Daniel Vetter
> >> Cc: Kenneth Graunke
> >> Cc: Jason Ekstrand
> >> Cc: Dave Airlie
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: mesa-...@lists.freedesktop.org
> >> ---
> >> Documentation/gpu/rfc/i915_gem_lmem.h | 255
> >>
> >> Documentation/gpu/rfc/i915_gem_lmem.rst | 139 +
> >> Documentation/gpu/rfc/index.rst | 4 +
> >> 3 files changed, 398 insertions(+)
> >> create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
> >> create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
> >>
> >> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
> >> b/Documentation/gpu/rfc/i915_gem_lmem.h
> >> new file mode 100644
> >> index ..2a82a452e9f2
> >> --- /dev/null
> >> +++ b/Documentation/gpu/rfc/i915_gem_lmem.h
> >> @@ -0,0 +1,255 @@
> >> +/*
> >> + * Note that drm_i915_query_item and drm_i915_query are existing bits
> >> of uAPI.
> >> + * For the regions query we are just adding a new query id, so no
> >> actual new
> >> + * ioctl or anything, but including it here for reference.
> >> + */
> >> +struct drm_i915_query_item {
> >> +#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
> >> +
> >> +__u64 query_id;
> >> +
> >> +/*
> >> + * When set to zero by userspace, this is filled with the
> >> size of the
> >> + * data to be written at the data_ptr pointer. The kernel
> >> sets this
> >> + * value to a negative value to signal an error on a
> >> particular query
> >> + * item.
> >> + */
> >> +__s32 length;
> >> +
> >> +__u32 flags;
> >> +/*
> >> + * Data will be written at the location pointed by data_ptr
> >> when the
> >> + * value of length matches the length of the data to be
> >> written by the
> >> + * kernel.
> >> + */
> >> +__u64 data_ptr;
> >> +};
> >> +
> >> +struct drm_i915_query {
> >> +__u32 num_items;
> >> +/*
> >> + * Unused for now. Must be cleared to zero.
> >> + */
> >> +__u32 flags;
> >> +/*
> >> + * This points to an array of num_items drm_i915_query_item
> >> structures.
> >> + */
> >> +__u64 items_ptr;
> >> +};
> >> +
> >> +#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE +
> >> DRM_I915_QUERY, struct drm_i915_query)
> >> +
> >> +/**
> >> + * enum drm_i915_gem_memory_class
> >> + */
> >> +enum drm_i915_gem_memory_class {
> >> + /** @I915_MEMORY_CLASS_SYSTEM: system memory */
> >> + I915_MEMORY_CLASS_SYSTEM = 0,
> >> + /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
> >> + I915_MEMORY_CLASS_DEVICE,
> >> +};
> >> +
> >> +/**
> >> + * struct drm_i915_gem_memory_class_instance
> >> + */
> >> +struct drm_i915_gem_memory_class_instance {
> >> + /** @memory_class: see enum drm_i915_gem_memory_class */
> >> + __u16 memory_class;
> >> +
> >> + /** @memory_instance: which instance */
> >> + __u16 memory_instance;
> >> +};
> >> +
> >> +/**
> >> + * struct drm_i915_memory_region_info
> >> + *
> >> + * Describes one region as known to the driver.
> >> + *
> >> + * Note
Re: [RFC PATCH] drm/i915: Simplify userptr locking
On Mon, Apr 12, 2021 at 7:51 PM Thomas Hellström
wrote:
>
> Use an rwlock instead of spinlock for the global notifier lock
> to reduce risk of contention in execbuf.
>
> Protect object state with the object lock whenever possible rather
> than with the global notifier lock
>
> Don't take an explicit page_ref in userptr_submit_init() but rather
> call get_pages() after obtaining the page list so that
> get_pages() holds the page_ref. This means we don't need to call
> userptr_submit_fini(), which is needed to avoid awkward locking
> in our upcoming VM_BIND code.
>
> CC'ing a broader audience since userptr handling is something we
> probably want to unify across drivers at some point.
>
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc: Intel Graphics Development
> Signed-off-by: Thomas Hellström
So I was panicking when I've seen this first because of the RFC and
feared it's the big discussion about which userptr semantics exactly
we should aim for. Which is something we really should nail. But
looking now again it's really that you remove some optional paths, and
the core bit with mmu_interval_read_retry is still there. It's just
mmu_interval_check_retry that goes out.
So no panic from me on this. But ideally I think needs Maarten to
review the details.
Wrt the panic topic, I think there's 3 legit ways to do userptr:
- using pin_user_page with PIN_LONGTERM
- using hmm/mmu_notifier_range, gpu page faults and tlb invalidate,
with no dma_fence and no page refcounts at all
- with mmu_notifier_range and dma_fence, and I think there the big
question is whether we should get some page references. I think it
would be great if we get as close as possible to the case with real
page faults/tlb invalidate, so no page references, since holding
random references.
I think ideally we'd at least document this, ideally with helpers used
by drivers, also I'd like a few more ponies :-)
Cheers, Daniel
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +++---
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 2 -
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 72 ++-
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 4 files changed, 31 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 5964e67c7d36..d3604ddfa93b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -994,7 +994,7 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned
> long handle)
> }
> }
>
> -static void eb_release_vmas(struct i915_execbuffer *eb, bool final, bool
> release_userptr)
> +static void eb_release_vmas(struct i915_execbuffer *eb, bool final)
> {
> const unsigned int count = eb->buffer_count;
> unsigned int i;
> @@ -1008,11 +1008,6 @@ static void eb_release_vmas(struct i915_execbuffer
> *eb, bool final, bool release
>
> eb_unreserve_vma(ev);
>
> - if (release_userptr && ev->flags &
> __EXEC_OBJECT_USERPTR_INIT) {
> - ev->flags &= ~__EXEC_OBJECT_USERPTR_INIT;
> - i915_gem_object_userptr_submit_fini(vma->obj);
> - }
> -
> if (final)
> i915_vma_put(vma);
> }
> @@ -1990,7 +1985,7 @@ static noinline int eb_relocate_parse_slow(struct
> i915_execbuffer *eb,
> }
>
> /* We may process another execbuffer during the unlock... */
> - eb_release_vmas(eb, false, true);
> + eb_release_vmas(eb, false);
> i915_gem_ww_ctx_fini(>ww);
>
> if (rq) {
> @@ -2094,7 +2089,7 @@ static noinline int eb_relocate_parse_slow(struct
> i915_execbuffer *eb,
>
> err:
> if (err == -EDEADLK) {
> - eb_release_vmas(eb, false, false);
> + eb_release_vmas(eb, false);
> err = i915_gem_ww_ctx_backoff(>ww);
> if (!err)
> goto repeat_validate;
> @@ -2191,7 +2186,7 @@ static int eb_relocate_parse(struct i915_execbuffer *eb)
>
> err:
> if (err == -EDEADLK) {
> - eb_release_vmas(eb, false, false);
> + eb_release_vmas(eb, false);
> err = i915_gem_ww_ctx_backoff(>ww);
> if (!err)
> goto retry;
> @@ -2268,7 +2263,7 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
>
> #ifdef CONFIG_MMU_NOTIFIER
> if (!err && (eb->args->flags & __EXEC_USERPTR_USED)) {
> - spin_lock(>i915->mm.notifier_lock);
> + read_lock(>i915->mm.notifier_lock);
>
> /*
> * count is always at least 1, otherwise __EXEC_USERPTR_USED
> @@ -2286,7 +2281,7 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
> break;
> }
>
> -
Re: [PATCH] drm/ttm: fix error handling if no BO can be swapped out
Am 20.04.21 um 16:32 schrieb Shiwu Zhang:
In case that all pre-allocated BOs are busy, just continue to populate
BOs since likely half of system memory in total is still free.
Signed-off-by: Shiwu Zhang
---
drivers/gpu/drm/ttm/ttm_device.c | 4 ++--
drivers/gpu/drm/ttm/ttm_tt.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 1f2024164d72..0200709db9be 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -133,7 +133,7 @@ int ttm_device_swapout(struct ttm_device *bdev, struct
ttm_operation_ctx *ctx,
struct ttm_resource_manager *man;
struct ttm_buffer_object *bo;
unsigned i, j;
- int ret;
+ int ret=-EBUSY;
spin_lock(>lru_lock);
for (i = TTM_PL_SYSTEM; i < TTM_NUM_MEM_TYPES; ++i) {
@@ -161,7 +161,7 @@ int ttm_device_swapout(struct ttm_device *bdev, struct
ttm_operation_ctx *ctx,
}
}
spin_unlock(>lru_lock);
- return 0;
+ return ret;
The function should return the number of pages swapped out. Returning 0
here is already perfectly ok.
}
EXPORT_SYMBOL(ttm_device_swapout);
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 48c407cff112..4e1e06a04428 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -329,6 +329,8 @@ int ttm_tt_populate(struct ttm_device *bdev,
ttm_dma32_pages_limit) {
ret = ttm_global_swapout(ctx, GFP_KERNEL);
+ if (ret == -EBUSY)
+ break;
if (ret < 0)
goto error;
Here we should just have a check for ret == 0 instead of testing for -EBUSY.
Regards,
Christian.
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] ovl: fix reference counting in ovl_mmap error path
mmap_region() now calls fput() on the vma->vm_file.
Fix this by using vma_set_file() so it doesn't need to be
handled manually here any more.
Signed-off-by: Christian König
Fixes: 1527f926fd04 ("mm: mmap: fix fput in error path v2")
CC: sta...@vger.kernel.org # 5.11+
---
fs/overlayfs/file.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
index dbfb35fb0ff7..3847cdc069b5 100644
--- a/fs/overlayfs/file.c
+++ b/fs/overlayfs/file.c
@@ -430,20 +430,11 @@ static int ovl_mmap(struct file *file, struct
vm_area_struct *vma)
if (WARN_ON(file != vma->vm_file))
return -EIO;
- vma->vm_file = get_file(realfile);
+ vma_set_file(vma, realfile);
old_cred = ovl_override_creds(file_inode(file)->i_sb);
ret = call_mmap(vma->vm_file, vma);
revert_creds(old_cred);
-
- if (ret) {
- /* Drop reference count from new vm_file value */
- fput(realfile);
- } else {
- /* Drop reference count from previous vm_file value */
- fput(file);
- }
-
ovl_file_accessed(file);
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] coda: fix reference counting in coda_file_mmap error path
mmap_region() now calls fput() on the vma->vm_file.
So we need to drop the extra reference on the coda file instead of the
host file.
Signed-off-by: Christian König
Fixes: 1527f926fd04 ("mm: mmap: fix fput in error path v2")
CC: sta...@vger.kernel.org # 5.11+
---
fs/coda/file.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/coda/file.c b/fs/coda/file.c
index 128d63df5bfb..ef5ca22bfb3e 100644
--- a/fs/coda/file.c
+++ b/fs/coda/file.c
@@ -175,10 +175,10 @@ coda_file_mmap(struct file *coda_file, struct
vm_area_struct *vma)
ret = call_mmap(vma->vm_file, vma);
if (ret) {
- /* if call_mmap fails, our caller will put coda_file so we
-* should drop the reference to the host_file that we got.
+ /* if call_mmap fails, our caller will put host_file so we
+* should drop the reference to the coda_file that we got.
*/
- fput(host_file);
+ fput(coda_file);
kfree(cvm_ops);
} else {
/* here we add redirects for the open/close vm_operations */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 4/4] drm/panfrost: Add mt8183-mali compatible string
Not that you need it but this patch is Reviewed-by: Alyssa Rosenzweig
On Wed, Apr 21, 2021 at 01:28:55PM +0800, Nicolas Boichat wrote:
> Add support for MT8183's G72 Bifrost.
>
> Signed-off-by: Nicolas Boichat
> Reviewed-by: Tomeu Vizoso
> Reviewed-by: Steven Price
> ---
>
> (no changes since v7)
>
> Changes in v7:
> - Fix GPU ID in commit message
>
> Changes in v6:
> - Context conflicts, reflow the code.
> - Use ARRAY_SIZE for power domains too.
>
> Changes in v5:
> - Change power domain name from 2d to core2.
>
> Changes in v4:
> - Add power domain names.
>
> Changes in v3:
> - Match mt8183-mali instead of bifrost, as we require special
>handling for the 2 regulators and 3 power domains.
>
> drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 83a461bdeea8..ca07098a6141 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
> .vendor_quirk = panfrost_gpu_amlogic_quirk,
> };
>
> +const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
> +const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1",
> "core2" };
> +static const struct panfrost_compatible mediatek_mt8183_data = {
> + .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
> + .supply_names = mediatek_mt8183_supplies,
> + .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
> + .pm_domain_names = mediatek_mt8183_pm_domains,
> +};
> +
> static const struct of_device_id dt_match[] = {
> /* Set first to probe before the generic compatibles */
> { .compatible = "amlogic,meson-gxm-mali",
> @@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
> { .compatible = "arm,mali-t860", .data = _data, },
> { .compatible = "arm,mali-t880", .data = _data, },
> { .compatible = "arm,mali-bifrost", .data = _data, },
> + { .compatible = "mediatek,mt8183-mali", .data = _mt8183_data },
> {}
> };
> MODULE_DEVICE_TABLE(of, dt_match);
> --
> 2.31.1.368.gbe11c130af-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo
On Wed, 21 Apr 2021 10:37:11 + wrote: > On 4/21/21 11:15 AM, Daniel Vetter wrote: > > On Tue, Apr 20, 2021 at 11:37:41AM +, peter.enderb...@sony.com wrote: > >> But I dont think they will. dma-buf does not have to be mapped to a > >> process, > >> and the case of vram, it is not covered in current global_zone. All of them > >> would be very nice to have in some form. But it wont change what the > >> correct value of what "Total" is. > > We need to understand what the "correct" value is. Not in terms of kernel > > code, but in terms of semantics. Like if userspace allocates a GL texture, > > is this supposed to show up in your metric or not. Stuff like that. > That it like that would like to only one pointer type. You need to know what > you pointing at to know what it is. it might be a hardware or a other pointer. To clarify the GL texture example: a GL texture consumes "graphics memory", whatever that is, but they are not allocated as dmabufs. So they count for resource consumption, but they do not show up in your counter, until they become exported. Most GL textures are never exported at all. In fact, exporting GL textures is a path strongly recommended against due to unsuitable EGL/GL API. As far as I understand, dmabufs are never allocated as is. Dmabufs always just wrap an existing memory allocation. So creating (exporting) a dmabuf does not increase resource usage. Allocation increases resource usage, and most allocations are never exported. > If there is a limitation on your pointers it is a good metric to count them > even if you don't know what they are. Same goes for dma-buf, they > are generic, but they consume some resources that are counted in pages. Given above, I could even argue that *dmabufs* do not consume resources. They only reference resources that were already allocated by some specific means (not generic). They might keep the resource allocated, preventing it from being freed if leaked. As you might know, there is no really generic "dmabuf allocator", not as a kernel UAPI nor as a userspace library (the hypothetical Unix Device Memory Allocator library notwithstanding). So this kind of leaves the question, what is DmaBufTotal good for? Is it the same kind of counter as VIRT in 'top'? If you know your particular programs, you can maybe infer if VIRT is too much or not, but for e.g. WebKitWebProcess it is normal to have 85 GB in VIRT and it's not a problem (like I have, on this 8 GB RAM machine). Thanks, pq pgp79fpmLc0v6.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Fix docbook descriptions for i915_gem_shrinker
Fixes the following htmldocs warning:
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
or member 'ww' not described in 'i915_gem_shrink'
Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.")
Reported-by: Stephen Rothwell
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 7545ddd83659..f4fb68e8955a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -72,6 +72,7 @@ static void try_to_writeback(struct drm_i915_gem_object *obj,
/**
* i915_gem_shrink - Shrink buffer object caches
+ * @ww: i915 gem ww acquire ctx, or NULL
* @i915: i915 device
* @target: amount of memory to make available, in pages
* @nr_scanned: optional output for number of pages scanned (incremental)
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Fix docbook descriptions for i915_cmd_parser
Fixes the following htmldocs warnings:
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter
'trampoline' description in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
member 'jump_whitelist' not described in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
member 'shadow_map' not described in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or
member 'batch_map' not described in 'intel_engine_cmd_parser'
drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter
'trampoline' description in 'intel_engine_cmd_parser'
Reported-by: Stephen Rothwell
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index e6f1e93a..afb9b7516999 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1369,6 +1369,18 @@ static int check_bbstart(u32 *cmd, u32 offset, u32
length,
return 0;
}
+/**
+ * intel_engine_cmd_parser_alloc_jump_whitelist() - preallocate jump whitelist
for intel_engine_cmd_parser()
+ * @batch_length: length of the commands in batch_obj
+ * @trampoline: Whether jump trampolines are used.
+ *
+ * Preallocates a jump whitelist for parsing the cmd buffer in
intel_engine_cmd_parser().
+ * This has to be preallocated, because the command parser runs in signaling
context,
+ * and may not allocate any memory.
+ *
+ * Return: NULL or pointer to a jump whitelist, or ERR_PTR() on failure. Use
+ * IS_ERR() to check for errors. Must bre freed() with kfree().
+ */
unsigned long *intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length,
bool trampoline)
{
@@ -1401,7 +1413,9 @@ unsigned long
*intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length,
* @batch_offset: byte offset in the batch at which execution starts
* @batch_length: length of the commands in batch_obj
* @shadow: validated copy of the batch buffer in question
- * @trampoline: whether to emit a conditional trampoline at the end of the
batch
+ * @jump_whitelist: buffer preallocated with
intel_engine_cmd_parser_alloc_jump_whitelist()
+ * @shadow_map: mapping to @shadow vma
+ * @batch_map: mapping to @batch vma
*
* Parses the specified batch buffer looking for privilege violations as
* described in the overview.
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
