24 Apr, 2019

1 commit


02 Jan, 2019

1 commit

  • drm_file.h embeds idr structures in DRM-specific structures. Include the
    corresponding header to make drm_file.h self-contained. Make it easier
    to drop drmP.h includes.

    [Updated commit message per Laurent's review while applying.]

    Cc: Sam Ravnborg
    Cc: Daniel Vetter
    Cc: Laurent Pinchart
    Reviewed-by: Daniel Vetter
    Reviewed-by: Laurent Pinchart
    Signed-off-by: Jani Nikula
    Link: https://patchwork.freedesktop.org/patch/msgid/2818b15332ab562722dfc324cf977b7eb4a04401.1545915059.git.jani.nikula@intel.com

    Jani Nikula
     

07 Nov, 2018

1 commit

  • This essentially undoes

    commit 39868bd7668bd47308b1dfd97c212757caee764f
    Author: Chris Wilson
    Date: Tue Oct 29 08:55:58 2013 +0000

    drm: Compact booleans within struct drm_file

    We do lockless access to these flags everywhere, and it's kinda not a
    great idea to mix lockless and bitfields. Aside from that gcc isn't
    generating great code for these.

    If this ever becomes an issue size-wise, I think we need atomic_t here
    and atomic bitflag ops.

    Cc: Chris Wilson
    Cc: David Herrmann
    Cc: Dave Airlie
    Acked-by: Chris Wilson
    Signed-off-by: Daniel Vetter
    Link: https://patchwork.freedesktop.org/patch/msgid/20181102132543.16486-2-daniel.vetter@ffwll.ch

    Daniel Vetter
     

20 Jun, 2018

1 commit

  • Due to the fact that writeback connectors behave in a special way
    in DRM (they always report being disconnected) we might confuse some
    userspace. Add a client capability for writeback connectors that will
    filter them out for clients that don't understand the capability.

    Changelog:
    - only accept the capability if the client has already set the
    DRM_CLIENT_CAP_ATOMIC one.

    Cc: Sean Paul
    Cc: Brian Starkey
    Signed-off-by: Liviu Dudau
    Reviewed-by: Eric Anholt
    Reviewed-by: Brian Starkey
    Link: https://patchwork.freedesktop.org/patch/229038/

    Liviu Dudau
     

14 May, 2018

1 commit

  • drm_minor_alloc() does multiplication on this enum, so the removal
    ended up moving render nodes down from 128 base to 64. This caused
    Mesa's surfaceless backend to be unable to open the render nodes,
    since it was still looking up at 128.

    v2: Add a comment warning the next person.

    Signed-off-by: Eric Anholt
    Fixes: 0d49f303e8a7 ("drm: remove all control node code")
    Reviewed-by: Daniel Vetter
    Cc: Sean Paul
    Link: https://patchwork.freedesktop.org/patch/msgid/20180509001425.12574-1-eric@anholt.net

    Eric Anholt
     

11 May, 2018

1 commit

  • To enable aspect-ratio support in DRM, blindly exposing the aspect
    ratio information along with mode, can break things in existing
    non-atomic user-spaces which have no intention or support to use this
    aspect ratio information.

    To avoid this, a new drm client cap is required to enable a non-atomic
    user-space to advertise if it supports modes with aspect-ratio. Based
    on this cap value, the kernel will take a call on exposing the aspect
    ratio info in modes or not.

    This patch adds the client cap for aspect-ratio.

    Since no atomic-userspaces blow up on receiving aspect-ratio
    information, the client cap for aspect-ratio is always enabled
    for atomic clients.

    Cc: Ville Syrjala
    Cc: Shashank Sharma
    Signed-off-by: Ankit Nautiyal

    V3: rebase
    V4: As suggested by Marteen Lankhorst modified the commit message
    explaining the need to use the DRM cap for aspect-ratio. Also,
    tweaked the comment lines in the code for better understanding and
    clarity, as recommended by Shashank Sharma.
    V5: rebase
    V6: rebase
    V7: rebase
    V8: rebase
    V9: rebase
    V10: rebase
    V11: rebase
    V12: As suggested by Daniel Vetter and Ville Syrjala,
    always enable aspect-ratio client cap for atomic userspaces,
    if no atomic userspace breaks on aspect-ratio bits.
    V13: rebase
    V14: rebase

    Reviewed-by: Shashank Sharma
    Reviewed-by: Daniel Vetter
    Signed-off-by: Maarten Lankhorst
    Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-7-git-send-email-ankit.k.nautiyal@intel.com

    Ankit Nautiyal
     

04 May, 2018

1 commit

  • With the ioctl and driver prep done, we can remove everything else.

    Reviewed-by: Sean Paul
    Signed-off-by: Daniel Vetter
    Cc: Gustavo Padovan
    Cc: Maarten Lankhorst
    Cc: Sean Paul
    Cc: David Airlie
    Link: https://patchwork.freedesktop.org/patch/msgid/20180420065159.4531-4-daniel.vetter@ffwll.ch

    Daniel Vetter
     

29 Nov, 2017

1 commit


14 Jun, 2017

1 commit

  • Sync objects are new toplevel drm object, that contain a
    pointer to a fence. This fence can be updated via command
    submission ioctls via drivers.

    There is also a generic wait obj API modelled on the vulkan
    wait API (with code modelled on some amdgpu code).

    These objects can be converted to an opaque fd that can be
    passes between processes.

    v2: rename reference/unreference to put/get (Chris)
    fix leaked reference (David Zhou)
    drop mutex in favour of cmpxchg (Chris)
    v3: cleanups from danvet, rebase on drm_fops rename
    check fd_flags is 0 in ioctls.
    v4: export find/free, change replace fence to take a
    syncobj. In order to support lookup first, replace
    later semantics which seem in the end to be cleaner.

    Reviewed-by: Sean Paul
    Reviewed-by: Chris Wilson
    Signed-off-by: Dave Airlie

    Dave Airlie
     

01 Jun, 2017

1 commit

  • drm_irq.c contains both the irq helper library (optional) and the
    vblank support (optional, but part of the modeset uapi, and doesn't
    require the use of the irq helpers at all.

    Split this up for more clarity of the scope of the individual bits.

    v2: Move misplaced hunks to this patch (Stefan).

    Cc: Stefan Agner
    Reviewed-by: Stefan Agner
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/20170531092146.12528-1-daniel.vetter@ffwll.ch

    Daniel Vetter
     

14 Mar, 2017

2 commits

  • Well, mostly drm_file.h, and clean up all related things:

    - I didnt' figure out the difference between preclose and postclose.
    The existing explanation in drm-internals.rst didn't convince me,
    since it's also really outdated - we clean up pending DRM events in
    the core nowadays. I put a FIXME in for the future.

    - Another FIXME is to have a macro for default fops.

    - Lots of links all around, main areas are to tie the overview in
    drm_file.c more into the callbacks in struct drm_device, and the
    other is to link render/primary node code to the right sections in
    drm-uapi.rst.

    - Also moved the open/close stuff to drm_drv.h from drm-internals.rst,
    seems like the better place for that information. Since that section
    was rather outdated this amounted to full-on rewrite.

    A big missing piece here is some overview graph, but I think better to
    wait with that one until drm_device and drm_driver are also fully
    documented.

    v2: Nits from Sean.

    Reviewed-by: Sean Paul
    Reviewed-by: Liviu Dudau
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-12-daniel.vetter@ffwll.ch

    Daniel Vetter
     
  • We might as well dump the drm_file pointer, that's about as useful
    a cookie as the pid. Noticed while typing docs for drm_file and friends.

    Since the only consumer of this is the tracepoints I think we can safely
    change this - those tracepoints should not be uapi relevant at all. It
    all goes back to

    commit b9c2c9ae882f058084e13e339925dbf8d2d20271
    Author: Jesse Barnes
    Date: Thu Jul 1 16:48:09 2010 -0700

    drm: add per-event vblank event trace points

    which doesn't give a special justification for using pid over a pointer.

    Also note that the nouveau code setting it is entirely pointless:
    Since this isn't a vblank event, it will never hit the vblank
    tracepoints.

    Cc: Ben Skeggs
    Reviewed-by: Sean Paul
    Reviewed-by: Liviu Dudau
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-11-daniel.vetter@ffwll.ch

    Daniel Vetter
     

09 Mar, 2017

1 commit

  • I'm torn on whether drm_minor really should be here or somewhere else.
    Maybe with more clarity after untangling drmP.h more this is easier to
    decide, for now I've put a FIXME comment right next to it. Right now
    we need struct drm_minor for the inline drm_file type helpers, and so
    it does kinda make sense to have them here.

    Next patch will kerneldoc-ify the entire pile.

    Reviewed-by: Gustavo Padovan
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-10-daniel.vetter@ffwll.ch

    Daniel Vetter