1. 10 10月, 2011 1 次提交
  2. 15 8月, 2011 1 次提交
  3. 04 8月, 2011 1 次提交
    • T
      drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC... · e384fab8
      Thomas Reim 提交于
      drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines (here: Asus M2A-VM HDMI)
      
          Some integrated ATI Radeon chipset implementations with add-on HDMI card
          (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even
          when the add-on card is not plugged in or HDMI is disabled in BIOS setup.
          In this case, drm_get_edid() and drm_edid_block_valid() periodically
          dump data and kernel errors into system log files and onto terminals.
          For these connectors DDC probing is extended by a check for a correct
          EDID header. Only in case a valid EDID header is also found, the
          (HDMI or DVI) connector will be used by the Radeon driver. This prevents
          the kernel driver from useless flooding of logs and terminal sessions with
          EDID dumps and error messages.
          This patch adds a flag 'requires_extended_probe' to the radeon_connector
          structure. In function radeon_connector_needs_extended_probe() this flag
          can be set on a chipset family/vendor/connector type specific basis.
          In addition, function radeon_ddc_probe() has been adapted to perform
          extended DDC probing if required by the connector's flag.
          Requires function drm_edid_header_is_valid() in DRM module provided by
          [PATCH] drm: Separate EDID Header Check from EDID Block Check.
      
          Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board
      
          BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196
          BugLink: http://bugs.launchpad.net/bugs/7228066
      
      Cc: <stable@kernel.org>
      Signed-off-by: NThomas Reim <reimth@gmail.com>
      Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
      Acked-by: NStephen Michaels <Stephen.Micheals@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e384fab8
  4. 17 6月, 2011 2 次提交
  5. 24 5月, 2011 1 次提交
  6. 20 5月, 2011 6 次提交
  7. 24 3月, 2011 1 次提交
    • A
      drm/radeon/kms: fix hardcoded EDID handling · fafcf94e
      Alex Deucher 提交于
      On some servers there is a hardcoded EDID provided
      in the vbios so that the driver will always see a
      display connected even if something like a KVM
      prevents traditional means like DDC or load
      detection from working properly.  Also most
      server boards with DVI are not actually DVI, but
      DVO connected to a virtual KVM service processor.
      If we fail to detect a monitor via DDC or load
      detection and a hardcoded EDID is available, use
      it.
      
      Additionally, when using the hardcoded EDID, use
      a copy of it rather than the actual one stored
      in the driver as the detect() and get_modes()
      functions may free it if DDC is successful.
      
      This fixes the virtual KVM on several internal
      servers.
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      fafcf94e
  8. 23 3月, 2011 1 次提交
  9. 14 2月, 2011 1 次提交
  10. 07 2月, 2011 1 次提交
    • D
      drm: dumb scanout create/mmap for intel/radeon (v3) · ff72145b
      Dave Airlie 提交于
      This is just an idea that might or might not be a good idea,
      it basically adds two ioctls to create a dumb and map a dumb buffer
      suitable for scanout. The handle can be passed to the KMS ioctls to create
      a framebuffer.
      
      It looks to me like it would be useful in the following cases:
      a) in development drivers - we can always provide a shadowfb fallback.
      b) libkms users - we can clean up libkms a lot and avoid linking
      to libdrm_*.
      c) plymouth via libkms is a lot easier.
      
      Userspace bits would be just calls + mmaps. We could probably
      mark these handles somehow as not being suitable for acceleartion
      so as top stop people who are dumber than dumb.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ff72145b
  11. 02 2月, 2011 1 次提交
  12. 07 1月, 2011 1 次提交
  13. 21 12月, 2010 1 次提交
  14. 22 11月, 2010 2 次提交
    • A
      drm/radeon/kms: add pageflip ioctl support (v3) · 6f34be50
      Alex Deucher 提交于
      This adds support for dri2 pageflipping.
      
      v2: precision updates from Mario Kleiner.
      v3: Multihead fixes from Mario Kleiner; missing crtc offset
          add note about update pending bit on pre-avivo chips
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6f34be50
    • M
      drm/kms/radeon: Add support for precise vblank timestamping. · f5a80209
      Mario Kleiner 提交于
      This patch adds new functions for use by the drm core:
      
      .get_vblank_timestamp() provides a precise timestamp
      for the end of the most recent (or current) vblank
      interval of a given crtc, as needed for the DRI2
      implementation of the OML_sync_control extension.
      
      It is a thin wrapper around the drm function
      drm_calc_vbltimestamp_from_scanoutpos() which does
      almost all the work and is shared across drivers.
      
      .get_scanout_position() provides the current horizontal
      and vertical video scanout position and "in vblank"
      status of a given crtc, as needed by the drm for use by
      drm_calc_vbltimestamp_from_scanoutpos().
      
      The function is also used by the dynamic gpu reclocking
      code to determine when it is safe to reclock inside vblank.
      
      For that purpose radeon_pm_in_vbl() is modified to
      accomodate a small change in the function prototype of
      the radeon_get_crtc_scanoutpos() which is hooked up to
      .get_scanout_position().
      
      This code has been tested on AVIVO hardware, a RV530
      (ATI Mobility Radeon X1600) in a Intel Core-2 Duo MacBookPro
      and some R600 variant (FireGL V7600) in a single cpu
      AMD Athlon 64 PC.
      Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
      Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f5a80209
  15. 18 11月, 2010 3 次提交
  16. 09 11月, 2010 1 次提交
  17. 25 10月, 2010 1 次提交
  18. 19 10月, 2010 3 次提交
  19. 06 10月, 2010 8 次提交
  20. 13 9月, 2010 1 次提交
  21. 02 9月, 2010 1 次提交
  22. 20 8月, 2010 1 次提交