dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH] panfrost: make mediatek_mt8183_supplies and mediatek_mt8183_pm_domains static
by Jiapeng Chong 20 Sep '21

20 Sep '21

This symbol is not used outside of panfrost_drv.c, so marks it static. Fix the following sparse warning: drivers/gpu/drm/panfrost/panfrost_drv.c:641:12: warning: symbol 'mediatek_mt8183_supplies' was not declared. Should it be static? drivers/gpu/drm/panfrost/panfrost_drv.c:642:12: warning: symbol 'mediatek_mt8183_pm_domains' was not declared. Should it be static? Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/panfrost/panfrost_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index 077cbbf..82ad9a6 100644 --- a/drivers/gpu/drm/panfrost/panfrost_drv.c +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c @@ -638,8 +638,8 @@ static int panfrost_remove(struct platform_device *pdev) .vendor_quirk = panfrost_gpu_amlogic_quirk, }; -const char * const mediatek_mt8183_supplies[] = { "mali", "sram" }; -const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2" }; +static const char * const mediatek_mt8183_supplies[] = { "mali", "sram" }; +static const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2" }; static const struct panfrost_compatible mediatek_mt8183_data = { .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies), .supply_names = mediatek_mt8183_supplies, -- 1.8.3.1

2 1

[PATCH v3 0/6] drm/i915: Suspend / resume backup- and restore of LMEM.
by Thomas Hellström 20 Sep '21

20 Sep '21

Implement backup and restore of LMEM during suspend / resume. What complicates things a bit is handling of pinned LMEM memory during suspend and the fact that we might be dealing with unmappable LMEM in the future, which makes us want to restrict the number of pinned objects that need memcpy resume. The first two patches are prereq patches implementing object content copy and a generic means of iterating through all objects in a region. The third patch adds the backup / recover / restore functions and the two last patches deal with restricting the number of objects we need to use memcpy for. v2: - Some polishing of patch 4/6, see patch commit message for details (Chris Wilson) - Rework of patch 3/6. v3: - Comment changes in patch 2/6 (Matthew Auld) - A number of changes to patch 3/6, see commit message. - Slightly reword comment in patch 5/6. (Matthew Auld). Thomas Hellström (6): drm/i915/ttm: Implement a function to copy the contents of two TTM-based objects drm/i915/gem: Implement a function to process all gem objects of a region drm/i915 Implement LMEM backup and restore for suspend / resume drm/i915/gt: Register the migrate contexts with their engines drm/i915: Don't back up pinned LMEM context images and rings during suspend drm/i915: Reduce the number of objects subject to memcpy recover drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 21 +- drivers/gpu/drm/i915/gem/i915_gem_pm.c | 95 +++++++- drivers/gpu/drm/i915/gem/i915_gem_pm.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_region.c | 70 ++++++ drivers/gpu/drm/i915/gem/i915_gem_region.h | 37 ++++ drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 98 +++++++-- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 14 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 208 ++++++++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h | 24 ++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 8 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 23 ++ drivers/gpu/drm/i915/gt/intel_engine_pm.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 + .../drm/i915/gt/intel_execlists_submission.c | 2 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 13 +- drivers/gpu/drm/i915/gt/intel_ring.c | 3 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 3 + drivers/gpu/drm/i915/gt/mock_engine.c | 2 + drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 10 +- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- 38 files changed, 652 insertions(+), 60 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h -- 2.31.1

2 15

[PATCH] drm: bridge: it66121: Added it66121 chip external screen status judgment.
by Yunlongli 20 Sep '21

20 Sep '21

