[PATCH v5 0/8] drm/omap: Add virtual-planes support

This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. This patch series adds virtual-plane support to omapdrm driver to allow the use of display wider than 2048 pixels. In order to do so we introduce the concept of hw_overlay which can then be dynamically allocated to a plane.

[PATCH v5 3/8] drm/omap: introduce omap_hw_overlay

From: Benoit Parrot Split out the hardware overlay specifics from omap_plane. To start, the hw overlays are statically assigned to planes. The goal is to eventually assign hw overlays dynamically to planes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then perform

[PATCH v5 2/8] drm/omap: Add ovl checking funcs to dispc_ops

From: Benoit Parrot In order to be able to dynamically assign overlays to planes we need to be able to asses the overlay capabilities. Add a helper function to be able to retrieve the supported capabilities of an overlay. And export the function to check if a fourcc is supported on a given over

[PATCH v5 1/8] drm/omap: Add ability to check if requested plane modes can be supported

From: Benoit Parrot We currently assume that an overlay has the same maximum width and maximum height as the overlay manager. This assumption is incorrect. On some variants the overlay manager maximum width is twice the maximum width that the overlay can handle. We need to add the appropriate dat

[PATCH v5 4/8] drm/omap: omap_plane: subclass drm_plane_state

From: Benoit Parrot In preparation to add omap plane state specific extensions we need to subclass drm_plane_state and add the relevant helpers. The addition of specific extension will be done separately. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong --- drivers/gpu/drm/omapdrm/

[PATCH v5 5/8] drm/omap: Add global state as a private atomic object

From: Benoit Parrot Global shared resources (like hw overlays) for omapdrm are implemented as a part of atomic state using the drm_private_obj infrastructure available in the atomic core. omap_global_state is introduced as a drm atomic private object. The two funcs omap_get_global_state() and om

[PATCH v5 8/8] drm/omap: Add a 'right overlay' to plane state

From: Benoit Parrot If the drm_plane has a source width that's greater than the max width supported by a single hw overlay, then we assign a 'r_overlay' to it in omap_plane_atomic_check(). Both overlays should have the capabilities required to handle the source framebuffer. The only parameters t

[PATCH v5 7/8] drm/omap: add plane_atomic_print_state support

From: Benoit Parrot Now that we added specific item to our subclassed drm_plane_state we can add omap_plane_atomic_print_state() helper to dump out our own driver specific plane state. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong --- drivers/gpu/drm/omapdrm/omap_plane.c | 18 +++

[PATCH v5 6/8] drm/omap: dynamically assign hw overlays to planes

From: Benoit Parrot (re)assign the hw overlays to planes based on required caps, and to handle situations where we could not modify an in-use plane. This means all planes advertise the superset of formats and properties. Userspace must (as always) use atomic TEST_ONLY step for atomic updates, as

Multiple DRI card detection in compositor systemd units

I'm trying to find a robust way to handle the phrasing of UDev rules and systemd dependencies about /dev/dri/cardXXX nodes to ensure that several compositor services running on different graphics cards of a device all can reliably start up. First, some basic observations: * The DRM su

Re: Multiple DRI card detection in compositor systemd units

I get the intuition behind the suggestion to aggregate using logind seats, as far as it goes. But it still seems to me that this just pushes the question back: how do you identify which card is which in order to assign it to a seat? Normally this is done using udev rules, right? Additionally, I'

[PATCH v12 00/17] drm/i915: Introduce Intel PXP

PXP (Protected Xe Path) is an i915 component, available on GEN12 and newer platforms, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. changes from v11: - Patch #8: Fix uninitialized variable. - Patch #15: Needed

Re: [PATCH] drm/i915/uncore: fwtable read handlers are now used on all forcewake platforms

On 23/09/2021 01:30, Matt Roper wrote: With the recent refactor of the uncore mmio handling, all forcewake-based platforms (i.e., graphics version 6 and beyond) now use the 'fwtable' read handlers. Let's pull the assignment out of the per-platform if/else ladder to make this more obvious. Sug

Re: [PATCH v3 1/6] dt-bindings: display: renesas, du: Provide bindings for r8a779a0

