dri-devel September 2019

dri-devel@lists.freedesktop.org

315 participants
2278 discussions

[PATCH] drm/bridge: tc358767: fix max_tu_symbol value
by Tomi Valkeinen 06 Nov '19

06 Nov '19

max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not what the spec says. The spec says: roundup ((input active video bandwidth in bytes/output active video bandwidth in bytes) * tu_size) It is not quite clear what the above means, but calculating max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and fixes the issues seen. This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes & 1.62Gbps was pretty bad for me). Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ti.com> --- drivers/gpu/drm/bridge/tc358767.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 13ade28a36a8..b6aa1bd47e1d 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -677,6 +677,8 @@ static int tc_set_video_mode(struct tc_data *tc, int upper_margin = mode->vtotal - mode->vsync_end; int lower_margin = mode->vsync_start - mode->vdisplay; int vsync_len = mode->vsync_end - mode->vsync_start; + u32 bits_per_pixel = 24; + u32 in_bw, out_bw; /* * Recommended maximum number of symbols transferred in a transfer unit: @@ -684,7 +686,10 @@ static int tc_set_video_mode(struct tc_data *tc, * (output active video bandwidth in bytes)) * Must be less than tu_size. */ - max_tu_symbol = TU_SIZE_RECOMMENDED - 1; + + in_bw = mode->clock * bits_per_pixel / 8; + out_bw = tc->link.base.num_lanes * tc->link.base.rate; + max_tu_symbol = DIV_ROUND_UP(in_bw * TU_SIZE_RECOMMENDED, out_bw); dev_dbg(tc->dev, "set mode %dx%d\n", mode->hdisplay, mode->vdisplay); -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

3 4

[PATCH v4 00/14] Improvements and fixes for mxsfb DRM driver
by Robert Chiras 05 Nov '19

05 Nov '19

This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM and 8QXP). Following, are the new features added and fixes from this patch-set: 1. Add support for drm_bridge On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel display connector, where an LCD panel can be attached, but instead it is connected to DSI controller. Since this DSI stands between the display controller (eLCDIF) and the physical connector, the DSI can be implemented as a DRM bridge. So, in order to be able to connect the mxsfb driver to the DSI driver, the support for a drm_bridge was needed in mxsfb DRM driver (the actual driver for the eLCDIF block). 2. Add support for additional pixel formats Some of the pixel formats needed by Android were not implemented in this driver, but they were actually supported. So, add support for them. 3. Add support for horizontal stride Having support for horizontal stride allows the use of eLCDIF with a GPU (for example) that can only output resolution sizes multiple of a power of 8. For example, 1080 is not a power of 16, so in order to support 1920x1080 output from GPUs that can produce linear buffers only in sizes multiple to 16, this feature is needed. 3. Few minor features and bug-fixing The addition of max-memory-bandwidth DT property was actually needed in order to limit the bandwidth usage of the eLCDIF block. This is need on systems where multiple display controllers are presend and the memory bandwidth is not enough to handle all of them at maximum capacity (like it is the case on 8MQ, where there are two display controllers: DCSS and eLCDIF). The rest of the patches are bug-fixes. v4: - Removed the "Fix vblank events" patch (will cover this issue later, on a separate thread) - Colleted "Tested-by" from Guido - Collected "Reviewed-by" from Rob Herring v3: - Removed the max-res property patches and added support for max-memory-bandwidth property, as it is also implemented in other drivers - Removed unnecessary drm_vblank_off in probe v2: - Collected Tested-by from Guido - Split the first patch, which added more than one feature into relevant patches, explaining each feature added - Also split the second patch into more patches, to differentiate between the feature itself (additional pixel formats support) and the cleanup of the register definitions for a better representation (guido) - Included a patch submitted by Guido, while he was testing my patch-set Guido Günther (1): drm/mxsfb: Read bus flags from bridge if present Mirela Rabulea (1): drm/mxsfb: Signal mode changed when bpp changed Robert Chiras (12): drm/mxsfb: Update mxsfb to support a bridge drm/mxsfb: Add defines for the rest of registers drm/mxsfb: Reset vital registers for a proper initialization drm/mxsfb: Update register definitions using bit manipulation defines drm/mxsfb: Update mxsfb with additional pixel formats drm/mxsfb: Add max-memory-bandwidth property for MXSFB dt-bindings: display: Add max-memory-bandwidth property for mxsfb drm/mxsfb: Update mxsfb to support LCD reset drm/mxsfb: Improve the axi clock usage drm/mxsfb: Clear OUTSTANDING_REQS bits drm/mxsfb: Add support for horizontal stride drm/mxsfb: Add support for live pixel format change .../devicetree/bindings/display/mxsfb.txt | 5 + drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++--- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 194 ++++++++++++-- drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +- drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +- drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++----- 6 files changed, 581 insertions(+), 136 deletions(-) -- 2.7.4

