[Bug 209457] AMDGPU resume fail with RX 580 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=209457 dark_syl...@yahoo.com.ar changed: What|Removed |Added CC||dark_syl...@yahoo.com.ar --- Comment #10 from dark_syl...@yahoo.com.ar --- I'm having the same problem; I'm using Ubuntu 18.04 LTS and whatever they backported to kernel 5.4.0-51-generic started causing this problem; while the problem goes away in 5.4.0-48-generic (Ubuntu flavors) I have more information: - Card is Radeon RX 560 Series (POLARIS11, DRM 3.35.0, 5.4.0-48-generic, LLVM 10.0.1) - The bug sometimes also triggers when plugging or unplugging an HDMI TV. (this may be https://bugzilla.kernel.org/show_bug.cgi?id=204241 ?) - The keyboard locks up, but I can still login via SSH - 'sudo shutdown now' will never finish. The kernel is stuck - In my case dmesg nor xorg.log notice at all something went wrong - Trying to kill X reveals the following: [ 1571.941734] Call Trace: [ 1571.941747] __schedule+0x293/0x720 [ 1571.941752] ? __queue_work+0x14c/0x400 [ 1571.941758] schedule+0x33/0xa0 [ 1571.941765] rpm_resume+0x108/0x780 [ 1571.941769] ? __switch_to_asm+0x40/0x70 [ 1571.941776] ? wait_woken+0x80/0x80 [ 1571.941782] __pm_runtime_resume+0x4e/0x80 [ 1571.941939] amdgpu_drm_ioctl+0x39/0x80 [amdgpu] [ 1571.941944] do_vfs_ioctl+0xa9/0x640 [ 1571.941950] ? __schedule+0x29b/0x720 [ 1571.941954] ksys_ioctl+0x75/0x80 [ 1571.941957] __x64_sys_ioctl+0x1a/0x20 [ 1571.941964] do_syscall_64+0x57/0x190 [ 1571.941968] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1571.941973] RIP: 0033:0x7f746d5a96d7 [ 1571.941982] Code: Bad RIP value. [ 1571.941985] RSP: 002b:7fff1ec6a7a8 EFLAGS: 3246 ORIG_RAX: 0010 [ 1571.941990] RAX: ffda RBX: 7fff1ec6a7e0 RCX: 7f746d5a96d7 [ 1571.941992] RDX: 7fff1ec6a7e0 RSI: c06864a2 RDI: 000d [ 1571.941994] RBP: 7fff1ec6a7e0 R08: R09: [ 1571.941996] R10: R11: 3246 R12: c06864a2 [ 1571.941998] R13: 000d R14: 55f52f391780 R15: 55f52f2176a0 [ 1571.942021] INFO: task chrome:shlo0:2563 blocked for more than 120 seconds. [ 1571.942026] Tainted: G OE 5.4.0-51-generic #56~18.04.1-Ubuntu [ 1571.942029] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1692.774402] python3:disk$2 D0 6187 1 0x80004002 [ 1692.774404] Call Trace: [ 1692.774410] __schedule+0x293/0x720 [ 1692.774414] ? __switch_to_asm+0x40/0x70 [ 1692.774419] schedule+0x33/0xa0 [ 1692.774424] schedule_preempt_disabled+0xe/0x10 [ 1692.774429] __mutex_lock.isra.9+0x26d/0x4e0 [ 1692.774436] __mutex_lock_slowpath+0x13/0x20 [ 1692.774441] ? __mutex_lock_slowpath+0x13/0x20 [ 1692.774446] mutex_lock+0x2f/0x40 [ 1692.774472] drm_release+0x2e/0xd0 [drm] [ 1692.774476] __fput+0xc6/0x260 [ 1692.774481] fput+0xe/0x10 [ 1692.774485] task_work_run+0x9d/0xc0 [ 1692.774491] do_exit+0x382/0xb80 [ 1692.774496] ? mem_cgroup_try_charge+0x75/0x190 [ 1692.774503] do_group_exit+0x43/0xa0 [ 1692.774506] get_signal+0x14f/0x860 [ 1692.774512] do_signal+0x34/0x6d0 [ 1692.774515] ? strlcpy+0x32/0x50 [ 1692.774519] ? __x64_sys_futex+0x13f/0x190 [ 1692.774525] exit_to_usermode_loop+0x90/0x130 [ 1692.774530] do_syscall_64+0x170/0x190 [ 1692.774534] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1692.774536] RIP: 0033:0x7f7f31d789f3 [ 1692.774541] Code: Bad RIP value. [ 1692.774543] RSP: 002b:7f7ef49abd10 EFLAGS: 0246 ORIG_RAX: 00ca [ 1692.774546] RAX: fe00 RBX: 02041e80 RCX: 7f7f31d789f3 [ 1692.774548] RDX: RSI: 0080 RDI: 02041ea8 [ 1692.774549] RBP: 02041ea4 R08: R09: [ 1692.774551] R10: R11: 0246 R12: 02041ea8 [ 1692.774553] R13: R14: 02041e58 R15: 0002 [ 1692.774558] INFO: task kworker/4:1:6532 blocked for more than 241 seconds. [ 1692.774561] Tainted: G OE 5.4.0-51-generic #56~18.04.1-Ubuntu [ 1692.774563] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1692.774566] kworker/4:1 D0 6532 2 0x80004000 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add gpu cooling support
Hi,
On Thu, Oct 15, 2020 at 12:07:01AM +0530, man...@codeaurora.org wrote:
> On 2020-10-14 18:59, Akhil P Oommen wrote:
> > On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote:
> > > On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote:
> > > > Hi,
> > > >
> > > > On Thu, Oct 8, 2020 at 10:10 AM Akhil P Oommen
> > > > wrote:
> > > > >
> > > > > Add cooling-cells property and the cooling maps for the gpu tzones
> > > > > to support GPU cooling.
> > > > >
> > > > > Signed-off-by: Akhil P Oommen
> > > > > ---
> > > > > arch/arm64/boot/dts/qcom/sc7180.dtsi | 29
> > > > > ++---
> > > > > 1 file changed, 22 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > > > > b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > > > > index d46b383..40d6a28 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > > > > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> > > > > @@ -2,7 +2,7 @@
> > > > > /*
> > > > >* SC7180 SoC device tree source
> > > > >*
> > > > > - * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> > > > > + * Copyright (c) 2019-20, The Linux Foundation. All rights
> > > > > reserved.
> > > > >*/
> > > > >
> > > > > #include
> > > > > @@ -1885,6 +1885,7 @@
> > > > > iommus = <_smmu 0>;
> > > > > operating-points-v2 = <_opp_table>;
> > > > > qcom,gmu = <>;
> > > > > + #cooling-cells = <2>;
> > > >
> > > > Presumably we should add this to the devicetree bindings, too?
> > Yes, thanks for catching this. Will update in the next patch.
> >
> > > >
> > > >
> > > > > interconnects = <_noc
> > > > > MASTER_GFX3D _virt SLAVE_EBI1>;
> > > > > interconnect-names = "gfx-mem";
> > > > > @@ -3825,16 +3826,16 @@
> > > > > };
> > > > >
> > > > > gpuss0-thermal {
> > > > > - polling-delay-passive = <0>;
> > > > > + polling-delay-passive = <100>;
> > > >
> > > > Why did you make this change? I'm pretty sure that we _don't_ want
> > > > this since we're using interrupts for the thermal sensor. See commit
> > > > 22337b91022d ("arm64: dts: qcom: sc7180: Changed polling mode in
> > > > Thermal-zones node").
> > >
> > > I was going to ask the same, this shouldn't be needed.
> As per our understanding unlike "polling-delay", this delay property is
> intended to activate polling thread on post trip threshold violation and it
> is irrespective of sensor is capable for trip interrupt or not.
> This polling is more of governor related. Below are the few references from
> Documentation/code which tells polling-delay-passive is needed for IPA for
> better IPA performance.
>
> As per Power allocator documentations
>
> 1.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/driver-api/thermal/power_allocator.rst?h=v5.4.71#n264
>
> "The power allocator governor's PID controller works best if there is a
> periodic tick. If you have a driver that calls
> `thermal_zone_device_update()` (or anything that ends up calling the
> governor's `throttle()` function) repetitively, the governor response
> won't be very good. Note that this is not particular to this
> governor, step-wise will also misbehave if you call its throttle()
> faster than the normal thermal framework tick (due to interrupts for
> example) as it will overreact"
>
> 2. In Power allocator code, when switch_on/control trip temp violation, it
> is enabling passive counter to activate passive polling @
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/thermal/power_allocator.c?h=v5.4.71#n634
>
> 3. while calculating derivative term, it is using passive_delay @
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/thermal/power_allocator.c?h=v5.4.71#n243
>
> 4. Sensor interrupt will work if temperature is fluctuating between
> trip_temp and hysteresis. But say a case where we are not enabling
> polling-delay-passive. In this case if current temperature > control_temp
> trip(2nd passive trip) and
> temperature trend is still raising, then sensor high trip will be disabled
> (OR configured for critical trip threshold). No more trip interrupt from
> sensor until it reaches critical trip or falls below control_temp
> hysteresis.
> How the governor re-evaluate its next mitigation without passive polling
> thread here ?
>
> I think the same is required for CPU thermal zone as well.
Thanks for the explication and pointers!
I ran some tests to re-confirm. For that I lowered the trip point temperatures
of CPU6 to 60/70, to make it easier to trigger throttling without necessarily
affecting the other CPUs. Further I enabled tracing for the events
'thermal_temperature',
'thermal_zone_trip' and 'thermal_power_allocator'. With that I ran a
[PATCH v5 5/5] dma-buf: Clarify that dma-buf sg lists are page aligned
The dma-buf API have been used under the assumption that the sg lists
returned from dma_buf_map_attachment() are fully page aligned. Lots of
stuff can break otherwise all over the place. Clarify this in the
documentation and add a check when DMA API debug is enabled.
Signed-off-by: Jianxin Xiong
Reviewed-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/dma-buf/dma-buf.c | 21 +
include/linux/dma-buf.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 844967f..7309c83 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -851,6 +851,9 @@ void dma_buf_unpin(struct dma_buf_attachment *attach)
* Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
* on error. May return -EINTR if it is interrupted by a signal.
*
+ * On success, the DMA addresses and lengths in the returned scatterlist are
+ * PAGE_SIZE aligned.
+ *
* A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
* the underlying backing storage is pinned for as long as a mapping exists,
* therefore users/importers should not hold onto a mapping for undue amounts
of
@@ -904,6 +907,24 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
attach->dir = direction;
}
+#ifdef CONFIG_DMA_API_DEBUG
+ {
+ struct scatterlist *sg;
+ u64 addr;
+ int len;
+ int i;
+
+ for_each_sgtable_dma_sg(sg_table, sg, i) {
+ addr = sg_dma_address(sg);
+ len = sg_dma_len(sg);
+ if (!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(len)) {
+ pr_debug("%s: addr %llx or len %x is not page
aligned!\n",
+__func__, addr, len);
+ }
+ }
+ }
+#endif /* CONFIG_DMA_API_DEBUG */
+
return sg_table;
}
EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a2ca294e..4a5fa70 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -145,7 +145,8 @@ struct dma_buf_ops {
*
* A _table scatter list of or the backing storage of the DMA buffer,
* already mapped into the device address space of the attached
-* with the provided _buf_attachment.
+* with the provided _buf_attachment. The addresses and lengths in
+* the scatter list are PAGE_SIZE aligned.
*
* On failure, returns a negative error value wrapped into a pointer.
* May also return -EINTR when a signal was received while being
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/5] RDMA/uverbs: Add uverbs command for dma-buf based MR registration
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 112 ++
include/uapi/rdma/ib_user_ioctl_cmds.h| 14
2 files changed, 126 insertions(+)
diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c
b/drivers/infiniband/core/uverbs_std_types_mr.c
index 9b22bb5..e54459f 100644
--- a/drivers/infiniband/core/uverbs_std_types_mr.c
+++ b/drivers/infiniband/core/uverbs_std_types_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -178,6 +179,85 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
return IS_UVERBS_COPY_ERR(ret) ? ret : 0;
}
+static int UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR)(
+ struct uverbs_attr_bundle *attrs)
+{
+ struct ib_uobject *uobj =
+ uverbs_attr_get_uobject(attrs,
UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ struct ib_pd *pd =
+ uverbs_attr_get_obj(attrs, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE);
+ struct ib_device *ib_dev = pd->device;
+
+ u64 start, length, virt_addr;
+ u32 fd, access_flags;
+ struct ib_mr *mr;
+ int ret;
+
+ if (!ib_dev->ops.reg_user_mr_dmabuf)
+ return -EOPNOTSUPP;
+
+ ret = uverbs_copy_from(, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_ADDR);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(_addr, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_HCA_VA);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_FD);
+ if (ret)
+ return ret;
+
+ ret = uverbs_get_flags32(_flags, attrs,
+UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+IB_ACCESS_SUPPORTED);
+ if (ret)
+ return ret;
+
+ ret = ib_check_mr_access(access_flags);
+ if (ret)
+ return ret;
+
+ mr = pd->device->ops.reg_user_mr_dmabuf(pd, start, length, virt_addr,
+ fd, access_flags,
+ >driver_udata);
+ if (IS_ERR(mr))
+ return PTR_ERR(mr);
+
+ mr->device = pd->device;
+ mr->pd = pd;
+ mr->type= IB_MR_TYPE_USER;
+ mr->uobject = uobj;
+ atomic_inc(>usecnt);
+
+ uobj->object = mr;
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+>lkey, sizeof(mr->lkey));
+ if (ret)
+ goto err_dereg;
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+>rkey, sizeof(mr->rkey));
+ if (ret)
+ goto err_dereg;
+
+ return 0;
+
+err_dereg:
+ ib_dereg_mr_user(mr, uverbs_get_cleared_udata(attrs));
+
+ return ret;
+}
+
DECLARE_UVERBS_NAMED_METHOD(
UVERBS_METHOD_ADVISE_MR,
UVERBS_ATTR_IDR(UVERBS_ATTR_ADVISE_MR_PD_HANDLE,
@@ -243,6 +323,37 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
UVERBS_ATTR_TYPE(u32),
UA_MANDATORY));
+DECLARE_UVERBS_NAMED_METHOD(
+ UVERBS_METHOD_REG_DMABUF_MR,
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_OBJECT_MR,
+ UVERBS_ACCESS_NEW,
+ UA_MANDATORY),
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_OBJECT_PD,
+ UVERBS_ACCESS_READ,
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_ADDR,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_HCA_VA,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_FD,
+ UVERBS_ATTR_TYPE(u32),
+ UA_MANDATORY),
+ UVERBS_ATTR_FLAGS_IN(UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+enum ib_access_flags),
+
[PATCH v5 0/5] RDMA: Add dma-buf support
This is the fifth version of the patch set. Changelog: v5: * Fix a few warnings reported by kernel test robot: - no previous prototype for function 'ib_umem_dmabuf_release' - no previous prototype for function 'ib_umem_dmabuf_map_pages' - comparison of distinct pointer types in 'check_add_overflow' * Add comment for the wait between getting the dma-buf sg tagle and updating the NIC page table v4: https://www.spinics.net/lists/linux-rdma/msg96767.html * Add a new ib_device method reg_user_mr_dmabuf() instead of expanding the existing method reg_user_mr() * Use a separate code flow for dma-buf instead of adding special cases to the ODP memory region code path * In invalidation callback, new mapping is updated as whole using work queue instead of being updated in page granularity in the page fault handler * Use dma_resv_get_excl() and dma_fence_wait() to ensure the content of the pages have been moved to the new location before the new mapping is programmed into the NIC * Add code to the ODP page fault handler to check the mapping status * The new access flag added in v3 is removed. * The checking for on-demand paging support in the new uverbs command is removed because it is implied by implementing the new ib_device method * Clarify that dma-buf sg lists are page aligned v3: https://www.spinics.net/lists/linux-rdma/msg96330.html * Use dma_buf_dynamic_attach() instead of dma_buf_attach() * Use on-demand paging mechanism to avoid pinning the GPU memory * Instead of adding a new parameter to the device method for memory registration, pass all the attributes including the file descriptor as a structure * Define a new access flag for dma-buf based memory region * Check for on-demand paging support in the new uverbs command v2: https://www.spinics.net/lists/linux-rdma/msg93643.html * The Kconfig option is removed. There is no dependence issue since dma-buf driver is always enabled. * The declaration of new data structure and functions is reorganized to minimize the visibility of the changes. * The new uverbs command now goes through ioctl() instead of write(). * The rereg functionality is removed. * Instead of adding new device method for dma-buf specific registration, existing method is extended to accept an extra parameter. * The correct function is now used for address range checking. v1: https://www.spinics.net/lists/linux-rdma/msg90720.html * The initial patch set * Implement core functions for importing and mapping dma-buf * Use dma-buf static attach interface * Add two ib_device methods reg_user_mr_fd() and rereg_user_mr_fd() * Add two uverbs commands via the write() interface * Add Kconfig option * Add dma-buf support to mlx5 device When enabled, an RDMA capable NIC can perform peer-to-peer transactions over PCIe to access the local memory located on another device. This can often lead to better performance than using a system memory buffer for RDMA and copying data between the buffer and device memory. Current kernel RDMA stack uses get_user_pages() to pin the physical pages backing the user buffer and uses dma_map_sg_attrs() to get the dma addresses for memory access. This usually doesn't work for peer device memory due to the lack of associated page structures. Several mechanisms exist today to facilitate device memory access. ZONE_DEVICE is a new zone for device memory in the memory management subsystem. It allows pages from device memory being described with specialized page structures, but what can be done with these page structures may be different from system memory. ZONE_DEVICE is further specialized into multiple memory types, such as one type for PCI p2pmem/p2pdma and one type for HMM. PCI p2pmem/p2pdma uses ZONE_DEVICE to represent device memory residing in a PCI BAR and provides a set of calls to publish, discover, allocate, and map such memory for peer-to-peer transactions. One feature of the API is that the buffer is allocated by the side that does the DMA transfer. This works well with the storage usage case, but is awkward with GPU-NIC communication, where typically the buffer is allocated by the GPU driver rather than the NIC driver. Heterogeneous Memory Management (HMM) utilizes mmu_interval_notifier and ZONE_DEVICE to support shared virtual address space and page migration between system memory and device memory. HMM doesn't support pinning device memory because pages located on device must be able to migrate to system memory when accessed by CPU. Peer-to-peer access is currently not supported by HMM. Dma-buf is a standard mechanism for sharing buffers among different device drivers. The buffer to be shared is exported by the owning driver and imported by the driver that wants to use it. The exporter provides a set of ops that the importer can call to pin and map the buffer. In addition, a file descriptor can be associated with a dma- buf object as the handle that can be passed to user space. This patch series adds dma-buf
[PATCH v5 2/5] RDMA/core: Add device method for registering dma-buf base memory region
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/device.c | 1 +
include/rdma/ib_verbs.h | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index feaec8d..d6cd0ac 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -2653,6 +2653,7 @@ void ib_set_device_ops(struct ib_device *dev, const
struct ib_device_ops *ops)
SET_DEVICE_OP(dev_ops, read_counters);
SET_DEVICE_OP(dev_ops, reg_dm_mr);
SET_DEVICE_OP(dev_ops, reg_user_mr);
+ SET_DEVICE_OP(dev_ops, reg_user_mr_dmabuf);
SET_DEVICE_OP(dev_ops, req_ncomp_notif);
SET_DEVICE_OP(dev_ops, req_notify_cq);
SET_DEVICE_OP(dev_ops, rereg_user_mr);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 9bf6c31..48bab74 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2004 Mellanox Technologies Ltd. All rights reserved.
* Copyright (c) 2004 Infinicon Corporation. All rights reserved.
- * Copyright (c) 2004 Intel Corporation. All rights reserved.
+ * Copyright (c) 2004, 2020 Intel Corporation. All rights reserved.
* Copyright (c) 2004 Topspin Corporation. All rights reserved.
* Copyright (c) 2004 Voltaire Corporation. All rights reserved.
* Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
@@ -2429,6 +2429,10 @@ struct ib_device_ops {
struct ib_mr *(*reg_user_mr)(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_udata *udata);
+ struct ib_mr *(*reg_user_mr_dmabuf)(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr, int dmabuf_fd,
+int mr_access_flags,
+struct ib_udata *udata);
int (*rereg_user_mr)(struct ib_mr *mr, int flags, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_pd *pd, struct ib_udata *udata);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/5] RDMA/umem: Support importing dma-buf as user memory region
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the buffer is registered as a memory region,
the file descriptor is passed to the RDMA driver along with other
parameters.
Implement the common code for importing dma-buf object and mapping
dma-buf pages.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/Makefile | 2 +-
drivers/infiniband/core/umem.c| 4 +
drivers/infiniband/core/umem_dmabuf.c | 206 ++
drivers/infiniband/core/umem_dmabuf.h | 11 ++
include/rdma/ib_umem.h| 32 +-
5 files changed, 253 insertions(+), 2 deletions(-)
create mode 100644 drivers/infiniband/core/umem_dmabuf.c
create mode 100644 drivers/infiniband/core/umem_dmabuf.h
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index ccf2670..8ab4eea 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -40,5 +40,5 @@ ib_uverbs-y :=uverbs_main.o
uverbs_cmd.o uverbs_marshall.o \
uverbs_std_types_srq.o \
uverbs_std_types_wq.o \
uverbs_std_types_qp.o
-ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
+ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index e9fecbd..8c608a5 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -2,6 +2,7 @@
* Copyright (c) 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005 Cisco Systems. All rights reserved.
* Copyright (c) 2005 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -43,6 +44,7 @@
#include
#include "uverbs.h"
+#include "umem_dmabuf.h"
static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int
dirty)
{
@@ -269,6 +271,8 @@ void ib_umem_release(struct ib_umem *umem)
{
if (!umem)
return;
+ if (umem->is_dmabuf)
+ return ib_umem_dmabuf_release(umem);
if (umem->is_odp)
return ib_umem_odp_release(to_ib_umem_odp(umem));
diff --git a/drivers/infiniband/core/umem_dmabuf.c
b/drivers/infiniband/core/umem_dmabuf.c
new file mode 100644
index 000..4d6d6f3
--- /dev/null
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+
+#include "uverbs.h"
+#include "umem_dmabuf.h"
+
+struct ib_umem_dmabuf {
+ struct ib_umem umem;
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+ const struct ib_umem_dmabuf_ops *ops;
+ void *device_context;
+ struct work_struct work;
+};
+
+static inline struct ib_umem_dmabuf *to_ib_umem_dmabuf(struct ib_umem *umem)
+{
+ return container_of(umem, struct ib_umem_dmabuf, umem);
+}
+
+static int ib_umem_dmabuf_map_pages(struct ib_umem *umem, bool first)
+{
+ struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(umem);
+ struct sg_table *sgt;
+ struct dma_fence *fence;
+ int err;
+
+ dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
+
+ sgt = dma_buf_map_attachment(umem_dmabuf->attach,
+DMA_BIDIRECTIONAL);
+
+ if (IS_ERR(sgt)) {
+ dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
+ return PTR_ERR(sgt);
+ }
+
+ umem_dmabuf->umem.sg_head = *sgt;
+ umem_dmabuf->umem.nmap = sgt->nents;
+ umem_dmabuf->sgt = sgt;
+
+ /*
+* Although the sg list is valid now, the content of the pages
+* may be not up-to-date. Wait for the exporter to finish
+* the migration.
+*/
+ fence = dma_resv_get_excl(umem_dmabuf->attach->dmabuf->resv);
+ if (fence)
+ dma_fence_wait(fence, false);
+
+ if (first)
+ err = umem_dmabuf->ops->init(umem,
+umem_dmabuf->device_context);
+ else
+ err = umem_dmabuf->ops->update(umem,
+ umem_dmabuf->device_context);
+
+ dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
+ return err;
+}
+
+int
[PATCH v5 4/5] RDMA/mlx5: Support dma-buf based userspace memory region
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/hw/mlx5/main.c| 2 +
drivers/infiniband/hw/mlx5/mlx5_ib.h | 5 ++
drivers/infiniband/hw/mlx5/mr.c | 119 +++
drivers/infiniband/hw/mlx5/odp.c | 42 +
4 files changed, 168 insertions(+)
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 89e04ca..ec4ad2f 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#include
@@ -4060,6 +4061,7 @@ static int mlx5_ib_enable_driver(struct ib_device *dev)
.query_srq = mlx5_ib_query_srq,
.query_ucontext = mlx5_ib_query_ucontext,
.reg_user_mr = mlx5_ib_reg_user_mr,
+ .reg_user_mr_dmabuf = mlx5_ib_reg_user_mr_dmabuf,
.req_notify_cq = mlx5_ib_arm_cq,
.rereg_user_mr = mlx5_ib_rereg_user_mr,
.resize_cq = mlx5_ib_resize_cq,
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index b1f2b34..65fcc18 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#ifndef MLX5_IB_H
@@ -1174,6 +1175,10 @@ int mlx5_ib_create_cq(struct ib_cq *ibcq, const struct
ib_cq_init_attr *attr,
struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int access_flags,
struct ib_udata *udata);
+struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr,
+int dmabuf_fd, int access_flags,
+struct ib_udata *udata);
int mlx5_ib_advise_mr(struct ib_pd *pd,
enum ib_uverbs_advise_mr_advice advice,
u32 flags,
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index b261797..24750f1 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2013-2015, Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -1462,6 +1463,124 @@ struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64
start, u64 length,
return ERR_PTR(err);
}
+static int mlx5_ib_umem_dmabuf_xlt_init(struct ib_umem *umem, void *context)
+{
+ struct mlx5_ib_mr *mr = context;
+ int flags = MLX5_IB_UPD_XLT_ENABLE;
+
+ if (!mr)
+ return -EINVAL;
+
+ return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
+}
+
+static int mlx5_ib_umem_dmabuf_xlt_update(struct ib_umem *umem, void *context)
+{
+ struct mlx5_ib_mr *mr = context;
+ int flags = MLX5_IB_UPD_XLT_ATOMIC;
+
+ if (!mr)
+ return -EINVAL;
+
+ return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
+}
+
+static int mlx5_ib_umem_dmabuf_xlt_invalidate(struct ib_umem *umem, void
*context)
+{
+ struct mlx5_ib_mr *mr = context;
+ int flags = MLX5_IB_UPD_XLT_ZAP | MLX5_IB_UPD_XLT_ATOMIC;
+
+ if (!mr)
+ return -EINVAL;
+
+ return mlx5_ib_update_xlt(mr, 0, mr->npages, PAGE_SHIFT, flags);
+}
+
+static struct ib_umem_dmabuf_ops mlx5_ib_umem_dmabuf_ops = {
+ .init = mlx5_ib_umem_dmabuf_xlt_init,
+ .update = mlx5_ib_umem_dmabuf_xlt_update,
+ .invalidate = mlx5_ib_umem_dmabuf_xlt_invalidate,
+};
+
+struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr,
+int dmabuf_fd, int access_flags,
+struct ib_udata *udata)
+{
+ struct mlx5_ib_dev *dev = to_mdev(pd->device);
+ struct mlx5_ib_mr *mr = NULL;
+ struct ib_umem *umem;
+ int page_shift;
+ int npages;
+ int ncont;
+ int order;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_INFINIBAND_USER_MEM))
+ return ERR_PTR(-EOPNOTSUPP);
+
+ mlx5_ib_dbg(dev,
+
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On Mon, Oct 12, 2020 at 09:59:22AM -0300, Melissa Wen wrote: > On 10/10, Daniel Vetter wrote: > > The only thing we support is xrgb. > > > > Signed-off-by: Daniel Vetter > > Cc: Rodrigo Siqueira > > Cc: Melissa Wen > > Cc: Haneen Mohammed > > Cc: Daniel Vetter > > --- > > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > > b/drivers/gpu/drm/vkms/vkms_drv.c > > index 726801ab44d4..eb4007443706 100644 > > --- a/drivers/gpu/drm/vkms/vkms_drv.c > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device > > *vkmsdev) > > dev->mode_config.max_height = YRES_MAX; > > dev->mode_config.cursor_width = 512; > > dev->mode_config.cursor_height = 512; > > - dev->mode_config.preferred_depth = 24; > > + dev->mode_config.preferred_depth = 32; > nice catch! > > > dev->mode_config.helper_private = _mode_config_helpers; > > > > return vkms_output_init(vkmsdev, 0); > > -- > > 2.28.0 > > > Thanks, > > Reviewed-by: Melissa Wen I merged the first 2 patches of this series, but noticed that you didn't reply with a r-b tag on the 3rd patch. Is that intentional or just oversight? Thanks, 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: linux-next: build failure after merge of the hmm tree
Hi all,
On Mon, 12 Oct 2020 15:19:48 +1100 Stephen Rothwell
wrote:
>
> On Tue, 6 Oct 2020 13:41:20 -0300 Jason Gunthorpe wrote:
> >
> > On Tue, Oct 06, 2020 at 08:35:08PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the hmm tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> > >
> > >
> > > Caused by commit
> > >
> > > 07da1223ec93 ("lib/scatterlist: Add support in dynamic allocation of SG
> > > table from pages")
> > >
> > > interacting with commit
> > >
> > > 707d561f77b5 ("drm: allow limiting the scatter list size.")
> > >
> > > from the drm tree.
> > >
> > > I have added the following merge fix patch
> > >
> > > From: Stephen Rothwell
> > > Date: Tue, 6 Oct 2020 20:22:51 +1100
> > > Subject: [PATCH] lib/scatterlist: merge fix for "drm: allow limiting the
> > > scatter list size."
> > >
> > > Signed-off-by: Stephen Rothwell
> > > drivers/gpu/drm/drm_prime.c | 9 ++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > index 11fe9ff76fd5..83ac901b65a2 100644
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -807,6 +807,7 @@ struct sg_table *drm_prime_pages_to_sg(struct
> > > drm_device *dev,
> > > struct page **pages, unsigned int
> > > nr_pages)
> > > {
> > > struct sg_table *sg = NULL;
> > > + struct scatterlist *sl;
> > > size_t max_segment = 0;
> > > int ret;
> > >
> > > @@ -820,11 +821,13 @@ struct sg_table *drm_prime_pages_to_sg(struct
> > > drm_device *dev,
> > > max_segment = dma_max_mapping_size(dev->dev);
> > > if (max_segment == 0 || max_segment > SCATTERLIST_MAX_SEGMENT)
> > > max_segment = SCATTERLIST_MAX_SEGMENT;
> > > - ret = __sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
> > > + sl = __sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
> > > nr_pages << PAGE_SHIFT,
> > > - max_segment, GFP_KERNEL);
> > > - if (ret)
> > > + max_segment, NULL, 0, GFP_KERNEL);
> > > + if (IS_ERR(sl)) {
> > > + ret = PTR_ERR(sl);
> > > goto out;
> > > + }
> > >
> > > return sg;
> > > out:
> >
> > This looks OK to me, thanks
>
> This merge fix patch is now being applied to the merge of the drm tree
> since the rdma tree (that is merged before the drm tree) has merged the
> hmm tree.
This merge fix patch is now being applied to the merge of the rdma tree
since the Linus has merged the drm tree.
--
Cheers,
Stephen Rothwell
pgpeLr3WNiQzy.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix incorrect dsc force enable logic
On 2020-10-15 3:40 p.m., Eryk Brol wrote:
[Why]
Missed removing a '!' which results in incorrect behavior
[How]
Remove the offending '!'
Signed-off-by: Eryk Brol
Reviewed-by: Harry Wentland
Harry
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 98b4d5e2e336..fc87b9faec92 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
@@ -644,7 +644,7 @@ static void try_disable_dsc(struct drm_atomic_state *state,
for (i = 0; i < count; i++) {
if (vars[i].dsc_enabled
&& vars[i].bpp_x16 ==
params[i].bw_range.max_target_bpp_x16
- && !params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
+ && params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
kbps_increase[i] = params[i].bw_range.stream_kbps -
params[i].bw_range.max_kbps;
tried[i] = false;
remaining_to_try += 1;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Fix incorrect dsc force enable logic
[Why]
Missed removing a '!' which results in incorrect behavior
[How]
Remove the offending '!'
Signed-off-by: Eryk Brol
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 98b4d5e2e336..fc87b9faec92 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
@@ -644,7 +644,7 @@ static void try_disable_dsc(struct drm_atomic_state *state,
for (i = 0; i < count; i++) {
if (vars[i].dsc_enabled
&& vars[i].bpp_x16 ==
params[i].bw_range.max_target_bpp_x16
- && !params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
+ && params[i].clock_force_enable ==
DSC_CLK_FORCE_DEFAULT) {
kbps_increase[i] = params[i].bw_range.stream_kbps -
params[i].bw_range.max_kbps;
tried[i] = false;
remaining_to_try += 1;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #6 from cornelius.riemenschnei...@googlemail.com --- Created attachment 292999 --> https://bugzilla.kernel.org/attachment.cgi?id=292999=edit crashing dmesg #3 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #5 from cornelius.riemenschnei...@googlemail.com --- Created attachment 292997 --> https://bugzilla.kernel.org/attachment.cgi?id=292997=edit crashing dmesg #2 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #3 from cornelius.riemenschnei...@googlemail.com --- Kernel is 5.8.14-arch1-1. I attached three dmesg outputs of the last two days, where each time the amdgpu driver seemed to cause a divide_error, and the screen froze. Audio playback, and in one case, video encoding (zoom call) continued working until I reset the system via the SysRq keys. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 --- Comment #4 from cornelius.riemenschnei...@googlemail.com --- Created attachment 292995 --> https://bugzilla.kernel.org/attachment.cgi?id=292995=edit crashing dmesg #1 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next pull for 5.10-rc1
On Fri, 16 Oct 2020 at 04:42, Linus Torvalds
wrote:
>
> On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds
> wrote:
> >
> > Thanks, looks good to me [..]
>
> Uhhuh. I already pushed things out, but my clang build (which I don't
> do between each merge) shows a problem:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:650:8:
> warning: logical not is only applied to the left hand side of this
> comparison [-Wlogical-not-parentheses]
> && !params[i].clock_force_enable == DSC_CLK_FORCE_DEFAULT) {
>^ ~~
>
> and I think clang is entirely right to complain about that code.
>
> Yes, the code may be correct, but even if it's correct, that's a
> really odd way to write things.
>
> Anyway, what it does is:
>
>!params[i].clock_force_enable
>
> turns 0 into 1, and anything that isn't 0 into 0.
>
> And DSC_CLK_FORCE_DEFAULT has a value of 0, so what that line actually means
> is
>
> (params[i].clock_force_enable == 0) == 0
>
> which obviously is
>
> params[i].clock_force_enable != 0
>
> which in this case is the same as
>
> params[i].clock_force_enable != DSC_CLK_FORCE_DEFAULT
>
> which may be what the code actually meant to do.
>
> So I suspect it does what it meant to do, but only because
> DSC_CLK_FORCE_DEFAULT also happens to be 0, which also acts as a
> boolean 'false'.
>
> But it's also possible that the '!' is a left-over, and the code
> actually _meant_ to do the exact reverse of that. I have no idea.
>
> This odd code was introduced by commit 0749ddeb7d6c ("drm/amd/display:
> Add DSC force disable to dsc_clock_en debugfs entry"), and can we
> please agree to not write this kind of obfuscated C code?
I've asked Alex to direct send you any fix for you to apply once he's
had a chance to validate it,
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next pull for 5.10-rc1
On Thu, Oct 15, 2020 at 10:51 AM Linus Torvalds
wrote:
>
> Thanks, looks good to me [..]
Uhhuh. I already pushed things out, but my clang build (which I don't
do between each merge) shows a problem:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:650:8:
warning: logical not is only applied to the left hand side of this
comparison [-Wlogical-not-parentheses]
&& !params[i].clock_force_enable == DSC_CLK_FORCE_DEFAULT) {
^ ~~
and I think clang is entirely right to complain about that code.
Yes, the code may be correct, but even if it's correct, that's a
really odd way to write things.
Anyway, what it does is:
!params[i].clock_force_enable
turns 0 into 1, and anything that isn't 0 into 0.
And DSC_CLK_FORCE_DEFAULT has a value of 0, so what that line actually means is
(params[i].clock_force_enable == 0) == 0
which obviously is
params[i].clock_force_enable != 0
which in this case is the same as
params[i].clock_force_enable != DSC_CLK_FORCE_DEFAULT
which may be what the code actually meant to do.
So I suspect it does what it meant to do, but only because
DSC_CLK_FORCE_DEFAULT also happens to be 0, which also acts as a
boolean 'false'.
But it's also possible that the '!' is a left-over, and the code
actually _meant_ to do the exact reverse of that. I have no idea.
This odd code was introduced by commit 0749ddeb7d6c ("drm/amd/display:
Add DSC force disable to dsc_clock_en debugfs entry"), and can we
please agree to not write this kind of obfuscated C code?
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v2 4/8] drm/i915/dp: Rename eDP VESA backlight interface functions
On Wed, Sep 16, 2020 at 01:18:51PM -0400, Lyude Paul wrote:
> Since we're about to add support for a second type of backlight control
> interface over DP AUX (specifically, Intel's proprietary HDR backlight
> controls) let's rename all of the current backlight hooks we have for
> vesa to make it clear that they're specific to the VESA interface and
> not Intel's.
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
Reviewed-by: Rodrigo Vivi
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c | 51 ++-
> 1 file changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe3..f601bcbe8ee46 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -25,7 +25,7 @@
> #include "intel_display_types.h"
> #include "intel_dp_aux_backlight.h"
>
> -static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
> +static void set_vesa_backlight_enable(struct intel_dp *intel_dp, bool enable)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> u8 reg_val = 0;
> @@ -56,7 +56,7 @@ static void set_aux_backlight_enable(struct intel_dp
> *intel_dp, bool enable)
> * Read the current backlight value from DPCD register(s) based
> * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> */
> -static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> +static u32 intel_dp_aux_vesa_get_backlight(struct intel_connector *connector)
> {
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> @@ -99,7 +99,8 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
> * 8-bit or 16 bit value (MSB and LSB)
> */
> static void
> -intel_dp_aux_set_backlight(const struct drm_connector_state *conn_state, u32
> level)
> +intel_dp_aux_vesa_set_backlight(const struct drm_connector_state *conn_state,
> + u32 level)
> {
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> @@ -129,7 +130,7 @@ intel_dp_aux_set_backlight(const struct
> drm_connector_state *conn_state, u32 lev
> * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> */
> -static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> +static bool intel_dp_aux_vesa_set_pwm_freq(struct intel_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> @@ -165,8 +166,8 @@ static bool intel_dp_aux_set_pwm_freq(struct
> intel_connector *connector)
> return true;
> }
>
> -static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
> *crtc_state,
> - const struct drm_connector_state
> *conn_state)
> +static void intel_dp_aux_vesa_enable_backlight(const struct intel_crtc_state
> *crtc_state,
> +const struct drm_connector_state
> *conn_state)
> {
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> @@ -206,7 +207,7 @@ static void intel_dp_aux_enable_backlight(const struct
> intel_crtc_state *crtc_st
> }
>
> if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
> - if (intel_dp_aux_set_pwm_freq(connector))
> + if (intel_dp_aux_vesa_set_pwm_freq(connector))
> new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
>
> if (new_dpcd_buf != dpcd_buf) {
> @@ -217,18 +218,18 @@ static void intel_dp_aux_enable_backlight(const struct
> intel_crtc_state *crtc_st
> }
> }
>
> - intel_dp_aux_set_backlight(conn_state,
> -connector->panel.backlight.level);
> - set_aux_backlight_enable(intel_dp, true);
> + intel_dp_aux_vesa_set_backlight(conn_state,
> + connector->panel.backlight.level);
> + set_vesa_backlight_enable(intel_dp, true);
> }
>
> -static void intel_dp_aux_disable_backlight(const struct drm_connector_state
> *old_conn_state)
> +static void intel_dp_aux_vesa_disable_backlight(const struct
> drm_connector_state *old_conn_state)
> {
> -
> set_aux_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
> - false);
> +
> set_vesa_backlight_enable(enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder)),
> + false);
> }
>
> -static u32
Re: [Intel-gfx] [RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately
On Wed, Sep 16, 2020 at 01:18:50PM -0400, Lyude Paul wrote:
> Currently, every different type of backlight hook that i915 supports is
> pretty straight forward - you have a backlight, probably through PWM
> (but maybe DPCD), with a single set of platform-specific hooks that are
> used for controlling it.
>
> HDR backlights, in particular VESA and Intel's HDR backlight
> implementations, can end up being more complicated. With Intel's
> proprietary interface, HDR backlight controls always run through the
> DPCD. When the backlight is in SDR backlight mode however, the driver
> may need to bypass the TCON and control the backlight directly through
> PWM.
>
> So, in order to support this we'll need to split our backlight callbacks
> into two groups: a set of high-level backlight control callbacks in
> intel_panel, and an additional set of pwm-specific backlight control
> callbacks. This also implies a functional changes for how these
> callbacks are used:
>
> * We now keep track of two separate backlight level ranges, one for the
> high-level backlight, and one for the pwm backlight range
> * We also keep track of backlight enablement and PWM backlight
> enablement separately
> * Since the currently set backlight level might not be the same as the
> currently programmed PWM backlight level, we stop setting
> panel->backlight.level with the currently programmed PWM backlight
> level in panel->backlight.pwm_funcs.setup(). Instead, we rely
> on the higher level backlight control functions to retrieve the
> current PWM backlight level (in this case, intel_pwm_get_backlight()).
> Note that there are still a few PWM backlight setup callbacks that
> do actually need to retrieve the current PWM backlight level, although
> we no longer save this value in panel->backlight.level like before.
> * panel->backlight.pwm_funcs.enable()/disable() both accept a PWM
> brightness level, unlike their siblings
> panel->backlight.enable()/disable(). This is so we can calculate the
> actual PWM brightness level we want to set on disable/enable in the
> higher level backlight enable()/disable() functions, since this value
> might be scaled from a brightness level that doesn't come from PWM.
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
> .../drm/i915/display/intel_display_types.h| 14 +-
> drivers/gpu/drm/i915/display/intel_panel.c| 436 ++
> 2 files changed, 246 insertions(+), 204 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b2d0edacc58c9..52a6543df842a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -221,6 +221,9 @@ struct intel_panel {
> bool alternate_pwm_increment; /* lpt+ */
>
> /* PWM chip */
> + u32 pwm_min;
> + u32 pwm_max;
> + bool pwm_enabled;
> bool util_pin_active_low; /* bxt+ */
> u8 controller; /* bxt+ only */
> struct pwm_device *pwm;
> @@ -229,6 +232,16 @@ struct intel_panel {
> /* DPCD backlight */
> u8 pwmgen_bit_count;
>
> + struct {
> + int (*setup)(struct intel_connector *connector, enum
> pipe pipe);
> + u32 (*get)(struct intel_connector *connector);
> + void (*set)(const struct drm_connector_state
> *conn_state, u32 level);
> + void (*disable)(const struct drm_connector_state
> *conn_state, u32 level);
> + void (*enable)(const struct intel_crtc_state
> *crtc_state,
> +const struct drm_connector_state
> *conn_state, u32 level);
> + u32 (*hz_to_pwm)(struct intel_connector *connector, u32
> hz);
> + } pwm_funcs;
> +
> struct backlight_device *device;
>
> /* Connector and platform specific backlight functions */
> @@ -238,7 +251,6 @@ struct intel_panel {
> void (*disable)(const struct drm_connector_state *conn_state);
> void (*enable)(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> - u32 (*hz_to_pwm)(struct intel_connector *connector, u32 hz);
I see my poor brain getting confused with these 2 levels with very similar
function sets
with same name.
But I currently have no suggestion for better organization or names...
> void (*power)(struct intel_connector *, bool enable);
> } backlight;
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index c0e36244bb07d..6d3e9d51d069c 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++
Re: [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels
On Wed, Sep 16, 2020 at 01:18:48PM -0400, Lyude Paul wrote:
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just read zeroes.
>
> We also take care not to reprogram the source OUI if it already matches
> what we expect. This is just to be careful so that we don't accidentally
> take the panel out of any backlight control modes we found it in.
>
> v2:
> * Add careful parameter to intel_edp_init_source_oui() to avoid
> re-writing the source OUI if it's already been set during driver
> initialization
>
> Signed-off-by: Lyude Paul
> Cc: thay...@noraisin.net
> Cc: Vasily Khoruzhick
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4bd10456ad188..7db2b6a3cd52e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct
> intel_dp *intel_dp,
> enable ? "enable" : "disable");
> }
>
> +static void
> +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 oui[] = { 0x00, 0xaa, 0x01 };
> + u8 buf[3] = { 0 };
> +
> + /*
> + * During driver init, we want to be careful and avoid changing the
> source OUI if it's
> + * already set to what we want, so as to avoid clearing any state by
> accident
> + */
> + if (careful) {
my first reaction here is why the problem described on the commit message
doesn't
appear during the init, and setting it to the same shouldn't be a problem... but
yeap, I agree the risk of taking panel down is high... let's move with the
careful approach
Reviewed-by: Rodrigo Vivi
> + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf,
> sizeof(buf)) < 0)
> + drm_err(>drm, "Failed to read source OUI\n");
> +
> + if (memcmp(oui, buf, sizeof(oui)) == 0)
> + return;
> + }
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui))
> < 0)
> + drm_err(>drm, "Failed to write source OUI\n");
> +}
> +
> /* If the sink supports it, try to set the power state appropriately */
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
> {
> @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int
> mode)
> } else {
> struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>
> + /* Write the source OUI as early as possible */
> + if (intel_dp_is_edp(intel_dp))
> + intel_edp_init_source_oui(intel_dp, false);
> +
> /*
>* When turning on, we need to retry for 1ms to give the sink
>* time to wake up.
> @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> intel_dp_get_dsc_sink_cap(intel_dp);
>
> + /*
> + * If needed, program our source OUI so we can make various
> Intel-specific AUX services
> + * available (such as HDR backlight controls)
> + */
> + intel_edp_init_source_oui(intel_dp, true);
> +
> return true;
> }
>
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave and Daniel, here goes couple display fixes for this last round of fixes before -rc1 drm-intel-next-fixes-2020-10-15: - Set all unused color plane offsets to ~0xfff again (Ville) - Fix TGL DKL PHY DP vswing handling (Ville) The following changes since commit c60b93cd4862d108214a14e655358ea714d7a12a: drm/i915: Avoid mixing integer types during batch copies (2020-09-30 14:24:54 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2020-10-15 for you to fetch changes up to 214bba50616f65264dfc30d095daef3ab7500f52: drm/i915: Set all unused color plane offsets to ~0xfff again (2020-10-12 14:23:22 -0400) - Set all unused color plane offsets to ~0xfff again (Ville) - Fix TGL DKL PHY DP vswing handling (Ville) Ville Syrjälä (2): drm/i915: Fix TGL DKL PHY DP vswing handling drm/i915: Set all unused color plane offsets to ~0xfff again drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- drivers/gpu/drm/i915/display/intel_display.c | 17 + 2 files changed, 6 insertions(+), 13 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next pull for 5.10-rc1
The pull request you sent on Thu, 15 Oct 2020 11:33:08 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-10-15 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/93b694d096cc10994c817730d4d50288f9ae3d66 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
Hi
On Thu, 15 Oct 2020 16:08:13 +0200 Christian König
wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
> > address space. The mapping's address is returned as struct dma_buf_map.
> > Each function is a simplified version of TTM's existing kmap code. Both
> > functions respect the memory's location ani/or writecombine flags.
> >
> > On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
> > two helpers that convert a GEM object into the TTM BO and forward the call
> > to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
> > callbacks.
> >
> > v4:
> > * drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
> > Christian)
>
> Bunch of minor comments below, but over all look very solid to me.
>
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
> > drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
> > drivers/gpu/drm/ttm/ttm_bo_util.c| 72
> > include/drm/drm_gem_ttm_helper.h | 6 +++
> > include/drm/ttm/ttm_bo_api.h | 28 +++
> > include/linux/dma-buf-map.h | 20
> > 5 files changed, 164 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > b/drivers/gpu/drm/drm_gem_ttm_helper.c index 0e4fb9ba43ad..db4c14d78a30
> > 100644 --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> > @@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p,
> > unsigned int indent, }
> > EXPORT_SYMBOL(drm_gem_ttm_print_info);
> >
> > +/**
> > + * drm_gem_ttm_vmap() - vmap _buffer_object
> > + * @gem: GEM object.
> > + * @map: [out] returns the dma-buf mapping.
> > + *
> > + * Maps a GEM object with ttm_bo_vmap(). This function can be used as
> > + * _gem_object_funcs.vmap callback.
> > + *
> > + * Returns:
> > + * 0 on success, or a negative errno code otherwise.
> > + */
> > +int drm_gem_ttm_vmap(struct drm_gem_object *gem,
> > +struct dma_buf_map *map)
> > +{
> > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > +
> > + return ttm_bo_vmap(bo, map);
> > +
> > +}
> > +EXPORT_SYMBOL(drm_gem_ttm_vmap);
> > +
> > +/**
> > + * drm_gem_ttm_vunmap() - vunmap _buffer_object
> > + * @gem: GEM object.
> > + * @map: dma-buf mapping.
> > + *
> > + * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
> > + * _gem_object_funcs.vmap callback.
> > + */
> > +void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
> > + struct dma_buf_map *map)
> > +{
> > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > +
> > + ttm_bo_vunmap(bo, map);
> > +}
> > +EXPORT_SYMBOL(drm_gem_ttm_vunmap);
> > +
> > /**
> >* drm_gem_ttm_mmap() - mmap _buffer_object
> >* @gem: GEM object.
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > b/drivers/gpu/drm/ttm/ttm_bo_util.c index bdee4df1f3f2..80c42c774c7d
> > 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > @@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
> > }
> > EXPORT_SYMBOL(ttm_bo_kunmap);
> >
> > +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
> > +{
> > + struct ttm_resource *mem = >mem;
> > + int ret;
> > +
> > + ret = ttm_mem_io_reserve(bo->bdev, mem);
> > + if (ret)
> > + return ret;
> > +
> > + if (mem->bus.is_iomem) {
> > + void __iomem *vaddr_iomem;
> > + unsigned long size = bo->num_pages << PAGE_SHIFT;
>
> Please use uint64_t here and make sure to cast bo->num_pages before
> shifting.
>
> We have an unit tests of allocating a 8GB BO and that should work on a
> 32bit machine as well :)
>
> > +
> > + if (mem->bus.addr)
> > + vaddr_iomem = (void *)(((u8 *)mem->bus.addr));
> > + else if (mem->placement & TTM_PL_FLAG_WC)
>
> I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new
> mem->bus.caching enum as replacement.
>
> > + vaddr_iomem = ioremap_wc(mem->bus.offset, size);
> > + else
> > + vaddr_iomem = ioremap(mem->bus.offset, size);
> > +
> > + if (!vaddr_iomem)
> > + return -ENOMEM;
> > +
> > + dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
> > +
> > + } else {
> > + struct ttm_operation_ctx ctx = {
> > + .interruptible = false,
> > + .no_wait_gpu = false
> > + };
> > + struct ttm_tt *ttm = bo->ttm;
> > + pgprot_t prot;
> > + void *vaddr;
> > +
> > + BUG_ON(!ttm);
>
> I think we can drop this, populate will just crash badly anyway.
>
> > +
> > + ret = ttm_tt_populate(bo->bdev, ttm, );
>
Re: [PATCH v2] drm/dp check aux_dev before use in drm_dp_aux_dev_get_by_minor()
Reviewed-by: Lyude Paul JFYI - since the commit this fixes has been in the kernel for a while, we should definitely Cc this to sta...@vger.kernel.org so that it gets backported. In the future, the dim tools have a command called "fixes" that can figure this out for you: https://drm.pages.freedesktop.org/maintainer-tools/dim.html I'll make sure to do that when I push your patch to drm-misc-next today, thanks! On Mon, 2020-10-12 at 22:59 -0700, zw...@yosper.io wrote: > I observed this when unplugging a DP monitor whilst a computer is asleep > and then waking it up. This left DP chardev nodes still being present on > the filesystem and accessing these device nodes caused an oops because > drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened. > This can also be reproduced by creating a device node with mknod(1) and > issuing an open(2) > > [166164.933198] BUG: kernel NULL pointer dereference, address: > 0018 > [166164.933202] #PF: supervisor read access in kernel mode > [166164.933204] #PF: error_code(0x) - not-present page > [166164.933205] PGD 0 P4D 0 > [166164.933208] Oops: [#1] PREEMPT SMP NOPTI > [166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: GW > 5.8.0-rc6+ #1 > [166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W > (1.11 ) 04/21/2020 > [166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70 > [drm_kms_helper] > [166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7 > c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6 > <8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1 > [166164.933236] RSP: 0018:b7d7c41cbbf0 EFLAGS: 00010246 > [166164.933237] RAX: RBX: 8a90001fe900 RCX: > > [166164.933238] RDX: RSI: 0003 RDI: > c0a40180 > [166164.933239] RBP: b7d7c41cbbf8 R08: R09: > 8a93e157d6d0 > [166164.933240] R10: R11: c0a40188 R12: > 0003 > [166164.933241] R13: 8a9402200e80 R14: 8a90001fe900 R15: > > [166164.933244] FS: 7f7fb041eb00() GS:8a941150() > knlGS: > [166164.933245] CS: 0010 DS: ES: CR0: 80050033 > [166164.933246] CR2: 0018 CR3: 352c2003 CR4: > 003606e0 > [166164.933247] Call Trace: > [166164.933264] auxdev_open+0x1b/0x40 [drm_kms_helper] > [166164.933278] chrdev_open+0xa7/0x1c0 > [166164.933282] ? cdev_put.part.0+0x20/0x20 > [166164.933287] do_dentry_open+0x161/0x3c0 > [166164.933291] vfs_open+0x2d/0x30 > [166164.933297] path_openat+0xb27/0x10e0 > [166164.933306] ? atime_needs_update+0x73/0xd0 > [166164.933309] do_filp_open+0x91/0x100 > [166164.933313] ? __alloc_fd+0xb2/0x150 > [166164.933316] do_sys_openat2+0x210/0x2d0 > [166164.933318] do_sys_open+0x46/0x80 > [166164.933320] __x64_sys_openat+0x20/0x30 > [166164.933328] do_syscall_64+0x52/0xc0 > [166164.96] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > (gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29 > Dump of assembler code for function drm_dp_aux_dev_get_by_minor: >0x00017b10 <+0>: callq 0x17b15 >0x00017b15 <+5>: push %rbp >0x00017b16 <+6>: mov%rsp,%rbp >0x00017b19 <+9>: push %r12 >0x00017b1b <+11>:mov%edi,%r12d >0x00017b1e <+14>:mov$0x0,%rdi >0x00017b25 <+21>:callq 0x17b2a > >0x00017b2a <+26>:mov%r12d,%esi >0x00017b2d <+29>:mov$0x0,%rdi >0x00017b34 <+36>:callq 0x17b39 > >0x00017b39 <+41>:mov0x18(%rax),%edx <= >0x00017b3c <+44>:mov%rax,%r12 >0x00017b3f <+47>:lea0x18(%rax),%rdi >0x00017b43 <+51>:test %edx,%edx >0x00017b45 <+53>:je 0x17b7a > >0x00017b47 <+55>:lea0x1(%rdx),%ecx >0x00017b4a <+58>:mov%edx,%eax >0x00017b4c <+60>:lock cmpxchg %ecx,(%rdi) >0x00017b50 <+64>:jne0x17b76 > >0x00017b52 <+66>:test %edx,%edx >0x00017b54 <+68>:js 0x17b6d > >0x00017b56 <+70>:test %ecx,%ecx >0x00017b58 <+72>:js 0x17b6d > >0x00017b5a <+74>:mov$0x0,%rdi >0x00017b61 <+81>:callq 0x17b66 > >0x00017b66 <+86>:mov%r12,%rax >0x00017b69 <+89>:pop%r12 >0x00017b6b <+91>:pop%rbp >0x00017b6c <+92>:retq >0x00017b6d <+93>:xor%esi,%esi >0x00017b6f <+95>:callq 0x17b74 > >0x00017b74 <+100>: jmp0x17b5a > >0x00017b76 <+102>: mov%eax,%edx >0x00017b78 <+104>: jmp0x17b43 > >0x00017b7a <+106>:
Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
> On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
> > > kernel address space. The mapping's address is returned as struct
> > > dma_buf_map. Each function is a simplified version of TTM's existing
> > > kmap code. Both functions respect the memory's location ani/or
> > > writecombine flags.
> > >
> > > On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
> > > two helpers that convert a GEM object into the TTM BO and forward the
> > > call to TTM's vmap/vunmap. These helpers can be dropped into the rsp
> > > GEM object callbacks.
> > >
> > > v4:
> > > * drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers
> > > (Daniel, Christian)
> >
> > Bunch of minor comments below, but over all look very solid to me.
>
> Yeah I think just duplicating the ttm bo map stuff for vmap is indeed the
> cleanest. And then we can maybe push the combinatorial monster into
> vmwgfx, which I think is the only user after this series. Or perhaps a
> dedicated set of helpers to map an invidual page (again using the
> dma_buf_map stuff).
From a quick look, I'd say it should be possible to have the same interface
for kmap/kunmap as for vmap/vunmap (i.e., parameters are bo and dma-buf-map).
All mapping state can be deduced from this. And struct ttm_bo_kmap_obj can be
killed off entirely.
Best regards
Thomas
>
> I'll let Christian with the details, but at a high level this is
> definitely
>
> Acked-by: Daniel Vetter
>
> Thanks a lot for doing all this.
> -Daniel
>
> >
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > ---
> > > drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
> > > drivers/gpu/drm/ttm/ttm_bo_util.c| 72
> > > include/drm/drm_gem_ttm_helper.h | 6 +++
> > > include/drm/ttm/ttm_bo_api.h | 28 +++
> > > include/linux/dma-buf-map.h | 20
> > > 5 files changed, 164 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > > b/drivers/gpu/drm/drm_gem_ttm_helper.c index 0e4fb9ba43ad..db4c14d78a30
> > > 100644 --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> > > @@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p,
> > > unsigned int indent, }
> > > EXPORT_SYMBOL(drm_gem_ttm_print_info);
> > > +/**
> > > + * drm_gem_ttm_vmap() - vmap _buffer_object
> > > + * @gem: GEM object.
> > > + * @map: [out] returns the dma-buf mapping.
> > > + *
> > > + * Maps a GEM object with ttm_bo_vmap(). This function can be used as
> > > + * _gem_object_funcs.vmap callback.
> > > + *
> > > + * Returns:
> > > + * 0 on success, or a negative errno code otherwise.
> > > + */
> > > +int drm_gem_ttm_vmap(struct drm_gem_object *gem,
> > > + struct dma_buf_map *map)
> > > +{
> > > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > > +
> > > + return ttm_bo_vmap(bo, map);
> > > +
> > > +}
> > > +EXPORT_SYMBOL(drm_gem_ttm_vmap);
> > > +
> > > +/**
> > > + * drm_gem_ttm_vunmap() - vunmap _buffer_object
> > > + * @gem: GEM object.
> > > + * @map: dma-buf mapping.
> > > + *
> > > + * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used
> > > as
> > > + * _gem_object_funcs.vmap callback.
> > > + */
> > > +void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
> > > + struct dma_buf_map *map)
> > > +{
> > > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > > +
> > > + ttm_bo_vunmap(bo, map);
> > > +}
> > > +EXPORT_SYMBOL(drm_gem_ttm_vunmap);
> > > +
> > > /**
> > >* drm_gem_ttm_mmap() - mmap _buffer_object
> > >* @gem: GEM object.
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > b/drivers/gpu/drm/ttm/ttm_bo_util.c index bdee4df1f3f2..80c42c774c7d
> > > 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > > @@ -32,6 +32,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
> > > }
> > > EXPORT_SYMBOL(ttm_bo_kunmap);
> > > +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
> > > +{
> > > + struct ttm_resource *mem = >mem;
> > > + int ret;
> > > +
> > > + ret = ttm_mem_io_reserve(bo->bdev, mem);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (mem->bus.is_iomem) {
> > > + void __iomem *vaddr_iomem;
> > > + unsigned long size = bo->num_pages << PAGE_SHIFT;
> >
> > Please use uint64_t here and make sure to cast bo->num_pages before
> > shifting.
> >
> > We have an unit tests of allocating a 8GB BO and that should work on a
> > 32bit machine as well :)
> >
> > > +
> > > + if (mem->bus.addr)
> > > +
Re: [git pull] drm next pull for 5.10-rc1
On Wed, Oct 14, 2020 at 6:33 PM Dave Airlie wrote: > > There are a bunch of conflicts but none of them seemed overly scary, > and sfr has provided resolutions for them all. I've put a tree up with > my merge results, so you can tell me I did it wrong here: > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.10-merged Thanks, looks good to me, and I missed the same msm_iommu.c patch you did, so kudos for pointing that one out too. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH RFC] drm/nouveau: fix memory leak in nvkm_iccsense_oneinit
On Thu, Oct 15, 2020 at 6:32 PM Karol Herbst wrote:
>
> Ben, I think this is like the 5th patch tackling this issue, I think
> we should merge one of those.
>
maybe I just confused that with reports, but it seems to turn up quite
a bit and maybe I should have pushed more of it as well...
Anyway, the patch itself looks good.
Reviewed-by: Karol Herbst
> On Thu, Oct 15, 2020 at 6:23 AM Keita Suzuki
> wrote:
> >
> > struct pw_rail_t is allocated as an array in function nvios_iccsense_parse,
> > and stored to a struct member of local variable. However, the array is not
> > freed when the local variable becomes invalid, and the reference is not
> > passed on, leading to a memory leak.
> >
> > Fix this by freeing struct pw_rail_t when exiting nvkm_iccsense_oneinit.
> >
> > Signed-off-by: Keita Suzuki
> > ---
> > drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > index fecfa6afcf54..8ba8d8e3f52a 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> > @@ -280,8 +280,10 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
> > }
> >
> > rail = kmalloc(sizeof(*rail), GFP_KERNEL);
> > - if (!rail)
> > + if (!rail) {
> > + kfree(stbl.rail);
> > return -ENOMEM;
> > + }
> >
> > rail->read = read;
> > rail->sensor = sensor;
> > @@ -291,6 +293,7 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
> > list_add_tail(>head, >rails);
> > }
> > }
> > + kfree(stbl.rail);
> > return 0;
> > }
> >
> > --
> > 2.17.1
> >
> > ___
> > Nouveau mailing list
> > nouv...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
> > address space. The mapping's address is returned as struct dma_buf_map.
> > Each function is a simplified version of TTM's existing kmap code. Both
> > functions respect the memory's location ani/or writecombine flags.
> >
> > On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
> > two helpers that convert a GEM object into the TTM BO and forward the call
> > to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
> > callbacks.
> >
> > v4:
> > * drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
> > Christian)
>
> Bunch of minor comments below, but over all look very solid to me.
Yeah I think just duplicating the ttm bo map stuff for vmap is indeed the
cleanest. And then we can maybe push the combinatorial monster into
vmwgfx, which I think is the only user after this series. Or perhaps a
dedicated set of helpers to map an invidual page (again using the
dma_buf_map stuff).
I'll let Christian with the details, but at a high level this is
definitely
Acked-by: Daniel Vetter
Thanks a lot for doing all this.
-Daniel
>
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
> > drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
> > drivers/gpu/drm/ttm/ttm_bo_util.c| 72
> > include/drm/drm_gem_ttm_helper.h | 6 +++
> > include/drm/ttm/ttm_bo_api.h | 28 +++
> > include/linux/dma-buf-map.h | 20
> > 5 files changed, 164 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > b/drivers/gpu/drm/drm_gem_ttm_helper.c
> > index 0e4fb9ba43ad..db4c14d78a30 100644
> > --- a/drivers/gpu/drm/drm_gem_ttm_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> > @@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p,
> > unsigned int indent,
> > }
> > EXPORT_SYMBOL(drm_gem_ttm_print_info);
> > +/**
> > + * drm_gem_ttm_vmap() - vmap _buffer_object
> > + * @gem: GEM object.
> > + * @map: [out] returns the dma-buf mapping.
> > + *
> > + * Maps a GEM object with ttm_bo_vmap(). This function can be used as
> > + * _gem_object_funcs.vmap callback.
> > + *
> > + * Returns:
> > + * 0 on success, or a negative errno code otherwise.
> > + */
> > +int drm_gem_ttm_vmap(struct drm_gem_object *gem,
> > +struct dma_buf_map *map)
> > +{
> > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > +
> > + return ttm_bo_vmap(bo, map);
> > +
> > +}
> > +EXPORT_SYMBOL(drm_gem_ttm_vmap);
> > +
> > +/**
> > + * drm_gem_ttm_vunmap() - vunmap _buffer_object
> > + * @gem: GEM object.
> > + * @map: dma-buf mapping.
> > + *
> > + * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
> > + * _gem_object_funcs.vmap callback.
> > + */
> > +void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
> > + struct dma_buf_map *map)
> > +{
> > + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> > +
> > + ttm_bo_vunmap(bo, map);
> > +}
> > +EXPORT_SYMBOL(drm_gem_ttm_vunmap);
> > +
> > /**
> >* drm_gem_ttm_mmap() - mmap _buffer_object
> >* @gem: GEM object.
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > index bdee4df1f3f2..80c42c774c7d 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > @@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
> > }
> > EXPORT_SYMBOL(ttm_bo_kunmap);
> > +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
> > +{
> > + struct ttm_resource *mem = >mem;
> > + int ret;
> > +
> > + ret = ttm_mem_io_reserve(bo->bdev, mem);
> > + if (ret)
> > + return ret;
> > +
> > + if (mem->bus.is_iomem) {
> > + void __iomem *vaddr_iomem;
> > + unsigned long size = bo->num_pages << PAGE_SHIFT;
>
> Please use uint64_t here and make sure to cast bo->num_pages before
> shifting.
>
> We have an unit tests of allocating a 8GB BO and that should work on a 32bit
> machine as well :)
>
> > +
> > + if (mem->bus.addr)
> > + vaddr_iomem = (void *)(((u8 *)mem->bus.addr));
> > + else if (mem->placement & TTM_PL_FLAG_WC)
>
> I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new
> mem->bus.caching enum as replacement.
>
> > + vaddr_iomem = ioremap_wc(mem->bus.offset, size);
> > + else
> > + vaddr_iomem = ioremap(mem->bus.offset, size);
> > +
> > + if (!vaddr_iomem)
> > + return -ENOMEM;
> > +
> > + dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
> > +
> > +
Re: [PATCH] dt-bindings: display: Add dsi-controller.yaml in DSI controller schemas
On 10/3/20 12:59 AM, Rob Herring wrote: > Some DSI controllers are missing a reference to the recently added > dsi-controller.yaml schema. Add it and we can drop the duplicate parts. > > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Eric Anholt > Cc: Nicolas Saenz Julienne > Cc: Florian Fainelli > Cc: Ray Jui > Cc: Scott Branden > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: "Guido Gúnther" > Cc: Robert Chiras > Cc: Philippe Cornu Hi Rob, and many thanks for the patch. For the stm32 part, Reviewed-by: Philippe Cornu Philippe :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH RFC] drm/nouveau: fix memory leak in nvkm_iccsense_oneinit
Ben, I think this is like the 5th patch tackling this issue, I think
we should merge one of those.
On Thu, Oct 15, 2020 at 6:23 AM Keita Suzuki
wrote:
>
> struct pw_rail_t is allocated as an array in function nvios_iccsense_parse,
> and stored to a struct member of local variable. However, the array is not
> freed when the local variable becomes invalid, and the reference is not
> passed on, leading to a memory leak.
>
> Fix this by freeing struct pw_rail_t when exiting nvkm_iccsense_oneinit.
>
> Signed-off-by: Keita Suzuki
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> index fecfa6afcf54..8ba8d8e3f52a 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
> @@ -280,8 +280,10 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
> }
>
> rail = kmalloc(sizeof(*rail), GFP_KERNEL);
> - if (!rail)
> + if (!rail) {
> + kfree(stbl.rail);
> return -ENOMEM;
> + }
>
> rail->read = read;
> rail->sensor = sensor;
> @@ -291,6 +293,7 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
> list_add_tail(>head, >rails);
> }
> }
> + kfree(stbl.rail);
> return 0;
> }
>
> --
> 2.17.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 5/5] dma-buf: Clarify that dma-buf sg lists are page aligned
Am 15.10.20 um 18:03 schrieb Daniel Vetter:
On Wed, Oct 14, 2020 at 09:16:01AM -0700, Jianxin Xiong wrote:
The dma-buf API have been used under the assumption that the sg lists
returned from dma_buf_map_attachment() are fully page aligned. Lots of
stuff can break otherwise all over the place. Clarify this in the
documentation and add a check when DMA API debug is enabled.
Signed-off-by: Jianxin Xiong
Reviewed-by: Christian König
lgtm, thanks for creating this and giving it a spin.
I'll queue this up in drm-misc-next for 5.11, should show up in linux-next
after the merge window is closed.
Thanks, I'm currently without landline internet and need to rely on my
mobile.
Christian.
Cheers, Daniel
---
drivers/dma-buf/dma-buf.c | 21 +
include/linux/dma-buf.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 844967f..7309c83 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -851,6 +851,9 @@ void dma_buf_unpin(struct dma_buf_attachment *attach)
* Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
* on error. May return -EINTR if it is interrupted by a signal.
*
+ * On success, the DMA addresses and lengths in the returned scatterlist are
+ * PAGE_SIZE aligned.
+ *
* A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
* the underlying backing storage is pinned for as long as a mapping exists,
* therefore users/importers should not hold onto a mapping for undue amounts
of
@@ -904,6 +907,24 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
attach->dir = direction;
}
+#ifdef CONFIG_DMA_API_DEBUG
+ {
+ struct scatterlist *sg;
+ u64 addr;
+ int len;
+ int i;
+
+ for_each_sgtable_dma_sg(sg_table, sg, i) {
+ addr = sg_dma_address(sg);
+ len = sg_dma_len(sg);
+ if (!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(len)) {
+ pr_debug("%s: addr %llx or len %x is not page
aligned!\n",
+__func__, addr, len);
+ }
+ }
+ }
+#endif /* CONFIG_DMA_API_DEBUG */
+
return sg_table;
}
EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index a2ca294e..4a5fa70 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -145,7 +145,8 @@ struct dma_buf_ops {
*
* A _table scatter list of or the backing storage of the DMA buffer,
* already mapped into the device address space of the attached
-* with the provided _buf_attachment.
+* with the provided _buf_attachment. The addresses and lengths in
+* the scatter list are PAGE_SIZE aligned.
*
* On failure, returns a negative error value wrapped into a pointer.
* May also return -EINTR when a signal was received while being
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=04%7C01%7Cchristian.koenig%40amd.com%7C58ee8712041e4e742fe408d87123e970%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637383746351346603%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=EwAEVcJa6gboHMEQ6XUymC%2BtjFoWd0wl8YUyzdnV5N8%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/80] htmldoc build fixes with Sphinx 2.x and 3.x
Em Thu, 15 Oct 2020 17:49:23 +0200 Daniel Vetter escreveu: > On Tue, Oct 13, 2020 at 01:53:15PM +0200, Mauro Carvalho Chehab wrote: > > This series actually folds the previous Sphinx 3.x patch series > > with the other patches I sent fixing warnings with Sphinx > > 2.x and with kernel-doc and that weren't merged yet via > > some other tree. > > > > It is based on the top of upstream, plus the media > > pull request I sent yesterday: > > > > https://lore.kernel.org/lkml/20201012134139.0d58f...@coco.lan/ > > > > My plan is to send a pull request with those patches after Thursday's > > linux next release. > > > > On this series, I removed the patches that depend on material > > currently found only at linux-next. > > Was a bit tricky to find the cover letter here and that you plan to > send these out this merge window. Sorry for that. As this series touch lots of subsystems, just c/c the maintainers mean more than 50 c/c to patch 00. Some e-mail servers may not accept e-mails with too many c/c people. Yet, checking at the c/c list of the original patch, you were copied on patch 00/80. So, maybe the e-mail server had silently dropped the original e-mail. > I think we'll have some confusion > now with Alex from amd having picked up a few already. I ended moving (at least part of) the drm patches from this series into a second one, as I'm intending to submit most of those patches today or tomorrow, and the remaining ones by the end of the merge window. > Anyway Acked-by: Daniel Vetter for the > remaining drm patches. Thank you! > Although I can also pick them up to > drm-misc-next (but that's going to be 5.11 or so). It would be a way better to have them merged for 5.10, in order to have a clean html build there. Thanks, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/5] RDMA/umem: Support importing dma-buf as user memory region
On Wed, Oct 14, 2020 at 09:15:16AM -0700, Jianxin Xiong wrote:
> Dma-buf is a standard cross-driver buffer sharing mechanism that can be
> used to support peer-to-peer access from RDMA devices.
>
> Device memory exported via dma-buf is associated with a file descriptor.
> This is passed to the user space as a property associated with the
> buffer allocation. When the buffer is registered as a memory region,
> the file descriptor is passed to the RDMA driver along with other
> parameters.
>
> Implement the common code for importing dma-buf object and mapping
> dma-buf pages.
>
> Signed-off-by: Jianxin Xiong
> Reviewed-by: Sean Hefty
> Acked-by: Michael J. Ruhl
> Acked-by: Christian Koenig
> ---
> drivers/infiniband/core/Makefile | 2 +-
> drivers/infiniband/core/umem.c| 4 +
> drivers/infiniband/core/umem_dmabuf.c | 200
> ++
> drivers/infiniband/core/umem_dmabuf.h | 11 ++
> include/rdma/ib_umem.h| 32 +-
> 5 files changed, 247 insertions(+), 2 deletions(-)
> create mode 100644 drivers/infiniband/core/umem_dmabuf.c
> create mode 100644 drivers/infiniband/core/umem_dmabuf.h
>
> diff --git a/drivers/infiniband/core/Makefile
> b/drivers/infiniband/core/Makefile
> index ccf2670..8ab4eea 100644
> --- a/drivers/infiniband/core/Makefile
> +++ b/drivers/infiniband/core/Makefile
> @@ -40,5 +40,5 @@ ib_uverbs-y := uverbs_main.o
> uverbs_cmd.o uverbs_marshall.o \
> uverbs_std_types_srq.o \
> uverbs_std_types_wq.o \
> uverbs_std_types_qp.o
> -ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
> +ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
> ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index e9fecbd..8c608a5 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -2,6 +2,7 @@
> * Copyright (c) 2005 Topspin Communications. All rights reserved.
> * Copyright (c) 2005 Cisco Systems. All rights reserved.
> * Copyright (c) 2005 Mellanox Technologies. All rights reserved.
> + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> *
> * This software is available to you under a choice of one of two
> * licenses. You may choose to be licensed under the terms of the GNU
> @@ -43,6 +44,7 @@
> #include
>
> #include "uverbs.h"
> +#include "umem_dmabuf.h"
>
> static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem,
> int dirty)
> {
> @@ -269,6 +271,8 @@ void ib_umem_release(struct ib_umem *umem)
> {
> if (!umem)
> return;
> + if (umem->is_dmabuf)
> + return ib_umem_dmabuf_release(umem);
> if (umem->is_odp)
> return ib_umem_odp_release(to_ib_umem_odp(umem));
>
> diff --git a/drivers/infiniband/core/umem_dmabuf.c
> b/drivers/infiniband/core/umem_dmabuf.c
> new file mode 100644
> index 000..4f2303e
> --- /dev/null
> +++ b/drivers/infiniband/core/umem_dmabuf.c
> @@ -0,0 +1,200 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "uverbs.h"
> +
> +struct ib_umem_dmabuf {
> + struct ib_umem umem;
> + struct dma_buf_attachment *attach;
> + struct sg_table *sgt;
> + const struct ib_umem_dmabuf_ops *ops;
> + void *device_context;
> + struct work_struct work;
> +};
> +
> +static inline struct ib_umem_dmabuf *to_ib_umem_dmabuf(struct ib_umem *umem)
> +{
> + return container_of(umem, struct ib_umem_dmabuf, umem);
> +}
> +
> +int ib_umem_dmabuf_map_pages(struct ib_umem *umem, bool first)
> +{
> + struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(umem);
> + struct sg_table *sgt;
> + struct dma_fence *fence;
> + int err;
> +
> + dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
> +
> + sgt = dma_buf_map_attachment(umem_dmabuf->attach,
> + DMA_BIDIRECTIONAL);
> +
> + if (IS_ERR(sgt)) {
> + dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
> + return PTR_ERR(sgt);
> + }
> +
> + umem_dmabuf->umem.sg_head = *sgt;
> + umem_dmabuf->umem.nmap = sgt->nents;
> + umem_dmabuf->sgt = sgt;
> +
Maybe you want to put the explanation why we have to first get the mapping
and then wait on it here as a comment, since that's rather non-obvious for
non-gpu people.
Either way I think the dma-buf side of this looks good now, both the map
and unmap side.
Acked-by: Daniel Vetter
> + fence = dma_resv_get_excl(umem_dmabuf->attach->dmabuf->resv);
> + if (fence)
> + dma_fence_wait(fence, false);
> +
> + if (first)
> + err = umem_dmabuf->ops->init(umem,
> +
Re: [PATCH v4 5/5] dma-buf: Clarify that dma-buf sg lists are page aligned
On Wed, Oct 14, 2020 at 09:16:01AM -0700, Jianxin Xiong wrote:
> The dma-buf API have been used under the assumption that the sg lists
> returned from dma_buf_map_attachment() are fully page aligned. Lots of
> stuff can break otherwise all over the place. Clarify this in the
> documentation and add a check when DMA API debug is enabled.
>
> Signed-off-by: Jianxin Xiong
lgtm, thanks for creating this and giving it a spin.
I'll queue this up in drm-misc-next for 5.11, should show up in linux-next
after the merge window is closed.
Cheers, Daniel
> ---
> drivers/dma-buf/dma-buf.c | 21 +
> include/linux/dma-buf.h | 3 ++-
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 844967f..7309c83 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -851,6 +851,9 @@ void dma_buf_unpin(struct dma_buf_attachment *attach)
> * Returns sg_table containing the scatterlist to be returned; returns
> ERR_PTR
> * on error. May return -EINTR if it is interrupted by a signal.
> *
> + * On success, the DMA addresses and lengths in the returned scatterlist are
> + * PAGE_SIZE aligned.
> + *
> * A mapping must be unmapped by using dma_buf_unmap_attachment(). Note that
> * the underlying backing storage is pinned for as long as a mapping exists,
> * therefore users/importers should not hold onto a mapping for undue
> amounts of
> @@ -904,6 +907,24 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> attach->dir = direction;
> }
>
> +#ifdef CONFIG_DMA_API_DEBUG
> + {
> + struct scatterlist *sg;
> + u64 addr;
> + int len;
> + int i;
> +
> + for_each_sgtable_dma_sg(sg_table, sg, i) {
> + addr = sg_dma_address(sg);
> + len = sg_dma_len(sg);
> + if (!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(len)) {
> + pr_debug("%s: addr %llx or len %x is not page
> aligned!\n",
> + __func__, addr, len);
> + }
> + }
> + }
> +#endif /* CONFIG_DMA_API_DEBUG */
> +
> return sg_table;
> }
> EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index a2ca294e..4a5fa70 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -145,7 +145,8 @@ struct dma_buf_ops {
>*
>* A _table scatter list of or the backing storage of the DMA buffer,
>* already mapped into the device address space of the attached
> - * with the provided _buf_attachment.
> + * with the provided _buf_attachment. The addresses and lengths in
> + * the scatter list are PAGE_SIZE aligned.
>*
>* On failure, returns a negative error value wrapped into a pointer.
>* May also return -EINTR when a signal was received while being
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209673] divide_error in amdgpu freezes screen
https://bugzilla.kernel.org/show_bug.cgi?id=209673 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your full dmesg output. What kernel are you running? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On Thu, Oct 15, 2020 at 07:55:32AM +0100, Christoph Hellwig wrote: > On Tue, Oct 13, 2020 at 02:42:38PM +0100, Robin Murphy wrote: > > I still think this situation would be best handled with a variant of > > dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set > > automatically when attaching to an unmanaged IOMMU domain. > > dma_ops_bypass should mostly do the right thing as-is. swiotlb bouncing > is triggered of two things: > > 1) the dma_mask. This is under control of the driver, and obviously > if it is too small for a legit reason we can't just proceed Somewhat related, but is there a way to tell the dma-api to fail instead of falling back to swiotlb? In many case for gpu drivers it's much better if we fall back to dma_alloc_coherent and manage the copying ourselves instead of abstracting this away in the dma-api. Currently that's "solved" rather pessimistically by always allocating from dma_alloc_coherent if swiotlb could be in the picture (at least for ttm based drivers, i915 just falls over). -Daniel > 2) force_dma_unencrypted() - we'd need to do an opt-out here, either > by a flag or by being smart and looking for an attached iommu on > the device > > > That way the > > device driver can make DMA API calls in the appropriate places that do the > > right thing either way, and only needs logic to decide whether to use the > > returned DMA addresses directly or ignore them if it knows they're > > overridden by its own IOMMU mapping. > > I'd be happy to review patches for this. -- 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 14/17] resource: Move devmem revoke code to resource framework
On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > >
> > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
> > > > >
> > > > > On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> > > > >
> > > > > > +struct address_space *iomem_get_mapping(void)
> > > > > > +{
> > > > > > + return iomem_inode->i_mapping;
> > > > >
> > > > > This should pair an acquire with the release below
> > > > >
> > > > > > + /*
> > > > > > + * Publish /dev/mem initialized.
> > > > > > + * Pairs with smp_load_acquire() in revoke_iomem().
> > > > > > + */
> > > > > > + smp_store_release(_inode, inode);
> > > > >
> > > > > However, this seems abnormal, initcalls rarely do this kind of stuff
> > > > > with global data..
> > > > >
> > > > > The kernel crashes if this fs_initcall is raced with
> > > > > iomem_get_mapping() due to the unconditional dereference, so I think
> > > > > it can be safely switched to a simple assignment.
> > > >
> > > > Ah yes I checked this all, but forgot to correctly annotate the
> > > > iomem_get_mapping access. For reference, see b34e7e298d7a ("/dev/mem:
> > > > Add missing memory barriers for devmem_inode").
> > >
> > > Oh yikes, so revoke_iomem can run concurrently during early boot,
> > > tricky.
> >
> > It runs early because request_mem_region() can run before fs_initcall.
> > Rather than add an unnecessary lock just arrange for the revoke to be
> > skipped before the inode is initialized. The expectation is that any
> > early resource reservations will block future userspace mapping
> > attempts.
>
> Actually, on this point a simple WRITE_ONCE/READ_ONCE pairing is OK,
> Paul once explained that the pointer chase on the READ_ONCE side is
> required to be like an acquire - this is why rcu_dereference is just
> READ_ONCE
Hm so WRITE_ONCE doesn't have any barriers, and we'd need that for
updating the pointer. That would leave things rather inconsistent, so
I think I'll just leave it as-is for symmetry reasons. None of this
code matters for performance anyway, so micro-optimizing barriers
seems a bit silly.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/of: Consider the state in which the ep is disabled
On Wed, Oct 14, 2020 at 09:48:43AM +0800, Kever Yang wrote:
> Hi Maintainers,
>
> Does this patch ready to merge?
Would maybe be good to get some acks from other drivers using this, then
Sandy can push to drm-misc-next.
-Daniel
>
> On 2020/7/7 下午7:25, Sandy Huang wrote:
> > don't mask possible_crtcs if remote-point is disabled.
> >
> > Signed-off-by: Sandy Huang
> > ---
> > drivers/gpu/drm/drm_of.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > index fdb05fbf72a0..565f05f5f11b 100644
> > --- a/drivers/gpu/drm/drm_of.c
> > +++ b/drivers/gpu/drm/drm_of.c
> > @@ -66,6 +66,9 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device
> > *dev,
> > uint32_t possible_crtcs = 0;
> > for_each_endpoint_of_node(port, ep) {
> > + if (!of_device_is_available(ep))
> > + continue;
> > +
> > remote_port = of_graph_get_remote_port(ep);
> > if (!remote_port) {
> > of_node_put(ep);
>
> Looks good to me.
>
>
> Reviewed-by: Kever Yang
--
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: [v2] drm/msm: Fix race condition in msm driver with async layer updates
On Thu, Oct 15, 2020 at 2:15 AM Krishna Manikandan
wrote:
>
> When there are back to back commits with async cursor update,
> there is a case where second commit can program the DPU hw
> blocks while first didn't complete flushing config to HW.
>
> Synchronize the compositions such that second commit waits
> until first commit flushes the composition.
>
> This change also introduces per crtc commit lock, such that
> commits on different crtcs are not blocked by each other.
>
> Changes in v2:
> - Use an array of mutexes in kms to handle commit
> lock per crtc. (Rob Clark)
>
> Signed-off-by: Krishna Manikandan
> ---
> drivers/gpu/drm/msm/msm_atomic.c | 32 +++-
> drivers/gpu/drm/msm/msm_kms.h| 6 --
> 2 files changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 561bfa4..f9bd472 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -61,10 +61,10 @@ static void msm_atomic_async_commit(struct msm_kms *kms,
> int crtc_idx)
>
> trace_msm_atomic_async_commit_start(crtc_mask);
>
> - mutex_lock(>commit_lock);
> + mutex_lock(>commit_lock[crtc_idx]);
>
> if (!(kms->pending_crtc_mask & crtc_mask)) {
> - mutex_unlock(>commit_lock);
> + mutex_unlock(>commit_lock[crtc_idx]);
> goto out;
> }
>
> @@ -79,7 +79,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms,
> int crtc_idx)
> */
> trace_msm_atomic_flush_commit(crtc_mask);
> kms->funcs->flush_commit(kms, crtc_mask);
> - mutex_unlock(>commit_lock);
>
> /*
> * Wait for flush to complete:
> @@ -90,9 +89,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms,
> int crtc_idx)
>
> vblank_put(kms, crtc_mask);
>
> - mutex_lock(>commit_lock);
> kms->funcs->complete_commit(kms, crtc_mask);
> - mutex_unlock(>commit_lock);
> + mutex_unlock(>commit_lock[crtc_idx]);
> kms->funcs->disable_commit(kms);
>
> out:
> @@ -171,6 +169,16 @@ static unsigned get_crtc_mask(struct drm_atomic_state
> *state)
> return mask;
> }
>
> +static int get_crtc_id(struct msm_kms *kms, unsigned int crtc_mask)
> +{
> + struct drm_crtc *crtc;
> +
> + for_each_crtc_mask(kms->dev, crtc, crtc_mask)
> + return drm_crtc_index(crtc);
> +
> + return 0;
> +}
this is closer, but a commit could still touch multiple CRTCs, I think
what you should do is add a lock/unlock helper, similar to
vblank_get/put(), ie:
static void lock_crtcs(struct msm_kms *kms, unsigned crtc_mask)
{
struct drm_crtc *crtc;
for_each_crtc_mask(kms->dev, crtc, crtc_mask)
mutex_lock(>commit_lock[drm_crtc_index(crtc)]);
}
and use that everywhere
(Technically we only go down the async path if there is only a single
crtc, but no reason not to use the lock/unlock helpers in both cases)
BR,
-R
> +
> void msm_atomic_commit_tail(struct drm_atomic_state *state)
> {
> struct drm_device *dev = state->dev;
> @@ -180,6 +188,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
> unsigned crtc_mask = get_crtc_mask(state);
> bool async = kms->funcs->vsync_time &&
> can_do_async(state, _crtc);
> + int crtc_idx = get_crtc_id(kms, crtc_mask);
>
> trace_msm_atomic_commit_tail_start(async, crtc_mask);
>
> @@ -189,12 +198,11 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
> * Ensure any previous (potentially async) commit has
> * completed:
> */
> + mutex_lock(>commit_lock[crtc_idx]);
> trace_msm_atomic_wait_flush_start(crtc_mask);
> kms->funcs->wait_flush(kms, crtc_mask);
> trace_msm_atomic_wait_flush_finish(crtc_mask);
>
> - mutex_lock(>commit_lock);
> -
> /*
> * Now that there is no in-progress flush, prepare the
> * current update:
> @@ -232,8 +240,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
> }
>
> kms->funcs->disable_commit(kms);
> - mutex_unlock(>commit_lock);
> -
> + mutex_unlock(>commit_lock[crtc_idx]);
> /*
> * At this point, from drm core's perspective, we
> * are done with the atomic update, so we can just
> @@ -260,8 +267,7 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
> */
> trace_msm_atomic_flush_commit(crtc_mask);
> kms->funcs->flush_commit(kms, crtc_mask);
> - mutex_unlock(>commit_lock);
> -
> + mutex_unlock(>commit_lock[crtc_idx]);
> /*
> * Wait for flush to complete:
> */
> @@ -271,9 +277,9 @@ void msm_atomic_commit_tail(struct drm_atomic_state
> *state)
>
> vblank_put(kms, crtc_mask);
>
> - mutex_lock(>commit_lock);
> +
Re: [git pull] drm next pull for 5.10-rc1
On Thu, Oct 15, 2020 at 10:53:28AM -0400, Alex Deucher wrote: > On Thu, Oct 15, 2020 at 9:59 AM Peilin Ye wrote: > > It has been applied to linux-next twice, for unknown reasons. Thank you! > > The patch was already in drm-next, but since it was a bug fix it was > applied it to 5.9 as well. Ah, I see. Thank you for the explanation! Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next pull for 5.10-rc1
On Thu, Oct 15, 2020 at 9:59 AM Peilin Ye wrote: > > Hi all, > > On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote: > > Peilin Ye (1): > > drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl() > > This patch is already in mainline: > > commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31 > Author: Peilin Ye > Date: Tue Jul 28 15:29:24 2020 -0400 > > drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl() > > It has been applied to linux-next twice, for unknown reasons. Thank you! The patch was already in drm-next, but since it was a bug fix it was applied it to 5.9 as well. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap()
et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of
implementing their own vmap callbacks.
v4:
* use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian)
* fix a trailing { in drm_gem_vmap()
* remove several empty functions instead of converting them (Daniel)
* comment uses of raw pointers with a TODO (Daniel)
* TODO list: convert more helpers to use struct dma_buf_map
Signed-off-by: Thomas Zimmermann
The amdgpu changes look good to me, but I can't fully judge the other stuff.
Acked-by: Christian König
---
Documentation/gpu/todo.rst | 18
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/ast/ast_cursor.c| 27 +++--
drivers/gpu/drm/ast/ast_drv.h | 7 +-
drivers/gpu/drm/drm_gem.c | 23 +++--
drivers/gpu/drm/drm_gem_cma_helper.c| 10 +-
drivers/gpu/drm/drm_gem_shmem_helper.c | 48 +
drivers/gpu/drm/drm_gem_vram_helper.c | 107 ++--
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 9 +-
drivers/gpu/drm/lima/lima_gem.c | 6 +-
drivers/gpu/drm/lima/lima_sched.c | 11 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 -
drivers/gpu/drm/nouveau/nouveau_prime.c | 20
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 14 +--
drivers/gpu/drm/qxl/qxl_display.c | 11 +-
drivers/gpu/drm/qxl/qxl_draw.c | 14 ++-
drivers/gpu/drm/qxl/qxl_drv.h | 11 +-
drivers/gpu/drm/qxl/qxl_object.c| 31 +++---
drivers/gpu/drm/qxl/qxl_object.h| 2 +-
drivers/gpu/drm/qxl/qxl_prime.c | 12 +--
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_gem.c | 7 +-
drivers/gpu/drm/radeon/radeon_prime.c | 20
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 22 ++--
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c | 10 +-
drivers/gpu/drm/udl/udl_modeset.c | 8 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 +-
drivers/gpu/drm/vc4/vc4_bo.c| 6 +-
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 16 ++-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.h | 6 +-
include/drm/drm_gem.h | 5 +-
include/drm/drm_gem_cma_helper.h| 2 +-
include/drm/drm_gem_shmem_helper.h | 4 +-
include/drm/drm_gem_vram_helper.h | 14 +--
47 files changed, 321 insertions(+), 295 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 700637e25ecd..7e6fc3c04add 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -446,6 +446,24 @@ Contact: Ville Syrjälä, Daniel Vetter
Level: Intermediate
+Use struct dma_buf_map throughout codebase
+--
+
+Pointers to shared device memory are stored in struct dma_buf_map. Each
+instance knows whether it refers to system or I/O memory. Most of the DRM-wide
+interface have been converted to use struct dma_buf_map, but implementations
+often still use raw pointers.
+
+The task is to use struct dma_buf_map where it makes sense.
+
+* Memory managers should use struct dma_buf_map for dma-buf-imported buffers.
+* TTM might benefit from using struct dma_buf_map internally.
+* Framebuffer copying and blitting helpers should operate on struct
dma_buf_map.
+
+Contact: Thomas Zimmermann , Christian König, Daniel
Vetter
+
+Level: Intermediate
+
Core refactorings
=
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b9674e..319839b87d37 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -239,6 +239,7 @@ config DRM_RADEON
select FW_LOADER
select DRM_KMS_HELPER
Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
two helpers that convert a GEM object into the TTM BO and forward the call
to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
callbacks.
v4:
* drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
Christian)
Bunch of minor comments below, but over all look very solid to me.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72
include/drm/drm_gem_ttm_helper.h | 6 +++
include/drm/ttm/ttm_bo_api.h | 28 +++
include/linux/dma-buf-map.h | 20
5 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 0e4fb9ba43ad..db4c14d78a30 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
+/**
+ * drm_gem_ttm_vmap() - vmap _buffer_object
+ * @gem: GEM object.
+ * @map: [out] returns the dma-buf mapping.
+ *
+ * Maps a GEM object with ttm_bo_vmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_gem_ttm_vmap(struct drm_gem_object *gem,
+struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ return ttm_bo_vmap(bo, map);
+
+}
+EXPORT_SYMBOL(drm_gem_ttm_vmap);
+
+/**
+ * drm_gem_ttm_vunmap() - vunmap _buffer_object
+ * @gem: GEM object.
+ * @map: dma-buf mapping.
+ *
+ * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ */
+void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
+ struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ ttm_bo_vunmap(bo, map);
+}
+EXPORT_SYMBOL(drm_gem_ttm_vunmap);
+
/**
* drm_gem_ttm_mmap() - mmap _buffer_object
* @gem: GEM object.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index bdee4df1f3f2..80c42c774c7d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = >mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_iomem;
+ unsigned long size = bo->num_pages << PAGE_SHIFT;
Please use uint64_t here and make sure to cast bo->num_pages before
shifting.
We have an unit tests of allocating a 8GB BO and that should work on a
32bit machine as well :)
+
+ if (mem->bus.addr)
+ vaddr_iomem = (void *)(((u8 *)mem->bus.addr));
+ else if (mem->placement & TTM_PL_FLAG_WC)
I've just nuked the TTM_PL_FLAG_WC flag in drm-misc-next. There is a new
mem->bus.caching enum as replacement.
+ vaddr_iomem = ioremap_wc(mem->bus.offset, size);
+ else
+ vaddr_iomem = ioremap(mem->bus.offset, size);
+
+ if (!vaddr_iomem)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
+
+ } else {
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
+ struct ttm_tt *ttm = bo->ttm;
+ pgprot_t prot;
+ void *vaddr;
+
+ BUG_ON(!ttm);
I think we can drop this, populate will just crash badly anyway.
+
+ ret = ttm_tt_populate(bo->bdev, ttm, );
+ if (ret)
+ return ret;
+
+ /*
+* We need to use vmap to get the desired page protection
+* or to make the buffer object look contiguous.
+*/
+ prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
The calling convention has changed on drm-misc-next as well, but should
be trivial to adapt.
Regards,
Christian.
+
Re: [PATCH v4 04/10] drm/exynos: Remove empty exynos_drm_gem_prime_{vmap,vunmap}()
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index e7a6eb96f692..13a35623ac04 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -137,8 +137,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
.free = exynos_drm_gem_free_object,
.get_sg_table = exynos_drm_gem_prime_get_sg_table,
- .vmap = exynos_drm_gem_prime_vmap,
- .vunmap = exynos_drm_gem_prime_vunmap,
.vm_ops = _drm_gem_vm_ops,
};
@@ -471,16 +469,6 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
return _gem->base;
}
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj)
-{
- return NULL;
-}
-
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 74e926abeff0..a23272fb96fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -107,8 +107,6 @@ struct drm_gem_object *
exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj);
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 03/10] drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 -
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 914f0867ff71..9682c26d89bb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -52,7 +52,6 @@ int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct
*vma);
int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device
*dev,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 67d9a2b9ea6a..bbd235473645 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -571,7 +571,6 @@ static const struct drm_gem_object_funcs
etnaviv_gem_object_funcs = {
.unpin = etnaviv_gem_prime_unpin,
.get_sg_table = etnaviv_gem_prime_get_sg_table,
.vmap = etnaviv_gem_prime_vmap,
- .vunmap = etnaviv_gem_prime_vunmap,
.vm_ops = _ops,
};
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 135fbff6fecf..a6d9932a32ae 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -27,11 +27,6 @@ void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj)
return etnaviv_gem_vmap(obj);
}
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* TODO msm_gem_vunmap() */
-}
-
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next pull for 5.10-rc1
Hi all, On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote: > Peilin Ye (1): > drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl() This patch is already in mainline: commit 543e8669ed9bfb30545fd52bc0e047ca4df7fb31 Author: Peilin Ye Date: Tue Jul 28 15:29:24 2020 -0400 drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl() It has been applied to linux-next twice, for unknown reasons. Thank you! Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 02/10] drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo.c | 1 -
include/drm/drm_gem_cma_helper.h | 1 -
3 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 2165633c9b9e..d527485ea0b7 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -537,23 +537,6 @@ void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj)
}
EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vmap);
-/**
- * drm_gem_cma_prime_vunmap - unmap a CMA GEM object from the kernel's virtual
- * address space
- * @obj: GEM object
- * @vaddr: kernel virtual address where the CMA GEM object was mapped
- *
- * This function removes a buffer exported via DRM PRIME from the kernel's
- * virtual address space. This is a no-op because CMA buffers cannot be
- * unmapped from kernel space. Drivers using the CMA helpers should set this
- * as their _gem_object_funcs.vunmap callback.
- */
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vunmap);
-
static const struct drm_gem_object_funcs drm_gem_cma_default_funcs = {
.free = drm_gem_cma_free_object,
.print_info = drm_gem_cma_print_info,
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index f432278173cd..557f0d1e6437 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -387,7 +387,6 @@ static const struct drm_gem_object_funcs
vc4_gem_object_funcs = {
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_prime_get_sg_table,
.vmap = vc4_prime_vmap,
- .vunmap = drm_gem_cma_prime_vunmap,
.vm_ops = _vm_ops,
};
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 2bfa2502607a..a064b0d1c480 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -104,7 +104,6 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj);
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
struct drm_gem_object *
drm_gem_cma_create_object_default_funcs(struct drm_device *dev, size_t size);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/10] drm/vram-helper: Remove invariant parameters from internal kmap function
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3213429f8444..2d5ed30518f1 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -382,32 +382,22 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
-static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
- bool map, bool *is_iomem)
+static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo)
{
int ret;
struct ttm_bo_kmap_obj *kmap = >kmap;
+ bool is_iomem;
if (gbo->kmap_use_count > 0)
goto out;
- if (kmap->virtual || !map)
- goto out;
-
ret = ttm_bo_kmap(>bo, 0, gbo->bo.num_pages, kmap);
if (ret)
return ERR_PTR(ret);
out:
- if (!kmap->virtual) {
- if (is_iomem)
- *is_iomem = false;
- return NULL; /* not mapped; don't increment ref */
- }
++gbo->kmap_use_count;
- if (is_iomem)
- return ttm_kmap_obj_virtual(kmap, is_iomem);
- return kmap->virtual;
+ return ttm_kmap_obj_virtual(kmap, _iomem);
}
static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo)
@@ -452,7 +442,7 @@ void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo)
ret = drm_gem_vram_pin_locked(gbo, 0);
if (ret)
goto err_ttm_bo_unreserve;
- base = drm_gem_vram_kmap_locked(gbo, true, NULL);
+ base = drm_gem_vram_kmap_locked(gbo);
if (IS_ERR(base)) {
ret = PTR_ERR(base);
goto err_drm_gem_vram_unpin_locked;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/stm: dsi: Use dev_ based logging
On 10/13/20 9:56 AM, Yannick Fertre wrote:
> Standardize on the dev_ based logging.
>
> Signed-off-by: Yannick Fertre
> ---
> Changes in v2:
> - restore function dsi_color_from_mipi.
> - reword commit.
>
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 55 ++-
> 1 file changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 164f79ef6269..a5a87c89aa07 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -76,6 +76,7 @@ enum dsi_color {
>
> struct dw_mipi_dsi_stm {
> void __iomem *base;
> + struct device *dev;
> struct clk *pllref_clk;
> struct dw_mipi_dsi *dsi;
> u32 hw_version;
> @@ -110,7 +111,8 @@ static inline void dsi_update_bits(struct dw_mipi_dsi_stm
> *dsi, u32 reg,
> dsi_write(dsi, reg, (dsi_read(dsi, reg) & ~mask) | val);
> }
>
> -static enum dsi_color dsi_color_from_mipi(enum mipi_dsi_pixel_format fmt)
> +static enum dsi_color dsi_color_from_mipi(struct dw_mipi_dsi_stm *dsi,
> + enum mipi_dsi_pixel_format fmt)
> {
> switch (fmt) {
> case MIPI_DSI_FMT_RGB888:
> @@ -122,7 +124,7 @@ static enum dsi_color dsi_color_from_mipi(enum
> mipi_dsi_pixel_format fmt)
> case MIPI_DSI_FMT_RGB565:
> return DSI_RGB565_CONF1;
> default:
> - DRM_DEBUG_DRIVER("MIPI color invalid, so we use rgb888\n");
> + dev_dbg(dsi->dev, "MIPI color invalid, so we use rgb888\n");
> }
> return DSI_RGB888;
> }
> @@ -205,14 +207,14 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
>SLEEP_US, TIMEOUT_US);
> if (ret)
> - DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
> + dev_dbg(dsi->dev, "!TIMEOUT! waiting REGU, let's continue\n");
>
> /* Enable the DSI PLL & wait for its lock */
> dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
> ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
>SLEEP_US, TIMEOUT_US);
> if (ret)
> - DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
> + dev_dbg(dsi->dev, "!TIMEOUT! waiting PLL, let's continue\n");
>
> return 0;
> }
> @@ -221,7 +223,7 @@ static void dw_mipi_dsi_phy_power_on(void *priv_data)
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
>
> - DRM_DEBUG_DRIVER("\n");
> + dev_dbg(dsi->dev, "\n");
>
> /* Enable the DSI wrapper */
> dsi_set(dsi, DSI_WCR, WCR_DSIEN);
> @@ -231,7 +233,7 @@ static void dw_mipi_dsi_phy_power_off(void *priv_data)
> {
> struct dw_mipi_dsi_stm *dsi = priv_data;
>
> - DRM_DEBUG_DRIVER("\n");
> + dev_dbg(dsi->dev, "\n");
>
> /* Disable the DSI wrapper */
> dsi_clear(dsi, DSI_WCR, WCR_DSIEN);
> @@ -267,11 +269,11 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
>
> if (pll_out_khz > dsi->lane_max_kbps) {
> pll_out_khz = dsi->lane_max_kbps;
> - DRM_WARN("Warning max phy mbps is used\n");
> + dev_warn(dsi->dev, "Warning max phy mbps is used\n");
> }
> if (pll_out_khz < dsi->lane_min_kbps) {
> pll_out_khz = dsi->lane_min_kbps;
> - DRM_WARN("Warning min phy mbps is used\n");
> + dev_warn(dsi->dev, "Warning min phy mbps is used\n");
> }
>
> /* Compute best pll parameters */
> @@ -281,7 +283,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
> ret = dsi_pll_get_params(dsi, pll_in_khz, pll_out_khz,
>, , );
> if (ret)
> - DRM_WARN("Warning dsi_pll_get_params(): bad params\n");
> + dev_warn(dsi->dev, "Warning dsi_pll_get_params(): bad
> params\n");
>
> /* Get the adjusted pll out value */
> pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
> @@ -299,12 +301,12 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
> drm_display_mode *mode,
>
> /* Select the color coding */
> dsi_update_bits(dsi, DSI_WCFGR, WCFGR_COLMUX,
> - dsi_color_from_mipi(format) << 1);
> + dsi_color_from_mipi(dsi, format) << 1);
>
> *lane_mbps = pll_out_khz / 1000;
>
> - DRM_DEBUG_DRIVER("pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
> - pll_in_khz, pll_out_khz, *lane_mbps);
> + dev_dbg(dsi->dev, "pll_in %ukHz pll_out %ukHz lane_mbps %uMHz\n",
> pll_in_khz, pll_out_khz,
> + *lane_mbps);
Hi Yannick,
And thank you for your patch.
You forgot to take into account the minor comment from Joe Perches.
Anyway,
Reviewed-by: Philippe Cornu
Thank you
Philippe
[PATCH v4 01/10] drm/vram-helper: Remove invariant parameters from internal kmap function
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3213429f8444..2d5ed30518f1 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -382,32 +382,22 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
-static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
- bool map, bool *is_iomem)
+static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo)
{
int ret;
struct ttm_bo_kmap_obj *kmap = >kmap;
+ bool is_iomem;
if (gbo->kmap_use_count > 0)
goto out;
- if (kmap->virtual || !map)
- goto out;
-
ret = ttm_bo_kmap(>bo, 0, gbo->bo.num_pages, kmap);
if (ret)
return ERR_PTR(ret);
out:
- if (!kmap->virtual) {
- if (is_iomem)
- *is_iomem = false;
- return NULL; /* not mapped; don't increment ref */
- }
++gbo->kmap_use_count;
- if (is_iomem)
- return ttm_kmap_obj_virtual(kmap, is_iomem);
- return kmap->virtual;
+ return ttm_kmap_obj_virtual(kmap, _iomem);
}
static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo)
@@ -452,7 +442,7 @@ void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo)
ret = drm_gem_vram_pin_locked(gbo, 0);
if (ret)
goto err_ttm_bo_unreserve;
- base = drm_gem_vram_kmap_locked(gbo, true, NULL);
+ base = drm_gem_vram_kmap_locked(gbo);
if (IS_ERR(base)) {
ret = PTR_ERR(base);
goto err_drm_gem_vram_unpin_locked;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/10] drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 5 -
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 914f0867ff71..9682c26d89bb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -52,7 +52,6 @@ int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct
*vma);
int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
struct drm_gem_object *etnaviv_gem_prime_import_sg_table(struct drm_device
*dev,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 67d9a2b9ea6a..bbd235473645 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -571,7 +571,6 @@ static const struct drm_gem_object_funcs
etnaviv_gem_object_funcs = {
.unpin = etnaviv_gem_prime_unpin,
.get_sg_table = etnaviv_gem_prime_get_sg_table,
.vmap = etnaviv_gem_prime_vmap,
- .vunmap = etnaviv_gem_prime_vunmap,
.vm_ops = _ops,
};
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 135fbff6fecf..a6d9932a32ae 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -27,11 +27,6 @@ void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj)
return etnaviv_gem_vmap(obj);
}
-void etnaviv_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* TODO msm_gem_vunmap() */
-}
-
int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(),
two helpers that convert a GEM object into the TTM BO and forward the call
to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object
callbacks.
v4:
* drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel,
Christian)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72
include/drm/drm_gem_ttm_helper.h | 6 +++
include/drm/ttm/ttm_bo_api.h | 28 +++
include/linux/dma-buf-map.h | 20
5 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
index 0e4fb9ba43ad..db4c14d78a30 100644
--- a/drivers/gpu/drm/drm_gem_ttm_helper.c
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned
int indent,
}
EXPORT_SYMBOL(drm_gem_ttm_print_info);
+/**
+ * drm_gem_ttm_vmap() - vmap _buffer_object
+ * @gem: GEM object.
+ * @map: [out] returns the dma-buf mapping.
+ *
+ * Maps a GEM object with ttm_bo_vmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int drm_gem_ttm_vmap(struct drm_gem_object *gem,
+struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ return ttm_bo_vmap(bo, map);
+
+}
+EXPORT_SYMBOL(drm_gem_ttm_vmap);
+
+/**
+ * drm_gem_ttm_vunmap() - vunmap _buffer_object
+ * @gem: GEM object.
+ * @map: dma-buf mapping.
+ *
+ * Unmaps a GEM object with ttm_bo_vunmap(). This function can be used as
+ * _gem_object_funcs.vmap callback.
+ */
+void drm_gem_ttm_vunmap(struct drm_gem_object *gem,
+ struct dma_buf_map *map)
+{
+ struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ ttm_bo_vunmap(bo, map);
+}
+EXPORT_SYMBOL(drm_gem_ttm_vunmap);
+
/**
* drm_gem_ttm_mmap() - mmap _buffer_object
* @gem: GEM object.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index bdee4df1f3f2..80c42c774c7d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -526,6 +527,77 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = >mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_iomem;
+ unsigned long size = bo->num_pages << PAGE_SHIFT;
+
+ if (mem->bus.addr)
+ vaddr_iomem = (void *)(((u8 *)mem->bus.addr));
+ else if (mem->placement & TTM_PL_FLAG_WC)
+ vaddr_iomem = ioremap_wc(mem->bus.offset, size);
+ else
+ vaddr_iomem = ioremap(mem->bus.offset, size);
+
+ if (!vaddr_iomem)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr_iomem(map, vaddr_iomem);
+
+ } else {
+ struct ttm_operation_ctx ctx = {
+ .interruptible = false,
+ .no_wait_gpu = false
+ };
+ struct ttm_tt *ttm = bo->ttm;
+ pgprot_t prot;
+ void *vaddr;
+
+ BUG_ON(!ttm);
+
+ ret = ttm_tt_populate(bo->bdev, ttm, );
+ if (ret)
+ return ret;
+
+ /*
+* We need to use vmap to get the desired page protection
+* or to make the buffer object look contiguous.
+*/
+ prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
+ vaddr = vmap(ttm->pages, bo->num_pages, 0, prot);
+ if (!vaddr)
+ return -ENOMEM;
+
+ dma_buf_map_set_vaddr(map, vaddr);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vmap);
+
+void ttm_bo_vunmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ if (dma_buf_map_is_null(map))
+ return;
+
+ if (map->is_iomem)
+ iounmap(map->vaddr_iomem);
+ else
+ vunmap(map->vaddr);
+ dma_buf_map_clear(map);
+
+ ttm_mem_io_free(bo->bdev, >mem);
+}
+EXPORT_SYMBOL(ttm_bo_vunmap);
+
static int
[PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions.
For drivers that employ a shadow buffer, fbdev's blit function retrieves
the framebuffer address as struct dma_buf_map, and uses dma_buf_map
interfaces to access the buffer.
The bochs driver on sparc64 uses a workaround to flag the framebuffer as
I/O memory and avoid a HW exception. With the introduction of struct
dma_buf_map, this is not required any longer. The patch removes the rsp
code from both, bochs and fbdev.
v4:
* move dma_buf_map changes into separate patch (Daniel)
* TODO list: comment on fbdev updates (Daniel)
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst| 19 ++-
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
drivers/gpu/drm/drm_fb_helper.c | 217 --
include/drm/drm_mode_config.h | 12 --
4 files changed, 220 insertions(+), 29 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 7e6fc3c04add..638b7f704339 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
-atomic modesetting and GEM vmap support. Current generic fbdev emulation
-expects the framebuffer in system memory (or system-like memory).
+atomic modesetting and GEM vmap support. Historically, generic fbdev emulation
+expected the framebuffer in system memory or system-like memory. By employing
+struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
+as well.
Contact: Maintainer of the driver you plan to convert
Level: Intermediate
+Reimplement functions in drm_fbdev_fb_ops without fbdev
+---
+
+A number of callback functions in drm_fbdev_fb_ops could benefit from
+being rewritten without dependencies on the fbdev module. Some of the
+helpers could further benefit from using struct dma_buf_map instead of
+raw pointers.
+
+Contact: Thomas Zimmermann , Daniel Vetter
+
+Level: Advanced
+
+
drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
-
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 13d0d04c4457..853081d186d5 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs->dev->mode_config.preferred_depth = 24;
bochs->dev->mode_config.prefer_shadow = 0;
bochs->dev->mode_config.prefer_shadow_fbdev = 1;
- bochs->dev->mode_config.fbdev_use_iomem = true;
bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
bochs->dev->mode_config.funcs = _mode_funcs;
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6212cd7cde1d..462b0c130ebb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct
work_struct *work)
}
static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
- struct drm_clip_rect *clip)
+ struct drm_clip_rect *clip,
+ struct dma_buf_map *dst)
{
struct drm_framebuffer *fb = fb_helper->fb;
unsigned int cpp = fb->format->cpp[0];
size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
void *src = fb_helper->fbdev->screen_buffer + offset;
- void *dst = fb_helper->buffer->map.vaddr + offset;
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y;
- for (y = clip->y1; y < clip->y2; y++) {
- if (!fb_helper->dev->mode_config.fbdev_use_iomem)
- memcpy(dst, src, len);
- else
- memcpy_toio((void __iomem *)dst, src, len);
+ dma_buf_map_incr(dst, offset); /* go to first pixel within clip rect */
+ for (y = clip->y1; y < clip->y2; y++) {
+ dma_buf_map_memcpy_to(dst, src, len);
+ dma_buf_map_incr(dst, fb->pitches[0]);
src += fb->pitches[0];
- dst += fb->pitches[0];
}
}
@@ -417,8 +415,9 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
ret = drm_client_buffer_vmap(helper->buffer, );
if (ret)
return;
- drm_fb_helper_dirty_blit_real(helper, _copy);
+
[PATCH v4 02/10] drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo.c | 1 -
include/drm/drm_gem_cma_helper.h | 1 -
3 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 2165633c9b9e..d527485ea0b7 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -537,23 +537,6 @@ void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj)
}
EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vmap);
-/**
- * drm_gem_cma_prime_vunmap - unmap a CMA GEM object from the kernel's virtual
- * address space
- * @obj: GEM object
- * @vaddr: kernel virtual address where the CMA GEM object was mapped
- *
- * This function removes a buffer exported via DRM PRIME from the kernel's
- * virtual address space. This is a no-op because CMA buffers cannot be
- * unmapped from kernel space. Drivers using the CMA helpers should set this
- * as their _gem_object_funcs.vunmap callback.
- */
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-EXPORT_SYMBOL_GPL(drm_gem_cma_prime_vunmap);
-
static const struct drm_gem_object_funcs drm_gem_cma_default_funcs = {
.free = drm_gem_cma_free_object,
.print_info = drm_gem_cma_print_info,
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index f432278173cd..557f0d1e6437 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -387,7 +387,6 @@ static const struct drm_gem_object_funcs
vc4_gem_object_funcs = {
.export = vc4_prime_export,
.get_sg_table = drm_gem_cma_prime_get_sg_table,
.vmap = vc4_prime_vmap,
- .vunmap = drm_gem_cma_prime_vunmap,
.vm_ops = _vm_ops,
};
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 2bfa2502607a..a064b0d1c480 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -104,7 +104,6 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
void *drm_gem_cma_prime_vmap(struct drm_gem_object *obj);
-void drm_gem_cma_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
struct drm_gem_object *
drm_gem_cma_create_object_default_funcs(struct drm_device *dev, size_t size);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use them correctly. This enables I/O-memory operations on all framebuffers
that require and support them.
Patches #1 to #4 prepare VRAM helpers and drivers.
Next is the update of the GEM vmap functions. Patch #5 adds vmap and vunmap
that is usable with TTM-based GEM drivers, and patch #6 updates GEM's
vmap/vunmap callback to forward instances of type struct dma_buf_map. While
the patch touches many files throughout the DRM modules, the applied changes
are mostly trivial interface fixes. Several TTM-based GEM drivers now use
the new vmap code. Patch #7 updates GEM's internal vmap/vunmap functions to
forward struct dma_buf_map.
With struct dma_buf_map propagated through the layers, patches #9 and #10
convert DRM clients and generic fbdev emulation to use it. Updating the
fbdev framebuffer will select the correct functions, either for system or
I/O memory.
v4:
* provide TTM vmap/vunmap plus GEM helpers and convert drivers
over (Christian, Daniel)
* remove several empty functions
* more TODOs and documentation (Daniel)
v3:
* recreate the whole patchset on top of struct dma_buf_map
v2:
* RFC patchset
Thomas Zimmermann (10):
drm/vram-helper: Remove invariant parameters from internal kmap
function
drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap()
drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap()
drm/exynos: Remove empty exynos_drm_gem_prime_{vmap,vunmap}()
drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers
drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM
backends
drm/gem: Update internal GEM vmap/vunmap interfaces to use struct
dma_buf_map
drm/gem: Store client buffer mappings as struct dma_buf_map
dma-buf-map: Add memcpy and pointer-increment interfaces
drm/fb_helper: Support framebuffers in I/O memory
Documentation/gpu/todo.rst | 37 ++-
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/ast/ast_cursor.c| 27 ++-
drivers/gpu/drm/ast/ast_drv.h | 7 +-
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
drivers/gpu/drm/drm_client.c| 38 ++--
drivers/gpu/drm/drm_fb_helper.c | 238 ++--
drivers/gpu/drm/drm_gem.c | 29 ++-
drivers/gpu/drm/drm_gem_cma_helper.c| 27 +--
drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++--
drivers/gpu/drm/drm_gem_ttm_helper.c| 38
drivers/gpu/drm/drm_gem_vram_helper.c | 117 +-
drivers/gpu/drm/drm_internal.h | 5 +-
drivers/gpu/drm/drm_prime.c | 14 +-
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 3 +-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 12 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12 -
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 -
drivers/gpu/drm/lima/lima_gem.c | 6 +-
drivers/gpu/drm/lima/lima_sched.c | 11 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 -
drivers/gpu/drm/nouveau/nouveau_prime.c | 20 --
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 14 +-
drivers/gpu/drm/qxl/qxl_display.c | 11 +-
drivers/gpu/drm/qxl/qxl_draw.c | 14 +-
drivers/gpu/drm/qxl/qxl_drv.h | 11 +-
drivers/gpu/drm/qxl/qxl_object.c| 31 ++-
drivers/gpu/drm/qxl/qxl_object.h| 2 +-
drivers/gpu/drm/qxl/qxl_prime.c | 12 +-
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_gem.c | 7 +-
drivers/gpu/drm/radeon/radeon_prime.c | 20 --
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 22 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c | 10 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 72 ++
drivers/gpu/drm/udl/udl_modeset.c | 8 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 +-
drivers/gpu/drm/vc4/vc4_bo.c| 7 +-
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c
[PATCH v4 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modified with
dma_buf_map interfaces.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_client.c| 34 +++--
drivers/gpu/drm/drm_fb_helper.c | 23 +-
include/drm/drm_client.h| 7 ---
3 files changed, 38 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index ac0082bed966..fe573acf1067 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -235,7 +235,7 @@ static void drm_client_buffer_delete(struct
drm_client_buffer *buffer)
{
struct drm_device *dev = buffer->client->dev;
- drm_gem_vunmap(buffer->gem, buffer->vaddr);
+ drm_gem_vunmap(buffer->gem, >map);
if (buffer->gem)
drm_gem_object_put(buffer->gem);
@@ -291,25 +291,31 @@ drm_client_buffer_create(struct drm_client_dev *client,
u32 width, u32 height, u
/**
* drm_client_buffer_vmap - Map DRM client buffer into address space
* @buffer: DRM client buffer
+ * @map_copy: Returns the mapped memory's address
*
* This function maps a client buffer into kernel address space. If the
- * buffer is already mapped, it returns the mapping's address.
+ * buffer is already mapped, it returns the existing mapping's address.
*
* Client buffer mappings are not ref'counted. Each call to
* drm_client_buffer_vmap() should be followed by a call to
* drm_client_buffer_vunmap(); or the client buffer should be mapped
* throughout its lifetime.
*
+ * The returned address is a copy of the internal value. In contrast to
+ * other vmap interfaces, you don't need it for the client's vunmap
+ * function. So you can modify it at will during blit and draw operations.
+ *
* Returns:
- * The mapped memory's address
+ * 0 on success, or a negative errno code otherwise.
*/
-void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
+int
+drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct dma_buf_map
*map_copy)
{
- struct dma_buf_map map;
+ struct dma_buf_map *map = >map;
int ret;
- if (buffer->vaddr)
- return buffer->vaddr;
+ if (dma_buf_map_is_set(map))
+ goto out;
/*
* FIXME: The dependency on GEM here isn't required, we could
@@ -319,13 +325,14 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
*buffer)
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- ret = drm_gem_vmap(buffer->gem, );
+ ret = drm_gem_vmap(buffer->gem, map);
if (ret)
- return ERR_PTR(ret);
+ return ret;
- buffer->vaddr = map.vaddr;
+out:
+ *map_copy = *map;
- return map.vaddr;
+ return 0;
}
EXPORT_SYMBOL(drm_client_buffer_vmap);
@@ -339,10 +346,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
*/
void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
{
- struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->vaddr);
+ struct dma_buf_map *map = >map;
- drm_gem_vunmap(buffer->gem, );
- buffer->vaddr = NULL;
+ drm_gem_vunmap(buffer->gem, map);
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c2f72bb6afb1..6212cd7cde1d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -378,7 +378,7 @@ static void drm_fb_helper_dirty_blit_real(struct
drm_fb_helper *fb_helper,
unsigned int cpp = fb->format->cpp[0];
size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
void *src = fb_helper->fbdev->screen_buffer + offset;
- void *dst = fb_helper->buffer->vaddr + offset;
+ void *dst = fb_helper->buffer->map.vaddr + offset;
size_t len = (clip->x2 - clip->x1) * cpp;
unsigned int y;
@@ -400,7 +400,8 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
struct drm_clip_rect *clip = >dirty_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
- void *vaddr;
+ struct dma_buf_map map;
+ int ret;
spin_lock_irqsave(>dirty_lock, flags);
clip_copy = *clip;
@@ -413,8 +414,8 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
/* Generic fbdev uses a shadow buffer */
if (helper->buffer) {
- vaddr = drm_client_buffer_vmap(helper->buffer);
- if (IS_ERR(vaddr))
+ ret = drm_client_buffer_vmap(helper->buffer, );
+ if
[PATCH v4 07/10] drm/gem: Update internal GEM vmap/vunmap interfaces to use struct dma_buf_map
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drivers/gpu/drm/drm_internal.h | 5 +++--
drivers/gpu/drm/drm_prime.c| 14 --
4 files changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 495f47d23d87..ac0082bed966 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -3,6 +3,7 @@
* Copyright 2018 Noralf Trønnes
*/
+#include
#include
#include
#include
@@ -304,7 +305,8 @@ drm_client_buffer_create(struct drm_client_dev *client, u32
width, u32 height, u
*/
void *drm_client_buffer_vmap(struct drm_client_buffer *buffer)
{
- void *vaddr;
+ struct dma_buf_map map;
+ int ret;
if (buffer->vaddr)
return buffer->vaddr;
@@ -317,13 +319,13 @@ void *drm_client_buffer_vmap(struct drm_client_buffer
*buffer)
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- vaddr = drm_gem_vmap(buffer->gem);
- if (IS_ERR(vaddr))
- return vaddr;
+ ret = drm_gem_vmap(buffer->gem, );
+ if (ret)
+ return ERR_PTR(ret);
- buffer->vaddr = vaddr;
+ buffer->vaddr = map.vaddr;
- return vaddr;
+ return map.vaddr;
}
EXPORT_SYMBOL(drm_client_buffer_vmap);
@@ -337,7 +339,9 @@ EXPORT_SYMBOL(drm_client_buffer_vmap);
*/
void drm_client_buffer_vunmap(struct drm_client_buffer *buffer)
{
- drm_gem_vunmap(buffer->gem, buffer->vaddr);
+ struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(buffer->vaddr);
+
+ drm_gem_vunmap(buffer->gem, );
buffer->vaddr = NULL;
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a89ad4570e3c..4d5fff4bd821 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1206,32 +1206,32 @@ void drm_gem_unpin(struct drm_gem_object *obj)
obj->funcs->unpin(obj);
}
-void *drm_gem_vmap(struct drm_gem_object *obj)
+int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
- struct dma_buf_map map;
int ret;
if (!obj->funcs->vmap)
- return ERR_PTR(-EOPNOTSUPP);
+ return -EOPNOTSUPP;
- ret = obj->funcs->vmap(obj, );
+ ret = obj->funcs->vmap(obj, map);
if (ret)
- return ERR_PTR(ret);
- else if (dma_buf_map_is_null())
- return ERR_PTR(-ENOMEM);
+ return ret;
+ else if (dma_buf_map_is_null(map))
+ return -ENOMEM;
- return map.vaddr;
+ return 0;
}
-void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr)
+void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map)
{
- struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(vaddr);
-
- if (!vaddr)
+ if (dma_buf_map_is_null(map))
return;
if (obj->funcs->vunmap)
- obj->funcs->vunmap(obj, );
+ obj->funcs->vunmap(obj, map);
+
+ /* Always set the mapping to NULL. Callers may rely on this. */
+ dma_buf_map_clear(map);
}
/**
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index b65865c630b0..58832d75a9bd 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -33,6 +33,7 @@
struct dentry;
struct dma_buf;
+struct dma_buf_map;
struct drm_connector;
struct drm_crtc;
struct drm_framebuffer;
@@ -187,8 +188,8 @@ void drm_gem_print_info(struct drm_printer *p, unsigned int
indent,
int drm_gem_pin(struct drm_gem_object *obj);
void drm_gem_unpin(struct drm_gem_object *obj);
-void *drm_gem_vmap(struct drm_gem_object *obj);
-void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
+int drm_gem_vmap(struct drm_gem_object *obj, struct dma_buf_map *map);
+void drm_gem_vunmap(struct drm_gem_object *obj, struct dma_buf_map *map);
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 89e2a2496734..cb8fbeeb731b 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -667,21 +667,15 @@ EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
*
* Sets up a kernel virtual mapping. This can be used as the _buf_ops.vmap
* callback. Calls into _gem_object_funcs.vmap for device specific
handling.
+ * The kernel virtual address is returned in map.
*
- * Returns the kernel virtual address or NULL on failure.
+ * Returns 0 on success or a negative errno code otherwise.
*/
int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map)
{
struct drm_gem_object *obj = dma_buf->priv;
-
[PATCH v4 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap()
et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of
implementing their own vmap callbacks.
v4:
* use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian)
* fix a trailing { in drm_gem_vmap()
* remove several empty functions instead of converting them (Daniel)
* comment uses of raw pointers with a TODO (Daniel)
* TODO list: convert more helpers to use struct dma_buf_map
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 18
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/ast/ast_cursor.c| 27 +++--
drivers/gpu/drm/ast/ast_drv.h | 7 +-
drivers/gpu/drm/drm_gem.c | 23 +++--
drivers/gpu/drm/drm_gem_cma_helper.c| 10 +-
drivers/gpu/drm/drm_gem_shmem_helper.c | 48 +
drivers/gpu/drm/drm_gem_vram_helper.c | 107 ++--
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 9 +-
drivers/gpu/drm/lima/lima_gem.c | 6 +-
drivers/gpu/drm/lima/lima_sched.c | 11 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 10 +-
drivers/gpu/drm/nouveau/Kconfig | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 -
drivers/gpu/drm/nouveau/nouveau_prime.c | 20
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 14 +--
drivers/gpu/drm/qxl/qxl_display.c | 11 +-
drivers/gpu/drm/qxl/qxl_draw.c | 14 ++-
drivers/gpu/drm/qxl/qxl_drv.h | 11 +-
drivers/gpu/drm/qxl/qxl_object.c| 31 +++---
drivers/gpu/drm/qxl/qxl_object.h| 2 +-
drivers/gpu/drm/qxl/qxl_prime.c | 12 +--
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_gem.c | 7 +-
drivers/gpu/drm/radeon/radeon_prime.c | 20
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 22 ++--
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 4 +-
drivers/gpu/drm/tiny/cirrus.c | 10 +-
drivers/gpu/drm/tiny/gm12u320.c | 10 +-
drivers/gpu/drm/udl/udl_modeset.c | 8 +-
drivers/gpu/drm/vboxvideo/vbox_mode.c | 11 +-
drivers/gpu/drm/vc4/vc4_bo.c| 6 +-
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 16 ++-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 ++--
drivers/gpu/drm/xen/xen_drm_front_gem.h | 6 +-
include/drm/drm_gem.h | 5 +-
include/drm/drm_gem_cma_helper.h| 2 +-
include/drm/drm_gem_shmem_helper.h | 4 +-
include/drm/drm_gem_vram_helper.h | 14 +--
47 files changed, 321 insertions(+), 295 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 700637e25ecd..7e6fc3c04add 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -446,6 +446,24 @@ Contact: Ville Syrjälä, Daniel Vetter
Level: Intermediate
+Use struct dma_buf_map throughout codebase
+--
+
+Pointers to shared device memory are stored in struct dma_buf_map. Each
+instance knows whether it refers to system or I/O memory. Most of the DRM-wide
+interface have been converted to use struct dma_buf_map, but implementations
+often still use raw pointers.
+
+The task is to use struct dma_buf_map where it makes sense.
+
+* Memory managers should use struct dma_buf_map for dma-buf-imported buffers.
+* TTM might benefit from using struct dma_buf_map internally.
+* Framebuffer copying and blitting helpers should operate on struct
dma_buf_map.
+
+Contact: Thomas Zimmermann , Christian König, Daniel
Vetter
+
+Level: Intermediate
+
Core refactorings
=
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b9674e..319839b87d37 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -239,6 +239,7 @@ config DRM_RADEON
select FW_LOADER
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_TTM_HELPER
select POWER_SUPPLY
select HWMON
select BACKLIGHT_CLASS_DEVICE
@@ -259,6 +260,7 @@ config DRM_AMDGPU
select DRM_KMS_HELPER
[PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
Signed-off-by: Thomas Zimmermann
---
include/linux/dma-buf-map.h | 72 +++--
1 file changed, 62 insertions(+), 10 deletions(-)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 2e8bbecb5091..6ca0f304dda2 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -32,6 +32,14 @@
* accessing the buffer. Use the returned instance and the helper functions
* to access the buffer's memory in the correct way.
*
+ * The type :c:type:`struct dma_buf_map ` and its helpers are
+ * actually independent from the dma-buf infrastructure. When sharing buffers
+ * among devices, drivers have to know the location of the memory to access
+ * the buffers in a safe way. :c:type:`struct dma_buf_map `
+ * solves this problem for dma-buf and its users. If other drivers or
+ * sub-systems require similar functionality, the type could be generalized
+ * and moved to a more prominent header file.
+ *
* Open-coding access to :c:type:`struct dma_buf_map ` is
* considered bad style. Rather then accessing its fields directly, use one
* of the provided helper functions, or implement your own. For example,
@@ -51,6 +59,14 @@
*
* dma_buf_map_set_vaddr_iomem( 0xdeadbeaf);
*
+ * Instances of struct dma_buf_map do not have to be cleaned up, but
+ * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
+ * always refer to system memory.
+ *
+ * .. code-block:: c
+ *
+ * dma_buf_map_clear();
+ *
* Test if a mapping is valid with either dma_buf_map_is_set() or
* dma_buf_map_is_null().
*
@@ -73,17 +89,19 @@
* if (dma_buf_map_is_equal(_map, _map))
* // always false
*
- * Instances of struct dma_buf_map do not have to be cleaned up, but
- * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
- * always refer to system memory.
+ * A set up instance of struct dma_buf_map can be used to access or manipulate
+ * the buffer memory. Depending on the location of the memory, the provided
+ * helpers will pick the correct operations. Data can be copied into the memory
+ * with dma_buf_map_memcpy_to(). The address can be manipulated with
+ * dma_buf_map_incr().
*
- * The type :c:type:`struct dma_buf_map ` and its helpers are
- * actually independent from the dma-buf infrastructure. When sharing buffers
- * among devices, drivers have to know the location of the memory to access
- * the buffers in a safe way. :c:type:`struct dma_buf_map `
- * solves this problem for dma-buf and its users. If other drivers or
- * sub-systems require similar functionality, the type could be generalized
- * and moved to a more prominent header file.
+ * .. code-block:: c
+ *
+ * const void *src = ...; // source buffer
+ * size_t len = ...; // length of src
+ *
+ * dma_buf_map_memcpy_to(, src, len);
+ * dma_buf_map_incr(, len); // go to first byte after the memcpy
*/
/**
@@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
*map)
}
}
+/**
+ * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
+ * @dst: The dma-buf mapping structure
+ * @src: The source buffer
+ * @len: The number of byte in src
+ *
+ * Copies data into a dma-buf mapping. The source buffer is in system
+ * memory. Depending on the buffer's location, the helper picks the correct
+ * method of accessing the memory.
+ */
+static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
*src, size_t len)
+{
+ if (dst->is_iomem)
+ memcpy_toio(dst->vaddr_iomem, src, len);
+ else
+ memcpy(dst->vaddr, src, len);
+}
+
+/**
+ * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
+ * @map: The dma-buf mapping structure
+ * @incr: The number of bytes to increment
+ *
+ * Increments the address stored in a dma-buf mapping. Depending on the
+ * buffer's location, the correct value will be updated.
+ */
+static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
+{
+ if (map->is_iomem)
+ map->vaddr_iomem += incr;
+ else
+ map->vaddr += incr;
+}
+
#endif /* __DMA_BUF_MAP_H__ */
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/10] drm/exynos: Remove empty exynos_drm_gem_prime_{vmap, vunmap}()
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index e7a6eb96f692..13a35623ac04 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -137,8 +137,6 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs = {
.free = exynos_drm_gem_free_object,
.get_sg_table = exynos_drm_gem_prime_get_sg_table,
- .vmap = exynos_drm_gem_prime_vmap,
- .vunmap = exynos_drm_gem_prime_vunmap,
.vm_ops = _drm_gem_vm_ops,
};
@@ -471,16 +469,6 @@ exynos_drm_gem_prime_import_sg_table(struct drm_device
*dev,
return _gem->base;
}
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj)
-{
- return NULL;
-}
-
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
-{
- /* Nothing to do */
-}
-
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 74e926abeff0..a23272fb96fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -107,8 +107,6 @@ struct drm_gem_object *
exynos_drm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach,
struct sg_table *sgt);
-void *exynos_drm_gem_prime_vmap(struct drm_gem_object *obj);
-void exynos_drm_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
int exynos_drm_gem_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
This patch adds a helper function to read the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new structure to store these caps,
which can then be used to get the PPS parameters for PCON-HDMI2.1 sink
pair. Which inturn will be used to take a call to override the existing
PPS-metadata, by either writing the entire new PPS metadata, or by
writing only the PPS override parameters.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 16 ++
drivers/gpu/drm/i915/display/intel_dp.c | 178 ++
2 files changed, 194 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 6c69922313d6..23282695a47f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1292,6 +1292,21 @@ struct intel_dp_pcon_frl {
int trained_rate_gbps;
};
+struct intel_dp_pcon_dsc {
+ bool enc_support;
+ bool pps_override_support;
+ bool blk_prediction_support;
+ u8 version_major;
+ u8 version_minor;
+ u8 color_fmt_mask;
+ u8 color_depth_mask;
+ u8 max_slices;;
+ u8 max_slice_width;
+ u8 line_buf_bit_depth;
+ u8 bpp_precision_incr;
+ int rc_buf_size;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1415,6 +1430,7 @@ struct intel_dp {
bool hobl_active;
struct intel_dp_pcon_frl frl;
+ struct intel_dp_pcon_dsc pcon_dsc;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index e6c4cb844e37..b4f8abaea607 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3882,6 +3882,182 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
+{
+ u8 buf;
+ u8 rc_buf_blk_size;
+ u8 max_slices = 0;
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct intel_dp_pcon_dsc *pcon_dsc = _dp->pcon_dsc;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_ENCODER, ) < 0) {
+ drm_err(>drm, "Failed to read DP_PCON_DSC_ENCODER\n");
+ return;
+ }
+ pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED;
+ pcon_dsc->pps_override_support = buf & DP_PCON_DSC_PPS_ENC_OVERRIDE;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_VERSION, ) < 0) {
+ drm_err(>drm, "Failed to read DP_PCON_DSC_VERSION\n");
+ return;
+ }
+ pcon_dsc->version_major = (buf & DP_PCON_DSC_MAJOR_MASK) >>
+ DP_PCON_DSC_MAJOR_SHIFT;
+ pcon_dsc->version_minor = (buf & DP_PCON_DSC_MINOR_MASK) >>
+ DP_PCON_DSC_MINOR_SHIFT;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_RC_BUF_BLK_INFO,
) < 0) {
+ drm_err(>drm, "Failed to read
DP_PCON_DSC_RC_BUF_BLK_INFO\n");
+ return;
+ }
+
+ switch (buf & DP_PCON_DSC_RC_BUF_BLK_SIZE) {
+ case DP_PCON_DSC_RC_BUF_BLK_1KB :
+ rc_buf_blk_size = 1;
+ break;
+ case DP_PCON_DSC_RC_BUF_BLK_4KB :
+ rc_buf_blk_size = 4;
+ break;
+ case DP_PCON_DSC_RC_BUF_BLK_16KB :
+ rc_buf_blk_size = 16;
+ break;
+ case DP_PCON_DSC_RC_BUF_BLK_64KB :
+ rc_buf_blk_size = 64;
+ break;
+ default :
+ rc_buf_blk_size = 0;
+ }
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_RC_BUF_SIZE, ) <
0) {
+ drm_err(>drm, "Failed to read DP_PCON_DSC_RC_BUF_SIZE\n");
+ return;
+ }
+ /* storing rc_buf_size in bytes */
+ pcon_dsc->rc_buf_size = (buf + 1) * rc_buf_blk_size * 1024;
+
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_SLICE_CAP_2, ) <
0) {
+ drm_err(>drm, "Failed to read DP_PCON_DSC_SLICE_CAP_2\n");
+ return;
+ }
+ if (buf & DP_PCON_DSC_24_PER_DSC_ENC)
+ max_slices = 24;
+ else if (buf & DP_PCON_DSC_20_PER_DSC_ENC)
+ max_slices = 20;
+ else if (buf & DP_PCON_DSC_16_PER_DSC_ENC)
+ max_slices = 16;
+
+ if (max_slices == 0) {
+ if (drm_dp_dpcd_readb(_dp->aux, DP_PCON_DSC_SLICE_CAP_1,
+ ) < 0) {
+ drm_err(>drm, "Failed to read
DP_PCON_DSC_SLICE_CAP_2\n");
+ return;
+ }
+
+ if (buf & DP_PCON_DSC_12_PER_DSC_ENC)
+ max_slices = 12;
+ else if (buf & DP_PCON_DSC_10_PER_DSC_ENC)
+ max_slices = 10;
+ else if (buf & DP_PCON_DSC_8_PER_DSC_ENC)
+ max_slices = 8;
+
[RFC 12/13] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 171 ++
drivers/gpu/drm/i915/display/intel_hdmi.h | 7 +
2 files changed, 178 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index f90838bc74fb..3c1df2c78438 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3438,3 +3438,174 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector);
}
+
+int intel_hdmi_dsc_get_slice_height(int vactive)
+{
+ int slice_height;
+
+ /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+ for (slice_height = 96; slice_height <= vactive; slice_height+=2)
+ if (vactive % slice_height == 0)
+ return slice_height;
+
+ return 0;
+}
+
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput)
+{
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE 272
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0 34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1 40
+#define MAX_HDMI_SLICE_WIDTH 2720
+ int kslice_adjust;
+ int adjusted_clk_khz;
+ int min_slices;
+ int target_slices;
+ int max_throughput; //max clock freq. in khz per slice
+ int max_slice_width;
+ int slice_width;
+ int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+ /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ kslice_adjust = 5;
+ else
+ kslice_adjust = 10;
+
+ adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+ if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+ else
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
+
+ /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+ max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+ min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+ max_slice_width = min(MAX_HDMI_SLICE_WIDTH, src_max_slice_width);
+
+ /*
+* Keep on increasing the num of slices/line, starting from min_slices
+* per line till we get such a number, for which the slice_width is
+* just less than max_slice_width. The slices/line selected should be
+* less than or equal to the max horizontal slices that the combination
+* of PCON encoder and HDMI decoder can support.
+*/
+ slice_width = max_slice_width;
+
+ while (slice_width >= max_slice_width) {
+ if (min_slices <= 1 && src_max_slices >= 1 && hdmi_max_slices
>= 1)
+ target_slices = 1;
+ else if (min_slices <= 2 && src_max_slices >= 2 &&
hdmi_max_slices >= 2)
+ target_slices = 2;
+ else if (min_slices <= 4 && src_max_slices >= 4 &&
hdmi_max_slices >= 4)
+ target_slices = 4;
+ else if (min_slices <= 8 && src_max_slices >= 8 &&
hdmi_max_slices >= 8)
+ target_slices = 8;
+ else if (min_slices <= 12 && src_max_slices >= 12 &&
hdmi_max_slices >= 12)
+ target_slices = 12;
+ else if (min_slices <= 16 && src_max_slices >= 16 &&
hdmi_max_slices >= 16)
+ target_slices = 16;
+ else
+ return 0;
+
+ slice_width =
DIV_ROUND_UP(crtc_state->hw.adjusted_mode.hdisplay, target_slices);
+ }
+
+ return target_slices;
+}
+
+int
+intel_hdmi_dsc_get_bpp(int src_fractional_bpp, int slice_width, int num_slices,
+ int
[RFC 09/13] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 19 +++
include/drm/drm_connector.h | 32
2 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8afb136e73f5..feee19657a7a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4889,10 +4889,29 @@ static void drm_parse_hdmi_21_additional_fields(struct
drm_connector *connector,
{
struct drm_hdmi_info *hdmi = >display_info.hdmi;
u8 max_frl_rate;
+ u8 dsc_max_frl_rate;
max_frl_rate = db[7] & DRM_EDID_MAX_FRL_RATE_MASK;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
+
+ hdmi->dsc_1p2 = db[11] & DRM_EDID_DSC_1P2;
+hdmi->dsc_native_420 = db[11] & DRM_EDID_DSC_NATIVE_420;
+ hdmi->dsc_all_bpp = db[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (db[11] & DRM_EDID_DSC_16BPC)
+ hdmi->dsc_bpc_supported = 16;
+ else if (db[11] & DRM_EDID_DSC_12BPC)
+ hdmi->dsc_bpc_supported = 12;
+ else if (db[11] & DRM_EDID_DSC_10BPC)
+ hdmi->dsc_bpc_supported = 10;
+ else
+ hdmi->dsc_bpc_supported = 0;
+
+ dsc_max_frl_rate = db[12] & DRM_EDID_DSC_MAX_FRL_RATE;
+ drm_get_max_frl_rate(dsc_max_frl_rate, >dsc_max_lanes,
+>dsc_max_frl_rate_per_lane);
+ hdmi->dsc_total_chunk_kbytes = db[13] & DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
}
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f351bf10c076..7100012f9c0f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -213,6 +213,38 @@ struct drm_hdmi_info {
/** @max_lanes: supported by sink */
u8 max_lanes;
+
+ /** @dsc_1p2: flag for dsc1.2 support by sink */
+ bool dsc_1p2;
+
+ /** @dsc_native_420: Does sink support DSC with 4:2:0 compression */
+ bool dsc_native_420;
+
+ /**
+* @dsc_all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
+* compressed formats
+*/
+ bool dsc_all_bpp;
+
+ /**
+* @dsc_bpc_supported: compressed bpc supported by sink : 10, 12 or 16
bpc
+*/
+ u8 dsc_bpc_supported;
+
+ /** @dsc_max_slices: maximum number of Horizontal slices supported by */
+ u8 dsc_max_slices;
+
+ /** @dsc_clk_per_slice : max pixel clock in MHz supported per slice */
+ u8 dsc_clk_per_slice;
+
+ /** @dsc_max_lanes : dsc max lanes supported for Fixed rate Link
training */
+ u8 dsc_max_lanes;
+
+ /** @dsc_max_frl_rate_per_lane : maximum frl rate with DSC per lane */
+ u8 dsc_max_frl_rate_per_lane;
+
+ /** @dsc_total_chunk_kbytes: max size of chunks in KBs supported per
line*/
+ u8 dsc_total_chunk_kbytes;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 10/13] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 93 +++
include/drm/drm_dp_helper.h | 109
2 files changed, 202 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 33a4ac2fb225..f10a9c2d6f04 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2929,3 +2929,96 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8 pps_buf_config)
+{
+ u8 buf = 0;
+ int ret;
+
+ buf |= DP_PCON_ENABLE_DSC_ENCODER;
+ if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+ buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+ buf |= pps_buf_config << 2;
+ }
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+/**
+ * drm_dp_pcon_pps_default() - Let PCON fill the default pps parameters
+ * for DSC1.2 between PCON & HDMI2.1 sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success, else returns negative error code.
+ * */
+int drm_dp_pcon_pps_default(struct drm_dp_aux *aux)
+{
+ int ret;
+
+ ret = drm_dp_pcon_configure_dsc_enc(aux,
DP_PCON_ENC_PPS_OVERRIDE_DISABLED);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_pps_default);
+
+/**
+ * drm_dp_pcon_pps_override_buf() - Configure PPS encoder override buffer for
+ * HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @pps_buf: 128 bytes to be written into PPS buffer for HDMI sink by PCON.
+ *
+ * Returns 0 on success, else returns negative error code.
+ * */
+int drm_dp_pcon_pps_override_buf(struct drm_dp_aux *aux, u8 pps_buf[128])
+{
+ int ret;
+
+ ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVERRIDE_BASE, _buf,
128);
+ if (ret < 0)
+ return ret;
+
+ ret = drm_dp_pcon_configure_dsc_enc(aux,
DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_pps_override_buf);
+
+/*
+ * drm_dp_pcon_pps_override_param() - Write PPS parameters to DSC encoder
+ * override registers
+ * @aux: DisplayPort AUX channel
+ * @pps_param: 3 Parameters (2 Bytes each) : Slice Width, Slice Height,
+ * bits_per_pixel.
+ *
+ * Returns 0 on success, else returns negative error code.
+ * */
+int drm_dp_pcon_pps_override_param(struct drm_dp_aux *aux, u8 pps_param[6])
+{
+ int ret;
+
+ ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVRD_SLICE_HEIGHT,
_param[0], 2);
+ if (ret < 0)
+ return ret;
+ ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVRD_SLICE_WIDTH,
_param[1], 2);
+ if (ret < 0)
+ return ret;
+ ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVRD_BPP, _param[2],
2);
+ if (ret < 0)
+ return ret;
+
+ ret = drm_dp_pcon_configure_dsc_enc(aux,
DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index eb26c86dc8ca..3de022d4a65e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -441,6 +441,83 @@ struct drm_device;
# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
+/* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
+#define DP_PCON_DSC_ENCODER 0x092
+# define DP_PCON_DSC_ENCODER_SUPPORTED (1 << 0)
+# define DP_PCON_DSC_PPS_ENC_OVERRIDE (1 << 1)
+
+/* DP-HDMI2.1 PCON DSC Version */
+#define DP_PCON_DSC_VERSION 0x093
+# define DP_PCON_DSC_MAJOR_MASK(0xF << 0)
+# define DP_PCON_DSC_MINOR_MASK(0xF << 4)
+# define DP_PCON_DSC_MAJOR_SHIFT 0
+# define DP_PCON_DSC_MINOR_SHIFT 4
+
+/* DP-HDMI2.1 PCON DSC RC Buffer block size */
+#define DP_PCON_DSC_RC_BUF_BLK_INFO0x094
+# define DP_PCON_DSC_RC_BUF_BLK_SIZE (0x3 << 0)
+# define DP_PCON_DSC_RC_BUF_BLK_1KB0
+# define DP_PCON_DSC_RC_BUF_BLK_4KB1
+# define DP_PCON_DSC_RC_BUF_BLK_16KB 2
+# define DP_PCON_DSC_RC_BUF_BLK_64KB 3
+
+/* DP-HDMI2.1 PCON DSC RC Buffer size */
+#define DP_PCON_DSC_RC_BUF_SIZE0x095
+
+/* DP-HDMI2.1 PCON DSC Slice capabilities-1 */
+#define DP_PCON_DSC_SLICE_CAP_10x096
+# define DP_PCON_DSC_1_PER_DSC_ENC (0x1 << 0)
+# define DP_PCON_DSC_2_PER_DSC_ENC (0x1 << 1)
+# define DP_PCON_DSC_4_PER_DSC_ENC
[RFC 08/13] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
is off; reinitiate frl link training to recover.
Also, HDMI FRL link error count range for each individual FRL
active lane is indicated by DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 668165dd2b1a..e6c4cb844e37 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5955,6 +5955,29 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+
+ is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ intel_dp_check_frl_training(intel_dp);
+ drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux,
_dp->attached_connector->base);
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6320,7 +6343,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6344,6 +6367,23 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
!val)
+ return;
+
+ drm_dp_dpcd_writeb(_dp->aux, DP_LINK_SERVICE_IRQ_VECTOR_ESI0,
val);
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6383,7 +6423,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -6815,7 +6856,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 05/13] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 7 +
drivers/gpu/drm/i915/display/intel_dp.c | 200 ++
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 209 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index e2f58d0575a2..6c69922313d6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1287,6 +1287,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1408,6 +1413,8 @@ struct intel_dp {
bool hobl_failed;
bool hobl_active;
+
+ struct intel_dp_pcon_frl frl;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index cd6934f28f32..c1342b5e7781 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2885,6 +2885,9 @@ static void intel_dp_prepare(struct intel_encoder
*encoder,
intel_dp->DP |= DP_PIPE_SEL_CHV(crtc->pipe);
else
intel_dp->DP |= DP_PIPE_SEL(crtc->pipe);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
}
@@ -3781,6 +3784,9 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3876,6 +3882,200 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_get_max_rate_gbps(struct intel_dp *intel_dp)
+{
+ int max_link_clock, max_lanes, max_rate_khz, max_rate_gbps;
+
+ max_link_clock = intel_dp_max_link_rate(intel_dp);
+ max_lanes = intel_dp_max_lane_count(intel_dp);
+ max_rate_khz = intel_dp_max_data_rate(max_link_clock, max_lanes);
+ max_rate_gbps = 8 * DIV_ROUND_UP(max_rate_khz, 100);
+
+ return max_rate_gbps;
+}
+
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+ int max_frl_mask = 0;
+
+ switch (max_frl) {
+ case 48:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_48GBPS;
+ break;
+ case 40:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_40GBPS;
+ break;
+ case 32:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_32GBPS;
+ break;
+ case 24:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_24GBPS;
+ break;
+ case 18:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_18GBPS;
+ break;
+ case 9:
+ max_frl_mask |= DP_PCON_FRL_BW_MASK_9GBPS;
+ break;
+ default:
+ max_frl_mask = 0;
+ }
+
+ return max_frl_mask;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lanes);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE true
+#define PCON_CONCURRENT_MODE true
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl, max_pcon_frl, max_sink_frl, max_rate_gbps, max_frl_edid,
ret;
+ u8 max_frl_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_rate_gbps = intel_dp_get_max_rate_gbps(intel_dp);
+ drm_dbg(>drm, "Source max rate = %d Gbps\n", max_rate_gbps);
+
+ max_pcon_frl = intel_dp->dfp.pcon_max_frl;
+
[RFC 02/13] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 51 +
include/drm/drm_connector.h | 6 +
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 631125b46e04..8afb136e73f5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4849,6 +4849,52 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static
+void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8
*max_rate_per_lane)
+{
+ switch(max_frl_rate) {
+ case 1:
+ *max_lanes = 3;
+ *max_rate_per_lane = 3;
+ break;
+ case 2:
+ *max_lanes = 3;
+ *max_rate_per_lane = 6;
+ break;
+ case 3:
+ *max_lanes = 4;
+ *max_rate_per_lane = 6;
+ break;
+ case 4:
+ *max_lanes = 4;
+ *max_rate_per_lane = 8;
+ break;
+ case 5:
+ *max_lanes = 4;
+ *max_rate_per_lane = 10;
+ break;
+ case 6:
+ *max_lanes = 4;
+ *max_rate_per_lane = 12;
+ break;
+ case 0:
+ default:
+ *max_lanes = 0;
+ *max_rate_per_lane = 0;
+ }
+}
+
+static void drm_parse_hdmi_21_additional_fields(struct drm_connector
*connector,
+ const u8 *db)
+{
+ struct drm_hdmi_info *hdmi = >display_info.hdmi;
+ u8 max_frl_rate;
+
+ max_frl_rate = db[7] & DRM_EDID_MAX_FRL_RATE_MASK;
+ drm_get_max_frl_rate(max_frl_rate, >max_lanes,
+>max_frl_rate_per_lane);
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4902,6 +4948,11 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ drm_parse_hdmi_21_additional_fields(connector, hf_vsdb);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 928136556174..f351bf10c076 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lanes: supported by sink */
+ u8 max_lanes;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 04/13] drm/i915: Capture max frl rate for PCON in dfp cap structure
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and
by the sink.
This patch captures these in dfp cap structure in intel_dp and uses
these to prune connector modes that cannot be supported by the PCON
and sink FRL bandwidth.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 33 +--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0b5df8e44966..e2f58d0575a2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1398,6 +1398,7 @@ struct intel_dp {
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
+ int pcon_max_frl, sink_max_frl;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0902a9aeeda1..cd6934f28f32 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -683,6 +683,24 @@ intel_dp_mode_valid_downstream(struct intel_connector
*connector,
const struct drm_display_info *info = >base.display_info;
int tmds_clock;
+ /* If PCON and HDMI2.1 sink both support FRL MODE, check FRL
+* bandwidth constraints.
+*/
+ if (intel_dp->dfp.pcon_max_frl) {
+ int target_bw;
+ int max_frl_bw;
+ int bpp = intel_dp_mode_min_output_bpp(>base, mode);
+
+ target_bw = bpp * DIV_ROUND_UP(target_clock, 100);
+
+ max_frl_bw = min(intel_dp->dfp.pcon_max_frl,
+intel_dp->dfp.sink_max_frl);
+ if (target_bw > max_frl_bw)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+ }
+
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
@@ -6383,13 +6401,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->downstream_ports,
edid);
+ intel_dp->dfp.pcon_max_frl =
+ drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
+ intel_dp->downstream_ports);
+
+ intel_dp->dfp.sink_max_frl = drm_dp_get_hdmi_max_frl_bw(_dp->aux);
+
drm_dbg_kms(>drm,
- "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d\n",
+ "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d, PCON Max FRL BW %dGbps, Sink Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
- intel_dp->dfp.max_tmds_clock);
+ intel_dp->dfp.max_tmds_clock,
+ intel_dp->dfp.pcon_max_frl,
+ intel_dp->dfp.sink_max_frl);
}
static void
@@ -6479,6 +6505,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
+ intel_dp->dfp.pcon_max_frl = 0;
+ intel_dp->dfp.sink_max_frl = 0;
+
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 06/13] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index bb0b9930958f..1834e5de60a7 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3484,6 +3484,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, if (!is_mst) intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); + intel_dp_check_frl_training(intel_dp); + intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); /* * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index c1342b5e7781..668165dd2b1a 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4206,6 +4206,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp, pipe_config); intel_dp_stop_link_train(intel_dp, pipe_config); @@ -6127,6 +6128,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, !intel_dp_mst_is_master_trans(crtc_state)) continue; + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp, crtc_state); intel_dp_stop_link_train(intel_dp, crtc_state); break; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 03/13] drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Minor changes:
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 305
include/drm/drm_dp_helper.h | 80 +
2 files changed, 385 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 14ddf28ecac0..df858533dbf7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2591,3 +2591,308 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS,
+ * returns 0 if not supported.
+ **/
+int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * returns 0, if not supported.
+ **/
+int drm_dp_get_hdmi_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, );
+ if (ret < 0)
+ return 0;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * max_frl_mask: mask for selecting the bandwidths supported by source,
+ * to be tried by Pcon f/w.
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GBPS;
+ break;
+ case 18:
+ buf |= DP_PCON_ENABLE_MAX_BW_18GBPS;
+ break;
+ case 24:
+
[RFC 01/13] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b27a0e2169c8..1cc5c2c73282 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10BPC (1 << 0)
+#define DRM_EDID_DSC_12BPC (1 << 1)
+#define DRM_EDID_DSC_16BPC (1 << 2)
+#define DRM_EDID_DSC_ALL_BPP (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_DSC_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE 0xf
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 13/13] drm/i915: Configure PCON for DSC1.1 to DSC1.2 encoding
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 120 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 121 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1834e5de60a7..f8fc2de7ad95 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3485,7 +3485,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_check_frl_training(intel_dp);
-
+ intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true);
/*
* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b4f8abaea607..2c7f6d04085e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -782,6 +782,16 @@ intel_dp_mode_valid(struct drm_connector *connector,
target_clock,
mode->hdisplay);
}
+
+ /*
+* TODO: If its a PCON with HDMI sink:
+* Assumption : Source only supports DSC1.1
+*
+* If HDMI supports DSC 1.2 but PCON does not support
+* DSC1.1->DSC1.2 encoding Then return MODE_CLOCK_HIGH.
+* Otherwise check if the mode can be applied according to
+* DSC capablities of the PCON and HDMI Sink combine.
+*/
}
if ((mode_rate > max_rate && !(dsc_max_output_bpp && dsc_slice_count))
||
@@ -4116,9 +4126,21 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
*intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
+ int max_frl_rate;
+ int max_lanes, rate_per_lane;
+ int max_dsc_lanes, dsc_rate_per_lane;
+
+ max_lanes = connector->display_info.hdmi.max_lanes;
+ rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+ max_frl_rate = max_lanes * rate_per_lane;
+
+ if (connector->display_info.hdmi.dsc_1p2) {
+ max_dsc_lanes = connector->display_info.hdmi.dsc_max_lanes;
+ dsc_rate_per_lane =
connector->display_info.hdmi.dsc_max_frl_rate_per_lane;
+ max_frl_rate = min(max_frl_rate, max_dsc_lanes *
dsc_rate_per_lane);
+ }
- return (connector->display_info.hdmi.max_frl_rate_per_lane *
- connector->display_info.hdmi.max_lanes);
+ return max_frl_rate;
}
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
@@ -4252,6 +4274,98 @@ void intel_dp_check_frl_training(struct intel_dp
*intel_dp)
drm_dbg(_priv->drm, "FRL training Completed\n");
}
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
+{
+
+ int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+ return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ int hdmi_throughput = connector->display_info.hdmi.dsc_clk_per_slice;
+ int hdmi_max_slices = connector->display_info.hdmi.dsc_max_slices;
+ int pcon_max_slices = intel_dp->pcon_dsc.max_slices;
+ int pcon_max_slice_width = intel_dp->pcon_dsc.max_slice_width;
+
+
+ return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
+pcon_max_slice_width,
+hdmi_max_slices, hdmi_throughput);
+}
+
+static int
+intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ int num_slices, int slice_width)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ int output_format = crtc_state->output_format;
+
[RFC 07/13] drm/dp_helper: Add support for link status and link recovery
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC interrupt mechanism. While source can always read final HDMI
sink’s status using I2C over AUX, it’s easier and faster to read
the PCON’s already read HDMI sink’s status registers.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 33 +
include/drm/drm_dp_helper.h | 16
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index df858533dbf7..33a4ac2fb225 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2896,3 +2896,36 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lanes; i++)
+ {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i ,
) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+
+ switch(error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d6f79b2d1287..eb26c86dc8ca 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -2047,4 +2062,5 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux, struct
drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 00/13] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299 The details are mentioned in DP to HDMI2.1 PCON Enum/Config improvement slide decks: https://groups.vesa.org/wg/DP/document/folder/1316 This RFC series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. v2: Added patch to capture the PCON FRL caps in downstream facing port cap structure. v3: Added patches for getting DSC capabilities of the PCON DSC encoder and HDMI decoder. Added support to configure PCON for DSC1.1 decoding and DSC1.2 encoding. Ankit Nautiyal (9): drm/dp_helper: Add FRL training support for a DP-HDMI2.1 PCON drm/i915: Capture max frl rate for PCON in dfp cap structure drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training drm/edid: Parse DSC1.2 cap fields from HFVSDB block drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1 drm/i915: Configure PCON for DSC1.1 to DSC1.2 encoding Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link status and link recovery drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 431 + drivers/gpu/drm/drm_edid.c| 70 +++ drivers/gpu/drm/i915/display/intel_ddi.c | 2 + .../drm/i915/display/intel_display_types.h| 24 + drivers/gpu/drm/i915/display/intel_dp.c | 576 +- drivers/gpu/drm/i915/display/intel_dp.h | 4 + drivers/gpu/drm/i915/display/intel_hdmi.c | 171 ++ drivers/gpu/drm/i915/display/intel_hdmi.h | 7 + include/drm/drm_connector.h | 38 ++ include/drm/drm_dp_helper.h | 205 +++ include/drm/drm_edid.h| 30 + 11 files changed, 1553 insertions(+), 5 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH drm/hisilicon v2 2/2] drm/hisilicon: Use the same style of variable type in hibmc_drm_drv
Hi
On Thu, 15 Oct 2020 17:00:17 +0800 Tian Tao wrote:
> Consistently Use the same style of variable type in hibmc_drm_drv.c and
> hibmc_drm_drv.h.
>
> Signed-off-by: Tian Tao
> Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 ++---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 8
> 2 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index 5632bce..0c1b40d
> 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -121,12 +121,11 @@ static void hibmc_kms_fini(struct hibmc_drm_private
> *priv) /*
> * It can operate in one of three modes: 0, 1 or Sleep.
> */
> -void hibmc_set_power_mode(struct hibmc_drm_private *priv,
> - unsigned int power_mode)
> +void hibmc_set_power_mode(struct hibmc_drm_private *priv, u32 power_mode)
> {
> - unsigned int control_value = 0;
> + u32 control_value = 0;
> void __iomem *mmio = priv->mmio;
> - unsigned int input = 1;
> + u32 input = 1;
>
> if (power_mode > HIBMC_PW_MODE_CTL_MODE_SLEEP)
> return;
> @@ -144,8 +143,8 @@ void hibmc_set_power_mode(struct hibmc_drm_private
> *priv,
> void hibmc_set_current_gate(struct hibmc_drm_private *priv, unsigned int
> gate) {
> - unsigned int gate_reg;
> - unsigned int mode;
> + u32 gate_reg;
> + u32 mode;
> void __iomem *mmio = priv->mmio;
>
> /* Get current power mode. */
> @@ -170,7 +169,7 @@ void hibmc_set_current_gate(struct hibmc_drm_private
> *priv, unsigned int gate)
> static void hibmc_hw_config(struct hibmc_drm_private *priv)
> {
> - unsigned int reg;
> + u32 reg;
>
> /* On hardware reset, power mode 0 is default. */
> hibmc_set_power_mode(priv, HIBMC_PW_MODE_CTL_MODE_MODE0);
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h index 6a63502..5c4030d
> 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -33,8 +33,8 @@ struct hibmc_drm_private {
> /* hw */
> void __iomem *mmio;
> void __iomem *fb_map;
> - unsigned long fb_base;
> - unsigned long fb_size;
> + u64 fb_base;
> + u64 fb_size;
No comment on why u64 is better than resource_size_t ?
Best regards
Thomas
>
> /* drm */
> struct drm_device *dev;
> @@ -56,9 +56,9 @@ static inline struct hibmc_drm_private
> *to_hibmc_drm_private(struct drm_device * }
>
> void hibmc_set_power_mode(struct hibmc_drm_private *priv,
> - unsigned int power_mode);
> + u32 power_mode);
> void hibmc_set_current_gate(struct hibmc_drm_private *priv,
> - unsigned int gate);
> + u32 gate);
>
> int hibmc_de_init(struct hibmc_drm_private *priv);
> int hibmc_vdac_init(struct hibmc_drm_private *priv);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] drm/vc4: hdmi: Enable 10/12 bpc output
Hi Maxime
On Thu, 8 Oct 2020 at 13:44, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
Something appears to be slightly off with this one. Running the
monitor (Dell U2718Q 4k monitor) at 1080p60.
Use modetest to switch "max bpc" to 10bpc, and the monitor reports 1080p48.
Use modetest to switch "max bpc" to 12bpc, and the monitor reports 1080p40.
I haven't got an HDMI analyser to hand to confirm whether we're
actually putting out 10 or 12bpc.
So at a guess a clock is unaltered, but the number of bits being sent
over the link is increased, thereby dropping the overall frame rate.
Having tested with the firmware it only points to my monitor not
supporting alternate bpc values - not so helpful.
I'm not sure the handling of the GCP is correct either. It is
enabled/disabled via bit 0 of HDMI_RAM_PACKET_CONFIG in the same way
all the infoframes are.
The firmware enables/disables sending the GCP when handling avmute,
but this driver isn't handling avmute so it never gets enabled
I'll have a further experiment to see if I can make things play ball.
I'll need to collect the analyser and deep colour display to really
try it out.
Dave
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 68 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 -
> 3 files changed, 77 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 21d20c8494e8..3ff72fab4c40 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -76,6 +76,17 @@
> #define VC5_HDMI_VERTB_VSPO_SHIFT 16
> #define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
>
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10,
> 8)
> +
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
> +
> +#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
> +
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
> +
> # define VC4_HD_M_SW_RST BIT(2)
> # define VC4_HD_M_ENABLE BIT(0)
>
> @@ -177,6 +188,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
> *connector)
>
> kfree(connector->state);
>
> + conn_state->base.max_bpc = 8;
> + conn_state->base.max_requested_bpc = 8;
> +
> __drm_atomic_helper_connector_reset(connector, _state->base);
> drm_atomic_helper_connector_tv_reset(connector);
> }
> @@ -224,12 +238,20 @@ static int vc4_hdmi_connector_init(struct drm_device
> *dev,
> vc4_hdmi->ddc);
> drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
>
> + /*
> +* Some of the properties below require access to state, like bpc.
> +* Allocate some default initial connector state with our reset
> helper.
> +*/
> + if (connector->funcs->reset)
> + connector->funcs->reset(connector);
> +
> /* Create and attach TV margin props to this connector. */
> ret = drm_mode_create_tv_margin_properties(dev);
> if (ret)
> return ret;
>
> drm_connector_attach_tv_margin_properties(connector);
> + drm_connector_attach_max_bpc_property(connector, 8, 16);
>
> connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
> DRM_CONNECTOR_POLL_DISCONNECT);
> @@ -495,6 +517,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
> bool enable)
> }
>
> static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -538,7 +561,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
> }
> +
> static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -558,6 +583,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> + unsigned char gcp;
> + bool gcp_en;
> + u32 reg;
>
> HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
>
[PATCH] drm/i915/jsl: Remove require_force_probe protection
Removing force probe protection from JSL platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.
Signed-off-by: Kamati Srinivas
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 16d4e72bed09..a61195a1883a 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -849,7 +849,6 @@ static const struct intel_device_info ehl_info = {
static const struct intel_device_info jsl_info = {
GEN11_FEATURES,
PLATFORM(INTEL_JASPERLAKE),
- .require_force_probe = 1,
.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
.ppgtt_size = 36,
};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
Hi Hariom, With Sunil's help was able to see EHL achieving rc6 state. Verified from sys entries, under no load to gpu rc6_residency_ms counter is changing. Also ran all the Rodrigo mention tests and I see them passing. But with i915_selftest dmesg warnings are still seen. Thanks, Srinivas -Original Message- From: Pandey, Hariom Sent: 09 October 2020 23:39 To: K, SrinivasX Cc: Souza, Jose ; ch...@chris-wilson.co.uk; Ausmus, James ; Nikula, Jani ; Roper, Matthew D ; intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Surendrakumar Upadhyay, TejaskumarX ; Vivi, Rodrigo Subject: RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection Hi Srinivas, Take Sunil's help who has recently validated RC6 on EHL DRM tip and found to be passing. If the WA were sporadically failing and if you confirm that RC6 is passing, this patch can be proceeded with. Thanks Hariom Pandey -Original Message- From: Vivi, Rodrigo Sent: Friday, October 9, 2020 7:09 PM To: K, SrinivasX Cc: Souza, Jose ; ch...@chris-wilson.co.uk; Ausmus, James ; Nikula, Jani ; Pandey, Hariom ; Roper, Matthew D ; intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Surendrakumar Upadhyay, TejaskumarX Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection > On Oct 9, 2020, at 1:31 AM, K, SrinivasX wrote: > > Hi Rodrigo, > > How do we get W/A and rc6 changes in, do you have any details? I told based on what I was seeing on https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html? focusing on the issues that are exclusively for ehl and not happening on other platforms. It looks like workarounds are fine there now. so I'm not sure if it was sporadic thing that day. for the rc6 there are a few testcases failing around it: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_pm_rc6_reside...@rc6-fence.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_pm_rc6_reside...@rc6-idle.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_selftest@live@gt_pm.html#dmesg-warnings415 > > Thanks, > Srinivas > > -Original Message- > From: Souza, Jose > Sent: 06 October 2020 23:33 > To: Vivi, Rodrigo ; ch...@chris-wilson.co.uk > Cc: Ausmus, James ; Nikula, Jani > ; Pandey, Hariom ; > Roper, Matthew D ; > intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; K, > SrinivasX ; Surendrakumar Upadhyay, TejaskumarX > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove > require_force_probe protection > > On Tue, 2020-10-06 at 10:55 -0700, Vivi, Rodrigo wrote: >> >>> On Oct 6, 2020, at 10:48 AM, Chris Wilson wrote: >>> >>> Quoting Souza, Jose (2020-10-06 18:46:45) +Rodrigo and Jani On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote: > Removing force probe protection from EHL platform. Did not observe > warnings, errors, flickering or any visual defects while doing > ordinary tasks like browsing and editing documents in a two > monitor setup. One of the requirements was also to have CI BAT all green and shards as green is possible but EHL don't show up in CI results, we actually have one single EHL machine in CI but I guess it is not able to run all tests that shards do: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9097/filelist.html >>> >>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html >> >> we are really close to that point. We just need to fix some w/a and >> rc6 issues before applying this change. >> >>> -Chris >> > > Huum okay we have drm-tip results for EHL but if someone sends a patch that > breaks EHL it will not be caught in pre-merge testing. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/ast something ate high-res modes (5.3->5.6 regression)
Hi On Thu, 15 Oct 2020 11:10:48 +0300 (EEST) "Ilpo Järvinen" wrote: > On Wed, 14 Oct 2020, Thomas Zimmermann wrote: > > On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen" > > wrote: > > > > > The high-res mode works, however, I wasn't expecting it to be this slow > > > though as I can see the slowish sweeps to redraw the screen or large > > > parts of it. Maybe you meant all along this slow (I was expecting > > > something like memcpy slow and this looks definitely much slower)? > > > > First of all, thanks for testing. I didn't expect it to be that slow > > either. > > > > > > > > While a large redrawing operation is going on, mouse cursor stops > > > moving normally until it is over and it then jumps to catch up. When > > > the mouse is over something that doesn't require large redraw, it seems > > > to work quite normally. > > > > > > > That sounds bad. The cursor is drawn by hardware, so I'd expect it to move > > smoothly across the screen. Maybe the position update is blocked from the > > framebuffer's memcpy within the kernel code. > > > > I was hoping the performance would be acceptable, but this sounds like a > > dealbreaker to me. I can look a bit closer if there are issues/bugs in the > > code that make it run slow. Not holding my breath for it though... > > Yeah, with like 5fps with full redraw it's not really acceptable (it's a > bit hard to estimate exactly but certainly less than 10fps). Writing to > video mem / normally working memcpy itself really cannot be this slow as > it would impact fps in non-shmem case too I think. I guess you run X for testing? In the current upstream kernel, X11 should use an internal shadow buffer to compose the displayed image; and then do it's own memcpy into video RAM. If you go to a lower resolution is the performance similar to the current upstream kernel? > > Also, there's more into this. I noticed that after using this kernel, > I cannot boot normally neither warm nor even cold boot after poweroff > (POST is slower than usual, beeps one less and gets stuck, I didn't > manage to switch into textual POST messages to see if there's any info as > the tab key for swithing got also broken). Sadly those beeps don't match > to the motherboard manual in ok nor broken case so I've no idea what they > mean and whether the beeps really related to POST or e.g. from graphics > init. > > Only after cutting power entirely from the machine, the boot again > succeeds. To me those symptoms sounds like it somehow managed to break > something related to IPMI because IPMI is reinitialized only if I remove > the power. If I've understood correctly IPMI is somehow connected to > graphics side within the AST. The AST chip does all kinds of things. It's hard to say if it's related. > > I haven't yet tested with the plain 5.9-rc5 to rule out it breaking > the boot (but I find it less likely to be case here). > > I can rebase the patch onto a more recent upstream kernel and send out an update. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2 22/22] drm/msm: Don't implicit-sync if only a single ring
On Tue, Oct 13, 2020 at 6:15 PM Rob Clark wrote:
>
> On Tue, Oct 13, 2020 at 4:08 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 12, 2020 at 08:07:38AM -0700, Rob Clark wrote:
> > > On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
> > > >
> > > > On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> > > > > From: Rob Clark
> > > > >
> > > > > Any cross-device sync use-cases *must* use explicit sync. And if
> > > > > there
> > > > > is only a single ring (no-preemption), everything is FIFO order and
> > > > > there is no need to implicit-sync.
> > > > >
> > > > > Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as
> > > > > behavior
> > > > > is undefined when fences are not used to synchronize buffer usage
> > > > > across
> > > > > contexts (which is the only case where multiple different priority
> > > > > rings
> > > > > could come into play).
> > > >
> > > > Uh does this mean msm is broken on dri2/3 and wayland? Or I'm I just
> > > > confused by your commit message?
> > >
> > > No, I don't think so. If there is only a single priority level
> > > ringbuffer (ie. no preemption to higher priority ring) then everything
> > > is inherently FIFO order.
> >
> > Well eventually you get a scheduler I guess/hope :-)
>
> we do have one currently for some gens, but not others.. hence the
> check for # of rings. (Ie. there is a ring per priority level, if
> only one ring, that means no preemption/scheduler)
Even without preempt a scheduler is somewhat useful, if you have a
very spammy client. Of course it assumes that everyone submits
reasonably short workloads, otherwise nothing you can do.
> > > For cases where we are sharing buffers with something external to drm,
> > > explicit sync will be used. And we don't implicit sync with display,
> > > otherwise x11 (frontbuffer rendering) would not work
> >
> > Uh now I'm even more confused. The implicit sync fences in dma_resv are
> > kinda for everyone. That's also why dma_resv with the common locking
> > approach is a useful idea.
> >
> > So display should definitely support implicit sync, and iirc msm does have
> > the helper hooked up.
>
> yup
>
> > Wrt other subsystems, I guess passing dma_fence around somehow doesn't fit
> > into v4l (the patches never landed), so v4l doesn't do any kind of sync
> > right now. But this could be fixed. Not sure what else is going on.
> >
> > So I guess I still have no idea why you put that into the commit message.
> >
> > btw for what you're trying to do yourself, the way to do this is to
> > allocate a fence timeline for your engine, compare fences, and no-op them
> > all out if their own the same timeline.
>
> we do that already (with a fence timeline per-ring, in the case of
> gens which support multiple rings / preemption).. this patch just
> short-circuits that in the case where we already knows the fences will
> of the same timeline
Ok so I think it's all good, no misunderstanding, but the commit
message. I think if you delete the first sentence that cross-device
sync must use explicit fences then it all makes sense and is
consistent. Or clarify it that this is cross-engine sync with explicit
internal synchronization, to differentiate it against cross-device
sync (as seen by userspace, like different drm_device instances) and
explicit dma_fence synchronization controlled by userspace.
-Daniel
> BR,
> -R
>
> > -Daniel
> >
> > >
> > > BR,
> > > -R
> > >
> > > > Since for these protocols we do expect implicit sync accross processes
> > > > to
> > > > work. Even across devices (and nvidia have actually provided quite a
> > > > bunch
> > > > of patches to make this work in i915 - ttm based drivers get this right,
> > > > plus dumb scanout drivers using the right helpers also get this all
> > > > right).
> > > > -Daniel
> > > >
> > > > >
> > > > > Signed-off-by: Rob Clark
> > > > > ---
> > > > > drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
> > > > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > index 3151a0ca8904..c69803ea53c8 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > @@ -277,7 +277,7 @@ static int submit_lock_objects(struct
> > > > > msm_gem_submit *submit)
> > > > > return ret;
> > > > > }
> > > > >
> > > > > -static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > > > > no_implicit)
> > > > > +static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > > > > implicit_sync)
> > > > > {
> > > > > int i, ret = 0;
> > > > >
> > > > > @@ -297,7 +297,7 @@ static int submit_fence_sync(struct
> > > > > msm_gem_submit *submit, bool no_implicit)
> > > > > return ret;
> > > > > }
> > > > >
> > > > > - if (no_implicit)
> > > > > + if (!implicit_sync)
> > > > >
Re: [PATCH] video: fbdev: sh_mobile_lcdcfb: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
On Wed, 14 Oct 2020 08:57:22 + Xu Wang wrote:
> Because clk_prepare_enable() and clk_disable_unprepare() already checked
> NULL clock parameter, so the additional checks are unnecessary, just
> remove them.
>
> Signed-off-by: Xu Wang
Reviewed-by: Thomas Zimmermann
> ---
> drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> b/drivers/video/fbdev/sh_mobile_lcdcfb.c index c1043420dbd3..c0952cc96bdb
> 100644 --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> @@ -341,8 +341,7 @@ static void lcdc_wait_bit(struct sh_mobile_lcdc_priv
> *priv, static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
> {
> if (atomic_inc_and_test(>hw_usecnt)) {
> - if (priv->dot_clk)
> - clk_prepare_enable(priv->dot_clk);
> + clk_prepare_enable(priv->dot_clk);
> pm_runtime_get_sync(priv->dev);
> }
> }
> @@ -351,8 +350,7 @@ static void sh_mobile_lcdc_clk_off(struct
> sh_mobile_lcdc_priv *priv) {
> if (atomic_sub_return(1, >hw_usecnt) == -1) {
> pm_runtime_put(priv->dev);
> - if (priv->dot_clk)
> - clk_disable_unprepare(priv->dot_clk);
> + clk_disable_unprepare(priv->dot_clk);
> }
> }
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb/dss: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
On Wed, 14 Oct 2020 08:49:20 + Xu Wang wrote:
> Because clk_prepare_enable() and clk_disable_unprepare() already checked
> NULL clock parameter, so the additional checks are unnecessary, just
> remove them.
>
> Signed-off-by: Xu Wang
Reviewed-by: Thomas Zimmermann
> ---
> drivers/video/fbdev/omap2/omapfb/dss/venc.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/venc.c index
> 0b0ad20afd63..8895fb8493d8 100644 ---
> a/drivers/video/fbdev/omap2/omapfb/dss/venc.c +++
> b/drivers/video/fbdev/omap2/omapfb/dss/venc.c @@ -890,8 +890,7 @@ static
> int venc_remove(struct platform_device *pdev)
> static int venc_runtime_suspend(struct device *dev)
> {
> - if (venc.tv_dac_clk)
> - clk_disable_unprepare(venc.tv_dac_clk);
> + clk_disable_unprepare(venc.tv_dac_clk);
>
> dispc_runtime_put();
>
> @@ -906,8 +905,7 @@ static int venc_runtime_resume(struct device *dev)
> if (r < 0)
> return r;
>
> - if (venc.tv_dac_clk)
> - clk_prepare_enable(venc.tv_dac_clk);
> + clk_prepare_enable(venc.tv_dac_clk);
>
> return 0;
> }
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] au1100fb: Remove NULL pointer check before clk_enable/disable
Hi On Wed, 14 Oct 2020 08:21:37 + Xu Wang wrote: > Because clk_enable, clk_disable, clk_prepare, and clk_unprepare already > checked NULL clock parameter, so the additional checks are unnecessary, > just remove them. All clk_*() functions seem to handle NULL pointers gracefully, so you can also remove these checks from the driver's _probe and _remove functions. Best regards Thomas > > Signed-off-by: Xu Wang > --- > drivers/video/fbdev/au1100fb.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c > index 37a6512feda0..3659dfbb81c1 100644 > --- a/drivers/video/fbdev/au1100fb.c > +++ b/drivers/video/fbdev/au1100fb.c > @@ -560,8 +560,7 @@ int au1100fb_drv_suspend(struct platform_device *dev, > pm_message_t state) /* Blank the LCD */ > au1100fb_fb_blank(VESA_POWERDOWN, >info); > > - if (fbdev->lcdclk) > - clk_disable(fbdev->lcdclk); > + clk_disable(fbdev->lcdclk); > > memcpy(, fbdev->regs, sizeof(struct au1100fb_regs)); > > @@ -577,8 +576,7 @@ int au1100fb_drv_resume(struct platform_device *dev) > > memcpy(fbdev->regs, , sizeof(struct au1100fb_regs)); > > - if (fbdev->lcdclk) > - clk_enable(fbdev->lcdclk); > + clk_enable(fbdev->lcdclk); > > /* Unblank the LCD */ > au1100fb_fb_blank(VESA_NO_BLANKING, >info); -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/17] resource: Move devmem revoke code to resource framework
On Thu, Oct 15, 2020 at 9:52 AM Daniel Vetter wrote:
>
> On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
> >
> > On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > > >
> > > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > > > > On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
> > > > > >
> > > > > > On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> > > > > >
> > > > > > > +struct address_space *iomem_get_mapping(void)
> > > > > > > +{
> > > > > > > + return iomem_inode->i_mapping;
> > > > > >
> > > > > > This should pair an acquire with the release below
> > > > > >
> > > > > > > + /*
> > > > > > > + * Publish /dev/mem initialized.
> > > > > > > + * Pairs with smp_load_acquire() in revoke_iomem().
> > > > > > > + */
> > > > > > > + smp_store_release(_inode, inode);
> > > > > >
> > > > > > However, this seems abnormal, initcalls rarely do this kind of stuff
> > > > > > with global data..
> > > > > >
> > > > > > The kernel crashes if this fs_initcall is raced with
> > > > > > iomem_get_mapping() due to the unconditional dereference, so I think
> > > > > > it can be safely switched to a simple assignment.
> > > > >
> > > > > Ah yes I checked this all, but forgot to correctly annotate the
> > > > > iomem_get_mapping access. For reference, see b34e7e298d7a ("/dev/mem:
> > > > > Add missing memory barriers for devmem_inode").
> > > >
> > > > Oh yikes, so revoke_iomem can run concurrently during early boot,
> > > > tricky.
> > >
> > > It runs early because request_mem_region() can run before fs_initcall.
> > > Rather than add an unnecessary lock just arrange for the revoke to be
> > > skipped before the inode is initialized. The expectation is that any
> > > early resource reservations will block future userspace mapping
> > > attempts.
> >
> > Actually, on this point a simple WRITE_ONCE/READ_ONCE pairing is OK,
> > Paul once explained that the pointer chase on the READ_ONCE side is
> > required to be like an acquire - this is why rcu_dereference is just
> > READ_ONCE
>
> Indeed this changed with the sm_read_barrier_depends() removal a year
> ago. Before that READ_ONCE and rcu_dereference where not actually the
> same. I guess I'll throw a patch on top to switch that over too.
Actually 2019 landed just the clean-up, the read change landed in 2017 already:
commit 76ebbe78f7390aee075a7f3768af197ded1bdfbb
Author: Will Deacon
Date: Tue Oct 24 11:22:47 2017 +0100
locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/17] resource: Move devmem revoke code to resource framework
On Thu, Oct 15, 2020 at 2:09 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> > >
> > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
> > > > >
> > > > > On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> > > > >
> > > > > > +struct address_space *iomem_get_mapping(void)
> > > > > > +{
> > > > > > + return iomem_inode->i_mapping;
> > > > >
> > > > > This should pair an acquire with the release below
> > > > >
> > > > > > + /*
> > > > > > + * Publish /dev/mem initialized.
> > > > > > + * Pairs with smp_load_acquire() in revoke_iomem().
> > > > > > + */
> > > > > > + smp_store_release(_inode, inode);
> > > > >
> > > > > However, this seems abnormal, initcalls rarely do this kind of stuff
> > > > > with global data..
> > > > >
> > > > > The kernel crashes if this fs_initcall is raced with
> > > > > iomem_get_mapping() due to the unconditional dereference, so I think
> > > > > it can be safely switched to a simple assignment.
> > > >
> > > > Ah yes I checked this all, but forgot to correctly annotate the
> > > > iomem_get_mapping access. For reference, see b34e7e298d7a ("/dev/mem:
> > > > Add missing memory barriers for devmem_inode").
> > >
> > > Oh yikes, so revoke_iomem can run concurrently during early boot,
> > > tricky.
> >
> > It runs early because request_mem_region() can run before fs_initcall.
> > Rather than add an unnecessary lock just arrange for the revoke to be
> > skipped before the inode is initialized. The expectation is that any
> > early resource reservations will block future userspace mapping
> > attempts.
>
> Actually, on this point a simple WRITE_ONCE/READ_ONCE pairing is OK,
> Paul once explained that the pointer chase on the READ_ONCE side is
> required to be like an acquire - this is why rcu_dereference is just
> READ_ONCE
Indeed this changed with the sm_read_barrier_depends() removal a year
ago. Before that READ_ONCE and rcu_dereference where not actually the
same. I guess I'll throw a patch on top to switch that over too.
-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
[PATCH] video: fbdev: sh_mobile_lcdcfb: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index c1043420dbd3..c0952cc96bdb 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -341,8 +341,7 @@ static void lcdc_wait_bit(struct sh_mobile_lcdc_priv *priv,
static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
{
if (atomic_inc_and_test(>hw_usecnt)) {
- if (priv->dot_clk)
- clk_prepare_enable(priv->dot_clk);
+ clk_prepare_enable(priv->dot_clk);
pm_runtime_get_sync(priv->dev);
}
}
@@ -351,8 +350,7 @@ static void sh_mobile_lcdc_clk_off(struct
sh_mobile_lcdc_priv *priv)
{
if (atomic_sub_return(1, >hw_usecnt) == -1) {
pm_runtime_put(priv->dev);
- if (priv->dot_clk)
- clk_disable_unprepare(priv->dot_clk);
+ clk_disable_unprepare(priv->dot_clk);
}
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] omapfb/dss: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare
Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Signed-off-by: Xu Wang
---
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
index 0b0ad20afd63..8895fb8493d8 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/venc.c
@@ -890,8 +890,7 @@ static int venc_remove(struct platform_device *pdev)
static int venc_runtime_suspend(struct device *dev)
{
- if (venc.tv_dac_clk)
- clk_disable_unprepare(venc.tv_dac_clk);
+ clk_disable_unprepare(venc.tv_dac_clk);
dispc_runtime_put();
@@ -906,8 +905,7 @@ static int venc_runtime_resume(struct device *dev)
if (r < 0)
return r;
- if (venc.tv_dac_clk)
- clk_prepare_enable(venc.tv_dac_clk);
+ clk_prepare_enable(venc.tv_dac_clk);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v1] drm/msm: Fix race condition in msm driver with async layer updates
When there are back to back commits with async cursor update,
there is a case where second commit can program the DPU hw
blocks while first didn't complete flushing config to HW.
Synchronize the compositions such that second commit waits
until first commit flushes the composition.
This change also introduces per crtc commit lock, such that
commits on different crtcs are not blocked by each other.
Signed-off-by: Krishna Manikandan
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 26
drivers/gpu/drm/msm/msm_atomic.c | 35 ++--
drivers/gpu/drm/msm/msm_kms.h| 5 +
5 files changed, 57 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index c2729f7..9024719 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1383,6 +1383,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
+ mutex_init(_crtc->commit_lock);
DPU_DEBUG("%s: successfully initialized crtc\n", dpu_crtc->name);
return crtc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index cec3474..1eeb73d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -169,6 +169,7 @@ struct dpu_crtc {
/* for handling internal event thread */
spinlock_t event_lock;
+ struct mutex commit_lock;
struct dpu_core_perf_params cur_perf;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c0a4d4e..f99ae7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -445,6 +445,30 @@ static void dpu_kms_wait_flush(struct msm_kms *kms,
unsigned crtc_mask)
dpu_kms_wait_for_commit_done(kms, crtc);
}
+static void dpu_kms_commit_lock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+ struct drm_crtc *crtc;
+ struct dpu_crtc *dpu_crtc;
+
+ for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
+ dpu_crtc = to_dpu_crtc(crtc);
+ mutex_lock(_crtc->commit_lock);
+ }
+}
+
+static void dpu_kms_commit_unlock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+ struct dpu_kms *dpu_kms = to_dpu_kms(kms);
+ struct drm_crtc *crtc;
+ struct dpu_crtc *dpu_crtc;
+
+ for_each_crtc_mask(dpu_kms->dev, crtc, crtc_mask) {
+ dpu_crtc = to_dpu_crtc(crtc);
+ mutex_unlock(_crtc->commit_lock);
+ }
+}
+
static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
@@ -738,6 +762,8 @@ static const struct msm_kms_funcs kms_funcs = {
#ifdef CONFIG_DEBUG_FS
.debugfs_init= dpu_kms_debugfs_init,
#endif
+ .commit_lock = dpu_kms_commit_lock,
+ .commit_unlock = dpu_kms_commit_unlock,
};
static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 561bfa4..d33253f 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -55,16 +55,32 @@ static void vblank_put(struct msm_kms *kms, unsigned
crtc_mask)
}
}
+static void msm_commit_lock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+ if (kms->funcs->commit_lock)
+ kms->funcs->commit_lock(kms, crtc_mask);
+ else
+ mutex_lock(>commit_lock);
+}
+
+static void msm_commit_unlock(struct msm_kms *kms, unsigned int crtc_mask)
+{
+ if (kms->funcs->commit_unlock)
+ kms->funcs->commit_unlock(kms, crtc_mask);
+ else
+ mutex_unlock(>commit_lock);
+}
+
static void msm_atomic_async_commit(struct msm_kms *kms, int crtc_idx)
{
unsigned crtc_mask = BIT(crtc_idx);
trace_msm_atomic_async_commit_start(crtc_mask);
- mutex_lock(>commit_lock);
+ msm_commit_lock(kms, crtc_mask);
if (!(kms->pending_crtc_mask & crtc_mask)) {
- mutex_unlock(>commit_lock);
+ msm_commit_unlock(kms, crtc_mask);
goto out;
}
@@ -79,7 +95,6 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
*/
trace_msm_atomic_flush_commit(crtc_mask);
kms->funcs->flush_commit(kms, crtc_mask);
- mutex_unlock(>commit_lock);
/*
* Wait for flush to complete:
@@ -90,9 +105,8 @@ static void msm_atomic_async_commit(struct msm_kms *kms, int
crtc_idx)
vblank_put(kms,
[PATCH] drm/amd: remove unnecessary conversion from bool value to bool
In functions vegam_is_dpm_running & vegam_populate_avfs_parameters,
maybe there is no need to conver bool condition to bool variable
or bool return value.
This change is to make the code a bit more readable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
index 0ecc18b55ffb..32ca472f58a6 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
@@ -296,8 +296,9 @@ static int vegam_process_firmware_header(struct pp_hwmgr
*hwmgr)
static bool vegam_is_dpm_running(struct pp_hwmgr *hwmgr)
{
return (1 == PHM_READ_INDIRECT_FIELD(hwmgr->device,
- CGS_IND_REG__SMC, FEATURE_STATUS,
VOLTAGE_CONTROLLER_ON))
- ? true : false;
+CGS_IND_REG__SMC,
+FEATURE_STATUS,
+VOLTAGE_CONTROLLER_ON));
}
static uint32_t vegam_get_mac_definition(uint32_t value)
@@ -1661,7 +1662,7 @@ static int vegam_populate_avfs_parameters(struct pp_hwmgr
*hwmgr)
(avfs_params.ucEnableGB_FUSE_TABLE_CKSON <<
AVFSGB0_Vdroop_Enable_SHIFT) |
(avfs_params.ucEnableGB_FUSE_TABLE_CKSOFF <<
AVFSGB1_Vdroop_Enable_SHIFT);
data->apply_avfs_cks_off_voltage =
- (avfs_params.ucEnableApplyAVFS_CKS_OFF_Voltage
== 1) ? true : false;
+ (avfs_params.ucEnableApplyAVFS_CKS_OFF_Voltage
== 1);
}
return result;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Hi Chun-Kuang,
On Wed, Oct 14, 2020 at 6:25 PM Fabien Parent wrote:
>
> Hi Chun-Kuang,
>
> On Wed, Oct 14, 2020 at 3:00 PM Chun-Kuang Hu wrote:
> >
> > Hi, Fabien:
> >
> > Fabien Parent 於 2020年10月14日 週三 上午2:19寫道：
> > >
> > > Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> > > MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
> >
> > I think you should drop this series. According to Mediatek HDMI
> > binding document [1], the second parameter of mediatek,syscon-hdmi is
> > the register offset. I think you could set register offset to 0x800
> > for mt8167.
> Ok, thank you. I will try it.
Thanks, it works. Dropping this series.
>
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt?h=v5.9
> >
> > Regards,
> > Chun-Kuang.
> >
> > >
> > > Signed-off-by: Fabien Parent
> > > ---
> > >
> > > Changelog:
> > > v2: fix name of pdata structure
> > >
> > > drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
> > > drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
> > > 2 files changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > index 57370c036497..484ea9cd654a 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > @@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data
> > > mt8173_hdmi_driver_data = {
> > > .sys_cfg20 = HDMI_SYS_CFG20,
> > > };
> > >
> > > +static struct mtk_hdmi_data mt8167_hdmi_driver_data = {
> > > + .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
> > > + .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
> > > +};
> > > +
> > > static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
> > > { .compatible = "mediatek,mt8173-hdmi",
> > > .data = _hdmi_driver_data },
> > > + { .compatible = "mediatek,mt8167-hdmi",
> > > + .data = _hdmi_driver_data },
> > > {}
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > > b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > > index 2050ba45b23a..a0f9c367d7aa 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > > @@ -195,6 +195,7 @@
> > > #define GEN_RGB(0 << 7)
> > >
> > > #define HDMI_SYS_CFG1C 0x000
> > > +#define MT8167_HDMI_SYS_CFG1C 0x800
> > > #define HDMI_ONBIT(0)
> > > #define HDMI_RST BIT(1)
> > > #define ANLG_ONBIT(2)
> > > @@ -211,6 +212,7 @@
> > > #define HTPLG_PIN_SEL_OFF BIT(30)
> > > #define AES_EFUSE_ENABLE BIT(31)
> > > #define HDMI_SYS_CFG20 0x004
> > > +#define MT8167_HDMI_SYS_CFG20 0x804
> > > #define DEEP_COLOR_MODE_MASK (3 << 1)
> > > #define COLOR_8BIT_MODE(0 << 1)
> > > #define COLOR_10BIT_MODE (1 << 1)
> > > --
> > > 2.28.0
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] au1100fb: Remove NULL pointer check before clk_enable/disable
Because clk_enable, clk_disable, clk_prepare, and clk_unprepare already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Signed-off-by: Xu Wang --- drivers/video/fbdev/au1100fb.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c index 37a6512feda0..3659dfbb81c1 100644 --- a/drivers/video/fbdev/au1100fb.c +++ b/drivers/video/fbdev/au1100fb.c @@ -560,8 +560,7 @@ int au1100fb_drv_suspend(struct platform_device *dev, pm_message_t state) /* Blank the LCD */ au1100fb_fb_blank(VESA_POWERDOWN, >info); - if (fbdev->lcdclk) - clk_disable(fbdev->lcdclk); + clk_disable(fbdev->lcdclk); memcpy(, fbdev->regs, sizeof(struct au1100fb_regs)); @@ -577,8 +576,7 @@ int au1100fb_drv_resume(struct platform_device *dev) memcpy(fbdev->regs, , sizeof(struct au1100fb_regs)); - if (fbdev->lcdclk) - clk_enable(fbdev->lcdclk); + clk_enable(fbdev->lcdclk); /* Unblank the LCD */ au1100fb_fb_blank(VESA_NO_BLANKING, >info); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add gpu cooling support
On 2020-10-14 18:59, Akhil P Oommen wrote:
On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote:
On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote:
Hi,
On Thu, Oct 8, 2020 at 10:10 AM Akhil P Oommen
wrote:
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 29
++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index d46b383..40d6a28 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2,7 +2,7 @@
/*
* SC7180 SoC device tree source
*
- * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-20, The Linux Foundation. All rights
reserved.
*/
#include
@@ -1885,6 +1885,7 @@
iommus = <_smmu 0>;
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;
+ #cooling-cells = <2>;
Presumably we should add this to the devicetree bindings, too?
Yes, thanks for catching this. Will update in the next patch.
interconnects = <_noc MASTER_GFX3D
_virt SLAVE_EBI1>;
interconnect-names = "gfx-mem";
@@ -3825,16 +3826,16 @@
};
gpuss0-thermal {
- polling-delay-passive = <0>;
+ polling-delay-passive = <100>;
Why did you make this change? I'm pretty sure that we _don't_ want
this since we're using interrupts for the thermal sensor. See commit
22337b91022d ("arm64: dts: qcom: sc7180: Changed polling mode in
Thermal-zones node").
I was going to ask the same, this shouldn't be needed.
As per our understanding unlike "polling-delay", this delay property is
intended to activate polling thread on post trip threshold violation and
it is irrespective of sensor is capable for trip interrupt or not.
This polling is more of governor related. Below are the few references
from Documentation/code which tells polling-delay-passive is needed for
IPA for better IPA performance.
As per Power allocator documentations
1.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/driver-api/thermal/power_allocator.rst?h=v5.4.71#n264
"The power allocator governor's PID controller works best if there is a
periodic tick. If you have a driver that calls
`thermal_zone_device_update()` (or anything that ends up calling the
governor's `throttle()` function) repetitively, the governor response
won't be very good. Note that this is not particular to this
governor, step-wise will also misbehave if you call its throttle()
faster than the normal thermal framework tick (due to interrupts for
example) as it will overreact"
2. In Power allocator code, when switch_on/control trip temp violation,
it is enabling passive counter to activate passive polling @
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/thermal/power_allocator.c?h=v5.4.71#n634
3. while calculating derivative term, it is using passive_delay @
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/thermal/power_allocator.c?h=v5.4.71#n243
4. Sensor interrupt will work if temperature is fluctuating between
trip_temp and hysteresis. But say a case where we are not enabling
polling-delay-passive. In this case if current temperature >
control_temp trip(2nd passive trip) and
temperature trend is still raising, then sensor high trip will be
disabled (OR configured for critical trip threshold). No more trip
interrupt from sensor until it reaches critical trip or falls below
control_temp hysteresis.
How the governor re-evaluate its next mitigation without passive
polling thread here ?
I think the same is required for CPU thermal zone as well.
polling-delay = <0>;
thermal-sensors = < 13>;
trips {
gpuss0_alert0: trip-point0 {
- temperature = <9>;
+ temperature = <95000>;
hysteresis = <2000>;
- type = "hot";
+ type = "passive";
Matthias probably knows better, but I wonder if we should be making
two passive trip levels like we do with CPU. IIRC this is important
if someone wants to be able to use this with IPA.
Yes, please introduce a second trip point and make both of them
'passive'.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Adding Manaf here.
-Akhil.
___
Re: [PATCH 2/5] thermal: devfreq_cooling: get a copy of device status
On 21/09/2020 14:20, Lukasz Luba wrote:
> Devfreq cooling needs to now the correct status of the device in order
> to operate. Do not rely on Devfreq last_status which might be a stale data
> and get more up-to-date values of the load.
>
> Devfreq framework can change the device status in the background. To
> mitigate this situation make a copy of the status structure and use it
> for internal calculations.
>
> In addition this patch adds normalization function, which also makes sure
> that whatever data comes from the device, it is in a sane range.
>
> Signed-off-by: Lukasz Luba
> ---
> drivers/thermal/devfreq_cooling.c | 52 +--
> 1 file changed, 43 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/thermal/devfreq_cooling.c
> b/drivers/thermal/devfreq_cooling.c
> index 7063ccb7b86d..cf045bd4d16b 100644
> --- a/drivers/thermal/devfreq_cooling.c
> +++ b/drivers/thermal/devfreq_cooling.c
> @@ -227,6 +227,24 @@ static inline unsigned long get_total_power(struct
> devfreq_cooling_device *dfc,
> voltage);
> }
>
> +static void _normalize_load(struct devfreq_dev_status *status)
> +{
> + /* Make some space if needed */
> + if (status->busy_time > 0x) {
> + status->busy_time >>= 10;
> + status->total_time >>= 10;
> + }
> +
> + if (status->busy_time > status->total_time)
> + status->busy_time = status->total_time;
> +
> + status->busy_time *= 100;
> + status->busy_time /= status->total_time ? : 1;
> +
> + /* Avoid division by 0 */
> + status->busy_time = status->busy_time ? : 1;
> + status->total_time = 100;
> +}
Not sure that works if the devfreq governor is not on-demand.
Is it possible to use the energy model directly in devfreq to compute
the energy consumption given the state transitions since the last reading ?
The power will be read directly from devfreq which will return:
nrj + (current_power * (jiffies - last_update)) / (jiffies - last_update)
The devfreq cooling device driver would result in a much simpler code, no?
> static int devfreq_cooling_get_requested_power(struct thermal_cooling_device
> *cdev,
> struct thermal_zone_device *tz,
> @@ -234,14 +252,22 @@ static int devfreq_cooling_get_requested_power(struct
> thermal_cooling_device *cd
> {
> struct devfreq_cooling_device *dfc = cdev->devdata;
> struct devfreq *df = dfc->devfreq;
> - struct devfreq_dev_status *status = >last_status;
> + struct devfreq_dev_status status;
> unsigned long state;
> - unsigned long freq = status->current_frequency;
> + unsigned long freq;
> unsigned long voltage;
> u32 dyn_power = 0;
> u32 static_power = 0;
> int res;
>
> + mutex_lock(>lock);
> + res = df->profile->get_dev_status(df->dev.parent, );
> + mutex_unlock(>lock);
> + if (res)
> + return res;
> +
> + freq = status.current_frequency;
> +
> state = freq_get_state(dfc, freq);
> if (state == THERMAL_CSTATE_INVALID) {
> res = -EAGAIN;
> @@ -269,16 +295,18 @@ static int devfreq_cooling_get_requested_power(struct
> thermal_cooling_device *cd
> } else {
> dyn_power = dfc->power_table[state];
>
> + _normalize_load();
> +
> /* Scale dynamic power for utilization */
> - dyn_power *= status->busy_time;
> - dyn_power /= status->total_time;
> + dyn_power *= status.busy_time;
> + dyn_power /= status.total_time;
> /* Get static power */
> static_power = get_static_power(dfc, freq);
>
> *power = dyn_power + static_power;
> }
>
> - trace_thermal_power_devfreq_get_power(cdev, status, freq, *power);
> + trace_thermal_power_devfreq_get_power(cdev, , freq, *power);
>
> return 0;
> fail:
> @@ -312,14 +340,20 @@ static int devfreq_cooling_power2state(struct
> thermal_cooling_device *cdev,
> {
> struct devfreq_cooling_device *dfc = cdev->devdata;
> struct devfreq *df = dfc->devfreq;
> - struct devfreq_dev_status *status = >last_status;
> - unsigned long freq = status->current_frequency;
> + struct devfreq_dev_status status;
> unsigned long busy_time;
> + unsigned long freq;
> s32 dyn_power;
> u32 static_power;
> s32 est_power;
> int i;
>
> + mutex_lock(>lock);
> + status = df->last_status;
> + mutex_unlock(>lock);
> +
> + freq = status.current_frequency;
> +
> if (dfc->power_ops->get_real_power) {
> /* Scale for resource utilization */
> est_power = power * dfc->res_util;
> @@ -331,8 +365,8 @@ static int devfreq_cooling_power2state(struct
> thermal_cooling_device *cdev,
> dyn_power = dyn_power > 0 ? dyn_power : 0;
>
> /* Scale dynamic
Re: [PATCH v2 4/8] dt-bindings: phy: convert HDMI PHY binding to YAML schema
On Wed, 2020-10-14 at 12:44 +0800, CK Hu wrote: > Hi, Chunfeng: > > On Tue, 2020-10-13 at 16:52 +0800, Chunfeng Yun wrote: > > Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml > > > > Signed-off-by: Chunfeng Yun > > --- > > v2: fix binding check warning of reg in example > > --- > > .../display/mediatek/mediatek,hdmi.txt| 17 +--- > > .../bindings/phy/mediatek,hdmi-phy.yaml | 90 +++ > > 2 files changed, 91 insertions(+), 16 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > > index 7b124242b0c5..edac18951a75 100644 > > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt > > @@ -50,22 +50,7 @@ Required properties: > > > > HDMI PHY > > > > - > > -The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel > > -output and drives the HDMI pads. > > - > > -Required properties: > > -- compatible: "mediatek,-hdmi-phy" > > -- reg: Physical base address and length of the module's registers > > -- clocks: PLL reference clock > > -- clock-names: must contain "pll_ref" > > -- clock-output-names: must be "hdmitx_dig_cts" on mt8173 > > -- #phy-cells: must be <0> > > -- #clock-cells: must be <0> > > - > > -Optional properties: > > -- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa > > -- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c > > +See phy/mediatek,hdmi-phy.yaml > > > > Example: > > > > diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml > > b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml > > new file mode 100644 > > index ..77df50204606 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml > > @@ -0,0 +1,90 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +# Copyright (c) 2020 MediaTek > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding > > + > > +maintainers: > > + - CK Hu > > I think you should remove "CK Hu " and add latest > mediatek drm maintainer: Ok, will do it, thanks > > DRM DRIVERS FOR MEDIATEK > M:Chun-Kuang Hu > M:Philipp Zabel > L:dri-devel@lists.freedesktop.org > S:Supported > F:Documentation/devicetree/bindings/display/mediatek/ > F:drivers/gpu/drm/mediatek/ > > Regards, > CK ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC] drm/nouveau: fix memory leak in nvkm_iccsense_oneinit
struct pw_rail_t is allocated as an array in function nvios_iccsense_parse,
and stored to a struct member of local variable. However, the array is not
freed when the local variable becomes invalid, and the reference is not
passed on, leading to a memory leak.
Fix this by freeing struct pw_rail_t when exiting nvkm_iccsense_oneinit.
Signed-off-by: Keita Suzuki
---
drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
index fecfa6afcf54..8ba8d8e3f52a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/iccsense/base.c
@@ -280,8 +280,10 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
}
rail = kmalloc(sizeof(*rail), GFP_KERNEL);
- if (!rail)
+ if (!rail) {
+ kfree(stbl.rail);
return -ENOMEM;
+ }
rail->read = read;
rail->sensor = sensor;
@@ -291,6 +293,7 @@ nvkm_iccsense_oneinit(struct nvkm_subdev *subdev)
list_add_tail(>head, >rails);
}
}
+ kfree(stbl.rail);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/msm/dp: fixes wrong connection state caused by failure of link train
Connection state is not set correctly happen when either failure of link
train due to cable unplugged in the middle of aux channel reading or
cable plugged in while in suspended state. This patch fixes these problems.
This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF.
Changes in V2:
-- Add more information to commit message.
Changes in V3:
-- change base
Changes in V4:
-- add Fixes tag
Fixes: 22688d4067f6 (drm/msm/dp: return correct connection status after suspend)
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 42 ++---
drivers/gpu/drm/msm/dp/dp_panel.c | 5
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index cb92d0c61a2f..c0665a0a4c78 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -45,7 +45,7 @@ enum {
ST_CONNECT_PENDING,
ST_CONNECTED,
ST_DISCONNECT_PENDING,
- ST_SUSPEND_PENDING,
+ ST_DISPLAY_OFF,
ST_SUSPENDED,
};
@@ -503,7 +503,7 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
+ if (state == ST_DISPLAY_OFF || state == ST_SUSPENDED) {
mutex_unlock(>event_mutex);
return 0;
}
@@ -525,14 +525,14 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
hpd->hpd_high = 1;
ret = dp_display_usbpd_configure_cb(>pdev->dev);
- if (ret) { /* failed */
+ if (ret) { /* link train failed */
hpd->hpd_high = 0;
dp->hpd_state = ST_DISCONNECTED;
+ } else {
+ /* start sentinel checking in case of missing uevent */
+ dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
}
- /* start sanity checking */
- dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
-
mutex_unlock(>event_mutex);
/* uevent will complete connection part */
@@ -577,11 +577,6 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
- mutex_unlock(>event_mutex);
- return 0;
- }
-
if (state == ST_DISCONNECT_PENDING || state == ST_DISCONNECTED) {
mutex_unlock(>event_mutex);
return 0;
@@ -608,7 +603,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
*/
dp_display_usbpd_disconnect_cb(>pdev->dev);
- /* start sanity checking */
+ /* start sentinel checking in case of missing uevent */
dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0, DP_TIMEOUT_5_SECOND);
/* signal the disconnect event early to ensure proper teardown */
@@ -648,7 +643,7 @@ static int dp_irq_hpd_handle(struct dp_display_private *dp,
u32 data)
/* irq_hpd can happen at either connected or disconnected state */
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
+ if (state == ST_DISPLAY_OFF) {
mutex_unlock(>event_mutex);
return 0;
}
@@ -1073,7 +1068,7 @@ static irqreturn_t dp_display_irq_handler(int irq, void
*dev_id)
}
if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) {
- /* delete connect pending event first */
+ /* stop sentinel connect pending checking */
dp_del_event(dp, EV_CONNECT_PENDING_TIMEOUT);
dp_add_event(dp, EV_IRQ_HPD_INT, 0, 0);
}
@@ -1204,13 +1199,10 @@ static int dp_pm_resume(struct device *dev)
status = dp_catalog_hpd_get_state_status(dp->catalog);
- if (status) {
+ if (status)
dp->dp_display.is_connected = true;
- } else {
+ else
dp->dp_display.is_connected = false;
- /* make sure next resume host_init be called */
- dp->core_initialized = false;
- }
mutex_unlock(>event_mutex);
@@ -1232,6 +1224,9 @@ static int dp_pm_suspend(struct device *dev)
dp->hpd_state = ST_SUSPENDED;
+ /* host_init will be called at pm_resume */
+ dp->core_initialized = false;
+
mutex_unlock(>event_mutex);
return 0;
@@ -1361,6 +1356,7 @@ int msm_dp_display_enable(struct msm_dp *dp, struct
drm_encoder *encoder)
mutex_lock(_display->event_mutex);
+ /* stop sentinel checking */
dp_del_event(dp_display, EV_CONNECT_PENDING_TIMEOUT);
rc = dp_display_set_mode(dp, _display->dp_mode);
@@ -1379,7 +1375,7 @@ int msm_dp_display_enable(struct msm_dp *dp, struct
drm_encoder *encoder)
state = dp_display->hpd_state;
- if
Re: [RFC PATCH 1/4] Add a RPMSG driver for the APU in the mt8183
Hi Alexandre,
On Wed, Sep 30, 2020 at 01:53:47PM +0200, Alexandre Bailon wrote:
> This adds a driver to communicate with the APU available
> in the mt8183. The driver is generic and could be used for other APU.
> It mostly provides a userspace interface to send messages and
> and share big buffers with the APU.
>
> Signed-off-by: Alexandre Bailon
> ---
> drivers/rpmsg/Kconfig | 9 +
> drivers/rpmsg/Makefile | 1 +
> drivers/rpmsg/apu_rpmsg.c | 606 +
> drivers/rpmsg/apu_rpmsg.h | 52 +++
> include/uapi/linux/apu_rpmsg.h | 36 ++
> 5 files changed, 704 insertions(+)
> create mode 100644 drivers/rpmsg/apu_rpmsg.c
> create mode 100644 drivers/rpmsg/apu_rpmsg.h
> create mode 100644 include/uapi/linux/apu_rpmsg.h
>
> diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> index f96716893c2a..3437c6fc8647 100644
> --- a/drivers/rpmsg/Kconfig
> +++ b/drivers/rpmsg/Kconfig
> @@ -64,4 +64,13 @@ config RPMSG_VIRTIO
> select RPMSG
> select VIRTIO
>
> +config RPMSG_APU
> + tristate "APU RPMSG driver"
> + help
> + This provides a RPMSG driver that provides some facilities to
> + communicate with an accelerated processing unit (APU).
> + This creates one or more char files that could be used by userspace
> + to send a message to an APU. In addition, this also take care of
> + sharing the memory buffer with the APU.
> +
> endmenu
> diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
> index ffe932ef6050..93e0f3de99c9 100644
> --- a/drivers/rpmsg/Makefile
> +++ b/drivers/rpmsg/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_RPMSG_QCOM_GLINK_RPM) += qcom_glink_rpm.o
> obj-$(CONFIG_RPMSG_QCOM_GLINK_SMEM) += qcom_glink_smem.o
> obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
> obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
> +obj-$(CONFIG_RPMSG_APU) += apu_rpmsg.o
> diff --git a/drivers/rpmsg/apu_rpmsg.c b/drivers/rpmsg/apu_rpmsg.c
> new file mode 100644
> index ..5131b8b8e1f2
> --- /dev/null
> +++ b/drivers/rpmsg/apu_rpmsg.c
> @@ -0,0 +1,606 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright 2020 BayLibre SAS
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "rpmsg_internal.h"
> +
> +#include
> +
> +#include "apu_rpmsg.h"
> +
> +/* Maximum of APU devices supported */
> +#define APU_DEV_MAX 2
> +
> +#define dev_to_apu(dev) container_of(dev, struct rpmsg_apu, dev)
> +#define cdev_to_apu(i_cdev) container_of(i_cdev, struct rpmsg_apu, cdev)
> +
> +struct rpmsg_apu {
> + struct rpmsg_device *rpdev;
> + struct cdev cdev;
> + struct device dev;
> +
> + struct rproc *rproc;
> + struct iommu_domain *domain;
> + struct iova_domain *iovad;
> + int iova_limit_pfn;
> +};
> +
> +struct rpmsg_request {
> + struct completion completion;
> + struct list_head node;
> + void *req;
> +};
> +
> +struct apu_buffer {
> + int fd;
> + struct dma_buf *dma_buf;
> + struct dma_buf_attachment *attachment;
> + struct sg_table *sg_table;
> + u32 iova;
> +};
> +
> +/*
> + * Shared IOVA domain.
> + * The MT8183 has two VP6 core but they are sharing the IOVA.
> + * They could be used alone, or together. In order to avoid conflict,
> + * create an IOVA domain that could be shared by those two core.
> + * @iovad: The IOVA domain to share between the APU cores
> + * @refcount: Allow to automatically release the IOVA domain once all the APU
> + *cores has been stopped
> + */
> +struct apu_iova_domain {
> + struct iova_domain iovad;
> + struct kref refcount;
> +};
> +
> +static dev_t rpmsg_major;
> +static DEFINE_IDA(rpmsg_ctrl_ida);
> +static DEFINE_IDA(rpmsg_minor_ida);
> +static DEFINE_IDA(req_ida);
> +static LIST_HEAD(requests);
> +static struct apu_iova_domain *apu_iovad;
> +
> +static int apu_rpmsg_callback(struct rpmsg_device *dev, void *data, int
> count,
> + void *priv, u32 addr)
> +{
> + struct rpmsg_request *rpmsg_req;
> + struct apu_dev_request *hdr = data;
> +
> + list_for_each_entry(rpmsg_req, , node) {
> + struct apu_dev_request *tmp_hdr = rpmsg_req->req;
> +
> + if (hdr->id == tmp_hdr->id) {
> + memcpy(rpmsg_req->req, data, count);
> + complete(_req->completion);
> +
> + return 0;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int apu_device_memory_map(struct rpmsg_apu *apu,
> + struct apu_buffer *buffer)
> +{
> + struct rpmsg_device *rpdev = apu->rpdev;
> + phys_addr_t phys;
> + int total_buf_space;
> + int iova_pfn;
> + int ret;
> +
> + if (!buffer->fd)
> + return 0;
> +
> + buffer->dma_buf = dma_buf_get(buffer->fd);
> + if (IS_ERR(buffer->dma_buf)) {
> +
Re: [PATCH v2 14/17] resource: Move devmem revoke code to resource framework
On Fri, Oct 09, 2020 at 11:28:54AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote:
> >
> > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
> > > >
> > > > On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
> > > >
> > > > > +struct address_space *iomem_get_mapping(void)
> > > > > +{
> > > > > + return iomem_inode->i_mapping;
> > > >
> > > > This should pair an acquire with the release below
> > > >
> > > > > + /*
> > > > > + * Publish /dev/mem initialized.
> > > > > + * Pairs with smp_load_acquire() in revoke_iomem().
> > > > > + */
> > > > > + smp_store_release(_inode, inode);
> > > >
> > > > However, this seems abnormal, initcalls rarely do this kind of stuff
> > > > with global data..
> > > >
> > > > The kernel crashes if this fs_initcall is raced with
> > > > iomem_get_mapping() due to the unconditional dereference, so I think
> > > > it can be safely switched to a simple assignment.
> > >
> > > Ah yes I checked this all, but forgot to correctly annotate the
> > > iomem_get_mapping access. For reference, see b34e7e298d7a ("/dev/mem:
> > > Add missing memory barriers for devmem_inode").
> >
> > Oh yikes, so revoke_iomem can run concurrently during early boot,
> > tricky.
>
> It runs early because request_mem_region() can run before fs_initcall.
> Rather than add an unnecessary lock just arrange for the revoke to be
> skipped before the inode is initialized. The expectation is that any
> early resource reservations will block future userspace mapping
> attempts.
Actually, on this point a simple WRITE_ONCE/READ_ONCE pairing is OK,
Paul once explained that the pointer chase on the READ_ONCE side is
required to be like an acquire - this is why rcu_dereference is just
READ_ONCE
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/mediatek: mtk_hdmi: add MT8167 support for HDMI
Hi Chun-Kuang,
On Wed, Oct 14, 2020 at 3:00 PM Chun-Kuang Hu wrote:
>
> Hi, Fabien:
>
> Fabien Parent 於 2020年10月14日 週三 上午2:19寫道：
> >
> > Add support for HDMI on MT8167. HDMI on MT8167 is similar to
> > MT8173/MT2701 execpt for the two registers: SYS_CFG1C and SYS_CFG20
>
> I think you should drop this series. According to Mediatek HDMI
> binding document [1], the second parameter of mediatek,syscon-hdmi is
> the register offset. I think you could set register offset to 0x800
> for mt8167.
Ok, thank you. I will try it.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt?h=v5.9
>
> Regards,
> Chun-Kuang.
>
> >
> > Signed-off-by: Fabien Parent
> > ---
> >
> > Changelog:
> > v2: fix name of pdata structure
> >
> > drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +++
> > drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 2 ++
> > 2 files changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > index 57370c036497..484ea9cd654a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > @@ -1835,9 +1835,16 @@ static struct mtk_hdmi_data mt8173_hdmi_driver_data
> > = {
> > .sys_cfg20 = HDMI_SYS_CFG20,
> > };
> >
> > +static struct mtk_hdmi_data mt8167_hdmi_driver_data = {
> > + .sys_cfg1c = MT8167_HDMI_SYS_CFG1C,
> > + .sys_cfg20 = MT8167_HDMI_SYS_CFG20,
> > +};
> > +
> > static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
> > { .compatible = "mediatek,mt8173-hdmi",
> > .data = _hdmi_driver_data },
> > + { .compatible = "mediatek,mt8167-hdmi",
> > + .data = _hdmi_driver_data },
> > {}
> > };
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > index 2050ba45b23a..a0f9c367d7aa 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
> > @@ -195,6 +195,7 @@
> > #define GEN_RGB(0 << 7)
> >
> > #define HDMI_SYS_CFG1C 0x000
> > +#define MT8167_HDMI_SYS_CFG1C 0x800
> > #define HDMI_ONBIT(0)
> > #define HDMI_RST BIT(1)
> > #define ANLG_ONBIT(2)
> > @@ -211,6 +212,7 @@
> > #define HTPLG_PIN_SEL_OFF BIT(30)
> > #define AES_EFUSE_ENABLE BIT(31)
> > #define HDMI_SYS_CFG20 0x004
> > +#define MT8167_HDMI_SYS_CFG20 0x804
> > #define DEEP_COLOR_MODE_MASK (3 << 1)
> > #define COLOR_8BIT_MODE(0 << 1)
> > #define COLOR_10BIT_MODE (1 << 1)
> > --
> > 2.28.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