Hi Kieran, On Thu, Sep 23, 2021 at 1:47 AM Kieran Bingham wrote: > From: Kieran Bingham > > Extend the Renesas DU display bindings to support the r8a779a0 V3U. > > Reviewed-by: Laurent Pinchart > Signed-off-by: Kieran Bingham > > --- > v2: > - Collected Laurent's tag > - Remove clock-names r

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Wed, 22 Sep 2021 11:28:37 -0400 Harry Wentland wrote: > On 2021-09-22 04:31, Pekka Paalanen wrote: > > On Tue, 21 Sep 2021 14:05:05 -0400 > > Harry Wentland wrote: > > > >> On 2021-09-21 09:31, Pekka Paalanen wrote: > >>> On Mon, 20 Sep 2021 20:14:50 -0400 > >>> Harry Wentland wrote: >

[PULL] drm-misc-next

Hi Dave, Daniel, Here's this week PR for drm-misc-next Maxime drm-misc-next-2021-09-23: drm-misc-next for 5.15: UAPI Changes: Cross-subsystem Changes: Core Changes: Driver Changes: - Conversions to dev_err_probe() helper - rockchip: Various build improvements, Use DRM_BRIDGE_ATTACH_N

Re: [PATCH v8 10/16] i915/gvt: remove spaces in pr_debug "gvt: core:" etc prefixes

On 2021.09.15 10:39:51 -0600, Jim Cromie wrote: > Taking embedded spaces out of existing prefixes makes them better > class-prefixes; simplifying the extra quoting needed otherwise: > > $> echo format "^gvt: core:" +p >control > > Dropping the internal spaces means any trailing space in a query

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On Wed, 22 Sep 2021 11:06:53 -0400 Harry Wentland wrote: > On 2021-09-20 20:14, Harry Wentland wrote: > > On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 > > -0400 > >> Harry Wentland wrote: > >> > > > > >>> +If a display's maximum HDR white level is correctly re

Re: [PATCH v4 24/24] drm/exynos: dsi: Adjust probe order

Hi Maxime, On 22.09.2021 10:53, Maxime Ripard wrote: > On Fri, Sep 17, 2021 at 02:35:05PM +0200, Marek Szyprowski wrote: >> On 13.09.2021 12:30, Andrzej Hajda wrote: >>> W dniu 10.09.2021 o 12:12, Maxime Ripard pisze: Without proper care and an agreement between how DSI hosts and devices

Re: Handling DRM master transitions cooperatively

On Wed, 22 Sep 2021 11:21:16 +0200 Hans de Goede wrote: > Hi, > > On 9/22/21 10:56 AM, Pekka Paalanen wrote: > > On Tue, 14 Sep 2021 15:45:21 +0200 > > Daniel Vetter wrote: > > > >> On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalanen wrote: > >>> On Wed, 8 Sep 2021 18:27:09 +0200 > >>