3 21

[PATCH v2 1/3] drm: Fix kerneldoc and remove unused struct member in self_refresh helper
by Sean Paul 04 Nov '19

04 Nov '19

From: Sean Paul <seanpaul(a)chromium.org> Artifacts of previous revisions. Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-1-sean@p… Changes in v2: - None --- drivers/gpu/drm/drm_self_refresh_helper.c | 1 - include/drm/drm_crtc.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c b/drivers/gpu/drm/drm_self_refresh_helper.c index 4b9424a8f1f1..9095cebf2147 100644 --- a/drivers/gpu/drm/drm_self_refresh_helper.c +++ b/drivers/gpu/drm/drm_self_refresh_helper.c @@ -53,7 +53,6 @@ struct drm_self_refresh_data { struct drm_crtc *crtc; struct delayed_work entry_work; - struct drm_atomic_state *save_state; unsigned int entry_delay_ms; }; diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 7e2963cad543..742b31043898 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -1107,7 +1107,7 @@ struct drm_crtc { /** * @self_refresh_data: Holds the state for the self refresh helpers * - * Initialized via drm_self_refresh_helper_register(). + * Initialized via drm_self_refresh_helper_init(). */ struct drm_self_refresh_data *self_refresh_data; }; -- Sean Paul, Software Engineer, Google / Chromium OS

3 8

[PATCH v5 00/12] arm/arm64: mediatek: Fix mmsys device probing
by matthias.bgg＠kernel.org 04 Nov '19

04 Nov '19

From: Matthias Brugger <mbrugger(a)suse.com> This is version four of the series. The biggest change are the last four patches which introduce how this should be handled in the future. Instead of creating the platform device in the DRM driver the device tree has in the mmsys memory range a child node to probe the clock part. That breaks backwards compatibility, so I only introduce that for SoCs which are not available to the general public (mt2712e) or only have the mmsys clock driver part implemented (mt6797). Changes since v4: - fix missing regmap accessors in drm diver (patch 1) - omit probe deffered warning on all drivers (patch 5) - update drm and clk bindings (patch 6 and 7) - put mmsys clock part in dts child node of mmsys. Only done for HW where no dts backport compatible breakage is expected (either DRM driver not yet implemented or no HW available to the public) (patch 9 to 12) Changes since v3: - use platform device to probe clock driver - add Acked-by CK Hu for the probe deferred patch Changes since v2: - fix kconfig typo (shame on me) - delete __initconst from mm_clocks as converted to a platform driver Changes since v1: - add binding documentation - ddp: use regmap_update_bits - ddp: ignore EPROBE_DEFER on clock probing - mfd: delete mmsys_private - add Reviewed-by and Acked-by tags MMSYS in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display subsystem. Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver get probed, which in effect breaks graphics on mt8173 and mt2701. This patch uses a platform device registration in the DRM driver, which will trigger the probe of the corresponding clock driver. It was tested on the bananapi-r2 and the Acer R13 Chromebook. Matthias Brugger (12): drm/mediatek: Use regmap for register access clk: mediatek: mt2701-mmsys: switch to platform device probing clk: mediatek: mt8173: switch mmsys to platform device probing drm/mediatek: Add support for mmsys through a pdev drm: mediatek: Omit warning on probe defers drm/mediatek: update dt-bindings dt-bindings: clock: mediatek: delete mmsys clocks dt-bindings: mediatek: Change the binding for mmsys clocks arm64: dts: mt2712e: Use the new mmsys clock compatible arm64: dts: mt6797: Use the new mmsys clock compatible clk: mediatek: mt2712e: Probe with new compatible clk: mediatek: mt6797: Probe with new compatible .../bindings/arm/mediatek/mediatek,mmsys.txt | 24 +++++---- .../display/mediatek/mediatek,disp.txt | 34 +++++++----- arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 8 ++- arch/arm64/boot/dts/mediatek/mt6797.dtsi | 8 ++- drivers/clk/mediatek/clk-mt2701-mm.c | 42 ++++++++++----- drivers/clk/mediatek/clk-mt2712-mm.c | 9 ++-- drivers/clk/mediatek/clk-mt6797-mm.c | 9 ++-- drivers/clk/mediatek/clk-mt8173.c | 51 +++++++++++++++--- drivers/gpu/drm/mediatek/mtk_disp_color.c | 4 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 +- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 53 ++++++++----------- drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 34 +++++++++--- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 6 ++- 17 files changed, 200 insertions(+), 102 deletions(-) -- 2.19.1

