Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 02 10月, 2009 6 次提交
  3. 29 9月, 2009 2 次提交
  5. 25 9月, 2009 1 次提交
    • D
      drm/radeon/kms: don't require up to 64k allocations. (v2) · 513bcb46
      由 Dave Airlie 提交于 
      This avoids needing to do a kmalloc > PAGE_SIZE for the main
indirect buffer chunk, it adds an accessor for all reads from
the chunk and caches a single page at a time for subsequent
reads.

changes since v1:
Use a two page pool which should be the most common case
a single packet spanning > PAGE_SIZE will be hit, but I'm
having trouble seeing anywhere we currently generate anything like that.
hopefully proper short page copying at end
added parser_error flag to set deep errors instead of having to test
every ib value fetch.
fixed bug in patch that went to list.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      513bcb46
  7. 23 9月, 2009 1 次提交
  9. 21 9月, 2009 2 次提交
  11. 18 9月, 2009 1 次提交
  13. 16 9月, 2009 2 次提交
  15. 15 9月, 2009 1 次提交
    • J
      drm/radeon/kms: clear confusion in GART init/deinit path · 4aac0473
      由 Jerome Glisse 提交于 
      GART static one time initialization was mixed up with GART
enabling/disabling which could happen several time for instance
during suspend/resume cycles. This patch splits all GART
handling into 4 differents function. gart_init is for one
time initialization, gart_deinit is called upon module unload
to free resources allocated by gart_init, gart_enable enable
the GART and is intented to be call after first initialization
and at each resume cycle or reset cycle. Finaly gart_disable
stop the GART and is intended to be call at suspend time or
when unloading the module.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      4aac0473
  17. 14 9月, 2009 2 次提交
  19. 11 9月, 2009 2 次提交
  21. 10 9月, 2009 2 次提交
  23. 08 9月, 2009 3 次提交
  25. 31 8月, 2009 1 次提交
    • B
      radeon: Use request_firmware() · 70967ab9
      由 Ben Hutchings 提交于 
      Loosely based on a patch by
Jaswinder Singh Rajput <jaswinderlinux@gmail.com>.

KMS support by Dave Airlie <airlied@redhat.com>.

For Radeon 100- to 500-series, firmware blobs look like:
    struct {
        __be32 datah;
        __be32 datal;
    } cp_ucode[256];

For Radeon 600-series, there are two separate firmware blobs:
    __be32 me_ucode[PM4_UCODE_SIZE * 3];
    __be32 pfp_ucode[PFP_UCODE_SIZE];

For Radeon 700-series, likewise:
    __be32 me_ucode[R700_PM4_UCODE_SIZE];
    __be32 pfp_ucode[R700_PFP_UCODE_SIZE];
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      70967ab9
  27. 21 8月, 2009 1 次提交
  29. 17 8月, 2009 1 次提交
  31. 16 8月, 2009 2 次提交
  33. 29 7月, 2009 4 次提交
    • M
      drm/radeon: Add radeon.test parameter for running BO GPU copy tests. · ecc0b326
      由 Michel Dänzer 提交于 
      If enabled, during initialization BO GTT->VRAM and VRAM->GTT GPU copies are
tested across the whole GTT aperture.

This has helped uncover the benchmark copy size bug and verify the maximum
aperture size supported by the AGP bridge in my PowerBook.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      ecc0b326
    • D
      drm/radeon/kms: vram sizing on certain r100 chips needs workaround. · 7a50f01a
      由 Dave Airlie 提交于 
      If an rn50/r100/m6/m7 GPU has < 64MB RAM, i.e. 8/16/32, the
aperture used to calculate the MC_FB_LOCATION needs to be worked
out from the CONFIG_APER_SIZE register, and not the actual vram size.

TTM VRAM size was also being initialised wrong, use actual vram size
to initialise it.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      7a50f01a
    • J
      drm/radeon/kms: fix bandwidth computation on avivo hardware · c93bb85b
      由 Jerome Glisse 提交于 
      Fix bandwidth computation and crtc priority in memory controller