Re: [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support

Hi, On Tue, Sep 21, 2021 at 03:42:05PM -0700, Rob Clark wrote: > On Tue, Sep 21, 2021 at 3:20 PM Doug Anderson wrote: > > > > Hi, > > > > On Mon, Sep 20, 2021 at 3:53 PM Rob Clark wrote: > > > > > > From: Rob Clark > > > > > > Slightly awkward to fish out the display_info when we aren't creatin

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Nikolaus, Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller a écrit : Hi Paul, thanks for another update. We have been delayed to rework the CI20 HDMI code on top of your series but it basically works in some situations. There is for example a problem if the EDID reports DRM

Re: Handling DRM master transitions cooperatively

Hi, On 9/23/21 10:23 AM, Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:21:16 +0200 > Hans de Goede wrote: > >> Hi, >> >> On 9/22/21 10:56 AM, Pekka Paalanen wrote: >>> On Tue, 14 Sep 2021 15:45:21 +0200 >>> Daniel Vetter wrote: >>> On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalan

[PATCH] drm/amd/display: Fix randomly flicking on overlay with enabled ABM

From: "Yipeng Chen (Jasber)" [Why] Enabled ABM (level != 0) would raise short pluse irq DC_IRQ_SOURCE_HPD1RX randomly with PSR error LINK_CRC_ERROR. Actually there is no hot plugging on EDP panel. After correcting CRC error, there is no need to send drm hotplug event. [How] Returning false would

Re: [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout

On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test case after executing around 800-900 of 1000 submitted requests. Given the time we allow elsewhere for fences to signal (in the order of seconds), inc

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Paul, > Am 23.09.2021 um 10:49 schrieb Paul Cercueil : > > Hi Nikolaus, > > Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller > a écrit : >> Hi Paul, >> thanks for another update. >> We have been delayed to rework the CI20 HDMI code on top of your series >> but it basically wor

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hello, On Thu, Sep 23, 2021 at 09:49:03AM +0100, Paul Cercueil wrote: > Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller a écrit : > > Hi Paul, > > thanks for another update. > > > > We have been delayed to rework the CI20 HDMI code on top of your series > > but it basically works i

Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs

On Sat, Sep 18, 2021 at 11:38 AM Oded Gabbay wrote: > > On Fri, Sep 17, 2021 at 3:30 PM Daniel Vetter wrote: > > > > On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote: > > > On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote: > > > > On Wed, Sep 15, 2021 at 10:45:36AM +03

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Nikolaus, On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: > > Am 23.09.2021 um 10:49 schrieb Paul Cercueil: > > Le jeu., sept. 23 2021 at 07:52:08 +0200, H. Nikolaus Schaller a écrit : > >> Hi Paul, > >> thanks for another update. > >> We have been delayed to rework the CI

Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

On 22/09/2021 07:25, Thomas Hellström wrote: We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using memcp

Re: [PATCH v2] backlight: propagate errors from get_brightness()

On Tue, 07 Sep 2021, Thomas Weißschuh wrote: > backlight.h documents "struct backlight_ops->get_brightness()" to return > a negative errno on failure. > So far these errors have not been handled in the backlight core. > This leads to negative values being exposed through sysfs although only > posi

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Laurent, > Am 23.09.2021 um 11:27 schrieb Laurent Pinchart > : > > Hi Nikolaus, > > On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: >> > + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, > + DRM_BRIDGE_ATTACH_NO_CONNE

Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

On 9/23/21 11:44 AM, Matthew Auld wrote: On 22/09/2021 07:25, Thomas Hellström wrote: We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Nikolaus, On Thu, Sep 23, 2021 at 11:55:56AM +0200, H. Nikolaus Schaller wrote: > > Am 23.09.2021 um 11:27 schrieb Laurent Pinchart: > > On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: > >> > > + ret = drm_bridge_attach(encoder, &ib->bridge, NULL, >

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout

On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test case after executing around 800-900 of 1000 submitted requests. Given the time we allow elsewhere for fences to signal (in the order of seconds), i

Re: [PATCH v2] backlight: propagate errors from get_brightness()

On 2021-09-23T10:48+0100, Lee Jones wrote: > On Tue, 07 Sep 2021, Thomas Weißschuh wrote: > > > backlight.h documents "struct backlight_ops->get_brightness()" to return > > a negative errno on failure. > > So far these errors have not been handled in the backlight core. > > This leads to negative

[PULL] drm-intel-fixes

Hi Dave & Daniel - drm-intel-fixes-2021-09-23: drm/i915 fixes for v5.15-rc3: - Fix ADL-P memory bandwidth parameters - Fix memory corruption due to a double free - Fix memory leak in DMC firmware handling BR, Jani. The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82:

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Laurent, > Am 23.09.2021 um 12:03 schrieb Laurent Pinchart > : > > Hi Nikolaus, > > On Thu, Sep 23, 2021 at 11:55:56AM +0200, H. Nikolaus Schaller wrote: >>> Am 23.09.2021 um 11:27 schrieb Laurent Pinchart: >>> On Thu, Sep 23, 2021 at 11:19:23AM +0200, H. Nikolaus Schaller wrote: >

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout

Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test case after executing around 800-900 of 1000 submitted requests. Given the time we allow els

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Laurent, > IMHO it is leaving (mature) dw-hdmi untouched and make attachment of a > connector > in ingenic_drm_bind() depend on some condition. Since I don't know details of the DRM bridge/encoder/connector APIs), let me reformulate the quersion for a condition specifically. How can one

Re: [PATCH] drm/amd/display: Fix randomly flicking on overlay with enabled ABM

On Thu, Sep 23, 2021 at 5:03 AM wrote: > > From: "Yipeng Chen (Jasber)" > > [Why] > Enabled ABM (level != 0) would raise short pluse irq DC_IRQ_SOURCE_HPD1RX > randomly with PSR error LINK_CRC_ERROR. Actually there is no hot plugging > on EDP panel. After correcting CRC error, there is no need to

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout

On 23/09/2021 12:47, Thomas Hellström wrote: Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test case after executing around 800-900 of 1000

[PATCH v3.1] dt-bindings: display: renesas, du: Provide bindings for r8a779a0

From: Kieran Bingham Extend the Renesas DU display bindings to support the r8a779a0 V3U. Reviewed-by: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Signed-off-by: Kieran Bingham --- v2: - Collected Laurent's tag - Remove clock-names requirement - Specify only a single clock v3: - Use

Re: [PATCH RESEND] drm/i915: Flush buffer pools on driver remove

Hi Matt, Thanks for review. On czwartek, 23 września 2021 00:24:29 CEST Matt Roper wrote: > On Fri, Sep 03, 2021 at 04:23:20PM +0200, Janusz Krzysztofik wrote: > > In preparation for clean driver release, attempts to drain work queues > > and release freed objects are taken at driver remove time.

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout

On 9/23/21 2:59 PM, Tvrtko Ursulin wrote: On 23/09/2021 12:47, Thomas Hellström wrote: Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the requests times out for the gem_exec_suspend igt test

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Nikolaus, Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller a écrit : Hi Laurent, Am 23.09.2021 um 12:03 schrieb Laurent Pinchart : Hi Nikolaus, On Thu, Sep 23, 2021 at 11:55:56AM +0200, H. Nikolaus Schaller wrote: Am 23.09.2021 um 11:27 schrieb Laurent Pinchart: On

Re: Multiple DRI card detection in compositor systemd units

On Wed, 22 Sep 2021 16:16:48 + "Hoosier, Matt" wrote: > > The /dev/dri/by-path idea works, I suppose, if you have different > physical graphics cards. In my case, that's not true. These are > virtualized cards that the silicon vendor's DRM drivers use to expose > different subsets of DRM res

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On 2021-09-23 04:01, Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:06:53 -0400 > Harry Wentland wrote: > >> On 2021-09-20 20:14, Harry Wentland wrote: >>> On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 >>> -0400 Harry Wentland wrote: >> >> >> > +

Re: [PATCH v2] backlight: propagate errors from get_brightness()

On Thu, 23 Sep 2021, Thomas Weißschuh wrote: > On 2021-09-23T10:48+0100, Lee Jones wrote: > > On Tue, 07 Sep 2021, Thomas Weißschuh wrote: > > > > > backlight.h documents "struct backlight_ops->get_brightness()" to return > > > a negative errno on failure. > > > So far these errors have not been

Re: [PATCH RESEND] drm/i915: Flush buffer pools on driver remove

On Thu, Sep 23, 2021 at 03:07:06PM +0200, Janusz Krzysztofik wrote: > Hi Matt, > > Thanks for review. > > On czwartek, 23 września 2021 00:24:29 CEST Matt Roper wrote: > > On Fri, Sep 03, 2021 at 04:23:20PM +0200, Janusz Krzysztofik wrote: > > > In preparation for clean driver release, attempts t

Re: [PATCH] drm/ttm: Don't delete the system manager before the delayed delete

On 9/20/21 10:59 AM, Zack Rusin wrote: On Sep 20, 2021, at 02:30, Christian König wrote: Am 17.09.21 um 19:53 schrieb Zack Rusin: On some hardware, in particular in virtualized environments, the system memory can be shared with the "hardware". In those cases the BO's allocated through the ttm

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout

On 23/09/2021 14:19, Thomas Hellström wrote: On 9/23/21 2:59 PM, Tvrtko Ursulin wrote: On 23/09/2021 12:47, Thomas Hellström wrote: Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC submission on DG1, the execution of the reques

Re: [PATCH] drm/ttm: Don't delete the system manager before the delayed delete

Am 23.09.21 um 15:53 schrieb Zack Rusin: On 9/20/21 10:59 AM, Zack Rusin wrote: On Sep 20, 2021, at 02:30, Christian König wrote: Am 17.09.21 um 19:53 schrieb Zack Rusin: On some hardware, in particular in virtualized environments, the system memory can be shared with the "hardware". In thos

Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)

Hi Nathan, On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote: > On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote: > > Hi Randy, > > > > On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap wrote: > > > On 8/19/21 6:59 AM, Maxime Ripard wrote: > > > > We already depe

Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)

On Thu, Sep 23, 2021 at 04:52:08PM +0200, Maxime Ripard wrote: > Hi Nathan, > > On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote: > > On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote: > > > Hi Randy, > > > > > > On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap

Re: [PATCH] drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid

On Mon, 20 Sep 2021, Akira Yokosawa wrote: > Nested grids in grid-table cells are not specified as proper ReST > constructs. > Commit 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0") > added a couple of kerneldoc tables of the form: > > +---+---+-

Re: [Intel-gfx] [PATCH v6 3/9] drm/i915/gt: Increase suspend timeout

On 9/23/21 4:33 PM, Tvrtko Ursulin wrote: On 23/09/2021 14:19, Thomas Hellström wrote: On 9/23/21 2:59 PM, Tvrtko Ursulin wrote: On 23/09/2021 12:47, Thomas Hellström wrote: Hi, Tvrtko, On 9/23/21 12:13 PM, Tvrtko Ursulin wrote: On 22/09/2021 07:25, Thomas Hellström wrote: With GuC su

Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC

On 2021-09-23 9:40 a.m., Harry Wentland wrote: On 2021-09-23 04:01, Pekka Paalanen wrote: On Wed, 22 Sep 2021 11:06:53 -0400 Harry Wentland wrote: On 2021-09-20 20:14, Harry Wentland wrote: On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 -0400 Harry Wentland wro

Re: [PATCH v2 09/12] lib: test_hmm add module param for zone device type

On 9/21/2021 12:14 AM, Alistair Popple wrote: On Tuesday, 21 September 2021 6:05:30 AM AEST Sierra Guiza, Alejandro (Alex) wrote: On 9/20/2021 3:53 AM, Alistair Popple wrote: On Tuesday, 14 September 2021 2:16:01 AM AEST Alex Sierra wrote: In order to configure device public in test_hmm, tw

Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)