fix: Add further confirm if external screens are involved. log: In the actual tests, the IT66121 chip sometimes misjudged whether it had an external screen, so, reference the it66121_user_guid.pdf about Audio/Video data is stable or not A typical initialization of HDMI link should be based on interrupt signal and appropriate register probing. Recommended flow is detailed in IT66121 Programming Guide. Simply put, the microcontroller should monitor the HPD status first. Upon valid HPD event, move on to check RxSENDetect register to see if the receiver chip is ready for further handshaking. When RxSENDetect is asserted, start reading EDID data through DDC channels and carry on the rest of the handshaking subsequently.If the micro-controller makes no use of the interrupt signal as well as the above-mentioned status registers, the link establishment might fail. Please do follow the suggested initialization flow recommended in IT66121 Programming Guide. So, I add the IT66121_SYS_STATUS_SENDECTECT register status detection. Signed-off-by: Yunlongli <liyunlonga(a)uniontech.com> --- drivers/gpu/drm/bridge/ite-it66121.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c index 2f2a09adb4bc..9ed4fa298d11 100644 --- a/drivers/gpu/drm/bridge/ite-it66121.c +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -523,7 +523,7 @@ static bool it66121_is_hpd_detect(struct it66121_ctx *ctx) if (regmap_read(ctx->regmap, IT66121_SYS_STATUS_REG, &val)) return false; - return val & IT66121_SYS_STATUS_HPDETECT; + return ((val & IT66121_SYS_STATUS_HPDETECT) && (val & IT66121_SYS_STATUS_SENDECTECT)); } static int it66121_bridge_attach(struct drm_bridge *bridge, -- 2.20.1

3 2

[PATCH] drm: bridge: it66121: Fix return value it66121_probe
by Alex Bee 20 Sep '21

20 Sep '21

Currently it66121_probe returns -EPROBE_DEFER if the there is no remote endpoint found in the device tree which doesn't seem helpful, since this is not going to change later and it is never checked if the next bridge has been initialized yet. It will fail in that case later while doing drm_bridge_attach for the next bridge in it66121_bridge_attach. Since the bindings documentation for it66121 bridge driver states there has to be a remote endpoint defined, its safe to return -EINVAL in that case. This additonally adds a check, if the remote endpoint is enabled and returns -EPROBE_DEFER, if the remote bridge hasn't been initialized (yet). Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Signed-off-by: Alex Bee <knaerzche(a)gmail.com> --- drivers/gpu/drm/bridge/ite-it66121.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c index 2f2a09adb4bc..4e945efc8eb9 100644 --- a/drivers/gpu/drm/bridge/ite-it66121.c +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -918,11 +918,23 @@ static int it66121_probe(struct i2c_client *client, return -EINVAL; ep = of_graph_get_remote_node(dev->of_node, 1, -1); - if (!ep) - return -EPROBE_DEFER; + if (!ep) { + dev_err(ctx->dev, "The endpoint is unconnected\n"); + return -EINVAL; + } + + if (!of_device_is_available(ep)) { + of_node_put(ep); + dev_err(ctx->dev, "The remote device is disabled\n"); + return -ENODEV; + } ctx->next_bridge = of_drm_find_bridge(ep); of_node_put(ep); + if (!ctx->next_bridge) { + dev_dbg(ctx->dev, "Next bridge not found, deferring probe\n"); + return -EPROBE_DEFER; + } i2c_set_clientdata(client, ctx); mutex_init(&ctx->lock); -- 2.30.2

2 1

[PATCH 0/5] lib: devres: Add managed helpers for write-combine setup
by Thomas Zimmermann 20 Sep '21

20 Sep '21

Add devm_arch_phys_wc_add() and devm_arch_io_reserve_memtype_wc() for automatic cleanup of writecombine setup. Several DRM drivers use the non-managed functions for setting their framebuffer memory to write-combine access. Convert ast, mgag200 and vboxvideo. Remove rsp clean-up code form drivers. Tested on mgag200 hardware. Thomas Zimmermann (5): lib: devres: Add managed arch_phys_wc_add() lib: devres: Add managed arch_io_reserve_memtype_wc() drm/ast: Use managed interfaces for framebuffer write combining drm/mgag200: Use managed interfaces for framebuffer write combining drm/vboxvideo: Use managed interfaces for framebuffer write combining drivers/gpu/drm/ast/ast_drv.h | 2 - drivers/gpu/drm/ast/ast_mm.c | 27 ++++----- drivers/gpu/drm/mgag200/mgag200_drv.h | 2 - drivers/gpu/drm/mgag200/mgag200_mm.c | 35 +++--------- drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +- drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 - drivers/gpu/drm/vboxvideo/vbox_ttm.c | 17 +++--- include/linux/io.h | 5 ++ lib/devres.c | 82 +++++++++++++++++++++++++++ 9 files changed, 113 insertions(+), 63 deletions(-) -- 2.33.0

3 10

[PATCH] drm/i915/dp: add a delay before setting panel brightness after power on
by Vasily Khoruzhick 20 Sep '21

20 Sep '21

Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to control brightness, apparently needs a delay before setting brightness after power on. Without this delay the panel does accept the setting and may come up with some arbitrary brightness (sometimes it's too dark, sometimes it's too bright, I wasn't able to find a system). I don't have access to the spec, so I'm not sure if it's expected behavior or a quirk for particular device. Delay was chosen by experiment: it works with 100ms, but fails with anything lower than 75ms. Signed-off-by: Vasily Khoruzhick <anarsoul(a)gmail.com> --- drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 ++++ 1 file changed, 4 insertions(+) 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 4f8337c7fd2e..c4f35e1b5870 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct intel_crtc_state *crtc_state, ctrl = old_ctrl; if (panel->backlight.edp.intel.sdr_uses_aux) { + /* Wait 100ms to ensure that panel is ready otherwise it may not + * set chosen backlight level + */ + msleep(100); ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE; intel_dp_aux_hdr_set_aux_backlight(conn_state, level); } else { -- 2.33.0

3 6

[PATCH 1/2] MAINTAINERS: fix up entry for AMD Powerplay
by Alex Deucher 20 Sep '21

20 Sep '21

Fix the path to cover both the older powerplay infrastructure and the newer SwSMU infrastructure. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 851255b71ccc..379092f34fff 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -972,12 +972,12 @@ L: platform-driver-x86(a)vger.kernel.org S: Maintained F: drivers/platform/x86/amd-pmc.* -AMD POWERPLAY +AMD POWERPLAY AND SWSMU M: Evan Quan <evan.quan(a)amd.com> L: amd-gfx(a)lists.freedesktop.org S: Supported T: git https://gitlab.freedesktop.org/agd5f/linux.git -F: drivers/gpu/drm/amd/pm/powerplay/ +F: drivers/gpu/drm/amd/pm/ AMD SEATTLE DEVICE TREE SUPPORT M: Brijesh Singh <brijeshkumar.singh(a)amd.com> -- 2.31.1

4 4

Have you attended XDC 2021? Give us your feedback!
by Samuel Iglesias Gonsálvez 20 Sep '21

20 Sep '21

Hi, First of all, thanks organizers for such a great conference. It was smooth and, although there were some issues as it is usual in any conference, they were fixed promptly :-) I would like also to thank all of you for attending and participating either via submitting talks, watching them or joining the hallway track in IRC :-D Without you this conference won't make sense. Now it is time to gather feedback from you :-D * Do you have any comment on how was XDC 2021? - For example, have you tried the new streaming service (https://streaming.media.ccc.de/xdc2021)? Was it fine? * Do you think we can improve on something for future events? * What did you like most/least about the conference? You can reply privately to me if you wish. We will share all the gathered feedback among organizers and the X.Org Foundation board. Now that I got your attention... Did you like XDC 2021? What about organizing XDC 2023 (likely in Europe)? We know this is a decision that takes time (trigger internal discussion, looking for volunteers, budget, and a venue suitable for the event, etc). Therefore, we encourage potential interested parties to start the internal discussions now, so any question they have can be answered before we open the call for proposals for XDC 2023 next year. Please read [0] and feel free to contact me or the board for more info if needed. Thanks, Sam [0] https://www.x.org/wiki/Events/RFP/

1 0

linux-next: manual merge of the drm-misc-fixes tree with Linus' tree
by Stephen Rothwell 19 Sep '21

19 Sep '21

Hi all, Today's linux-next merge of the drm-misc-fixes tree got a conflict in: drivers/gpu/drm/vc4/vc4_hdmi.c between commit: b1044a9b8100 ("Revert drm/vc4 hdmi runtime PM changes") from Linus' tree and commits: 36e9bcb8edfc ("drm/vc4: select PM") a22dad7fa0cd ("drm/vc4: hdmi: Rework the pre_crtc_configure error handling") from the drm-misc-fixes tree. I fixed it up (I just effectively reverted the change in Linus' tree) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell

1 0

[PATCH] net: mana: Prefer struct_size over open coded arithmetic
by Len Baker 19 Sep '21

19 Sep '21

As noted in the "Deprecated Interfaces, Language Features, Attributes, and Conventions" documentation [1], size calculations (especially multiplication) should not be performed in memory allocator (or similar) function arguments due to the risk of them overflowing. This could lead to values wrapping around and a smaller allocation being made than the caller was expecting. Using those allocations could lead to linear overflows of heap memory and other misbehaviors. So, use the struct_size() helper to do the arithmetic instead of the argument "size + count * size" in the kzalloc() function. [1] https://www.kernel.org/doc/html/v5.14/process/deprecated.html#open-coded-ar… Signed-off-by: Len Baker <len.baker(a)gmx.com> --- drivers/net/ethernet/microsoft/mana/hw_channel.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/hw_channel.c b/drivers/net/ethernet/microsoft/mana/hw_channel.c index 1a923fd99990..0efdc6c3c32a 100644 --- a/drivers/net/ethernet/microsoft/mana/hw_channel.c +++ b/drivers/net/ethernet/microsoft/mana/hw_channel.c @@ -398,9 +398,7 @@ static int mana_hwc_alloc_dma_buf(struct hw_channel_context *hwc, u16 q_depth, int err; u16 i; - dma_buf = kzalloc(sizeof(*dma_buf) + - q_depth * sizeof(struct hwc_work_request), - GFP_KERNEL); + dma_buf = kzalloc(struct_size(dma_buf, reqs, q_depth), GFP_KERNEL); if (!dma_buf) return -ENOMEM; -- 2.25.1

4 6

← Newer
1
...
44
45
46
47
48
49
50
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021