1. 18 5月, 2010 11 次提交
  2. 23 4月, 2010 2 次提交
  3. 09 4月, 2010 4 次提交
  4. 07 4月, 2010 1 次提交
    • D
      drm/fb: fix fbdev object model + cleanup properly. · 38651674
      Dave Airlie 提交于
      The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work.
      
      This patch
      
      a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs.
      b) migrated all the fb helper functions out of the crtc helper file into the fb helper file.
      c) pushed the fb probing/hotplug control into the driver
      d) makes the surface sizes into a structure for ease of passing
      This changes the intel/radeon/nouveau drivers to use the new helper.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      38651674
  5. 06 4月, 2010 3 次提交
    • J
      drm/radeon/kms: simplify & improve GPU reset V2 · 90aca4d2
      Jerome Glisse 提交于
      This simplify and improve GPU reset for R1XX-R6XX hw, it's
      not 100% reliable here are result:
      - R1XX/R2XX works bunch of time in a row, sometimes it
        seems it can work indifinitly
      - R3XX/R3XX the most unreliable one, sometimes you will be
        able to reset few times, sometimes not even once
      - R5XX more reliable than previous hw, seems to work most
        of the times but once in a while it fails for no obvious
        reasons (same status than previous reset just no same
        happy ending)
      - R6XX/R7XX are lot more reliable with this patch, still
        it seems that it can fail after a bunch (reset every
        2sec for 3hour bring down the GPU & computer)
      
      This have been tested on various hw, for some odd reasons
      i wasn't able to lockup RS480/RS690 (while they use to
      love locking up).
      
      Note that on R1XX-R5XX the cursor will disapear after
      lockup haven't checked why, switch to console and back
      to X will restore cursor.
      
      Next step is to record the bogus command that leaded to
      the lockup.
      
      V2 Fix r6xx resume path to avoid reinitializing blit
      module, use the gpu_lockup boolean to avoid entering
      inifinite waiting loop on fence while reiniting the GPU
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      90aca4d2
    • J
      drm/radeon/kms: rename gpu_reset to asic_reset · a2d07b74
      Jerome Glisse 提交于
      Patch rename gpu_reset to asic_reset in prevision of having
      gpu_reset doing more stuff than just basic asic reset.
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a2d07b74
    • J
      drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V4 · 225758d8
      Jerome Glisse 提交于
      This patch cleanup the fence code, it drops the timeout field of
      fence as the time to complete each IB is unpredictable and shouldn't
      be bound.
      
      The fence cleanup lead to GPU lockup detection improvement, this
      patch introduce a callback, allowing to do asic specific test for
      lockup detection. In this patch the CP is use as a first indicator
      of GPU lockup. If CP doesn't make progress during 1second we assume
      we are facing a GPU lockup.
      
      To avoid overhead of testing GPU lockup frequently due to fence
      taking time to be signaled we query the lockup callback every
      500msec. There is plenty code comment explaining the design & choise
      inside the code.
      
      This have been tested mostly on R3XX/R5XX hw, in normal running
      destkop (compiz firefox, quake3 running) the lockup callback wasn't
      call once (1 hour session). Also tested with forcing GPU lockup and
      lockup was reported after the 1s CP activity timeout.
      
      V2 switch to 500ms timeout so GPU lockup get call at least 2 times
         in less than 2sec.
      V3 store last jiffies in fence struct so on ERESTART, EBUSY we keep
         track of how long we already wait for a given fence
      V4 make sure we got up to date cp read pointer so we don't have
         false positive
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      225758d8
  6. 31 3月, 2010 4 次提交
  7. 15 3月, 2010 5 次提交
  8. 01 3月, 2010 2 次提交
    • D
      vga_switcheroo: fix build on platforms with no ACPI · 8edb381d
      Dave Airlie 提交于
      radeon was always including the atpx code unnecessarily, also core
      switcheroo was including acpi headers.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      8edb381d
    • D
      vga_switcheroo: initial implementation (v15) · 6a9ee8af
      Dave Airlie 提交于
      Many new laptops now come with 2 gpus, one to be used for low power
      modes and one for gaming/on-ac applications. These GPUs are typically
      wired to the laptop panel and VGA ports via a multiplexer unit which
      is controlled via ACPI methods.
      
      4 combinations of systems typically exist - with 2 ACPI methods.
      Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method
      ATI/ATI - some ASUS - use ATPX ACPI Method
      Intel/Nvidia - - use _DSM ACPI method
      Nvidia/Nvidia -  - use _DSM ACPI method.
      
      TODO:
      This patch adds support for the ATPX method and initial bits
      for the _DSM methods that need to written by someone with
      access to the hardware.
      Add a proper non-debugfs interface - need to get some proper
      testing first.
      
      v2: add power up/down support for both devices
      on W500 puts i915/radeon into D3 and cuts power to radeon.
      
      v3: redo probing methods, no DMI list, drm devices call to
      register with switcheroo, it tries to find an ATPX method on
      any device and once there is two devices + ATPX it inits the
      switcher.
      
      v4: ATPX msg handling using buffers - should work on more machines
      
      v5: rearchitect after more mjg59 discussion - move ATPX handling to
          radeon driver.
      
      v6: add file headers + initial nouveau bits (to be filled out).
      
      v7: merge delayed switcher code.
      
      v8: avoid suspend/resume of gpu that is off
      
      v9: rearchitect - mjg59 is always right. - move all ATPX code to
      radeon, should allow simpler DSM also proper ATRM handling
      
      v10: add ATRM support for radeon BIOS, add mutex to lock vgasr_priv
      
      v11: fix bug in resuming Intel for 2nd time.
      
      v12: start fixing up nvidia code blindly.
      
      v13: blindly guess at finishing nvidia code
      
      v14: remove radeon audio hacks - fix up intel resume more like upstream
      
      v15: clean up printks + remove unnecessary igd/dis pointers
      
      mount debugfs
      
      /sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected
       + 2 cards.
      
      DIS - immediate change to discrete
      IGD - immediate change to IGD
      DDIS - delayed change to discrete
      DIGD - delayed change to IGD
      ON - turn on not in use
      OFF - turn off not in use
      
      Tested on W500 (Intel/ATI) and T500 (Intel/ATI)
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6a9ee8af
  9. 23 2月, 2010 2 次提交
  10. 18 2月, 2010 3 次提交
  11. 16 2月, 2010 1 次提交
    • J
      drm/radeon/kms: fix indirect buffer management V2 · e821767b
      Jerome Glisse 提交于
      There is 3 different distinct states for an indirect buffer (IB) :
        1- free with no fence
        2- free with a fence
        3- non free (fence doesn't matter)
      Previous code mixed case 2 & 3 in a single one leading to possible
      catastrophique failure. This patch rework the handling and properly
      separate each case. So when you get ib we set the ib as non free and
      fence status doesn't matter. Fence become active (ie has a meaning
      for the ib code) once the ib is scheduled or free. This patch also
      get rid of the alloc bitmap as it was overkill, we know go through
      IB pool list like in a ring buffer as the oldest IB is the first
      one the will be free.
      
      Fix :
      https://bugs.freedesktop.org/show_bug.cgi?id=26438
      and likely other bugs.
      
      V2 remove the scheduled list, it's useless now, fix free ib scanning
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      e821767b
  12. 11 2月, 2010 2 次提交
    • D
      drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page · 82568565
      Dave Airlie 提交于
      this uses a new entrypoint to invalidate gart entries instead of using 0.
      Changed to rather than pointing to 0 address point empty entry to dummy
      page. This might help to avoid hard lockup if for some wrong
      reasons GPU try to access unmapped GART entry.
      
      I'm not 100% sure this is going to work, we probably need to allocate
      a dummy page and point all the GTT entries at it similiar to what AGP does.
      but we can test this first I suppose.
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      82568565
    • J
      drm/radeon/kms: r600/r700 command stream checker · 961fb597
      Jerome Glisse 提交于
      This patch add cs checker to r600/r700 hw. Command stream checking
      will rewrite some of the cs value in order to restrict GPU access
      to BO size. This doesn't break old userspace but just enforce safe
      value. It should break any things that was using the r600/r700 cs
      ioctl to do forbidden things (malicious software), though we are
      not aware of such things.
      
      Here is the list of thing we check :
      - enforcing resource size
      - enforcing color buffer slice tile max, will restrict cb access
      - enforcing db buffer slice tile max, will restrict db access
      
      We don't check for shader bigger than the BO in which they are
      supposed to be, such use would lead to GPU lockup and is harmless
      from security POV, as far as we can tell (note that even checking
      for this wouldn't prevent someone to write bogus shader that lead
      to lockup).
      
      This patch has received as much testing as humanly possible with
      old userspace to check that it didn't break such configuration.
      However not all the applications out there were tested, thus it
      might broke some odd, rare applications.
      
      [airlied: fix rules for cs checker for parallel builds]
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      961fb597