On Thu, Sep 23, 2021 at 07:55:32AM -0700, Nathan Chancellor wrote: > On Thu, Sep 23, 2021 at 04:52:08PM +0200, Maxime Ripard wrote: > > Hi Nathan, > > > > On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote: > > > On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote: > > > >

[patch 07/11] drm/i915/pmu: Use hrtimer_forward_now()

hrtimer_forward() is about to be removed from the public interfaces. Replace it with hrtimer_forward_now() which provides the same functionality. Signed-off-by: Thomas Gleixner Cc: David Airlie Cc: intel-...@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Jani Nikula Cc: dri-devel@lists.freedesk

[patch 00/11] hrtimers: Cleanup hrtimer_forward() [ab]use

A recent syzbot report unearthed abuse of hrtimer_forward() which can cause runaway timers hogging the CPU in timer expiry context by rearming the timer in the past over and over. This happens when the caller uses timer->expiry for the 'now' argument of hrtimer_forward(). That works as long as the

Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver

Hi Chun-Kuang, Missatge de Chun-Kuang Hu del dia dt., 21 de set. 2021 a les 15:15: > > Hi, Enric: > > Enric Balletbo Serra 於 2021年9月21日 週二 下午4:36寫道： > > > > Hi Chun-Kuang, > > > > (again without html format, sorry for the noise) > > > > Missatge de Chun-Kuang Hu del dia dj., 12 > > d’ag. 2021 a

