Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 23 2月, 2011 1 次提交
  3. 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
  5. 04 2月, 2011 1 次提交
  7. 02 2月, 2011 1 次提交
  9. 17 1月, 2011 1 次提交
  11. 07 1月, 2011 8 次提交
  13. 06 1月, 2011 2 次提交
  15. 05 1月, 2011 2 次提交
  17. 23 11月, 2010 3 次提交
  19. 22 11月, 2010 2 次提交
  21. 18 11月, 2010 1 次提交
  23. 12 10月, 2010 1 次提交
    • J
      drm/radeon/kms: avoid corner case issue with unmappable vram V2 · c919b371
      由 Jerome Glisse 提交于 
      We should not allocate any object into unmappable vram if we
have no means to access them which on all GPU means having the
CP running and on newer GPU having the blit utility working.

This patch limit the vram allocation to visible vram until
we have acceleration up and running.

Note that it's more than unlikely that we run into any issue
related to that as when acceleration is not woring userspace
should allocate any object in vram beside front buffer which
should fit in visible vram.

V2 use real_vram_size as mc_vram_size could be bigger than
   the actual amount of vram

[airlied: fixup r700_cp_stop case]
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      c919b371
  25. 06 10月, 2010 4 次提交
  27. 02 9月, 2010 1 次提交
  29. 30 8月, 2010 1 次提交
  31. 10 8月, 2010 1 次提交
    • A
      drm/radeon/kms: unify i2c handling · f376b94f
      由 Alex Deucher 提交于 
      Previously we added i2c buses as needed when enumerating connectors
power management, etc.  This only exposed the actual buses used and
could have lead to the same buse getting created more than once if
one buses was used for more than one purpose.  This patch sets up
all i2c buses on the card in one place and users of the buses just
point back to the one instance.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      f376b94f
  33. 04 8月, 2010 1 次提交
  35. 02 8月, 2010 6 次提交
  37. 16 7月, 2010 1 次提交
    • A
      drm/radeon/kms: fix gtt MC base alignment on rs4xx/rs690/rs740 asics · 8d369bb1
      由 Alex Deucher 提交于 
      The asics in question have the following requirements with regard to
their gart setups:

1. The GART aperture size has to be in the form of 2^X bytes, where X is from 25 to 31
2. The GART aperture MC base has to be aligned to a boundary equal to the size of the
aperture.
3. The GART page table has to be aligned to the boundary equal to the size of the table.
4. The GART page table size is: table_entry_size * (aperture_size / page_size)
5. The GART page table has to be allocated in non-paged, non-cached, contiguous system
memory.

This patch takes care 2.  The rest should already be handled properly.

This fixes a regression noticed by: Torsten Kaiser <just.for.lkml@googlemail.com>
Tested-by: NTorsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      8d369bb1
  39. 01 7月, 2010 1 次提交
    • R
      DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re:... · 3f53eb6f
      由 Rafael J. Wysocki 提交于 
      DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re: [Regression, post-2.6.34] Hibernation broken on machines with radeon/KMS and r300)

There is a regression from 2.6.34 related to the recent radeon power
management changes, caused by attempting to cancel a delayed work
item that's never been scheduled.  However, the code as is has some
other issues potentially leading to visible problems.

First, the mutex around cancel_delayed_work() in radeon_pm_suspend()
doesn't really serve any purpose, because cancel_delayed_work() only
tries to delete the work's timer.  Moreover, it doesn't prevent the
work handler from running, so the handler can do some wrong things if
it wins the race and in that case it will rearm itself to do some
more wrong things going forward.  So, I think it's better to wait for
the handler to return in case it's already been queued up for
execution.  Also, it should be prevented from rearming itself in that
case.

Second, in radeon_set_pm_method() the cancel_delayed_work() is not
sufficient to prevent the work handler from running and queing up
itself for the next run (the failure scenario is that
cancel_delayed_work() returns 0, so the handler is run, it waits on
the mutex and then rearms itself after the mutex has been released),
so again the work handler should be prevented from rearming itself in
that case..

Finally, there's a potential deadlock in radeon_pm_fini(), because
cancel_delayed_work_sync() is called under rdev->pm.mutex, but the
work handler tries to acquire the same mutex (if it wins the race).

Fix the issues described above.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      3f53eb6f