dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH] drm/drm_file.c: Define drm_send_event_helper() as 'static'
by Fabio M. De Francesco 26 Apr '21

26 Apr '21

drm_send_event_helper() has not prototype, it has internal linkage and therefore it should be defined with storage class 'static'. Signed-off-by: Fabio M. De Francesco <fmdefrancesco(a)gmail.com> --- drivers/gpu/drm/drm_file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c index 7efbccffc2ea..17f38d873972 100644 --- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -786,7 +786,7 @@ EXPORT_SYMBOL(drm_event_cancel_free); * The timestamp variant of dma_fence_signal is used when the caller * sends a valid timestamp. */ -void drm_send_event_helper(struct drm_device *dev, +static void drm_send_event_helper(struct drm_device *dev, struct drm_pending_event *e, ktime_t timestamp) { assert_spin_locked(&dev->event_lock); -- 2.31.1

2 1

Re: [PATCH 08/12] vfio/gvt: Convert to use vfio_register_group_dev()
by Jason Gunthorpe 26 Apr '21

26 Apr '21

On Mon, Apr 26, 2021 at 04:13:55PM +0200, Christoph Hellwig wrote: > > diff --git a/drivers/vfio/mdev/Makefile b/drivers/vfio/mdev/Makefile > > index ff9ecd80212503..7c236ba1b90eb1 100644 > > +++ b/drivers/vfio/mdev/Makefile > > @@ -1,5 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > > > -mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o vfio_mdev.o > > +mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o > > > > obj-$(CONFIG_VFIO_MDEV) += mdev.o > > diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c > > index 51b8a9fcf866ad..f95d01b57fb168 100644 > > +++ b/drivers/vfio/mdev/mdev_core.c > > I think all these mdev core changes belong into a separate commit with a > separate commit log. Gah, they were split, I must have flubbed up a rebase on Friday :\ commit daeb9dd3a152e21d11960805b55e34967987e8cf vfio/mdev: Remove vfio_mdev.c Now that all mdev drivers directly create their own mdev_device driver and directly register with the vfio core's vfio_device_ops this is all dead code. Delete vfio_mdev.c and the mdev_parent_ops members that are connected to it. Preserve VFIO's design of allowing mdev drivers to be !GPL by allowing the three functions that replace this module for !GPL usage. This goes along with the other 19 symbols that are already marked !GPL in VFIO. Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> I'll fix it > > static int __init mdev_init(void) > > { > > - int rc; > > - > > - rc = mdev_bus_register(); > > - if (rc) > > - return rc; > > - rc = mdev_register_driver(&vfio_mdev_driver); > > - if (rc) > > - goto err_bus; > > - return 0; > > -err_bus: > > - mdev_bus_unregister(); > > - return rc; > > + return mdev_bus_register(); > > Weird indentation. But I think it would be best to just kill off the > mdev_init wrapper anyway. Oh, right good point > > diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/vfio/mdev/mdev_driver.c > > index 6e96c023d7823d..0012a9ee7cb0a4 100644 > > +++ b/drivers/vfio/mdev/mdev_driver.c > > @@ -74,15 +74,8 @@ static int mdev_remove(struct device *dev) > > static int mdev_match(struct device *dev, struct device_driver *drv) > > { > > struct mdev_device *mdev = to_mdev_device(dev); > > + > > + return drv == &mdev->type->parent->ops->device_driver->driver; > > } > > Btw, I think we don't even need ->match with the switch to use > device_bind_driver that I suggested. See my other email for why it is like this.. > > -EXPORT_SYMBOL_GPL(vfio_init_group_dev); > > +EXPORT_SYMBOL(vfio_init_group_dev); > > > -EXPORT_SYMBOL_GPL(vfio_register_group_dev); > > +EXPORT_SYMBOL(vfio_register_group_dev); > > > -EXPORT_SYMBOL_GPL(vfio_unregister_group_dev); > > +EXPORT_SYMBOL(vfio_unregister_group_dev); > > Err, no. vfio should remain EXPORT_SYMBOL_GPL, just because the weird > mdev "GPL condom" that should never have been merged in that form went away. VFIO is already !GPL - there are 19 symbols supporting this today. What happened here is that this patch make all of those symbols unusable !GPL by changing how registration works so you can't get the vfio_device argument to use with the API family. So, either the two registration functions need to be !GPL to make the other 19 symbols make sense, or the entire !GPL needs to be ripped out. The lost commit message above was explaining this. Since it is predominately !GPL today, I'd prefer a discussion on changing VFIO to be GPL only to be in its own patch proposing removing all 22 !GPL symbols. Those are always fun threads.. Jason

1 0

[PATCH v2] drm/i915: Invoke BXT _DSM to enable MUX on HP Workstation laptops
by Kai-Heng Feng 26 Apr '21

26 Apr '21

On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX to discrete GFX after S3. This is not desirable, because userspace will treat connected display as a new one, losing display settings. The expected behavior is to let discrete GFX drives all external displays. The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX. The method is inside the BXT _DSM, so add the _DSM and call it accordingly. I also tested some MUX-less and iGPU only laptops with the BXT _DSM, no regression was found. v2: - Forward declare struct pci_dev. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113 References: https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh… Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/gpu/drm/i915/display/intel_acpi.c | 17 +++++++++++++++++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 +++ drivers/gpu/drm/i915/i915_drv.c | 5 +++++ 3 files changed, 25 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c b/drivers/gpu/drm/i915/display/intel_acpi.c index 833d0c1be4f1..c7b57c22dce3 100644 --- a/drivers/gpu/drm/i915/display/intel_acpi.c +++ b/drivers/gpu/drm/i915/display/intel_acpi.c @@ -14,11 +14,16 @@ #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */ #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */ +#define INTEL_DSM_FN_PLATFORM_BXT_MUX_INFO 0 /* No args */ static const guid_t intel_dsm_guid = GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f, 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c); +static const guid_t intel_bxt_dsm_guid = + GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260, + 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14); + static char *intel_dsm_port_name(u8 id) { switch (id) { @@ -176,6 +181,18 @@ void intel_unregister_dsm_handler(void) { } +void intel_bxt_dsm_detect(struct pci_dev *pdev) +{ + acpi_handle dhandle; + + dhandle = ACPI_HANDLE(&pdev->dev); + if (!dhandle) + return; + + acpi_evaluate_dsm(dhandle, &intel_bxt_dsm_guid, INTEL_DSM_REVISION_ID, + INTEL_DSM_FN_PLATFORM_BXT_MUX_INFO, NULL); +} + /* * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All Devices * Attached to the Display Adapter). diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h b/drivers/gpu/drm/i915/display/intel_acpi.h index e8b068661d22..d2d560d63bb3 100644 --- a/drivers/gpu/drm/i915/display/intel_acpi.h +++ b/drivers/gpu/drm/i915/display/intel_acpi.h @@ -6,15 +6,18 @@ #ifndef __INTEL_ACPI_H__ #define __INTEL_ACPI_H__ +struct pci_dev; struct drm_i915_private; #ifdef CONFIG_ACPI void intel_register_dsm_handler(void); void intel_unregister_dsm_handler(void); +void intel_bxt_dsm_detect(struct pci_dev *pdev); void intel_acpi_device_id_update(struct drm_i915_private *i915); #else static inline void intel_register_dsm_handler(void) { return; } static inline void intel_unregister_dsm_handler(void) { return; } +static inline void intel_bxt_dsm_detect(struct pci_dev *pdev) { return; } static inline void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; } #endif /* CONFIG_ACPI */ diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 785dcf20c77b..57b12068aab4 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -853,6 +853,8 @@ int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto out_cleanup_gem; + intel_bxt_dsm_detect(pdev); + i915_driver_register(i915); enable_rpm_wakeref_asserts(&i915->runtime_pm); @@ -1215,6 +1217,7 @@ int i915_suspend_switcheroo(struct drm_i915_private *i915, pm_message_t state) static int i915_drm_resume(struct drm_device *dev) { struct drm_i915_private *dev_priv = to_i915(dev); + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev); int ret; disable_rpm_wakeref_asserts(&dev_priv->runtime_pm); @@ -1271,6 +1274,8 @@ static int i915_drm_resume(struct drm_device *dev) intel_gvt_resume(dev_priv); + intel_bxt_dsm_detect(pdev); + enable_rpm_wakeref_asserts(&dev_priv->runtime_pm); return 0; -- 2.30.2

3 6

[PATCH v3 1/4] drm/i915/uapi: hide kernel doc warnings
by Matthew Auld 26 Apr '21

26 Apr '21

It's not properly formatted kernel doc, just nerf the warnings for now. Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Jordan Justen <jordan.l.justen(a)intel.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Kenneth Graunke <kenneth(a)whitecape.org> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Dave Airlie <airlied(a)gmail.com> Cc: dri-devel(a)lists.freedesktop.org Cc: mesa-dev(a)lists.freedesktop.org --- include/uapi/drm/i915_drm.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index ddc47bbf48b6..a50257cde9ff 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1054,12 +1054,12 @@ struct drm_i915_gem_exec_fence { __u32 flags; }; -/** +/* * See drm_i915_gem_execbuffer_ext_timeline_fences. */ #define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0 -/** +/* * This structure describes an array of drm_syncobj and associated points for * timeline variants of drm_syncobj. It is invalid to append this structure to * the execbuf if I915_EXEC_FENCE_ARRAY is set. @@ -1700,7 +1700,7 @@ struct drm_i915_gem_context_param { __u64 value; }; -/** +/* * Context SSEU programming * * It may be necessary for either functional or performance reason to configure @@ -2067,7 +2067,7 @@ struct drm_i915_perf_open_param { __u64 properties_ptr; }; -/** +/* * Enable data capture for a stream that was either opened in a disabled state * via I915_PERF_FLAG_DISABLED or was later disabled via * I915_PERF_IOCTL_DISABLE. @@ -2081,7 +2081,7 @@ struct drm_i915_perf_open_param { */ #define I915_PERF_IOCTL_ENABLE _IO('i', 0x0) -/** +/* * Disable data capture for a stream. * * It is an error to try and read a stream that is disabled. @@ -2090,7 +2090,7 @@ struct drm_i915_perf_open_param { */ #define I915_PERF_IOCTL_DISABLE _IO('i', 0x1) -/** +/* * Change metrics_set captured by a stream. * * If the stream is bound to a specific context, the configuration change @@ -2103,7 +2103,7 @@ struct drm_i915_perf_open_param { */ #define I915_PERF_IOCTL_CONFIG _IO('i', 0x2) -/** +/* * Common to all i915 perf records */ struct drm_i915_perf_record_header { @@ -2151,7 +2151,7 @@ enum drm_i915_perf_record_type { DRM_I915_PERF_RECORD_MAX /* non-ABI */ }; -/** +/* * Structure to upload perf dynamic configuration into the kernel. */ struct drm_i915_perf_oa_config { -- 2.26.3

7 26

[PATCH] display: Fix typo issue
by zuoqilin1＠163.com 26 Apr '21

26 Apr '21

From: zuoqilin <zuoqilin(a)yulong.com> Change 'befor' to 'before'. Signed-off-by: zuoqilin <zuoqilin(a)yulong.com> --- drivers/gpu/drm/i915/display/vlv_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c index f94025e..45187ff 100644 --- a/drivers/gpu/drm/i915/display/vlv_dsi.c +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c @@ -846,7 +846,7 @@ static void intel_dsi_pre_enable(struct intel_atomic_state *state, intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); /* Enable port in pre-enable phase itself because as per hw team - * recommendation, port should be enabled befor plane & pipe */ + * recommendation, port should be enabled before plane & pipe */ if (is_cmd_mode(intel_dsi)) { for_each_dsi_port(port, intel_dsi->ports) intel_de_write(dev_priv, -- 1.9.1

2 1

[drm-intel:drm-intel-next 3/4] drivers/gpu/drm/i915/display/intel_dp_hdcp.c:582 intel_dp_hdcp2_read_msg() error: uninitialized symbol 'msg_end'.
by Dan Carpenter 26 Apr '21

26 Apr '21

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next head: b29854ec3b9ca6512a783e2153465f27a777a654 commit: 989cf9a93892409cf8e84c30c0faaa522ac83807 [3/4] drm/i915/hdcp: Add DP HDCP2.2 timeout to read entire msg config: i386-randconfig-m031-20210401 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> smatch warnings: drivers/gpu/drm/i915/display/intel_dp_hdcp.c:582 intel_dp_hdcp2_read_msg() error: uninitialized symbol 'msg_end'. vim +/msg_end +582 drivers/gpu/drm/i915/display/intel_dp_hdcp.c d079b7e4b6389e Sean Paul 2020-08-18 526 static d079b7e4b6389e Sean Paul 2020-08-18 527 int intel_dp_hdcp2_read_msg(struct intel_digital_port *dig_port, d079b7e4b6389e Sean Paul 2020-08-18 528 u8 msg_id, void *buf, size_t size) d079b7e4b6389e Sean Paul 2020-08-18 529 { d079b7e4b6389e Sean Paul 2020-08-18 530 struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev); d079b7e4b6389e Sean Paul 2020-08-18 531 unsigned int offset; d079b7e4b6389e Sean Paul 2020-08-18 532 u8 *byte = buf; d079b7e4b6389e Sean Paul 2020-08-18 533 ssize_t ret, bytes_to_recv, len; d079b7e4b6389e Sean Paul 2020-08-18 534 const struct hdcp2_dp_msg_data *hdcp2_msg_data; 989cf9a9389240 Anshuman Gupta 2021-03-24 535 ktime_t msg_end; ^^^^^^^^^^^^^^^^ 989cf9a9389240 Anshuman Gupta 2021-03-24 536 bool msg_expired; d079b7e4b6389e Sean Paul 2020-08-18 537 d079b7e4b6389e Sean Paul 2020-08-18 538 hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id); d079b7e4b6389e Sean Paul 2020-08-18 539 if (!hdcp2_msg_data) d079b7e4b6389e Sean Paul 2020-08-18 540 return -EINVAL; d079b7e4b6389e Sean Paul 2020-08-18 541 offset = hdcp2_msg_data->offset; d079b7e4b6389e Sean Paul 2020-08-18 542 d079b7e4b6389e Sean Paul 2020-08-18 543 ret = intel_dp_hdcp2_wait_for_msg(dig_port, hdcp2_msg_data); d079b7e4b6389e Sean Paul 2020-08-18 544 if (ret < 0) d079b7e4b6389e Sean Paul 2020-08-18 545 return ret; d079b7e4b6389e Sean Paul 2020-08-18 546 d079b7e4b6389e Sean Paul 2020-08-18 547 if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) { d079b7e4b6389e Sean Paul 2020-08-18 548 ret = get_receiver_id_list_size(dig_port); d079b7e4b6389e Sean Paul 2020-08-18 549 if (ret < 0) d079b7e4b6389e Sean Paul 2020-08-18 550 return ret; d079b7e4b6389e Sean Paul 2020-08-18 551 d079b7e4b6389e Sean Paul 2020-08-18 552 size = ret; d079b7e4b6389e Sean Paul 2020-08-18 553 } d079b7e4b6389e Sean Paul 2020-08-18 554 bytes_to_recv = size - 1; ^^^^^^^^^^^^^^^^^^^^^^^^ Is it possible to for "size" to be 1? d079b7e4b6389e Sean Paul 2020-08-18 555 d079b7e4b6389e Sean Paul 2020-08-18 556 /* DP adaptation msgs has no msg_id */ d079b7e4b6389e Sean Paul 2020-08-18 557 byte++; d079b7e4b6389e Sean Paul 2020-08-18 558 d079b7e4b6389e Sean Paul 2020-08-18 559 while (bytes_to_recv) { In that case, we would never enter this loop. d079b7e4b6389e Sean Paul 2020-08-18 560 len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ? d079b7e4b6389e Sean Paul 2020-08-18 561 DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_recv; d079b7e4b6389e Sean Paul 2020-08-18 562 989cf9a9389240 Anshuman Gupta 2021-03-24 563 /* Entire msg read timeout since initiate of msg read */ 989cf9a9389240 Anshuman Gupta 2021-03-24 564 if (bytes_to_recv == size - 1 && hdcp2_msg_data->msg_read_timeout > 0) 989cf9a9389240 Anshuman Gupta 2021-03-24 565 msg_end = ktime_add_ms(ktime_get_raw(), 989cf9a9389240 Anshuman Gupta 2021-03-24 566 hdcp2_msg_data->msg_read_timeout); 989cf9a9389240 Anshuman Gupta 2021-03-24 567 d079b7e4b6389e Sean Paul 2020-08-18 568 ret = drm_dp_dpcd_read(&dig_port->dp.aux, offset, d079b7e4b6389e Sean Paul 2020-08-18 569 (void *)byte, len); d079b7e4b6389e Sean Paul 2020-08-18 570 if (ret < 0) { d079b7e4b6389e Sean Paul 2020-08-18 571 drm_dbg_kms(&i915->drm, "msg_id %d, ret %zd\n", d079b7e4b6389e Sean Paul 2020-08-18 572 msg_id, ret); d079b7e4b6389e Sean Paul 2020-08-18 573 return ret; d079b7e4b6389e Sean Paul 2020-08-18 574 } d079b7e4b6389e Sean Paul 2020-08-18 575 d079b7e4b6389e Sean Paul 2020-08-18 576 bytes_to_recv -= ret; d079b7e4b6389e Sean Paul 2020-08-18 577 byte += ret; d079b7e4b6389e Sean Paul 2020-08-18 578 offset += ret; d079b7e4b6389e Sean Paul 2020-08-18 579 } 989cf9a9389240 Anshuman Gupta 2021-03-24 580 989cf9a9389240 Anshuman Gupta 2021-03-24 581 if (hdcp2_msg_data->msg_read_timeout > 0) { 989cf9a9389240 Anshuman Gupta 2021-03-24 @582 msg_expired = ktime_after(ktime_get_raw(), msg_end); 989cf9a9389240 Anshuman Gupta 2021-03-24 583 if (msg_expired) { 989cf9a9389240 Anshuman Gupta 2021-03-24 584 drm_dbg_kms(&i915->drm, "msg_id %d, entire msg read timeout(mSec): %d\n", 989cf9a9389240 Anshuman Gupta 2021-03-24 585 msg_id, hdcp2_msg_data->msg_read_timeout); 989cf9a9389240 Anshuman Gupta 2021-03-24 586 return -ETIMEDOUT; 989cf9a9389240 Anshuman Gupta 2021-03-24 587 } 989cf9a9389240 Anshuman Gupta 2021-03-24 588 } 989cf9a9389240 Anshuman Gupta 2021-03-24 589 d079b7e4b6389e Sean Paul 2020-08-18 590 byte = buf; d079b7e4b6389e Sean Paul 2020-08-18 591 *byte = msg_id; d079b7e4b6389e Sean Paul 2020-08-18 592 d079b7e4b6389e Sean Paul 2020-08-18 593 return size; d079b7e4b6389e Sean Paul 2020-08-18 594 } --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

2 1

[PATCH 1/2] mm/vmscan: add sync_shrinkers function
by Christian König 26 Apr '21

26 Apr '21

To be able to switch to a spinlock and reduce lock contention in the TTM shrinker we don't want to hold a mutex while unmapping and freeing pages from the pool. But then we somehow need to prevent a race between (for example) the shrinker trying to free pages and hotplug trying to remove the device which those pages belong to. Taking and releasing the shrinker semaphore on the write side after unmapping and freeing all pages should make sure that no shrinker is running in paralell any more. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- include/linux/shrinker.h | 1 + mm/vmscan.c | 10 ++++++++++ 2 files changed, 11 insertions(+) diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h index 0f80123650e2..6b75dc372fce 100644 --- a/include/linux/shrinker.h +++ b/include/linux/shrinker.h @@ -92,4 +92,5 @@ extern void register_shrinker_prepared(struct shrinker *shrinker); extern int register_shrinker(struct shrinker *shrinker); extern void unregister_shrinker(struct shrinker *shrinker); extern void free_prealloced_shrinker(struct shrinker *shrinker); +extern void sync_shrinkers(void); #endif diff --git a/mm/vmscan.c b/mm/vmscan.c index 562e87cbd7a1..46cd9c215d73 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -408,6 +408,16 @@ void unregister_shrinker(struct shrinker *shrinker) } EXPORT_SYMBOL(unregister_shrinker); +/** + * sync_shrinker - Wait for all running shrinkers to complete. + */ +void sync_shrinkers(void) +{ + down_write(&shrinker_rwsem); + up_write(&shrinker_rwsem); +} +EXPORT_SYMBOL(sync_shrinkers); + #define SHRINK_BATCH 128 static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, -- 2.25.1

4 6

[v2 0/2] drm: Add support for backlight control of eDP panel on ti-sn65dsi86 bridge
by Rajeev Nandan 26 Apr '21

26 Apr '21

The backlight level of an eDP panel can be controlled through the AUX channel using DPCD registers of the panel. The capability for the Source device to adjust backlight characteristics within the panel, using the Sink device DPCD registers is indicated by the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE bit in the EDP_GENERAL_CAPABILITY_1 register (DPCD Address 701h, bit0). In this configuration, the eDP TCON receives the backlight level information from the host, through the AUX channel. Anderson's patch series [1] exposed the DDC bus from ti-sn65dsi86 bridge, that gives an option to move the backlight control out of the bridge and to create a separate backlight driver. Changes in v2: - Created a new DisplayPort aux backlight driver and moved the code from drm_dp_aux_backlight.c (v1) to the new driver. - Removed the changes done in ti-sn65dsi86 bridge. (Rob Herring) [1] https://lore.kernel.org/dri-devel/20210416223950.3586967-1-dianders@chromiu… Rajeev Nandan (2): dt-bindings: backlight: add DisplayPort aux backlight backlight: Add DisplayPort aux backlight driver .../bindings/leds/backlight/dp-aux-backlight.yaml | 49 +++++ drivers/video/backlight/Kconfig | 7 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/dp_aux_backlight.c | 245 +++++++++++++++++++++ 4 files changed, 302 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml create mode 100644 drivers/video/backlight/dp_aux_backlight.c -- 2.7.4

3 4

Re: [REGRESSION] drm/etnaviv: command buffer outside valid memory window
by Primoz Fiser 26 Apr '21

26 Apr '21

Hi all, we are still affected by this issue from 2019 on 5.10. For example when setting "cma=256M" on phycore imx6q with 2G ram we get: > [ 12.573276] etnaviv etnaviv: command buffer outside valid memory window > [ 12.616460] etnaviv etnaviv: command buffer outside valid memory window > [ 12.662517] etnaviv etnaviv: command buffer outside valid memory window > [ 12.714859] etnaviv etnaviv: command buffer outside valid memory window On the other hand, when we set "cma=128M" this doesn't happen. For now, we were able to get around this issue by applying Lucas' patches: > "[PATCH 1/2] mm: cma: export functions to get CMA base and size" > "[PATCH 2/2] drm/etnaviv: use CMA area to compute linear window offset > if possible" However those didn't get accepted into mainline? Has there been any progress on this? Any tips on how to properly fix this in mainline? BR, Primoz > Am Samstag, den 22.06.2019, 17:16 +0100 schrieb Russell King - ARM Linux admin: > >/While updating my various systems for the TCP SACK issue, I notice />/that while most platforms are happy, the Cubox-i4 is not. During />/boot, we get: />//>/[ 0.000000] cma: Reserved 256 MiB at 0x30000000 />/... />/[ 0.000000] Kernel command line: console=ttymxc0,115200n8 > console=tty1 video=mxcfb0:dev=hdmi root=/dev/nfs rw cma=256M > ahci_imx.hotplug=1 splash resume=/dev/sda1 />/[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, > 524288 bytes) />/[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, > 262144 bytes) />/[ 0.000000] Memory: 1790972K/2097152K available (8471K kernel > code, 693K rwdata, 2844K rodata, 500K init, 8062K bss, 44036K > reserved, 262144K cma-reserved, 1310720K highmem) />/... />/[ 13.101098] etnaviv-gpu 130000.gpu: command buffer outside valid > memory window />/[ 13.171963] etnaviv-gpu 134000.gpu: command buffer outside valid > memory window / > Yes, that's a regression due to different default CMA area placement > and etnaviv not being smart enough to move the linear window to the > right offset. > > Patches to fix this (but have rightfully been shot down, due to > layering violations) are "[PATCH 1/2] mm: cma: export functions to get > CMA base and size" and "[PATCH 2/2] drm/etnaviv: use CMA area to > compute linear window offset if possible". > > >/and shortly after the login prompt appears, the entire SoC appears to />/lock up - it becomes unresponsive on the network, or via serial console />/to sysrq requests. />//>/I suspect the GPU ends up scribbling over the CPU's vector page/kernel />/as a result of the above two etnaviv errors when Xorg attempts to start />/using the GPU. / > This should not be possible. The driver notices that the command buffer > isn't accessible to the GPU, which aborts the GPU init. While the > etnaviv DRM device is still accessible, it will not expose any > enumerable GPU cores to userspace. So there is no way for userspace to > actually submit GPU commands. > > Regards, > Lucas

1 0

Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints
by Simon Ser 26 Apr '21

26 Apr '21

Hi all, I'm working on a Wayland extension [1] that, among other things, allows compositors to advertise the preferred device to be used by Wayland clients. In general, compositors will send a render node. However, in the case of split render/display SoCs, things get a little bit complicated. The Wayland compositor will find the display-only DRM device (usually at /dev/dri/card0). This DRM device will have a DRM primary node, but no DRM render node. The Wayland compositor will create a GBM device from this display-only device, then create an EGL display. Under the hood, Mesa's kmsro will kick in and magically open a render node from a different device. However the compositor has no knowledge of this, and has no way to discover the render node opened by kmsro. This is an issue because the compositor has no render node to send to Wayland clients. The compositor is forced to send a primary node to clients. Clients will need to open the primary node and rely on Mesa's renderonly to once again magically open the render node under the hood. In general clients cannot be expected to be able to open primary nodes. This happens to work on systemd distributions because udev sets a special uaccess tag on the primary node that makes logind grant permissions to users physically logged in on a VT. This will fall apart on non-logind systems and on systems where no user is physically logged in. Additionally, it may be desirable to deny access to primary nodes in sandboxes. So I believe the best way forward would be for the compositor to send the render node to clients. This could prevent clients to allocate buffers suitable for scan-out, but that can be fixed with some kind of buffer constraints negotiation, like we presented at XDC 2020 [2]. There are a few solutions: 1. Require compositors to discover the render device by trying to import a buffer. For each available render device, the compositor would allocate a buffer, export it as a DMA-BUF, import it to the display-only device, then try to drmModeAddFB. 2. Allow compositors to query the render device magically opened by kmsro. This could be done either via EGL_EXT_device_drm, or via a new EGL extension. 3. Allow compositors to query the kernel drivers to know which devices are compatible with each other. Some uAPI to query a compatible display device from a render-only device, or vice-versa, has been suggested in the past. (1) has a number of limitations and gotchas. It requires allocating real buffers, this has a rather big cost for something done at compositor initialization time. It requires to select a buffer format and modifier compatible with both devices, so it can't be isolated in a simple function (and e.g. shared between all compositors in libdrm). Some drivers will allow to drmModeAddFB buffers that can't be scanned out, and will only reject the buffer at atomic commit time. (2) wouldn't work with non-EGL APIs such as Vulkan. Eric Anholt seemed pretty opposed to this idea, but I didn't fully understood why. I don't know how feasible (3) is. The kernel drivers must be able to decide whether buffers coming from another driver can be scanned out, but how early can they give an answer? Can they give an answer solely based on a DRM node, and not a DMA-BUF? Feedback is welcome. Do you agree with the premise that compositors need access to the render node? Do you have any other potential solution in mind? Which solution would you prefer? Thanks, Simon [1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8 [2]: https://xdc2020.x.org/event/9/contributions/634/

4 4

← Newer
1
...
27
28
29
30
31
32
33
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021