dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[PATCH 00/11] of: Fix DMA configuration for non-DT masters
by Nicolas Saenz Julienne 14 Oct '19

14 Oct '19

Hi All, this series tries to address one of the issues blocking us from upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that devices not represented in DT which sit behind a PCI bus fail to get the bus' DMA addressing constraints. This is due to the fact that of_dma_configure() assumes it's receiving a DT node representing the device being configured, as opposed to the PCIe bridge node we currently pass. This causes the code to directly jump into PCI's parent node when checking for 'dma-ranges' and misses whatever was set there. To address this I create a new API in OF - inspired from Robin Murphys original proposal[2] - which accepts a bus DT node as it's input in order to configure a device's DMA constraints. The changes go deep into of/address.c's implementation, as a device being having a DT node assumption was pretty strong. On top of this work, I also cleaned up of_dma_configure() removing its redundant arguments and creating an alternative function for the special cases not applicable to either the above case or the default usage. IMO the resulting functions are more explicit. They will probably surface some hacky usages that can be properly fixed as I show with the DT fixes on the Layerscape platform. This was also tested on a Raspberry Pi 4 with a custom PCIe driver and on a Seattle AMD board. Regards, Nicolas [1] https://patchwork.kernel.org/patch/9650345/#20294961 [2] https://patchwork.kernel.org/patch/9650345/ --- Nicolas Saenz Julienne (11): of: address: clean-up unused variable in of_dma_get_range() of: base: introduce __of_n_*_cells_parent() of: address: use parent DT node in bus->count_cells() of: address: introduce of_translate_dma_address_parent() of: expose __of_get_dma_parent() to OF subsystem of: address: use parent OF node in of_dma_get_range() dts: arm64: layerscape: add dma-ranges property to qoric-mc node dts: arm64: layerscape: add dma-ranges property to pcie nodes of: device: remove comment in of_dma_configure() of: device: introduce of_dma_configure_parent() of: simplify of_dma_config()'s arguments .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 1 + .../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 5 + .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 1 + drivers/base/platform.c | 2 +- drivers/bcma/main.c | 2 +- drivers/bus/fsl-mc/fsl-mc-bus.c | 2 +- drivers/dma/qcom/hidma_mgmt.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/gpu/host1x/bus.c | 4 +- drivers/media/platform/qcom/venus/firmware.c | 2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 +- drivers/of/address.c | 136 +++++++++--------- drivers/of/base.c | 69 +++++++-- drivers/of/device.c | 59 +++++++- drivers/of/of_private.h | 5 + drivers/pci/pci-driver.c | 3 +- drivers/xen/gntdev.c | 2 +- include/linux/of_address.h | 8 +- include/linux/of_device.h | 23 ++- 22 files changed, 223 insertions(+), 113 deletions(-) -- 2.23.0

5 26

[PATCH] drm/drm_edid: correct VIC and HDMI_VIC under HDMI 2.0
by Wayne Lin 14 Oct '19

14 Oct '19

