- 03 10月, 2012 5 次提交
-
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
v2/v3: Ben Skeggs <bskeggs@redhat.com> - fix typo in default bus selection - fix accidental loss of destructor v4: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com> - fix typo causing incorrect default i2c port settings when no BMP data Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
v2: Ben Skeggs <bskeggs@redhat.com> - rebase on top of v3.6-rc6 with gpio reset patch integrated already Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
v2: Ben Skeggs <bskeggs@redhat.com> - use unaligned macros to access vbios image - endianness fixes Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
This commit provides most of the infrastructure to support a major overhaul of Nouveau's internals coming in the following commits. This work aims to take all the things we've learned over the last several years, and turn that into a cleaner architecture that's more maintainable going forward. RAMHT and MM bits of the new core have been left out for the moment, and will be pulled in as I go through the process of porting the code to become either subdev or engine modules. There are several main goals I wanted to achieve through this work: -- Reduce complexity The goal here was to make each component of the driver as independent as possible, which will ease maintainability and readability, and provide a good base for resetting locked up GPU units in the future. -- Better tracking of GPU units that are required at any given time This is for future PM work, we'll be able to tell exactly what parts of the GPU we need powered at any given point (etc). -- Expose all available NVIDIA GPUs to the client In order to support things such as multi-GPU channels, we want to be able to expose all the NVIDIA GPUs to the client over a single file descriptor so it can send a single push buffer to multiple GPUs. -- Untangle the core hardware support code from the DRM implementation This happened initially as an unexpected side-effect of developing the initial core infrastructure in userspace, but it turned into a goal of the whole project. Initial benefits will be the availablility of a number of userspace tools and tests using the same code as the driver itself, but will also be important as I look into some virtualisation ideas. v2: Ben Skeggs <bskeggs@redhat.com> - fix duplicate assignments noticed by clang - implement some forgotten yelling in error path - ensure 64-bit engine mask is used everywhere v3: Marcin Slusarz <marcin.slusarz@gmail.com> - sparse fixes - inline nv_printk into nv_assert to prevent recursive inlining issues v4: Ben Skeggs <bskeggs@redhat.com> - fixed minor memory leak on gpuobj destruction Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 15 6月, 2009 1 次提交
-
-
由 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>
-
- 14 7月, 2008 1 次提交
-
-
由 Dave Airlie 提交于
With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 02 1月, 2006 1 次提交
-
-
由 Dave Airlie 提交于
Cleanup SIS + TDFX drivers with latest changes from CVS. From: Eric Anholt <anholt@freebsd.org> Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 11 11月, 2005 1 次提交
-
-
由 Dave Airlie 提交于
Signed-off-by: NDave Airlie <airlied@linux.ie>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-