9 38

[Bug 111487] AMD vega - display off/on -> solid green display
by bugzilla-daemon＠freedesktop.org 04 Nov '19

04 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=111487 Bug ID: 111487 Summary: AMD vega - display off/on -> solid green display Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: not set Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: bzz(a)atomicbee.cz Created attachment 145168 --> https://bugs.freedesktop.org/attachment.cgi?id=145168&action=edit dmesg after display turned off and on again I have disabled all screensavers/sleep modes on my desktop and keeping it running 24/7 only turning off the display. Using Opensuse tumbleweed and started to get flickering in graphics (only when for example scrolling or moving cursor over icons etc. not when the "image" is static) Also when i turn off and then on the display, i got just solid green display and following warning/errors in dmesg: [37101.852459] WARNING: CPU: 2 PID: 2102 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:854 dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] [37101.852460] Modules linked in: fuse vhost_net vhost tap tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bpfilter scsi_transport_iscsi af_packet br_netfilter bridge stp llc iscsi_ibft iscsi_boot_sysfs msr nls_iso8859_1 nls_cp437 vfat fat edac_mce_amd kvm_amd ccp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_realtek snd_hda_codec_generic aes_x86_64 ledtrig_audio crypto_simd cryptd glue_helper snd_hda_codec_hdmi eeepc_wmi asus_wmi sparse_keymap wmi_bmof rfkill snd_hda_intel pcspkr k10temp snd_hda_codec sp5100_tco snd_hda_core i2c_piix4 snd_hwdep snd_pcm r8169 snd_timer snd realtek soundcore joydev libphy gpio_amdpt gpio_generic pcc_cpufreq button acpi_cpufreq uas usb_storage hid_logitech_hidpp btrfs hid_logitech_dj libcrc32c xor raid6_pq hid_generic usbhid amdgpu crc32c_intel amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_pci xhci_hcd usbcore wmi [37101.852471] video pinctrl_amd sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [37101.852473] CPU: 2 PID: 2102 Comm: X Tainted: G W 5.2.9-1-default #1 openSUSE Tumbleweed (unreleased) [37101.852474] Hardware name: System manufacturer System Product Name/PRIME B450M-A, BIOS 1804 07/29/2019 [37101.852514] RIP: 0010:dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] [37101.852515] Code: 83 c8 ff e9 a9 ca f9 ff 48 c7 c7 b8 aa 6c c0 e8 7c d5 2c d0 0f 0b 83 c8 ff e9 93 ca f9 ff 48 c7 c7 b8 aa 6c c0 e8 66 d5 2c d0 <0f> 0b 80 bb 93 01 00 00 00 75 05 e9 79 ee f9 ff 48 8b 83 80 02 00 [37101.852515] RSP: 0018:ffffac1083c1b638 EFLAGS: 00010282 [37101.852516] RAX: 0000000000000024 RBX: ffff9257e5060000 RCX: 0000000000000006 [37101.852516] RDX: 0000000000000007 RSI: 0000000000000002 RDI: ffff9257eea99a10 [37101.852517] RBP: ffff9252e0fd0ec0 R08: 000021be72bbc983 R09: ffff9257ee800000 [37101.852517] R10: 000000000000b22e R11: 00000000001d545c R12: ffff9252e0fd0000 [37101.852517] R13: ffff9257e5060000 R14: ffff9257e582e540 R15: 0000000000000003 [37101.852518] FS: 00007fddbce26940(0000) GS:ffff9257eea80000(0000) knlGS:0000000000000000 [37101.852518] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37101.852519] CR2: 00000008004354c8 CR3: 00000007d22e6000 CR4: 00000000003406e0 [37101.852519] Call Trace: [37101.852558] dcn10_program_pipe+0x1a7/0x270 [amdgpu] [37101.852596] dcn10_apply_ctx_for_surface+0x4d6/0x5e0 [amdgpu] [37101.852634] dc_commit_updates_for_stream+0x7f1/0xbe0 [amdgpu] [37101.852671] amdgpu_dm_commit_planes.constprop.0+0x6b4/0x880 [amdgpu] [37101.852709] amdgpu_dm_atomic_commit_tail+0x9be/0xd30 [amdgpu] [37101.852714] ? commit_tail+0x3c/0x70 [drm_kms_helper] [37101.852718] commit_tail+0x3c/0x70 [drm_kms_helper] [37101.852722] drm_atomic_helper_commit+0x108/0x110 [drm_kms_helper] [37101.852726] restore_fbdev_mode_atomic+0x1b3/0x1c0 [drm_kms_helper] [37101.852729] drm_fb_helper_pan_display+0xb6/0x1c0 [drm_kms_helper] [37101.852731] fb_pan_display+0x83/0x100 [37101.852732] bit_update_start+0x1a/0x40 [37101.852733] fbcon_switch+0x3a3/0x570 [37101.852734] redraw_screen+0x128/0x210 [37101.852735] fbcon_blank+0x277/0x2a0 [37101.852737] do_unblank_screen+0xaa/0x150 [37101.852738] complete_change_console+0x54/0xd0 [37101.852738] vt_ioctl+0x1181/0x11c0 [37101.852744] ? drm_setmaster_ioctl+0xb0/0xb0 [drm] [37101.852745] tty_ioctl+0x372/0x8c0 [37101.852746] ? ktime_get_mono_fast_ns+0x4e/0x90 [37101.852747] do_vfs_ioctl+0x447/0x640 [37101.852748] ? do_futex+0x10a/0x1d0 [37101.852749] ksys_ioctl+0x5e/0x90 [37101.852750] ? trace_hardirqs_off_thunk+0x1a/0x33 [37101.852751] __x64_sys_ioctl+0x16/0x20 [37101.852752] do_syscall_64+0x6e/0x1e0 [37101.852753] entry_SYSCALL_64_after_hwframe+0x49/0xbe [37101.852754] RIP: 0033:0x7fddbd20a7c7 [37101.852755] Code: 00 00 90 48 8b 05 d1 86 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 86 0c 00 f7 d8 64 89 01 48 [37101.852755] RSP: 002b:00007fff001ac908 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 [37101.852756] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fddbd20a7c7 [37101.852756] RDX: 0000000000000001 RSI: 0000000000005605 RDI: 000000000000000c [37101.852756] RBP: 00005617c64392cc R08: 0000000000000000 R09: 00007fff001ac630 [37101.852757] R10: 0000000000000007 R11: 0000000000003246 R12: 00005617c6439390 [37101.852757] R13: 00005617c6439380 R14: 00005617c64392c8 R15: 00007fff001ac984 [37101.852758] ---[ end trace 4bb79af4c980bd53 ]--- attached full dmesg after turning off and on display (Dell U3014) also attached glxinfo after reboot (because when i got solid green display, nothing else that full reboot will fix it. Or i didn't find yet what could. systemctl restart display-manager doesn't help) -- You are receiving this mail because: You are the assignee for the bug.

