An error occurred fetching the project authors.
  1. 11 Mar, 2019 1 commit
  2. 17 Jan, 2019 1 commit
  3. 03 Oct, 2018 1 commit
    • Neil Armstrong's avatar
      drm/fb_helper: Allow leaking fbdev smem_start · 4be9bd10
      Neil Armstrong authored
      Since "drm/fb: Stop leaking physical address", the default behaviour of
      the DRM fbdev emulation is to set the smem_base to 0 and pass the new
      FBINFO_HIDE_SMEM_START flag.
      
      The main reason is to avoid leaking physical addresse to user-space, and
      it follows a general move over the kernel code to avoid user-space to
      manipulate physical addresses and then use some other mechanisms like
      dma-buf to transfer physical buffer handles over multiple subsystems.
      
      But, a lot of devices depends on closed sources binaries to enable
      OpenGL hardware acceleration that uses this smem_start value to
      pass physical addresses to out-of-tree modules in order to render
      into these physical adresses. These should use dma-buf buffers allocated
      from the DRM display device instead and stop relying on fbdev overallocation
      to gather DMA memory (some HW vendors delivers GBM and Wayland capable
      binaries, but older unsupported devices won't have these new binaries
      and are doomed until an Open Source solution like Lima finalizes).
      
      Since these devices heavily depends on this kind of software and because
      the smem_start population was available for years, it's a breakage to
      stop leaking smem_start without any alternative solutions.
      
      This patch adds a Kconfig depending on the EXPERT config and an unsafe
      kernel module parameter tainting the kernel when enabled.
      
      A clear comment and Kconfig help text was added to clarify why and when
      this patch should be reverted, but in the meantime it's a necessary
      feature to keep.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Cc: Noralf Trønnes <noralf@tronnes.org>
      Cc: Maxime Ripard <maxime.ripard@bootlin.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Ben Skeggs <skeggsb@gmail.com>
      Cc: Christian König <christian.koenig@amd.com>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Tested-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1538136355-15383-1-git-send-email-narmstrong@baylibre.com
      4be9bd10
  4. 28 Aug, 2018 1 commit
  5. 13 Jul, 2018 1 commit
  6. 09 Jul, 2018 1 commit
    • Arnd Bergmann's avatar
      drm: vkms: select DRM_KMS_HELPER · 5ba57bab
      Arnd Bergmann authored
      Without this, we get link errors during randconfig build:
      
      drivers/gpu/drm/vkms/vkms_drv.o:(.rodata+0xa0): undefined reference to `drm_atomic_helper_check'
      drivers/gpu/drm/vkms/vkms_drv.o:(.rodata+0xa8): undefined reference to `drm_atomic_helper_commit'
      drivers/gpu/drm/vkms/vkms_plane.o:(.rodata+0x0): undefined reference to `drm_atomic_helper_update_plane'
      drivers/gpu/drm/vkms/vkms_plane.o:(.rodata+0x8): undefined reference to `drm_atomic_helper_disable_plane'
      drivers/gpu/drm/vkms/vkms_plane.o:(.rodata+0x18): undefined reference to `drm_atomic_helper_plane_reset'
      drivers/gpu/drm/vkms/vkms_plane.o:(.rodata+0x28): undefined reference to `drm_atomic_helper_plane_duplicate_state'
      drivers/gpu/drm/vkms/vkms_plane.o:(.rodata+0x30): undefined reference to `drm_atomic_helper_plane_destroy_state'
      drivers/gpu/drm/vkms/vkms_output.o:(.rodata+0x1c0): undefined reference to `drm_helper_probe_single_connector_modes'
      drivers/gpu/drm/vkms/vkms_crtc.o:(.rodata+0x40): undefined reference to `drm_atomic_helper_crtc_reset'
      drivers/gpu/drm/vkms/vkms_crtc.o:(.rodata+0x70): undefined reference to `drm_atomic_helper_set_config'
      drivers/gpu/drm/vkms/vkms_crtc.o:(.rodata+0x78): undefined reference to `drm_atomic_helper_page_flip'
      drivers/gpu/drm/vkms/vkms_crtc.o:(.rodata+0x90): undefined reference to `drm_atomic_helper_crtc_duplicate_state'
      drivers/gpu/drm/vkms/vkms_crtc.o:(.rodata+0x98): undefined reference to `drm_atomic_helper_crtc_destroy_state'
      
      Fixes: 854502fa ("drm/vkms: Add basic CRTC initialization")
      Fixes: 1c7c5fd9 ("drm/vkms: Introduce basic VKMS driver")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180709154901.1989316-1-arnd@arndb.de
      5ba57bab
  7. 05 Jul, 2018 2 commits
  8. 04 May, 2018 2 commits
  9. 03 May, 2018 1 commit
    • Eric Anholt's avatar
      drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+ · 57692c94
      Eric Anholt authored
      This driver will be used to support Mesa on the Broadcom 7268 and 7278
      platforms.
      
      V3D 3.3 introduces an MMU, which means we no longer need CMA or vc4's
      complicated CL/shader validation scheme.  This massively changes the
      GEM behavior, so I've forked off to a new driver.
      
      v2: Mark SUBMIT_CL as needing DRM_AUTH.  coccinelle fixes from kbuild
          test robot. Drop personal git link from MAINTAINERS.  Don't
          double-map dma-buf imported BOs.  Add kerneldoc about needing MMU
          eviction.  Drop prime vmap/unmap stubs.  Delay mmap offset setup
          to mmap time.  Use drm_dev_init instead of _alloc.  Use
          ktime_get() for wait_bo timeouts.  Drop drm_can_sleep() usage,
          since we don't modeset.  Switch page tables back to WC (debug
          change to coherent had slipped in).  Switch
          drm_gem_object_unreference_unlocked() to
          drm_gem_object_put_unlocked().  Simplify overflow mem handling by
          not sharing overflow mem between jobs.
      v3: no changes
      v4: align submit_cl to 64 bits (review by airlied), check zero flags in
          other ioctls.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v4)
      Acked-by: Dave Airlie <airlied@linux.ie> (v3, requested submit_cl change)
      Link: https://patchwork.freedesktop.org/patch/msgid/20180430181058.30181-3-eric@anholt.net
      57692c94
  10. 03 Apr, 2018 1 commit
    • Oleksandr Andrushchenko's avatar
      drm/xen-front: Add support for Xen PV display frontend · c575b7ee
      Oleksandr Andrushchenko authored
      Add support for Xen para-virtualized frontend display driver.
      Accompanying backend [1] is implemented as a user-space application
      and its helper library [2], capable of running as a Weston client
      or DRM master.
      Configuration of both backend and frontend is done via
      Xen guest domain configuration options [3].
      
      Driver limitations:
       1. Only primary plane without additional properties is supported.
       2. Only one video mode supported which resolution is configured
          via XenStore.
       3. All CRTCs operate at fixed frequency of 60Hz.
      
      1. Implement Xen bus state machine for the frontend driver according to
      the state diagram and recovery flow from display para-virtualized
      protocol: xen/interface/io/displif.h.
      
      2. Read configuration values from Xen store according
      to xen/interface/io/displif.h protocol:
        - read connector(s) configuration
        - read buffer allocation mode (backend/frontend)
      
      3. Handle Xen event channels:
        - create for all configured connectors and publish
          corresponding ring references and event channels in Xen store,
          so backend can connect
        - implement event channels interrupt handlers
        - create and destroy event channels with respect to Xen bus state
      
      4. Implement shared buffer handling according to the
      para-virtualized display device protocol at xen/interface/io/displif.h:
        - handle page directories according to displif protocol:
          - allocate and share page directories
          - grant references to the required set of pages for the
            page directory
        - allocate xen balllooned pages via Xen balloon driver
          with alloc_xenballooned_pages/free_xenballooned_pages
        - grant references to the required set of pages for the
          shared buffer itself
        - implement pages map/unmap for the buffers allocated by the
          backend (gnttab_map_refs/gnttab_unmap_refs)
      
      5. Implement kernel modesetiing/connector handling using
      DRM simple KMS helper pipeline:
      
      - implement KMS part of the driver with the help of DRM
        simple pipepline helper which is possible due to the fact
        that the para-virtualized driver only supports a single
        (primary) plane:
        - initialize connectors according to XenStore configuration
        - handle frame done events from the backend
        - create and destroy frame buffers and propagate those
          to the backend
        - propagate set/reset mode configuration to the backend on display
          enable/disable callbacks
        - send page flip request to the backend and implement logic for
          reporting backend IO errors on prepare fb callback
      
      - implement virtual connector handling:
        - support only pixel formats suitable for single plane modes
        - make sure the connector is always connected
        - support a single video mode as per para-virtualized driver
          configuration
      
      6. Implement GEM handling depending on driver mode of operation:
      depending on the requirements for the para-virtualized environment,
      namely requirements dictated by the accompanying DRM/(v)GPU drivers
      running in both host and guest environments, number of operating
      modes of para-virtualized display driver are supported:
       - display buffers can be allocated by either
         frontend driver or backend
       - display buffers can be allocated to be contiguous
         in memory or not
      
      Note! Frontend driver itself has no dependency on contiguous memory for
      its operation.
      
      6.1. Buffers allocated by the frontend driver.
      
      The below modes of operation are configured at compile-time via
      frontend driver's kernel configuration.
      
      6.1.1. Front driver configured to use GEM CMA helpers
           This use-case is useful when used with accompanying DRM/vGPU driver
           in guest domain which was designed to only work with contiguous
           buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can
           only import contiguous PRIME buffers, thus requiring frontend driver
           to provide such. In order to implement this mode of operation
           para-virtualized frontend driver can be configured to use
           GEM CMA helpers.
      
      6.1.2. Front driver doesn't use GEM CMA
           If accompanying drivers can cope with non-contiguous memory then, to
           lower pressure on CMA subsystem of the kernel, driver can allocate
           buffers from system memory.
      
      Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
      may require IOMMU support on the platform, so accompanying DRM/vGPU
      hardware can still reach display buffer memory while importing PRIME
      buffers from the frontend driver.
      
      6.2. Buffers allocated by the backend
      
      This mode of operation is run-time configured via guest domain
      configuration through XenStore entries.
      
      For systems which do not provide IOMMU support, but having specific
      requirements for display buffers it is possible to allocate such buffers
      at backend side and share those with the frontend.
      For example, if host domain is 1:1 mapped and has DRM/GPU hardware
      expecting physically contiguous memory, this allows implementing
      zero-copying use-cases.
      
      Note, while using this scenario the following should be considered:
        a) If guest domain dies then pages/grants received from the backend
           cannot be claimed back
        b) Misbehaving guest may send too many requests to the
           backend exhausting its grant references and memory
           (consider this from security POV).
      
      Note! Configuration options 1.1 (contiguous display buffers) and 2
      (backend allocated buffers) are not supported at the same time.
      
      7. Handle communication with the backend:
       - send requests and wait for the responses according
         to the displif protocol
       - serialize access to the communication channel
       - time-out used for backend communication is set to 3000 ms
       - manage display buffers shared with the backend
      
      [1] https://github.com/xen-troops/displ_be
      [2] https://github.com/xen-troops/libxenbe
      [3] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in;h=a699367779e2ae1212ff8f638eff0206ec1a1cc9;hb=refs/heads/master#l1257Signed-off-by: default avatarOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180403112317.28751-2-andr2000@gmail.com
      c575b7ee
  11. 17 Jan, 2018 1 commit
  12. 07 Dec, 2017 1 commit
  13. 05 Dec, 2017 1 commit
  14. 04 Dec, 2017 2 commits
    • Hans de Goede's avatar
      drm: Add support for a panel-orientation connector property, v6 · 8d70f395
      Hans de Goede authored
      On some devices the LCD panel is mounted in the casing in such a way that
      the up/top side of the panel does not match with the top side of the
      device (e.g. it is mounted upside-down).
      
      This commit adds the necessary infra for lcd-panel drm_connector-s to
      have a "panel orientation" property to communicate how the panel is
      orientated vs the casing.
      
      Userspace can use this property to check for non-normal orientation and
      then adjust the displayed image accordingly by rotating it to compensate.
      
      Changes in v2:
      -Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
       access it easily
      -Have a single drm_connector_init_panel_orientation_property rather then
       create and attach functions. The caller is expected to set
       drm_display_info.panel_orientation before calling this, then this will
       check for platform specific quirks overriding the panel_orientation and if
       the panel_orientation is set after this then it will attach the property.
      
      Changes in v6:
      -Use an enum (with kerneldoc) rather then #defines for
       DRM_MODE_PANEL_ORIENTATION_*
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-4-hdegoede@redhat.com
      8d70f395
    • Hans de Goede's avatar
      drm: Add panel orientation quirks, v6. · 404d1a3e
      Hans de Goede authored
      Some x86 clamshell design devices use portrait tablet screens and a display
      engine which cannot rotate in hardware, so the firmware just leaves things
      as is and we cannot figure out that the display is oriented non upright
      from the hardware.
      
      So at least on x86, we need a quirk table for this. This commit adds a DMI
      based quirk table which is initially populated with 5 such devices: Asus
      T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.
      
      This quirk table will be used by the drm code to let userspace know that
      the display is not mounted upright inside the devices case through a new
      panel orientation drm-connector property, as well as to tell fbcon to
      rotate the console so that it shows the right way up.
      
      Changes in v5:
      -Add a kernel-doc comment documenting drm_get_panel_orientation_quirk()
      -Remove board_* matches from the dmi-matches for the VIOS LTH17 laptop,
       keeping only the (identical) sys_vendor and product_name matches.
       This is necessary because an older version of the bios has
       board_vendor set to VOIS instead of VIOS
      
      Changes in v6:
      -Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-3-hdegoede@redhat.com
      404d1a3e
  15. 26 Sep, 2017 2 commits
    • Felix Kuehling's avatar
      drm/amdgpu: Track pending retry faults in IH and VM (v2) · a2f14820
      Felix Kuehling authored
      IH tracks pending retry faults in a hash table for fast lookup in
      interrupt context. Each VM has a short FIFO of pending VM faults for
      processing in a bottom half.
      
      The IH prescreening stage adds retry faults and filters out repeated
      retry interrupts to minimize the impact of interrupt storms.
      
      It's the VM's responsibility remove pending faults once they are
      handled. For now this is only done when the VM is destroyed.
      
      v2:
      - Made the hash table smaller and the FIFO longer. I never want the
        FIFO to fill up, because that would make prescreen take longer.
        128 pending page faults should be enough to keep migrations busy.
      Signed-off-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Acked-by: Christian König <christian.koenig@amd.com> (v1)
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      a2f14820
    • Felix Kuehling's avatar
      drm/amd: Closed hash table with low overhead (v2) · 5d86b2c3
      Felix Kuehling authored
      This adds a statically sized closed hash table implementation with
      low memory and CPU overhead. The API is inspired by kfifo.
      
      Storing, retrieving and deleting data does not involve any dynamic
      memory management, which makes it ideal for use in interrupt context.
      Static memory usage per entry comprises a 32 or 64 bit hash key, two
      bits for occupancy tracking and the value size stored in the table.
      No list heads or pointers are needed. Therefore this data structure
      should be quite cache-friendly, too.
      
      It uses linear probing and lazy deletion. During lookups free space
      is reclaimed and entries relocated to speed up future lookups.
      
      v2: squash in do_div and _BITOPS_LONG_SHIFT fixes
      Signed-off-by: default avatarFelix Kuehling <Felix.Kuehling@amd.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      5d86b2c3
  16. 19 Sep, 2017 1 commit
  17. 23 Aug, 2017 1 commit
    • Linus Walleij's avatar
      drm/tve200: Add new driver for TVE200 · 179c02fe
      Linus Walleij authored
      This adds a new DRM driver for the Faraday Technology TVE200
      block. This "TV Encoder" encodes a ITU-T BT.656 stream and can
      be found in the StorLink SL3516 (later Cortina Systems CS3516)
      as well as the Grain Media GM8180.
      
      I do not have definitive word from anyone at Faraday that this
      IP block is theirs, but it bears the hallmark of their 3-digit
      version code (200) and is used in two SoCs from completely
      different companies. (Grain Media was fully owned by Faraday
      until it was transferred to NovoTek this january, and
      Faraday did lots of work on the StorLink SoCs.)
      
      The D-Link DIR-685 uses this in connection with the Ilitek
      ILI9322 panel driver that supports BT.656 input, while the
      GM8180 apparently has been used with the Cirrus Logic CS4954
      digital video encoder. The oldest user seems to be
      something called Techwall 2835.
      
      This driver is heavily inspired by Eric Anholt's PL111
      driver and therefore I have mentioned all the ancestor authors
      in the header file.
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170820100557.24991-2-linus.walleij@linaro.org
      179c02fe
  18. 08 May, 2017 1 commit
    • Tom Cooksey's avatar
      drm/pl111: Initial drm/kms driver for pl111 · bed41005
      Tom Cooksey authored
      This is a modesetting driver for the pl111 CLCD display controller
      found on various ARM platforms such as the Versatile Express. The
      driver has only been tested on the bcm911360_entphn platform so far,
      with PRIME-based buffer sharing between vc4 and clcd.
      
      It reuses the existing devicetree binding, while not using quite as
      many of its properties as the fbdev driver does (those are left for
      future work).
      
      v2: Nearly complete rewrite by anholt, cutting 2/3 of the code thanks
          to DRM core's excellent new helpers.
      v3: Don't match pl110 any more, don't attach if we don't have a DRM
          panel, use DRM_GEM_CMA_FOPS, update MAINTAINERS, use the simple
          display helper, use drm_gem_cma_dumb_create (same as our wrapper).
      v4: Change the driver's .name to not clash with fbdev in sysfs, drop
          platform alias, drop redundant "drm" in DRM driver name, hook up
          .prepare_fb to the CMA helper so that DMA fences should work.
      v5: Move register definitions inside the driver directory, fix build
          in COMPILE_TEST and !AMBA mode.
      v6: Drop TIM2_CLKSEL for now to be consistent with existing DT
          bindings, switch back to external register definitions.
      Signed-off-by: default avatarTom Cooksey <tom.cooksey@arm.com>
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Linus Walleij <linus.walleij@linaro.org> (v5)
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170413031746.12921-2-eric@anholt.net
      bed41005
  19. 14 Apr, 2017 1 commit
  20. 26 Feb, 2017 1 commit
  21. 18 Feb, 2017 1 commit
  22. 12 Jan, 2017 1 commit
  23. 09 Jan, 2017 1 commit
  24. 06 Jan, 2017 2 commits
  25. 27 Dec, 2016 2 commits
  26. 06 Dec, 2016 1 commit
    • Marek Vasut's avatar
      drm: Add new driver for MXSFB controller · 45d59d70
      Marek Vasut authored
      Add new driver for the MXSFB controller found in i.MX23/28/6SX .
      The MXSFB controller is a simple framebuffer controller with one
      parallel LCD output. Unlike the MXSFB fbdev driver that is used
      on these systems now, this driver uses the DRM/KMS framework.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      45d59d70
  27. 01 Dec, 2016 1 commit
    • Neil Armstrong's avatar
      drm: Add support for Amlogic Meson Graphic Controller · bbbe775e
      Neil Armstrong authored
      The Amlogic Meson Display controller is composed of several components :
      
      DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
         | vd1   _______     _____________    _________________     |               |
      D  |-------|      |----|            |   |                |    |   HDMI PLL    |
      D  | vd2   | VIU  |    | Video Post |   | Video Encoders |<---|-----VCLK      |
      R  |-------|      |----| Processing |   |                |    |               |
         | osd2  |      |    |            |---| Enci ----------|----|-----VDAC------|
      R  |-------| CSC  |----| Scalers    |   | Encp ----------|----|----HDMI-TX----|
      A  | osd1  |      |    | Blenders   |   | Encl ----------|----|---------------|
      M  |-------|______|----|____________|   |________________|    |               |
      ___|__________________________________________________________|_______________|
      
      VIU: Video Input Unit
      ---------------------
      
      The Video Input Unit is in charge of the pixel scanout from the DDR memory.
      It fetches the frames addresses, stride and parameters from the "Canvas" memory.
      This part is also in charge of the CSC (Colorspace Conversion).
      It can handle 2 OSD Planes and 2 Video Planes.
      
      VPP: Video Post Processing
      --------------------------
      
      The Video Post Processing is in charge of the scaling and blending of the
      various planes into a single pixel stream.
      There is a special "pre-blending" used by the video planes with a dedicated
      scaler and a "post-blending" to merge with the OSD Planes.
      The OSD planes also have a dedicated scaler for one of the OSD.
      
      VENC: Video Encoders
      --------------------
      
      The VENC is composed of the multiple pixel encoders :
       - ENCI : Interlace Video encoder for CVBS and Interlace HDMI
       - ENCP : Progressive Video Encoder for HDMI
       - ENCL : LCD LVDS Encoder
      The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
      tree and provides the scanout clock to the VPP and VIU.
      The ENCI is connected to a single VDAC for Composite Output.
      The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
      
      This driver is a DRM/KMS driver using the following DRM components :
       - GEM-CMA
       - PRIME-CMA
       - Atomic Modesetting
       - FBDev-CMA
      
      For the following SoCs :
       - GXBB Family (S905)
       - GXL Family (S905X, S905D)
       - GXM Family (S912)
      
      The current driver only supports the CVBS PAL/NTSC output modes, but the
      CRTC/Planes management should support bigger modes.
      But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in
      a second time.
      
      The Device Tree bindings makes use of the endpoints video interface definitions
      to connect to the optional CVBS and in the future the HDMI Connector nodes.
      
      HDMI Support is planned for a next release.
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarNeil Armstrong <narmstrong@baylibre.com>
      bbbe775e
  28. 16 Nov, 2016 1 commit
    • Gustavo Padovan's avatar
      drm/fence: add in-fences support · 96260142
      Gustavo Padovan authored
      There is now a new property called IN_FENCE_FD attached to every plane
      state that receives sync_file fds from userspace via the atomic commit
      IOCTL.
      
      The fd is then translated to a fence (that may be a fence_array
      subclass or just a normal fence) and then used by DRM to fence_wait() for
      all fences in the sync_file to signal. So it only commits when all
      framebuffers are ready to scanout.
      
      v2: Comments by Daniel Vetter:
      	- remove set state->fence = NULL in destroy phase
      	- accept fence -1 as valid and just return 0
      	- do not call fence_get() - sync_file_fences_get() already calls it
      	- fence_put() if state->fence is already set, in case userspace
      	set the property more than once.
      
      v3: WARN_ON if fence is set but state has no FB
      
      v4: Comment from Maarten Lankhorst
      	- allow set fence with no related fb
      
      v5: rename FENCE_FD to IN_FENCE_FD
      
      v6: Comments by Daniel Vetter:
      	- rename plane_state->in_fence back to "fence"
      	- re-introduce WARN_ON if fence set but no fb
      
           - rebase after fence -> dma_fence rename
      
      v7: Comments by Brian Starkey
      	- set state->fence to NULL when duplicating the state
      	- fail if IN_FENCE_FD was already set
      
      v8: rebase against latest drm-misc
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Reviewed-by: default avatarBrian Starkey <brian.starkey@arm.com>
      Reviewed-by: default avatarSean Paul <seanpaul@chromium.org>
      Tested-by: default avatarRobert Foss <robert.foss@collabora.com>
      [danvet: Rebase onto extracted drm_mode_config.[hc].]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      96260142
  29. 09 Nov, 2016 2 commits
  30. 08 Nov, 2016 1 commit
  31. 07 Nov, 2016 1 commit
  32. 31 Aug, 2016 1 commit
  33. 25 Aug, 2016 1 commit