so that crtc memory request are fullfill in time to avoid display
artifact.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      c93bb85b
    • D
      drm/radeon/kms: add initial colortiling support. · e024e110
      由 Dave Airlie 提交于 
      This adds new set/get tiling interfaces where the pitch
and macro/micro tiling enables can be set. Along with
a flag to decide if this object should have a surface when mapped.

The only thing we need to allocate with a mapped surface should be
the frontbuffer. Note rotate scanout shouldn't require one, and
back/depth shouldn't either, though mesa needs some fixes.

It fixes the TTM interfaces along Thomas's suggestions, and I've tested
the surface stealing code with two X servers and not seen any lockdep issues.

I've stopped tiling the fbcon frontbuffer, as I don't see there being
any advantage other than testing, I've left the testing commands in there,
just flip the fb_tiled to true in radeon_fb.c

Open: Can we integrate endian swapping in with this?

Future features:
texture tiling - need to relocate texture registers TXOFFSET* with tiling info.

This also merges Michel's cleanup surfaces regs at init time patch
even though it makes sense on its own, this patch really relies on it.

Some PowerMac firmwares set up a tiling surface at the beginning of VRAM
which messes us up otherwise.
that patch is:
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      e024e110
  35. 15 7月, 2009 4 次提交
  37. 19 6月, 2009 1 次提交
    • J
      drm/radeon: command stream checker for r3xx-r5xx hardware · 068a117c
      由 Jerome Glisse 提交于 
      For security purpose we want to make sure the userspace process doesn't
access memory beyond buffer it owns. To achieve this we need to check
states the userspace program. For color buffer and zbuffer we check that
the clipping register will discard access beyond buffers set as color
or zbuffer. For vertex buffer we check that no vertex fetch will happen
beyond buffer end. For texture we check various texture states (number
of mipmap level, texture size, texture depth, ...) to compute the amount
of memory the texture fetcher might access.

The command stream checking impact the performances so far quick benchmark
shows an average of 3% decrease in fps of various applications. It can
be optimized a bit more by caching result of checking and thus avoid a
full recheck if no states changed since last check.

Note that this patch is still incomplete on checking side as it doesn't
check 2d rendering states.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      068a117c
  39. 15 6月, 2009 1 次提交
    • J
      drm/radeon: introduce kernel modesetting for radeon hardware · 771fe6b9
      由 Jerome Glisse 提交于 
      Add kernel modesetting support to radeon driver, use the ttm memory
manager to manage memory and DRM/GEM to provide userspace API.
In order to avoid backward compatibility issue and to allow clean
design and code the radeon kernel modesetting use different code path
than old radeon/drm driver.

When kernel modesetting is enabled the IOCTL of radeon/drm
driver are considered as invalid and an error message is printed
in the log and they return failure.

KMS enabled userspace will use new API to talk with the radeon/drm
driver. The new API provide functions to create/destroy/share/mmap
buffer object which are then managed by the kernel memory manager
(here TTM). In order to submit command to the GPU the userspace
provide a buffer holding the command stream, along this buffer
userspace have to provide a list of buffer object used by the
command stream. The kernel radeon driver will then place buffer
in GPU accessible memory and will update command stream to reflect
the position of the different buffers.

The kernel will also perform security check on command stream
provided by the user, we want to catch and forbid any illegal use
of the GPU such as DMA into random system memory or into memory
not owned by the process supplying the command stream. This part
of the code is still incomplete and this why we propose that patch
as a staging driver addition, future security might forbid current
experimental userspace to run.

This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX
(radeon up to X1950). Works is underway to provide support for R6XX,
R7XX and newer hardware (radeon from HD2XXX to HD4XXX).

Authors:
    Jerome Glisse <jglisse@redhat.com>
    Dave Airlie <airlied@redhat.com>
    Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      771fe6b9