1 7

[PATCH v2] fbdev: c2p: Fix link failure on non-inlining
by Geert Uytterhoeven 04 Nov '19

04 Nov '19

When the compiler decides not to inline the Chunky-to-Planar core functions, the build fails with: c2p_planar.c:(.text+0xd6): undefined reference to `c2p_unsupported' c2p_planar.c:(.text+0x1dc): undefined reference to `c2p_unsupported' c2p_iplan2.c:(.text+0xc4): undefined reference to `c2p_unsupported' c2p_iplan2.c:(.text+0x150): undefined reference to `c2p_unsupported' Fix this by marking the functions __always_inline. While this could be triggered before by manually enabling both CONFIG_OPTIMIZE_INLINING and CONFIG_CC_OPTIMIZE_FOR_SIZE, it was exposed in the m68k defconfig by commit ac7c3e4ff401b304 ("compiler: enable CONFIG_OPTIMIZE_INLINING forcibly"). Fixes: 9012d011660ea5cf ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING") Reported-by: noreply(a)ellerman.id.au Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Reviewed-by: Masahiro Yamada <yamada.masahiro(a)socionext.com> --- This is a fix for v5.4-rc1. v2: - Add Reviewed-by, - Fix Fixes, - Add more explanation. --- drivers/video/fbdev/c2p_core.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/c2p_core.h b/drivers/video/fbdev/c2p_core.h index e1035a865fb945f0..45a6d895a7d7208e 100644 --- a/drivers/video/fbdev/c2p_core.h +++ b/drivers/video/fbdev/c2p_core.h @@ -29,7 +29,7 @@ static inline void _transp(u32 d[], unsigned int i1, unsigned int i2, extern void c2p_unsupported(void); -static inline u32 get_mask(unsigned int n) +static __always_inline u32 get_mask(unsigned int n) { switch (n) { case 1: @@ -57,7 +57,7 @@ static inline u32 get_mask(unsigned int n) * Transpose operations on 8 32-bit words */ -static inline void transp8(u32 d[], unsigned int n, unsigned int m) +static __always_inline void transp8(u32 d[], unsigned int n, unsigned int m) { u32 mask = get_mask(n); @@ -99,7 +99,7 @@ static inline void transp8(u32 d[], unsigned int n, unsigned int m) * Transpose operations on 4 32-bit words */ -static inline void transp4(u32 d[], unsigned int n, unsigned int m) +static __always_inline void transp4(u32 d[], unsigned int n, unsigned int m) { u32 mask = get_mask(n); @@ -126,7 +126,7 @@ static inline void transp4(u32 d[], unsigned int n, unsigned int m) * Transpose operations on 4 32-bit words (reverse order) */ -static inline void transp4x(u32 d[], unsigned int n, unsigned int m) +static __always_inline void transp4x(u32 d[], unsigned int n, unsigned int m) { u32 mask = get_mask(n); -- 2.17.1

2 2

[PATCH V6 0/8] backlight: qcom-wled: Support for QCOM wled driver
by Kiran Gunda 04 Nov '19

04 Nov '19

This patch series renames the pm8941-wled.c driver to qcom-wled.c to add the support for multiple PMICs supported by qualcomm. This patch series supports both PM8941 and PMI8998 WLED. The PMI8998 WLED has the support to handle the OVP (over voltage protection) and the SC (short circuit protection) interrupts. It also has the auto string detection algorithm support to configure the right strings if the user specified string configuration is in-correct. These three features are added in this series for PMI8998. changes from v1: - Fixed the commit message for - backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c Changes from v2: - Fixed bjorn and other reviewer's comments - Seperated the device tree bindings - Splitted out the WLED4 changes in seperate patch - Merged OVP and auto string detection patch Changes from v3: - Added Reviewed-by/Acked-by tags - Fixed comments from Bjorn/Vinod/Rob - Splitting the "backlight: qcom-wled: Add support for WLED4 peripheral" patch to seperate the WLED3 specific restructure. Changes from v4: - Added reviewed-by/Acked-by tags - Fixed comments from Bjorn/Daniel/Pavel Changes from v5: - Fixed comments from Bjorn/Pavel Kiran Gunda (8): backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c backlight: qcom-wled: restructure the qcom-wled bindings backlight: qcom-wled: Add new properties for PMI8998 backlight: qcom-wled: Rename PM8941* to WLED3 backlight: qcom-wled: Restructure the driver for WLED3 backlight: qcom-wled: Add support for WLED4 peripheral backlight: qcom-wled: add support for short circuit handling. backlight: qcom-wled: Add auto string detection logic .../bindings/leds/backlight/pm8941-wled.txt | 42 - .../bindings/leds/backlight/qcom-wled.txt | 150 +++ drivers/video/backlight/Kconfig | 8 +- drivers/video/backlight/Makefile | 2 +- drivers/video/backlight/pm8941-wled.c | 424 ------- drivers/video/backlight/qcom-wled.c | 1288 ++++++++++++++++++++ 6 files changed, 1443 insertions(+), 471 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt delete mode 100644 drivers/video/backlight/pm8941-wled.c create mode 100644 drivers/video/backlight/qcom-wled.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

5 17

[Bug 109887] vega56 undervolting/overclocking voltage issues
by bugzilla-daemon＠freedesktop.org 31 Oct '19

31 Oct '19

https://bugs.freedesktop.org/show_bug.cgi?id=109887 Bug ID: 109887 Summary: vega56 undervolting/overclocking voltage issues Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: kgkggl+bugs.freedesktop.org(a)gmail.com Created attachment 143547 --> https://bugs.freedesktop.org/attachment.cgi?id=143547&action=edit dmesg output I overwrite "pp_od_clk_voltage" to control the voltage, but I have a problem. The GPU voltage represents the value of "/sys/class/drm/card0/device/hwmon/hwmon0/in0_input" If I set "pp_od_clk_voltage" before starting Xorg/compton/WM, the GPU voltage will be locked at 1200mv. If I set "pp_od_clk_voltage" after starting Xorg/compton/WM, the GPU is locked to 1200mv after a heavy load. Unless I set "echo c > /sys/class/drm/card0/device/pp_od_clk_voltage" again, the idle voltage will return to 900-950mv.But still higher than the set value. Then we have a new problem.I can't control the "P7" voltage by setting "pp_od_clk_voltage". The value in "pp_od_clk_voltage" can be changed, but the reading is always 1200mv when the GPU jumps to "P7". I set "P6" and "P7" to the same value to prevent the GPU from jumping to "P7" My "pp_od_clk_voltage" setting: OD_SCLK: 0: 852Mhz 800mV 1: 974Mhz 825mV 2: 1096Mhz 850mV 3: 1218Mhz 875mV 4: 1340Mhz 900mV 5: 1462Mhz 925mV 6: 1584Mhz 950mV 7: 1584Mhz 950mV OD_MCLK: 0: 167Mhz 800mV 1: 500Mhz 800mV 2: 700Mhz 900mV 3: 800Mhz 950mV OD_RANGE: SCLK: 852MHz 2400MHz MCLK: 167MHz 1500MHz VDDC: 800mV 1200mV Default "pp_od_clk_voltage" setting OD_SCLK: 0: 852Mhz 800mV 1: 991Mhz 900mV 2: 1138Mhz 950mV 3: 1269Mhz 1000mV 4: 1312Mhz 1050mV 5: 1474Mhz 1100mV 6: 1538Mhz 1150mV 7: 1590Mhz 1200mV OD_MCLK: 0: 167Mhz 800mV 1: 500Mhz 800mV 2: 700Mhz 900mV 3: 800Mhz 950mV OD_RANGE: SCLK: 852MHz 2400MHz MCLK: 167MHz 1500MHz VDDC: 800mV 1200mV RYZEN 1700 MSI B350M MORTAR PowerColor Radeon RX Vega 56 Linux 5.0.0-arch1-1-ARCH #1 SMP PREEMPT Mon Mar 4 14:11:43 UTC 2019 x86_64 GNU/Linux Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 18

[PATCH v4 0/2] backlight_lm3630a: add enable_gpios property
by Andreas Kemnade 29 Oct '19

29 Oct '19

To be able to handle the HWEN pin of the lm3630a, add an enable gpio to the driver and a property. Tested on Kobo Clara HD. Changes in v2: simplification and reordering Changes in v3: added acked-by removed legacy include Changes in v4: added reviewed-by moved gpio to the right position in the bindings example Andreas Kemnade (2): dt-bindings: backlight: lm3630a: add enable_gpios backlight: lm3630a: add an enable gpio for the HWEN pin .../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +++++ drivers/video/backlight/lm3630a_bl.c | 9 +++++++++ 2 files changed, 14 insertions(+) -- 2.20.1

5 8

[Bug 204947] New: Scatter Gather not working properly on Raven ?
by bugzilla-daemon＠bugzilla.kernel.org 27 Oct '19

27 Oct '19

https://bugzilla.kernel.org/show_bug.cgi?id=204947 Bug ID: 204947 Summary: Scatter Gather not working properly on Raven ? Product: Drivers Version: 2.5 Kernel Version: master Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: haxk612(a)gmail.com Regression: No I have Acer Nitro 5 with Ryzen 5 2500U and RX560X. The dGPU is wired into iGPU (VEGA8) so we have to use PRIME. I reported a bug earlier about tearing in games. I have been told i have to wait for scatter gather support. Now that its in place i tried it to my suprise tearing was still there. Only way to get rid of it is to use TearFree which intrduces stuttering at even 60fps. If you need anything just tell me i will be happy to provide any logs or that sort of stuff. -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2019