1. 30 7月, 2015 1 次提交
  2. 01 10月, 2014 1 次提交
  3. 08 1月, 2014 2 次提交
  4. 23 7月, 2013 3 次提交
    • M
      drm/radeon: fix combios tables on older cards · cef1d00c
      Mark Kettenis 提交于
      Noticed that my old Radeon 7500 hung after printing
      
         drm: GPU not posted. posting now...
      
      when it wasn't selected as the primary card the BIOS.  Some digging
      revealed that it was hanging in combios_parse_mmio_table() while
      parsing the ASIC INIT 3 table.  Looking at the BIOS ROM for the card,
      it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
      The code is just processing random garbage.  No surprise it hangs!
      
      Why do I say that there is no ASIC INIT 3 table is the BIOS?  This
      table is found through the MISC INFO table.  The MISC INFO table can
      be found at offset 0x5e in the COMBIOS header.  But the header is
      smaller than that.  The COMBIOS header starts at offset 0x126.  The
      standard PCI Data Structure (the bit that starts with 'PCIR') lives at
      offset 0x180.  That means that the COMBIOS header can not be larger
      than 0x5a bytes and therefore cannot contain a MISC INFO table.
      
      I looked at a dozen or so BIOS images, some my own, some downloaded from:
      
          <http://www.techpowerup.com/vgabios/index.php?manufacturer=ATI&page=1>
      
      It is fairly obvious that the size of the COMBIOS header can be found
      at offset 0x6 of the header.  Not sure if it is a 16-bit number or
      just an 8-bit number, but that doesn't really matter since the tables
      seems to be always smaller than 256 bytes.
      
      So I think combios_get_table_offset() should check if the requested
      table is present.  This can be done by checking the offset against the
      size of the header.  See the diff below.  The diff is against the WIP
      OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
      point.  But I don't think this bit of the code changed much since
      then.
      
      For what it is worth:
      Signed-off-by: NMark Kettenis <kettenis@openbsd.org>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      cef1d00c
    • A
      drm/radeon: improve dac adjust heuristics for legacy pdac · 03ed8cf9
      Alex Deucher 提交于
      Hopefully avoid more quirks in the future due to bogus
      vbios dac data.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      03ed8cf9
    • O
      drm/radeon: Another card with wrong primary dac adj · f7929f34
      Ondrej Zary 提交于
      Hello,
      got another card with "too bright" problem:
      Sapphire Radeon VE 7000 DDR (VGA+S-Video)
      
      lspci -vnn:
      01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
              Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]
      
      The patch below fixes the problem for this card.
      But I don't like the blacklist, couldn't some heuristic be used instead?
      The interesting thing is that the manufacturer is the same as the other card
      needing the same quirk. I wonder how many different types are broken this way.
      
      The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.
      
      ====================
      drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR
      
      Values from BIOS are wrong, causing too bright colors.
      Use default values instead.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f7929f34
  5. 08 3月, 2013 1 次提交
  6. 30 1月, 2013 1 次提交
  7. 03 1月, 2013 1 次提交
  8. 14 12月, 2012 1 次提交
  9. 03 10月, 2012 1 次提交
  10. 21 9月, 2012 2 次提交
  11. 13 8月, 2012 1 次提交
  12. 03 5月, 2012 1 次提交
  13. 10 4月, 2012 1 次提交
  14. 13 11月, 2011 1 次提交
  15. 10 10月, 2011 1 次提交
  16. 30 8月, 2011 1 次提交
  17. 04 8月, 2011 1 次提交
  18. 25 7月, 2011 1 次提交
  19. 16 6月, 2011 1 次提交
  20. 14 6月, 2011 1 次提交
  21. 09 6月, 2011 1 次提交
  22. 09 5月, 2011 1 次提交
  23. 04 5月, 2011 2 次提交
  24. 04 4月, 2011 1 次提交
  25. 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
  26. 14 2月, 2011 1 次提交
  27. 04 2月, 2011 1 次提交
  28. 21 12月, 2010 1 次提交
  29. 22 11月, 2010 1 次提交
  30. 19 11月, 2010 1 次提交
  31. 12 10月, 2010 1 次提交
  32. 13 9月, 2010 1 次提交
  33. 20 8月, 2010 1 次提交
  34. 10 8月, 2010 2 次提交