In HDMI 1.4 defines 4k modes without specific aspect ratio. However, in HDMI 2.0, adds aspect ratio attribute to distinguish different 4k modes. According to Appendix E of HDMI 2.0 spec, source should use VSIF to indicate VIC mode only when the mode is one defined in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC. eg: VIC_103 should use AVI infoframes and VIC_93 use VSIF When the sink is HDMI 2.0, current code in drm_hdmi_avi_infoframe_from_display_mode will also force mode VIC_103 to have VIC value 0. This violates the spec and needs to be corrected. The same situation occurs in drm_hdmi_vendor_infoframe_from_display_mode and should set HDMI_VIC when the mode is one defined in HDMI 1.4b 4K modes. --- drivers/gpu/drm/drm_edid.c | 95 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 92 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 649cfd8b4200..0fea9bf4ec67 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1306,6 +1306,37 @@ static const struct drm_display_mode edid_4k_modes[] = { .vrefresh = 24, }, }; +/* + * 4k modes of HDMI 1.4 defined in HDMI 2.0. Index using the VIC. + */ +static const struct drm_display_mode hdmi_1_4_edid_4k_modes[] = { + /* 0 - dummy, VICs start at 1 */ + { }, + /* 1 - 3840x2160@30Hz */ + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, + 3840, 4016, 4104, 4400, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, + /* 2 - 3840x2160@25Hz */ + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, + 3840, 4896, 4984, 5280, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, + /* 3 - 3840x2160@24Hz */ + { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, + 3840, 5116, 5204, 5500, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, + /* 4 - 4096x2160@24Hz (SMPTE) */ + { DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 297000, + 4096, 5116, 5204, 5500, 0, + 2160, 2168, 2178, 2250, 0, + DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC), + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135, }, +}; /*** DDC fetch and block validation ***/ static const u8 edid_header[] = { @@ -3061,6 +3092,19 @@ hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode) return cea_mode_alternate_clock(hdmi_mode); } +/* + * Calculate the alternate clock for HDMI modes (those from the HDMI vendor + * specific block). + * + * It's almost like hdmi_mode_alternate_clock(), but no exception for VIC 4 mode. + * There is an alternate clock (23.98Hz) of VIC 4 mode (4096x2160@24Hz) in HDMI 2.0 + */ +static unsigned int +hdmi_1_4_mode_alternate_clock(const struct drm_display_mode *hdmi_mode) +{ + return cea_mode_alternate_clock(hdmi_mode); +} + static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_match, unsigned int clock_tolerance) { @@ -3121,11 +3165,53 @@ static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match) return 0; } +/* + * drm_match_hdmi_1_4_mode - look for a HDMI 1.4 mode matching given mode + * @to_match: display mode + * + * An HDMI mode is one defined in the HDMI vendor specific block. + * In HDMI 2.0, only few 4k resolutions with specific aspect ratio should + * utilize H14b VSIF. + * + * Returns the HDMI Video ID (VIC) of the mode or 0 if it isn't one. + */ +static u8 drm_match_hdmi_1_4_mode(const struct drm_display_mode *to_match) +{ + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; + u8 vic; + + if (!to_match->clock) + return 0; + + if (to_match->picture_aspect_ratio) + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; + + for (vic = 1; vic < ARRAY_SIZE(hdmi_1_4_edid_4k_modes); vic++) { + const struct drm_display_mode *hdmi_1_4_mode = &hdmi_1_4_edid_4k_modes[vic]; + unsigned int clock1, clock2; + + /* Make sure to also match alternate clocks */ + clock1 = hdmi_1_4_mode->clock; + clock2 = hdmi_1_4_mode_alternate_clock(hdmi_1_4_mode); + + if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) || + KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) && + drm_mode_match(to_match, hdmi_1_4_mode, match_flags)) + return vic; + } + return 0; +} + static bool drm_valid_hdmi_vic(u8 vic) { return vic > 0 && vic < ARRAY_SIZE(edid_4k_modes); } +static bool drm_valid_hdmi_1_4_vic(u8 vic) +{ + return vic > 0 && vic < ARRAY_SIZE(hdmi_1_4_edid_4k_modes); +} + static int add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid) { @@ -4894,10 +4980,12 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, * HDMI 1.4b 4K modes */ if (frame->video_code) { - u8 vendor_if_vic = drm_match_hdmi_mode(mode); + u8 vendor_if_vic = is_hdmi2_sink(connector) ? + drm_match_hdmi_1_4_mode(mode) : drm_match_hdmi_mode(mode); bool is_s3d = mode->flags & DRM_MODE_FLAG_3D_MASK; - if (drm_valid_hdmi_vic(vendor_if_vic) && !is_s3d) + if (!is_s3d && is_hdmi2_sink(connector) ? + drm_valid_hdmi_1_4_vic(vendor_if_vic) : drm_valid_hdmi_vic(vendor_if_vic)) frame->video_code = 0; } @@ -5125,7 +5213,8 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe *frame, if (!has_hdmi_infoframe) return -EINVAL; - vic = drm_match_hdmi_mode(mode); + vic = is_hdmi2_sink(connector) ? + drm_match_hdmi_1_4_mode(mode) : drm_match_hdmi_mode(mode); s3d_flags = mode->flags & DRM_MODE_FLAG_3D_MASK; /* -- 2.17.1

3 6

[PATCH 1/3] dma-buf: add dma_resv_ctx for deadlock handling
by Christian König 14 Oct '19

14 Oct '19

The ww_mutex framework allows for detecting deadlocks when multiple threads try to acquire the same set of locks in different order. The problem is that handling those deadlocks was the burden of the user of the ww_mutex implementation and at least some users didn't got that right on the first try. So introduce a new dma_resv_ctx object which can be used to simplify the deadlock handling. This is done by tracking all locked dma_resv objects in the context as well as the last contended object. When a deadlock occurse we now unlock all previously locked objects and acquire the contended lock in the slow path. After this is done -EDEADLK is still returned to signal that all other locks now need to be re-acquired again. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/Makefile | 2 +- drivers/dma-buf/dma-resv-ctx.c | 108 +++++++++++++++++++++++++++++++++ include/linux/dma-resv-ctx.h | 68 +++++++++++++++++++++ include/linux/dma-resv.h | 1 + 4 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 drivers/dma-buf/dma-resv-ctx.c create mode 100644 include/linux/dma-resv-ctx.h diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 03479da06422..da7701c85de2 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \ - dma-resv.o seqno-fence.o + dma-resv.o dma-resv-ctx.o seqno-fence.o obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o diff --git a/drivers/dma-buf/dma-resv-ctx.c b/drivers/dma-buf/dma-resv-ctx.c new file mode 100644 index 000000000000..cad10fa6f80b --- /dev/null +++ b/drivers/dma-buf/dma-resv-ctx.c @@ -0,0 +1,108 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright 2019 Advanced Micro Devices, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: + * Christian König <christian.koenig(a)amd.com> + */ + +#include <linux/dma-resv-ctx.h> + +/** + * dma_resv_ctx_init - initialize a reservation context + * @ctx: the context to initialize + * + * Start using this reservation context to lock reservation objects for update. + */ +void dma_resv_ctx_init(struct dma_resv_ctx *ctx) +{ + ww_acquire_init(&ctx->base, &reservation_ww_class); + init_llist_head(&ctx->locked); + ctx->contended = NULL; +} +EXPORT_SYMBOL(dma_resv_ctx_init); + +/** + * dma_resv_ctx_unlock_all - unlock all reservation objects + * @ctx: the context which holds the reservation objects + * + * Unlocks all reservation objects locked with this context. + */ +void dma_resv_ctx_unlock_all(struct dma_resv_ctx *ctx) +{ + struct dma_resv *obj, *next; + + if (ctx->contended) + dma_resv_unlock(ctx->contended); + ctx->contended = NULL; + + llist_for_each_entry_safe(obj, next, ctx->locked.first, locked) + ww_mutex_unlock(&obj->lock); + init_llist_head(&ctx->locked); +} +EXPORT_SYMBOL(dma_resv_ctx_unlock_all); + +/** + * dma_resv_ctx_lock - lock a reservation object with deadlock handling + * @ctx: the context which should be used to lock the object + * @obj: the object which needs to be locked + * @interruptible: if we should wait interruptible + * + * Use @ctx to lock the reservation object. If a deadlock is detected we backoff + * by releasing all locked objects and use the slow path to lock the reservation + * object. After successfully locking in the slow path -EDEADLK is returned to + * signal that all other locks must be re-taken as well. + */ +int dma_resv_ctx_lock(struct dma_resv_ctx *ctx, struct dma_resv *obj, + bool interruptible) +{ + int ret = 0; + + if (unlikely(ctx->contended == obj)) + ctx->contended = NULL; + else if (interruptible) + ret = dma_resv_lock_interruptible(obj, &ctx->base); + else + ret = dma_resv_lock(obj, &ctx->base); + + if (likely(!ret)) { + /* don't use llist_add here, we have separate locking */ + obj->locked.next = ctx->locked.first; + ctx->locked.first = &obj->locked; + return 0; + } + if (unlikely(ret != -EDEADLK)) + return ret; + + dma_resv_ctx_unlock_all(ctx); + + if (interruptible) { + ret = dma_resv_lock_slow_interruptible(obj, &ctx->base); + if (unlikely(ret)) + return ret; + } else { + dma_resv_lock_slow(obj, &ctx->base); + } + + ctx->contended = obj; + return -EDEADLK; +} +EXPORT_SYMBOL(dma_resv_ctx_lock); diff --git a/include/linux/dma-resv-ctx.h b/include/linux/dma-resv-ctx.h new file mode 100644 index 000000000000..86473de65167 --- /dev/null +++ b/include/linux/dma-resv-ctx.h @@ -0,0 +1,68 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright 2019 Advanced Micro Devices, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: + * Christian König <christian.koenig(a)amd.com> + */ + +#ifndef _LINUX_DMA_RESV_CTX_H +#define _LINUX_DMA_RESV_CTX_H + +#include <linux/llist.h> +#include <linux/dma-resv.h> + +/** + * struct dma_resv_ctx - context to lock reservation objects + * @base: ww_acquire_ctx used for deadlock detection + * @locked: list of dma_resv objects locked in this context + * @contended: contended dma_resv object + */ +struct dma_resv_ctx { + struct ww_acquire_ctx base; + struct llist_head locked; + struct dma_resv *contended; +}; + +/** + * dma_resv_ctx_done - wrapper for ww_acquire_done + * @ctx: the reservation context which is done with locking + */ +static inline void dma_resv_ctx_done(struct dma_resv_ctx *ctx) +{ + ww_acquire_done(&ctx->base); +} + +/** + * dma_resv_ctx_fini - wrapper for ww_acquire_fini + * @ctx: the reservation context which is finished + */ +static inline void dma_resv_ctx_fini(struct dma_resv_ctx *ctx) +{ + ww_acquire_fini(&ctx->base); +} + +void dma_resv_ctx_init(struct dma_resv_ctx *ctx); +void dma_resv_ctx_unlock_all(struct dma_resv_ctx *ctx); +int dma_resv_ctx_lock(struct dma_resv_ctx *ctx, struct dma_resv *obj, + bool interruptible); + +#endif /* _LINUX_DMA_RESV_CTX_H */ diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h index ee50d10f052b..1267822c2669 100644 --- a/include/linux/dma-resv.h +++ b/include/linux/dma-resv.h @@ -71,6 +71,7 @@ struct dma_resv_list { */ struct dma_resv { struct ww_mutex lock; + struct llist_node locked; seqcount_t seq; struct dma_fence __rcu *fence_excl; -- 2.17.1

3 6

[PATCH 0/6] drm/amdgpu: Fix incorrect encoder API usages
by Lyude Paul 14 Oct '19

14 Oct '19

Noticed this while trying to respin my MST suspend/resume patch series. It's not technically possible (at least until someone moves amdgpu away from the deprecated drm_device->driver->{load,unload} hooks) for amdgpu to properly register all of it's encoders before registering with userspace. However, amdgpu also apparently adds and removes encoders along with MST connectors - which is a much bigger issue as userspace applications definitely do not expect this type of behavior. So, let's fix it and add some WARNs() so new drivers don't accidentally make this mistake in the future. Lyude Paul (6): drm/amdgpu/dm/mst: Don't create MST topology managers for eDP ports drm/amdgpu/dm/mst: Remove unnecessary NULL check drm/amdgpu/dm/mst: Use ->atomic_best_encoder drm/amdgpu/dm/mst: Make MST encoders per-CRTC and fix encoder usage drm/amdgpu/dm/mst: Report possible_crtcs incorrectly, for now drm/encoder: WARN() when adding/removing encoders after device registration drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 ++++++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 - .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 46 ++++++++++--------- .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 3 ++ drivers/gpu/drm/drm_encoder.c | 31 ++++++++++--- 6 files changed, 70 insertions(+), 29 deletions(-) -- 2.21.0

5 16

[PATCH] Add framebuffer max width/height fields to drm_mode_config
by Jeykumar Sankaran 14 Oct '19

14 Oct '19

Below two discussion threads will provide the context behind this patch. https://www.spinics.net/lists/dri-devel/msg229070.html https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332881@… Seperating out the core framework patch from vendor implementation. Jeykumar Sankaran (1): drm: add fb max width/height fields to drm_mode_config drivers/gpu/drm/drm_framebuffer.c | 17 +++++++++++++---- include/drm/drm_mode_config.h | 3 +++ 2 files changed, 16 insertions(+), 4 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

4 7

[PATCH v7 0/5] Add a generic driver for LED-based backlight
by Jean-Jacques Hiblot 14 Oct '19

14 Oct '19

This series aims to add a led-backlight driver, similar to pwm-backlight, but using a LED class device underneath. A few years ago (2015), Tomi Valkeinen posted a series implementing a backlight driver on top of a LED device: https://patchwork.kernel.org/patch/7293991/ https://patchwork.kernel.org/patch/7294001/ https://patchwork.kernel.org/patch/7293981/ The discussion stopped because Tomi lacked the time to work on it. changes in v7: - rebased on top of linux-leds/for-next - populate the of_node member of the LED device if fwnode is a of_node (this is a new patch and the first of the series). - devm_led_get() works only when the device tree is used. Add a few checks for that. changes in v6: - trim the list of included headers - remove useless definition of BKL_FULL_BRIGHTNESS changes in v5: - removed LED brightness scaling - disable sysfs the interface of the LEDs when used by the backlight device changes in v4: - fix dev_err() messages and commit logs following the advices of Pavel - cosmetic changes (indents, getting rid of "? 1 : 0" in led_match_led_node()) changes in v3: - dt binding: don't limit the brightness range to 0-255. Use the range of the underlying LEDs. as a side-effect, all LEDs must now have the same range - driver: Adapt to dt binding update. - driver: rework probe() for clarity and remove the remaining goto. changes in v2: - handle more than one LED. - don't make the backlight device a child of the LED controller. - make brightness-levels and default-brightness-level optional - removed the option to use a GPIO enable. - removed the option to use a regulator. It should be handled by the LED core - don't make any change to the LED core (not needed anymore) Jean-Jacques Hiblot (3): leds: populate the device's of_node when possible leds: Add managed API to get a LED from a device driver dt-bindings: backlight: Add led-backlight binding Tomi Valkeinen (2): leds: Add of_led_get() and led_put() backlight: add led-backlight driver .../bindings/leds/backlight/led-backlight.txt | 28 ++ drivers/leds/led-class.c | 106 ++++++- drivers/video/backlight/Kconfig | 7 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/led_bl.c | 260 ++++++++++++++++++ include/linux/leds.h | 6 + 6 files changed, 407 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/leds/backlight/led-backlight.txt create mode 100644 drivers/video/backlight/led_bl.c -- 2.17.1

3 14

[PATCH] drm/rockchip/rk3066: Use devm_platform_ioremap_resource() in rk3066_hdmi_bind()
by Markus Elfring 13 Oct '19

13 Oct '19

From: Markus Elfring <elfring(a)users.sourceforge.net> Date: Sat, 21 Sep 2019 20:32:25 +0200 Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> --- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c index 85fc5f01f761..cdb401f4283d 100644 --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c @@ -743,7 +743,6 @@ static int rk3066_hdmi_bind(struct device *dev, struct device *master, struct platform_device *pdev = to_platform_device(dev); struct drm_device *drm = data; struct rk3066_hdmi *hdmi; - struct resource *iores; int irq; int ret; @@ -753,12 +752,7 @@ static int rk3066_hdmi_bind(struct device *dev, struct device *master, hdmi->dev = dev; hdmi->drm_dev = drm; - - iores = platform_get_resource(pdev, IORESOURCE_MEM, 0); - if (!iores) - return -ENXIO; - - hdmi->regs = devm_ioremap_resource(dev, iores); + hdmi->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(hdmi->regs)) return PTR_ERR(hdmi->regs); -- 2.23.0

2 1

[Bug 108771] [amdgpu]] *ERROR* ring gfx timeout
by bugzilla-daemon＠freedesktop.org 12 Oct '19

12 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=108771 Bug ID: 108771 Summary: [amdgpu]] *ERROR* ring gfx timeout Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: john.ettedgui(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 142492 --> https://bugs.freedesktop.org/attachment.cgi?id=142492&action=edit dmesg Hello there, I constantly get this issue with a RX 580 while playing a couple certain scenes of The Last Story on the Dolphin emulator. To pass the first scenes I had to lower all graphics options and it worked with OpenGL or Vulkan with RADV. To pass the 2nd one I had to use OGL only, which was super slow compared to VK, so I'm guessing it was not sending enough data to trigger the issue. I've had other similar system crashes in this game in the past few days, but they were not sticking like this one, just restarting the machine would allow me to proceed, so I am not sure if it was related or not. I've tried Linux 4.18.15, 4.18.17, 4.18.19 and 4.19.2 with no difference. I've also tried a few LLVM/Mesa builds from the 29th October to the 13th November and no difference either. I'm on Arch Linux 64b, Xorg 1.20.3, xf86-video-amdgpu 18.1.0, mesa 90d68858ed, llvm 346744, with an i7 4790k, a 580 and 16Gb of RAM. I wasn't sure where to file this bug so I hope this is correct. Thank you! -- You are receiving this mail because: You are the assignee for the bug.

1 12

[PATCH] drm/meson: fix max mode_config height/width
by Neil Armstrong 11 Oct '19

11 Oct '19

The mode_config max_width/max_height determines the maximum framebuffer size the pixel reader can handle. But the values were set thinking they were determining the maximum screen dimensions. This patch changes the values to the maximum height/width the CANVAS block can handle rounded to some coherent values. Fixes: a41e82e6c457 ("drm/meson: Add support for components") Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- drivers/gpu/drm/meson/meson_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c index d344312..2e29968 100644 --- a/drivers/gpu/drm/meson/meson_drv.c +++ b/drivers/gpu/drm/meson/meson_drv.c @@ -243,8 +243,8 @@ static int meson_drv_bind_master(struct device *dev, bool has_components) goto free_drm; drm_mode_config_init(drm); - drm->mode_config.max_width = 3840; - drm->mode_config.max_height = 2160; + drm->mode_config.max_width = 16384; + drm->mode_config.max_height = 8192; drm->mode_config.funcs = &meson_mode_config_funcs; /* Hardware Initialization */ -- 2.7.4

3 9

[PATCHv2 0/7] drm/omap: misc improvements
by Tomi Valkeinen 11 Oct '19

11 Oct '19

Hi, This is v2 of the series. Changes compared to v1: Dropped (Jyri will work on them): - drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix - drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes Added: - drm/omap: avoid copy in mgr_fld_read/write - drm/omap: hdmi4: fix use of uninitialized var Fixed the issues pointed out by Laurent. Tomi Alejandro Hernandez (1): drm/omap: tweak HDMI DDC timings Jyri Sarha (1): drm/omap: dss: move platform_register_drivers() to dss.c and remove core.c Tomi Valkeinen (5): drm/omap: drop unneeded locking from mgr_fld_write() drm/omap: avoid copy in mgr_fld_read/write drm/omap: fix missing scaler pixel fmt limitations drm/omap: hdmi5: automatically choose limited/full range output drm/omap: hdmi4: fix use of uninitialized var drivers/gpu/drm/omapdrm/dss/Makefile | 2 +- drivers/gpu/drm/omapdrm/dss/core.c | 55 ---------- drivers/gpu/drm/omapdrm/dss/dispc.c | 46 ++++++--- drivers/gpu/drm/omapdrm/dss/dss.c | 37 +++++++ drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 5 +- drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 125 ++++++++++++----------- 6 files changed, 137 insertions(+), 133 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

3 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019