dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

[RFC PATCH 0/2] Add Xilinx DSI-TX DRM driver
by Venkateshwar Rao Gannavarapu 08 Jul '20

08 Jul '20

MIPI DSI TX subsystem allows you to quickly create systems based on the MIPI protocol. It interfaces between the video processing subsystems and MIPI-based displays. An internal high-speed physical layer design, D-PHY, is provided to allow direct connection to display peripherals. The subsystem consists of the following sub-blocks: - MIPI D-PHY - MIPI DSI TX Controller - AXI Crossbar Please refer pg238 [1]. The DSI TX Controller receives stream of image data through an input stream interface. At design time, this subsystem can be configured to number of lanes and command mode support. This patch series adds the dt-binding and DRM driver for Xilinx DSI-TX soft IP. patch is created on git://linuxtv.org/pinchartl/media.git drm/dpsub/next References: [1]: https://www.xilinx.com/support/documentation/ip_documentation/mipi_dsi_tx_s… Venkateshwar Rao Gannavarapu (2): dt-bindings: display: xlnx: Add Xilinx DSI TX subsystem bindings drm: xlnx: driver for Xilinx DSI TX Subsystem .../devicetree/bindings/display/xlnx/xlnx,dsi.txt | 68 ++ drivers/gpu/drm/xlnx/Kconfig | 11 + drivers/gpu/drm/xlnx/Makefile | 2 + drivers/gpu/drm/xlnx/xlnx_dsi.c | 755 +++++++++++++++++++++ 4 files changed, 836 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/xlnx/xlnx,dsi.txt create mode 100644 drivers/gpu/drm/xlnx/xlnx_dsi.c -- 2.7.4 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

5 16

RE: [RFC PATCH v2 0/3] RDMA: add dma-buf support
by Xiong, Jianxin 08 Jul '20

08 Jul '20