[PATCH v2] drm/i915/bdb: Fix version check

With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+" the size of bdb_lfp_backlight_data structure has been increased, causing if-statement in the parse_lfp_backlight function that comapres this structure size to the one retrieved from BDB, always to fail for older revisions. This patch cal

Re: [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support

On Wed, Sep 22, 2021 at 5:44 PM Laurent Pinchart wrote: > > Hi Rob, > > Thank you for the patch. > > On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote: > > From: Rob Clark > > > > Slightly awkward to fish out the display_info when we aren't creating > > own connector. But I don't see an

Re: Multiple DRI card detection in compositor systemd units

Hi Pekka, Those are fair answers. In my case, it does happen that the configuration available on the virtual cards includes a way to set distinct names reported by drmGetVersion()->name. It looks like the consensus is that UDev rules probably shouldn't be consulting the name as a distinguishin

[PATCH 1/1] drm: This patch fixes colour banding caused by wrong information passed by the Lenovo Thinkpad L540 panel.

Hi, there is an issue with Lenovo Thinkpad L540 very similar to those described here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749420 or here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788308 that is a bad looking color banding with dark colors mainly. It happens with an

Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

On Thu, Sep 23, 2021 at 12:05:58AM +0300, Kirill A. Shutemov wrote: > Unless we find other way to guarantee RIP-relative access, we must use > fixup_pointer() to access any global variables. Yah, I've asked compiler folks about any guarantees we have wrt rip-relative addresses but it doesn't look

Re: [PATCH 1/1] drm: This patch fixes colour banding caused by wrong information passed by the Lenovo Thinkpad L540 panel.

On Thu, Sep 23, 2021 at 2:15 PM Francesco Paolo Lovergine wrote: > > Hi, The patch title is a little long. How about something like: drm: fix colour banding on Lenovo Thinkpad L540 panel > > there is an issue with Lenovo Thinkpad L540 very similar to those described > here: > https://bugs.lau

[PATCH] drm/vc4: crtc: Make sure the HDMI controller is powered when disabling

Since commit 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time"), during the initial setup of the driver we call into the VC4 HDMI controller hooks to make sure the controller is properly disabled. However, we were never making sure that the device was properly powered while doing so. Thi

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Paul, > Am 23.09.2021 um 15:30 schrieb Paul Cercueil : > > Hi Nikolaus, > > Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller > a écrit : >> Hi Laurent, >> Ah, ok. >> But then we still have issues. >> Firstly I would assume that get_edid only works properly if it is initialized

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Le jeu., sept. 23 2021 at 20:52:23 +0200, H. Nikolaus Schaller a écrit : Hi Paul, Am 23.09.2021 um 15:30 schrieb Paul Cercueil : Hi Nikolaus, Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller a écrit : Hi Laurent, Ah, ok. But then we still have issues. Firstly I wo

Re: [PATCH] DRM/Panel : abt-y030xx067a yellow tint fix

Hi Christophe, Paul, On Tue, Sep 14, 2021 at 11:27:16AM +0200, Christophe Branchereau wrote: > The previous parameters caused an unbalanced yellow tint. > > Signed-off-by: Christophe Branchereau with the subject fixed the patch is: Acked-by: Sam Ravnborg Paul - I assume you will apply this as

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

Hi Paul, > Am 23.09.2021 um 21:39 schrieb Paul Cercueil : > > > > Le jeu., sept. 23 2021 at 20:52:23 +0200, H. Nikolaus Schaller > a écrit : >> Hi Paul, >>> Am 23.09.2021 um 15:30 schrieb Paul Cercueil : >>> Hi Nikolaus, >>> Le jeu., sept. 23 2021 at 13:41:28 +0200, H. Nikolaus Schaller >>>

Re: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture

Change of plan: Instead of a BoF, this is now a session in the "GPU/media/AI buffer management and interop MC" micro conference. Thank you Daniel Stone for making that happen. https://linuxplumbersconf.org/event/11/contributions/1112/ It is scheduled for tomorrow (Friday) 08:40-10:00 Pacific,

Re: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture

On Thu, Sep 23, 2021 at 04:25:08PM -0400, Felix Kuehling wrote: > Change of plan: Instead of a BoF, this is now a session in the "GPU/media/AI > buffer management and interop MC" micro conference. Thank you Daniel Stone > for making that happen. > https://linuxplumbersconf.org/event/11/contribution

Re: [PATCH v6 1/2] drm/bridge: parade-ps8640: Use regmap APIs

Hi, On Tue, Sep 21, 2021 at 11:06 AM Philip Chen wrote: > > Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs, > which will simplify the future update on ps8640 driver. > > Reviewed-by: Douglas Anderson > Acked-by: Sam Ravnborg > Signed-off-by: Philip Chen > --- > > (no ch

Re: [PATCH v12 05/35] dt-bindings: clock: tegra-car: Document new clock sub-nodes

On Mon, 20 Sep 2021 21:11:15 +0300, Dmitry Osipenko wrote: > Document sub-nodes which describe Tegra SoC clocks that require a higher > voltage of the core power domain in order to operate properly on a higher > clock rates. Each node contains a phandle to OPP table and power domain. > > The root

[pull] amdgpu, amdkfd drm-fixes-5.15

Hi Dave, Daniel, Fixes for 5.15. The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82: Linux 5.15-rc2 (2021-09-19 17:28:22 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.15-2021-09-23 for you to fe

RE: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture

[AMD Official Use Only] Hi Matt, I originally picked the 10 am pdt time slot to avoid those conflicts. But I see the overlap is only partial. I also see Peterz is giving a talk that also overlaps partially. But I think this is survivable. I suggest we just try to make this work as best we can.

Re: [PATCH] DRM/Panel : abt-y030xx067a yellow tint fix

Hi, Le jeu., sept. 23 2021 at 22:17:51 +0200, Sam Ravnborg a écrit : Hi Christophe, Paul, On Tue, Sep 14, 2021 at 11:27:16AM +0200, Christophe Branchereau wrote: The previous parameters caused an unbalanced yellow tint. Signed-off-by: Christophe Branchereau with the subject fixed the p

Re: [PATCH v3 6/6] drm/ingenic: Attach bridge chain to encoders

On Thursday, 23 September 2021 22:23:28 CEST H. Nikolaus Schaller wrote: > > > Am 23.09.2021 um 21:39 schrieb Paul Cercueil : > > > > Start by wiring things properly, like in my previously linked DTS, and > > *test*. If it fails, tell us where it fails. > > Well, I tell where drm_bridge_attach fa

Re: BoF at LPC: Documenting the Heterogeneous Memory Model Architecture

Hi, On Thu, 23 Sept 2021 at 21:40, Matthew Wilcox wrote: > On Thu, Sep 23, 2021 at 04:25:08PM -0400, Felix Kuehling wrote: > > Change of plan: Instead of a BoF, this is now a session in the "GPU/media/AI > > buffer management and interop MC" micro conference. Thank you Daniel Stone > > for making

Re: [PATCH v2 0/4] CMDQ refinement of Mediatek DRM driver

Hi, Enric: Enric Balletbo Serra 於 2021年9月24日 週五 上午12:36寫道： > > Hi Chun-Kuang, > > Missatge de Chun-Kuang Hu del dia dt., 21 de > set. 2021 a les 15:15: > > > > Hi, Enric: > > > > Enric Balletbo Serra 於 2021年9月21日 週二 下午4:36寫道： > > > > > > Hi Chun-Kuang, > > > > > > (again without html format, so

[PATCH 0/3] drm/panel: Proper cleanup after mipi_dsi_attach()

I've tested a few dual-DSI panel drivers which choke if they PROBE_DEFER at the wrong time, so I patched those up in patch 1 and 2. Patch 3 fixes the other drivers that I couldn't test, but seem to have all the same problem. Brian Norris (3): drm/panel: kingdisplay-kd097d04: Delete panel on att

[PATCH 2/3] drm/panel: innolux-p079zca: Delete panel on attach() failure

If we fail to attach (e.g., because 1 of 2 dual-DSI controllers aren't ready), we leave a dangling drm_panel reference to freed memory. Clean that up on failure. This problem exists since the driver's introduction, but is especially relevant after refactored for dual-DSI variants. Fixes: 14c8f2e9

[PATCH 1/3] drm/panel: kingdisplay-kd097d04: Delete panel on attach() failure

If we fail to attach (e.g., because 1 of 2 dual-DSI controllers aren't ready), we leave a dangling drm_panel reference to freed memory. Clean that up on failure. Fixes: 2a994cbed6b2 ("drm/panel: Add Kingdisplay KD097D04 panel driver") Signed-off-by: Brian Norris --- drivers/gpu/drm/panel/panel-

[PATCH 3/3] drm/panel: Delete panel on mipi_dsi_attach() failure

Many DSI panel drivers fail to clean up their panel references on mipi_dsi_attach() failure, so we're leaving a dangling drm_panel reference to freed memory. Clean that up on failure. Noticed by inspection, after seeing similar problems on other drivers. Therefore, I'm not marking Fixes/stable. S

[PATCH v2] drm/amd/display: Fix randomly flicking on overlay with enabled ABM

From: "Yipeng Chen (Jasber)" [Why] Enabled ABM (level != 0) would raise short pulse irq DC_IRQ_SOURCE_HPD1RX randomly with PSR error LINK_CRC_ERROR. Actually there is no hot plugging on EDP panel. After correcting CRC error, there is no need to send drm hotplug event. [How] Returning false would

[PATCH v5 1/2] pwm: Introduce single-PWM of_xlate function

The existing pxa driver and the upcoming addition of PWM support in the TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and thereby a need for a of_xlate function with the period as its single argument. Introduce a common helper function in the core that can be used as of_xlate b

[PATCH v5 2/2] drm/bridge: ti-sn65dsi86: Implement the pwm_chip

The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4, with the primary purpose of controlling the backlight of the attached panel. Add an implementation that exposes this using the standard PWM framework, to allow e.g. pwm-backlight to expose this to the user. Signed-off-by: Bjorn A

Re: [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support

Hi Rob, On Thu, Sep 23, 2021 at 10:31:52AM -0700, Rob Clark wrote: > On Wed, Sep 22, 2021 at 5:44 PM Laurent Pinchart wrote: > > On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > Slightly awkward to fish out the display_info when we aren't creating > > >

Re: [PATCH v2 6/9] vfio/mdev: Add mdev available instance checking to the core

On Tue, 2021-09-21 at 10:19 -0300, Jason Gunthorpe wrote: > On Mon, Sep 20, 2021 at 08:02:29PM +0200, Cornelia Huck wrote: > > On Thu, Sep 09 2021, Jason Gunthorpe wrote: > > > > > Many of the mdev drivers use a simple counter for keeping track > > > of the > > > available instances. Move this co

Re: [PATCH v2 2/9] vfio/ccw: Pass vfio_ccw_private not mdev_device to various functions

On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote: > mdev_device should only be used in functions assigned to ops > callbacks, > interior functions should use the struct vfio_ccw_private instead of > repeatedly trying to get it from the mdev. > > Signed-off-by: Jason Gunthorpe > --- > dri

Re: [PATCH v2 1/9] vfio/ccw: Use functions for alloc/free of the vfio_ccw_private

On Thu, 2021-09-09 at 16:38 -0300, Jason Gunthorpe wrote: > Makes the code easier to understand what is memory lifecycle and what > is > other stuff. > > Signed-off-by: Jason Gunthorpe > --- > drivers/s390/cio/vfio_ccw_drv.c | 137 ++-- > > 1 file changed, 78 inserti

[git pull] drm fixes for 5.15-rc3

Hey Linus, quiet week this week, just some i915 and amd fixes, just getting ready for my all nighter maintainer summit! Dave. drm-fixes-2021-09-24: drm fixes for 5.15-rc3 i915: - Fix ADL-P memory bandwidth parameters - Fix memory corruption due to a double free - Fix memory leak in DMC firmware

Re: [PATCH v5 13/16] drm/mediatek: add ETHDR support for MT8195

Hi Chun-Kuang, Thanks for the review. On Wed, 2021-09-22 at 08:09 +0800, Chun-Kuang Hu wrote: > Hi, Nancy: > > Nancy.Lin 於 2021年9月6日 週一 下午3:15寫道： > > > > ETHDR is a part of ovl_adaptor. > > ETHDR is designed for HDR video and graphics conversion in the > > external > > display path. It handles

[PATCH v2 14/17] drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()

As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos --- drivers/gpu/drm/gma500/psb_device.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions

[PATCH v2 10/17] drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()

As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos Reviewed-by: Sean Paul --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++- 1 file changed, 10 i

[PATCH v2 16/17] drm: cleanup: remove drm_modeset_(un)lock_all()

Functions drm_modeset_lock_all() and drm_modeset_unlock_all() are no longer used anywhere and can be removed. Signed-off-by: Fernando Ramos --- drivers/gpu/drm/drm_modeset_lock.c | 94 +- include/drm/drm_modeset_lock.h | 2 - 2 files changed, 3 insertions(+), 93

  1   2   >