1. 08 2月, 2017 1 次提交
  2. 03 2月, 2017 2 次提交
  3. 09 1月, 2017 1 次提交
  4. 30 12月, 2016 1 次提交
  5. 14 11月, 2016 1 次提交
  6. 10 10月, 2016 1 次提交
  7. 04 10月, 2016 1 次提交
  8. 19 9月, 2016 1 次提交
  9. 29 8月, 2016 1 次提交
    • A
      drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y · 749cc6f7
      Arnd Bergmann 提交于
      When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration
      in which some DRM drivers are built-in, but the framebuffer core is a
      loadable module. This results in a link error, such as:
      
      drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe':
      radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to `remove_conflicting_framebuffers'
      drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe':
      amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to `remove_conflicting_framebuffers'
      drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init':
      mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to `remove_conflicting_framebuffers'
      drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe':
      mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to `remove_conflicting_framebuffers'
      Makefile:969: recipe for target 'vmlinux' failed
      
      This changes the compile-time check to IS_REACHABLE, which means we end up
      not calling remove_conflicting_framebuffers() in the configuration, which
      seems good enough, as we know that no framebuffer driver is loaded by the
      time that the built-in DRM driver calls remove_conflicting_framebuffers.
      
      We could alternatively avoid the link error by forcing CONFIG_FB to not
      be a module in this case, but that wouldn't change anything at runtime,
      and just make the already convoluted set of dependencies worse here.
      
      I could not find out what happens if the fbdev driver gets loaded as
      a module after the DRM driver is already initialized, but that is a case
      that can happen with or without this patch.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 0a3bfe29 ("drm/fb-helper: Fix the dummy remove_conflicting_framebuffers")
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160829123428.3260105-1-arnd@arndb.de
      Link: http://patchwork.freedesktop.org/patch/msgid/1472461923-14364-1-git-send-email-gnuiyl@gmail.com
      749cc6f7
  10. 24 8月, 2016 1 次提交
  11. 23 8月, 2016 2 次提交
  12. 17 8月, 2016 1 次提交
  13. 12 8月, 2016 1 次提交
  14. 09 6月, 2016 1 次提交
  15. 02 5月, 2016 1 次提交
  16. 12 2月, 2016 1 次提交
  17. 08 12月, 2015 2 次提交
  18. 17 9月, 2015 2 次提交
  19. 08 9月, 2015 1 次提交
  20. 06 8月, 2015 6 次提交
    • A
      drm: Add top level Kconfig option for DRM fbdev emulation · a03fdcb1
      Archit Taneja 提交于
      Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
      Most modesetting drivers enable provide fbdev emulation by default by
      selecting KMS FB helpers. A few provide a separate Kconfig option for the
      user to enable or disbale fbdev emulation.
      
      Enabling fbdev emulation is finally a distro-level decision. Having a top
      level Kconfig option for fbdev emulation helps by providing a uniform way
      to enable/disable fbdev emulation for any modesetting driver. It also lets
      us remove unnecessary driver specific Kconfig options that causes bloat.
      
      With a top level Kconfig in place, we can stub out the fb helper functions
      when not needed without breaking functionality. Having stub functions also
      prevents drivers to require wrapping fb helper function calls with #ifdefs.
      
      DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev
      emulation by default and majority of distributions expect the fbdev
      interface in the kernel.
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a03fdcb1
    • A
      drm/fb_helper: Create a wrapper for fb_set_suspend · fdefa58a
      Archit Taneja 提交于
      Some drm drivers call fb_set_suspend. Create a drm_fb_helper function
      that wraps around these calls.
      
      This is part of an effort to prevent drm drivers from calling fbdev
      functions directly, in order to make fbdev emulation a top level drm
      option.
      
      v3:
      - Fixed kerneldoc errors
      
      v2:
      - Added kerneldocs
      - Added a check for non-NULL fb_helper before proceeding. This will
        make the helpers work when we have a module param for fbdev emulation
      - Follow the drm way of aligning of arguments in func definitions
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      fdefa58a
    • A
      drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs · 742547b7
      Archit Taneja 提交于
      drm drivers that emulate fbdev populate their fb_fillrect, fb_copyarea
      and fb_imageblit fb_ops with the help of cfb_* or sys_* fbdev core
      helper functions.
      
      Create drm_fb_helper functions that wrap around these calls.
      
      This is part of an effort to prevent drm drivers from calling fbdev
      functions directly, in order to make fbdev emulation a top level drm
      option.
      
      v3:
      - Fixed kerneldoc errors
      
      v2:
      - Added kerneldocs
      - Follow the drm way of aligning of arguments in func definitions
      - Remove unnecessary checks for non NULL fb_info
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      742547b7
    • A
      drm/fb_helper: Create wrappers for fb_sys_read/write funcs · cbb1a82e
      Archit Taneja 提交于
      Some drm drivers populate their fb_ops with fb_sys_read/write fb sysfs
      ops.
      
      Create a drm_fb_helper function that wraps around these calls.
      
      This is part of an effort to prevent drm drivers from calling fbdev
      functions directly, in order to make fbdev emulation a top level drm
      option.
      
      v3:
      - Fix kerneldoc errors
      
      v2:
      - Added kerneldocs
      - Follow the drm way of aligning of arguments in func definitions
      - Remove unnecessary checks for non NULL fb_info
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cbb1a82e
    • A
      drm/fb_helper: Create a wrapper for unlink_framebuffer · 47074ab7
      Archit Taneja 提交于
      Some drm drivers call unlink_framebuffer. Create a drm_fb_helper function
      that wraps around these calls.
      
      This is part of an effort to prevent drm drivers from calling fbdev
      functions directly, in order to make fbdev emulation a top level drm
      option.
      
      v2:
      - Added kerneldocs
      - Added a check for non-NULL fb_helper before proceeding. This will
        make the helpers work when we have a module param for fbdev emulation
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      47074ab7
    • A
      drm/fb_helper: Add drm_fb_helper functions to manage fb_info creation · b8017d6c
      Archit Taneja 提交于
      Every drm driver calls framebuffer_alloc, fb_alloc_cmap,
      unregister_framebuffer, fb_dealloc_cmap and framebuffer_release in
      order to emulate fbdev support.
      
      Create drm_fb_helper functions that perform the above operations.
      
      This is part of an effort to prevent drm drivers from calling fbdev
      functions directly. It also removes repetitive code from drivers.
      
      There are some drivers that call alloc_apertures after framebuffer_alloc
      and some that don't. Make the helper always call alloc_apertures. This
      would make certain drivers allocate memory for apertures but not use
      them. Since it's a small amount of memory, it shouldn't be an issue.
      
      v2:
      - Added kerneldocs
      - Added a check for non-NULL fb_helper before proceeding. This will
        make the helpers work when we have a module param for fbdev emulation
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b8017d6c
  21. 12 3月, 2015 1 次提交
  22. 21 1月, 2015 1 次提交
  23. 09 12月, 2014 1 次提交
  24. 06 8月, 2014 1 次提交
    • C
      drm: Perform cmdline mode parsing during connector initialisation · eaf99c74
      Chris Wilson 提交于
      i915.ko has a custom fbdev initialisation routine that aims to preserve
      the current mode set by the BIOS, unless overruled by the user. The
      user's wishes are determined by what, if any, mode is specified on the
      command line (via the video= parameter). However, that command line mode
      is first parsed by drm_fb_helper_initial_config() which is called after
      i915.ko's custom initial_config() as a fallback method. So in order for
      us to honour it, we need to move the cmdline parser earlier. If we
      perform the connector cmdline parsing as soon as we initialise the
      connector, that cmdline mode and forced status is then available even if
      the fbdev helper is not compiled in or never called.
      
      We also then expose the cmdline user mode in the connector mode lists.
      
      v2: Rebase after connector->name upheaval.
      
      v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely
      simplifies things while at that.
      
      v4: Fix checkpatch.
      
      v5: Select FB_CMDLINE to adapt to the changed fbdev patch.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
      Cc: dri-devel@lists.freedesktop.org
      Cc: Julia Lemire <jlemire@matrox.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      eaf99c74
  25. 08 7月, 2014 3 次提交
  26. 05 6月, 2014 1 次提交
  27. 19 2月, 2014 1 次提交
  28. 13 2月, 2014 1 次提交
  29. 10 5月, 2013 1 次提交