> -----Original Message----- > From: Jason Gunthorpe <jgg(a)ziepe.ca> > Sent: Tuesday, June 30, 2020 10:35 AM > To: Xiong, Jianxin <jianxin.xiong(a)intel.com> > Cc: linux-rdma(a)vger.kernel.org; Doug Ledford <dledford(a)redhat.com>; Sumit Semwal <sumit.semwal(a)linaro.org>; Leon Romanovsky > <leon(a)kernel.org>; Vetter, Daniel <daniel.vetter(a)intel.com>; Christian Koenig <christian.koenig(a)amd.com> > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support > > On Tue, Jun 30, 2020 at 05:21:33PM +0000, Xiong, Jianxin wrote: > > > > Heterogeneous Memory Management (HMM) utilizes > > > > mmu_interval_notifier and ZONE_DEVICE to support shared virtual > > > > address space and page migration between system memory and device > > > > memory. HMM doesn't support pinning device memory because pages > > > > located on device must be able to migrate to system memory when > > > > accessed by CPU. Peer-to-peer access is possible if the peer can > > > > handle page fault. For RDMA, that means the NIC must support on-demand paging. > > > > > > peer-peer access is currently not possible with hmm_range_fault(). > > > > Currently hmm_range_fault() always sets the cpu access flag and device > > private pages are migrated to the system RAM in the fault handler. > > However, it's possible to have a modified code flow to keep the device > > private page info for use with peer to peer access. > > Sort of, but only within the same device, RDMA or anything else generic can't reach inside a DEVICE_PRIVATE and extract anything useful. But pfn is supposed to be all that is needed. > > > > So.. this patch doesn't really do anything new? We could just make a MR against the DMA buf mmap and get to the same place? > > > > That's right, the patch alone is just half of the story. The > > functionality depends on availability of dma-buf exporter that can pin > > the device memory. > > Well, what do you want to happen here? The RDMA parts are reasonable, but I don't want to add new functionality without a purpose - the > other parts need to be settled out first. At the RDMA side, we mainly want to check if the changes are acceptable. For example, the part about adding 'fd' to the device ops and the ioctl interface. All the previous comments are very helpful for us to refine the patch so that we can be ready when GPU side support becomes available. > > The need for the dynamic mapping support for even the current DMA Buf hacky P2P users is really too bad. Can you get any GPU driver to > support non-dynamic mapping? We are working on direct direction. > > > > > migrate to system RAM. This is due to the lack of knowledge about > > > > whether the importer can perform peer-to-peer access and the lack > > > > of resource limit control measure for GPU. For the first part, the > > > > latest dma-buf driver has a peer-to-peer flag for the importer, > > > > but the flag is currently tied to dynamic mapping support, which > > > > requires on-demand paging support from the NIC to work. > > > > > > ODP for DMA buf? > > > > Right. > > Hum. This is not actually so hard to do. The whole dma buf proposal would make a lot more sense if the 'dma buf MR' had to be the > dynamic kind and the driver had to provide the faulting. It would not be so hard to change mlx5 to be able to work like this, perhaps. (the > locking might be a bit tricky though) The main issue is that not all NICs support ODP. > > > > > There are a few possible ways to address these issues, such as > > > > decoupling peer-to-peer flag from dynamic mapping, allowing more > > > > leeway for individual drivers to make the pinning decision and > > > > adding GPU resource limit control via cgroup. We would like to get > > > > comments on this patch series with the assumption that device > > > > memory pinning via dma-buf is supported by some GPU drivers, and > > > > at the same time welcome open discussions on how to address the > > > > aforementioned issues as well as GPU-NIC peer-to-peer access solutions in general. > > > > > > These seem like DMA buf problems, not RDMA problems, why are you > > > asking these questions with a RDMA patch set? The usual DMA buf people are not even Cc'd here. > > > > The intention is to have people from both RDMA and DMA buffer side to > > comment. Sumit Semwal is the DMA buffer maintainer according to the > > MAINTAINERS file. I agree more people could be invited to the discussion. > > Just added Christian Koenig to the cc-list. > > Would be good to have added the drm lists too Thanks, cc'd dri-devel here, and will also do the same for the previous part of the thread. > > > If the umem_description you mentioned is for information used to > > create the umem (e.g. a structure for all the parameters), then this would work better. > > It would make some more sense, and avoid all these weird EOPNOTSUPPS. Good, thanks for the suggestion. > > Jason

5 23

[RFC PATCH 0/4] DSI/DBI and TinyDRM driver
by Paul Cercueil 08 Jul '20

08 Jul '20

Hi, Here's a follow-up on the previous discussion about the current state of DSI/DBI panel drivers, TinyDRM, and the need of a cleanup. This patchset introduces the following: * It slightly tweaks the MIPI DSI code so that it supports MIPI DBI over various buses. This patch has been tested with a non-upstream DRM panel driver for a ILI9331 DBI/8080 panel, written with the DSI framework (and doesn't include <drm/drm_mipi_dbi.h>), and non-upstream DSI/DBI host driver for the Ingenic SoCs. * A SPI DBI host driver, using the current MIPI DSI framework. It allows MIPI DSI/DBI drivers to be written with the DSI framework, even if they are connected over SPI, instead of registering as SPI device drivers. Since most of these panels can be connected over various buses, it permits to reuse the same driver independently of the bus used. * A TinyDRM driver for DSI/DBI panels, once again independent of the bus used; the only dependency (currently) being that the panel must understand DCS commands. * A DRM panel driver to test the stack. This driver controls Ilitek ILI9341 based DBI panels, like the Adafruit YX240QV29-T 320x240 2.4" TFT LCD panel. This panel was converted from drivers/gpu/drm/tiny/ili9341.c. I would like to emphasize that while it has been compile-tested, I did not test it with real hardware since I do not have any DBI panel connected over SPI. I did runtime-test the code, just without any panel connected. Another thing to note, is that it does not break Device Tree ABI. The display node stays the same: display@0 { compatible = "adafruit,yx240qv29", "ilitek,ili9341"; reg = <0>; spi-max-frequency = <32000000>; dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>; rotation = <270>; backlight = <&backlight>; }; The reason it works, is that the "adafruit,yx240qv29" device is probed on the SPI bus, so it will match with the SPI/DBI host driver. This will in turn register the very same node with the DSI bus, and the ILI9341 DRM panel driver will probe. The driver will detect that no controller is linked to the panel, and eventually register the DBI/DSI TinyDRM driver. I can't stress it enough that this is a RFC, so it still has very rough edges. Cheers, -Paul Paul Cercueil (4): gpu/drm: dsi: Let host and device specify supported bus gpu/drm: Add SPI DBI host driver gpu/drm: Add TinyDRM for DSI/DBI panels gpu/drm: Add Ilitek ILI9341 DBI panel driver drivers/gpu/drm/bridge/Kconfig | 8 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/dbi-spi.c | 159 +++++++++ drivers/gpu/drm/drm_mipi_dsi.c | 9 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 347 +++++++++++++++++++ drivers/gpu/drm/tiny/Kconfig | 8 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/tiny-dsi.c | 262 ++++++++++++++ include/drm/drm_mipi_dsi.h | 31 ++ 11 files changed, 836 insertions(+) create mode 100644 drivers/gpu/drm/bridge/dbi-spi.c create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c create mode 100644 drivers/gpu/drm/tiny/tiny-dsi.c -- 2.26.2

