similar to: [PATCH] drm: remove UMS leftover

New getfb2 functionality uses drm_mode_fb_cmd2 struct to be symmetric with addfb2. Also modifies *_fb_create_handle() calls to accept a format_plane_index so that handles for each plane can be generated. Previously, many *_fb_create_handle() calls simply defaulted to plane 0 only. Signed-off-by: Joe Kniss <djmk at google.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +-

- 'joi' on irc pointed out that this triggers a BUG_ON, because kzalloc could sleep. - The irq handler should restore the value NV03_PFIFO_CACHES, but still it's better if this stuff doesn't happen in the middle of fifo create context. I see no reason in spin locking pgraph create context, it isn't activated at that stage. - Move and rename the lock after some discussion with

All non-kms driver fields are now located in struct drm_legacy_state. A driver-wide instance is available via struct drm_driver.legacy. The call sites test if the driver is marked with DRIVER_LEGACY before accessing the fields. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_bufs.c | 10 +++++----- drivers/gpu/drm/drm_context.c | 9

On Tue, May 12, 2020 at 3:10 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi Alex > > Am 12.05.20 um 20:32 schrieb Alex Deucher: > > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > >> > >> Hi > >> > >> Am 11.05.20 um 19:17 schrieb Christian K?nig: > >>> Hi guys, >

- In case of suspend lockups it's nice to know it happened in nouveau. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drv.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index 874adf5..ec8452f 100644 ---

Since we'll be allocating resources for kthread_create_worker() in the next commit (which could fail and require us to clean up the mess), let's simplify the cleanup process a bit by registering a drm_vblank_init_release() action for each drm_vblank_crtc so they're still cleaned up if we fail to initialize one of them. Changes since v3: * Use drmm_add_action_or_reset() - Daniel Vetter

Since we'll be allocating resources for kthread_create_worker() in the next commit (which could fail and require us to clean up the mess), let's simplify the cleanup process a bit by registering a drm_vblank_init_release() action for each drm_vblank_crtc so they're still cleaned up if we fail to initialize one of them. Changes since v3: * Use drmm_add_action_or_reset() - Daniel Vetter

--- drivers/gpu/drm/nouveau/nouveau_state.c | 52 ++++++++++++++++--------------- 1 files changed, 27 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 2ed41d3..25d207c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -317,7 +317,7 @@ nouveau_card_init(struct

--- drivers/gpu/drm/nouveau/nouveau_state.c | 73 ++++++++++++++++++++----------- 1 files changed, 48 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 2ed41d3..9fc5824 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -317,7 +317,7 @@ nouveau_card_init(struct

mimic the behavior of vblank_disable_fn(), another caller of drm_vblank_disable_and_save(). This avoids oopsing, while trying to disable vblank on a not connected display: [ 12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm] [ 12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc uvcvideo rtsx_usb_ms

On Tue, 12 May 2020 at 20:48, Alex Deucher <alexdeucher at gmail.com> wrote: > > >> > > >> There's some AGP support code in the DRM core. Can some of that declared > > >> as legacy? > > >> > > >> Specifically, what about these AGP-related ioctl calls? Can they be > > >> declared as legacy? It would appear to me that

Hi Alex Am 12.05.20 um 20:32 schrieb Alex Deucher: > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Hi >> >> Am 11.05.20 um 19:17 schrieb Christian K?nig: >>> Hi guys, >>> >>> Well let's face it AGP is a total headache to maintain and dead for at least 10+ years. >>> >>> We

On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote: > I believe the solution is to not call drm_crtc_vblank_off for atomic > modesetting in nouveau_display_fini. I think Ben's working on it. Yes, the goal of vblank_on/off was very much to not paper over driver bugs with clever tricks like these. If the driver cant keep track of its vblank, something has gone wrong, and the core

This adds basic support for driving sensor chips off the nvidia i2c buses, along with basic support for reading the internal GPU sensor on supported chipsets. It's heavily cribbed off nvclock. Having scanned a large number of bioses, I'm pretty convinced that the appropriate i2c bus is always number 2 in the list on <g80 - I'm not sure about later cards yet. There's still a lot

On Thu, Jul 20, 2017 at 11:58 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Mh ok, > > paper over in nouveau_display_fini until Ben comes up with a better idea > then?! No paper needed, just don't call drm_vblank_off for the atomic case. Not sure why that patch isn't landed yet, it should be simple. -Daniel > > Greetings, > > Tobias

I believe the solution is to not call drm_crtc_vblank_off for atomic modesetting in nouveau_display_fini. I think Ben's working on it. On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > mimic the behavior of vblank_disable_fn(), another caller of > drm_vblank_disable_and_save(). > > This avoids oopsing, while trying to

Mh ok, paper over in nouveau_display_fini until Ben comes up with a better idea then?! Greetings, Tobias On 7/20/17 10:13 AM, Daniel Vetter wrote: > On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote: >> I believe the solution is to not call drm_crtc_vblank_off for atomic >> modesetting in nouveau_display_fini. I think Ben's working on it. > Yes, the goal of

i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and atomic_commit. drm_object_property_get_value() does not read the correct value of atomic properties if DRIVER_ATOMIC is not set. Checking whether the driver uses atomic modeset is a better check instead as the property values are tracked in the state structures. v2: Included header Cc: Daniel Vetter <daniel.vetter at

i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and atomic_commit. drm_object_property_get_value() does not read the correct value of atomic properties if DRIVER_ATOMIC is not set. Checking whether the driver uses atomic modeset is a better check instead as the property values are tracked in the state structures. v2: Included header Cc: Daniel Vetter <daniel.vetter at

Hi, > - add a small core function to registerr HOT_X/HOT_Y for a (cursor) plane, > e.g. drm_plane_register_hotspot(). That should allocate the properties > (if they don't exist yet) and then attach those props to the cursor. We > don't want those props everywhere, but only on drivers that support/need > them, aka virtual hw. Hmm, why is this special to virtual hw?