6 16

[PATCH] drm/stm: repair runtime power management
by Marek Vasut 08 Jul '20

08 Jul '20

Add missing pm_runtime_get_sync() into ltdc_crtc_atomic_enable() to match pm_runtime_put_sync() in ltdc_crtc_atomic_disable(), otherwise the LTDC might suspend via runtime PM, disable clock, and then fail to resume later on. The test which triggers it is roughly -- run qt5 application which uses eglfs platform and etnaviv, stop the application, sleep for 15 minutes, run the application again. This leads to a timeout waiting for vsync, because the LTDC has suspended, but did not resume. Fixes: 35ab6cfbf211 ("drm/stm: support runtime power management") Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Yannick Fertré <yannick.fertre(a)st.com> Cc: Philippe Cornu <philippe.cornu(a)st.com> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Vincent Abriou <vincent.abriou(a)st.com> Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com> Cc: Alexandre Torgue <alexandre.torgue(a)st.com> To: dri-devel(a)lists.freedesktop.org Cc: linux-stm32(a)st-md-mailman.stormreply.com Cc: linux-arm-kernel(a)lists.infradead.org --- ------------[ cut here ]------------ WARNING: CPU: 0 PID: 297 at drivers/gpu/drm/drm_atomic_helper.c:1494 drm_atomic_helper_wait_for_vblanks+0x1dc/0x200 [CRTC:35:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 297 Comm: QSGRenderThread Not tainted 5.6.0-rc3-next-20200228-00010-g318bf0fc08ef #2 Hardware name: STM32 (Device Tree Support) [<c010f18c>] (unwind_backtrace) from [<c010afb8>] (show_stack+0x10/0x14) [<c010afb8>] (show_stack) from [<c07b1d3c>] (dump_stack+0xb4/0xd0) [<c07b1d3c>] (dump_stack) from [<c011d8b8>] (__warn+0xd4/0xf0) [<c011d8b8>] (__warn) from [<c011dc4c>] (warn_slowpath_fmt+0x78/0xa8) [<c011dc4c>] (warn_slowpath_fmt) from [<c04a266c>] (drm_atomic_helper_wait_for_vblanks+0x1dc/0x200) [<c04a266c>] (drm_atomic_helper_wait_for_vblanks) from [<c04a510c>] (drm_atomic_helper_commit_tail+0 x50/0x60) [<c04a510c>] (drm_atomic_helper_commit_tail) from [<c04a52a8>] (commit_tail+0x12c/0x13c) [<c04a52a8>] (commit_tail) from [<c04a53b4>] (drm_atomic_helper_commit+0xf4/0x100) [<c04a53b4>] (drm_atomic_helper_commit) from [<c04a2d38>] (drm_atomic_helper_set_config+0x58/0x6c) [<c04a2d38>] (drm_atomic_helper_set_config) from [<c04b1994>] (drm_mode_setcrtc+0x450/0x550) [<c04b1994>] (drm_mode_setcrtc) from [<c04ad570>] (drm_ioctl_kernel+0x90/0xe8) [<c04ad570>] (drm_ioctl_kernel) from [<c04ad8ac>] (drm_ioctl+0x2e4/0x32c) [<c04ad8ac>] (drm_ioctl) from [<c0246784>] (vfs_ioctl+0x20/0x38) [<c0246784>] (vfs_ioctl) from [<c02470f0>] (ksys_ioctl+0xbc/0x7b0) [<c02470f0>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x54) Exception stack(0xee8f3fa8 to 0xee8f3ff0) 3fa0: 00000005 adcbeb18 00000005 c06864a2 adcbeb18 00000001 3fc0: 00000005 adcbeb18 c06864a2 00000036 00000029 00000023 00000023 00000007 3fe0: b113b098 adcbeafc b1125413 b6155cf8 ---[ end trace 2ad5ba954ceb767a ]--- --- drivers/gpu/drm/stm/ltdc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 99bf93e8b36f..301de0498078 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -425,9 +425,12 @@ static void ltdc_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_state) { struct ltdc_device *ldev = crtc_to_ltdc(crtc); + struct drm_device *ddev = crtc->dev; DRM_DEBUG_DRIVER("\n"); + pm_runtime_get_sync(ddev->dev); + /* Sets the background color value */ reg_write(ldev->regs, LTDC_BCCR, BCCR_BCBLACK); -- 2.25.0

4 7

[PATCH v13 0/2] Add initial support for slimport anx7625
by Xin Ji 08 Jul '20

08 Jul '20

Hi all, The following series add support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the v13 version, any mistakes, please let me know, I will fix it in the next series. Change history: v13: Fix comments from Launrent Pinchart and Rob Herring - Picked up Rob's Reviewed-By - Add .detect and .get_edid interface in bridge funcs. v12: Fix comments from Hsin-Yi Wang - Rebase the code on kernel 5.7, fix DRM interface not match issue. v11: Fix comments from Rob Herring - Update commit message. - Remove unused label. v10: Fix comments from Rob Herring, Daniel. - Fix dt_binding_check warning. - Update description. v9: Fix comments from Sam, Nicolas, Daniel - Remove extcon interface. - Remove DPI support. - Fix dt_binding_check complains. - Code clean up and update description. v8: Fix comments from Nicolas. - Fix several coding format. - Update description. v7: - Fix critical timing(eg:odd hfp/hbp) in "mode_fixup" interface, enhance MIPI RX tolerance by setting register MIPI_DIGITAL_ADJ_1 to 0x3D. Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP .../bindings/display/bridge/analogix,anx7625.yaml | 95 + drivers/gpu/drm/bridge/analogix/Kconfig | 9 + drivers/gpu/drm/bridge/analogix/Makefile | 1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 1999 ++++++++++++++++++++ drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++++ 5 files changed, 2501 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4

3 6

[PATCH v2 00/14] Support more HDMI modes on RK3228/RK3328
by Jonas Karlman 07 Jul '20

07 Jul '20

This series make it possible to use more HDMI modes on RK3328, and presumably also on RK3228. It also prepares for a future YUV420 and 10-bit output series. Part of this has been reworked from vendor BSP 4.4 kernel commits. Patch 1-5 fixes issues and shortcomings in the inno hdmi phy driver. Patch 6 prepares for use of high TMDS bit rates used with HDMI 2.0 and 10-bit output modes. Patch 7-13 changes rk3228/rk3328 to use mode_valid functions suited for the inno hdmi phy instead of the dw-hdmi phy. These changes allows for more CEA modes to be usable, e.g. some 4K and fractal modes. Patch 14 adds support for more pixel clock rates in order to support common DMT modes in addition to CEA modes. Note: I have only been able to build test RK322x related changes as I do not have any RK322x device to test on. All modes, including fractal modes, has been tested with modetest on a RK3328 Rock64 device using e.g. modetest -M rockchip -s 39:3840x2160-29.97 Changes in v2: - collect acked-by tag - drop the limit resolution width to 3840 patch This series is also available at [1] and the early work on YUV420 and 10-bit output is available at [2]. [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-inno-hdmi-phy [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-bus-format Regards, Jonas Algea Cao (1): phy/rockchip: inno-hdmi: Support more pre-pll configuration Huicong Xu (1): phy/rockchip: inno-hdmi: force set_rate on power_on Jonas Karlman (11): phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328 phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write drm/rockchip: dw-hdmi: allow high tmds bit rates drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328 clk: rockchip: set parent rate for DCLK_VOP clock on rk3228 arm64: dts: rockchip: increase vop clock rate on rk3328 arm64: dts: rockchip: add vpll clock to hdmi node on rk3328 ARM: dts: rockchip: add vpll clock to hdmi node on rk3228 drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328 drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328 Zheng Yang (1): phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate arch/arm/boot/dts/rk322x.dtsi | 4 +- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +- drivers/clk/rockchip/clk-rk3228.c | 2 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 47 ++++++-- drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 110 ++++++++++++------ 5 files changed, 120 insertions(+), 49 deletions(-) -- 2.17.1

3 18

[PATCH v3 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
by Hans de Goede 07 Jul '20

07 Jul '20

Hi All, Here is v3 of my patch series converting the i915 driver's code for controlling the panel's backlight with an external PWM controller to use the atomic PWM API. See below for the changelog. Initially the plan was for this series to consist of 2 parts: 1. convert the pwm-crc driver to support the atomic PWM API and 2. convert the i915 driver's PWM code to use the atomic PWM API. But during testing I've found a number of bugs in the pwm-lpss and I found that the acpi_lpss code needs some special handling because of some ugliness found in most Cherry Trail DSDTs. So now this series has grown somewhat large and consists of 4 parts: 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness 2. various fixes to the pwm-lpss driver 3. convert the pwm-crc driver to support the atomic PWM API and 4. convert the i915 driver's PWM code to use the atomic PWM API So we need to discuss how to merge this (once it passes review). Although the inter-dependencies are only runtime I still think we should make sure that 1-3 are in the drm-intel-next-queued (dinq) tree before merging the i915 changes. Both to make sure that the intel-gfx CI system does not become unhappy and for bisecting reasons. The involved acpi_lpss and pwm drivers do not see a whole lot of churn, so it likely is the easiest to just merge everything through dinq. Rafael and Thierry, can I get your Acked-by for directly merging this into dinq? This series has been tested (and re-tested after adding various bug-fixes) extensively. It has been tested on the following devices: -Asus T100TA BYT + CRC-PMIC PWM -Toshiba WT8-A BYT + CRC-PMIC PWM -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM -Asus T100HA CHT + CRC-PMIC PWM -Terra Pad 1061 BYT + LPSS PWM -Trekstor Twin 10.1 BYT + LPSS PWM -Asus T101HA CHT + CRC-PMIC PWM -GPD Pocket CHT + CRC-PMIC PWM Changelog: Changes in v2: - Fix coverletter subject - Drop accidentally included debugging patch - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once ( - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX Changes in v3: - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value" - Use base_unit_range - 1 as maximum value for the clamp() - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume" - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" patch from previous versions of this patch-set, which really was a hack working around the resume issue which this patch fixes properly. - PATCH v3 6 - 11 pwm-crc changes: - Various small changes resulting from the reviews by Andy and Uwe, including some refactoring of the patches to reduce the amount of churn in the patch-set Regards, Hans

4 35

[PATCH v4 0/9] drm/vc4: Turn the TXP into a CRTC
by Maxime Ripard 07 Jul '20

07 Jul '20

Hi, This is another part of the rpi4 HDMI series that got promoted to a series of its own to try to reduce the main one. This rework is needed since the bcm2711 used in the rpi4 has a more complex routing in the HVS that doesn't allow to use a fairly simple mapping like what was used before. Since that mapping affects both the pixelvalves and the TXP, turning the TXP into a CRTC just like pixelvalves are allows to deal with the mapping in the CRTC states, which turns out to be pretty convenient. Let me know what you think, Maxime Changes from v3: - Stripped the patches out of the main HDMI series - Change the bind order of the HVS to avoid a compatible check - Added Eric's tags - Rebased on top of drm-misc-next Maxime Ripard (9): drm/vc4: Reorder the bind order of the devices drm/vc4: crtc: Move HVS setup code to the HVS driver drm/vc4: crtc: Make state functions public drm/vc4: crtc: Split CRTC data in two drm/vc4: crtc: Only access the PixelValve registers if we have to drm/vc4: crtc: Move the CRTC initialisation to a separate function drm/vc4: crtc: Move the txp_armed function to the TXP drm/vc4: txp: Turn the TXP into a CRTC of its own drm/vc4: crtc: Remove the feed_txp tests drivers/gpu/drm/vc4/vc4_crtc.c | 427 ++++++---------------------------- drivers/gpu/drm/vc4/vc4_drv.c | 2 +- drivers/gpu/drm/vc4/vc4_drv.h | 38 ++- drivers/gpu/drm/vc4/vc4_hvs.c | 291 +++++++++++++++++++++++- drivers/gpu/drm/vc4/vc4_txp.c | 109 ++++++++- 5 files changed, 522 insertions(+), 345 deletions(-) base-commit: ebd11f706c9d9756edad5b5f3f3310d77d77f60c -- git-series 0.9.1

2 12

[Bug 208129] New: amdgpu: polaris10 sudden crash, garbled graphics.
by bugzilla-daemon＠bugzilla.kernel.org 06 Jul '20

06 Jul '20

https://bugzilla.kernel.org/show_bug.cgi?id=208129 Bug ID: 208129 Summary: amdgpu: polaris10 sudden crash, garbled graphics. Product: Drivers Version: 2.5 Kernel Version: 5.5.17 Hardware: x86-64 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: mkj(a)gotu.dk Regression: No I'm running up-to-date Debian 10 + backports. While using ordinary everyday programs, like webbrowser with video inside, text editors, etc. my visuals suddenly froze a little while, but audio still playing in background. Keyboard still worked, but screen graphics was garbled as show in the attached picture. GPU fan speeded up and down a few times and settled again. I managed to switch to another TTY and dump informations about crash before I rebooted the machine. Note that I often suspend my machine after work. -- You are receiving this mail because: You are watching the assignee of the bug.

1 8

[PATCH 0/8] Fix a bunch of W=1 warnings in Backlight
by Lee Jones 06 Jul '20

06 Jul '20

Attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (8): backlight: lms501kf03: Remove unused const variables backlight: lcd: Add missing kerneldoc entry for 'struct device parent' backlight: ili922x: Add missing kerneldoc descriptions for CHECK_FREQ_REG() args backlight: ili922x: Remove invalid use of kerneldoc syntax backlight: ili922x: Add missing kerneldoc description for ili922x_reg_dump()'s arg backlight: backlight: Supply description for function args in existing Kerneldocs backlight: lm3630a_bl: Remove invalid checks for unsigned int < 0 backlight: qcom-wled: Remove unused configs for LED3 and LED4 drivers/video/backlight/backlight.c | 2 ++ drivers/video/backlight/ili922x.c | 8 ++++++-- drivers/video/backlight/lcd.c | 1 + drivers/video/backlight/lm3630a_bl.c | 4 ++-- drivers/video/backlight/lms501kf03.c | 8 -------- drivers/video/backlight/qcom-wled.c | 8 -------- 6 files changed, 11 insertions(+), 20 deletions(-) -- 2.25.1

3 27

← Newer
1
...
16
17
18
19
20
21
22
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020