commit f2475176fbf8590a5d9c029ec08fa05c5bde5860
Author: Ryan Hope <[email protected]>
Date: Fri Jun 12 12:17:54 2009 -0400
fix ttm kconfig
diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index 0686829..299a73c 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -6,4 +6,4 @@ ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o ttm_global.o
-obj-m += ttm.o
+obj-$(CONFIG_DRM_TTM) += ttm.o
On Sun, Jun 14, 2009 at 9:32 AM, Ryan Hope <[email protected]> wrote:
> I have found 2 issues while using these patches. The first issue I already
> brought up with Glisse, the TTM module can not be built into the kernel. The
> first patch fixes this issue. The second issue is that when radeon drm
> module is built into the kernel, fbcon does not get loaded before radeon so
> I get a black screen and hardlock. The second patch fixes the initialization
> order (maybe there is a better way but this is what I came up with).
> -Ryan
>
>
> On Wed, Jun 10, 2009 at 11:55 AM, Jerome Glisse <[email protected]>wrote:
>
>> Hello,
>>
>> For size reason (~1.2M) the patch can be found here (along with others
>> needed patches):
>>
>> http://people.freedesktop.org/~glisse/kms/0006-radeon-introduce-kernel-modesetting-for-radeon-hard.patch
>>
>> This work depends on Thomas TTM memory manager posted earlier and was
>> written by Dave Airlie, Alex Deucher and myself. We would like to get
>> radeon kernel modesetting in 2.6.31 as a staging driver but given the
>> layout of drm/radeon we have the code source is in
>> drivers/gpu/drm/radeon and not in subfolder of drivers/staging. Is this
>> an issue ?
>>
>> The main reason, i think of, for considering radeon/KMS as staging
>> driver is security. With current patch you can (with some difficulties)
>> theoretically write or read GPU object of other process, i am pretty
>> confident that you cannot access system ram beside one allocated for
>> GPU object. Also we might need to change a little bit the ABI (there is
>> no yet userspace release of code supporting this ABI it's all in various
>> branch ddx/mesa/libdrm).
>>
>> Meanwhile we would still like to give the opportunity to people to test
>> this code and thus helps us find bugs or design errors. I would like to
>> thank all people who have done early testing on this code.
>>
>>
>> Here is a brief description of code layout for people courageous enough
>> to review the patch:
>> atom* files hold atom helper & interpreter, atombios is a kind of script
>> language used by AMD to provide a set of functions that driver can use,
>> this is mostly useful for low level GPU initialization (setting up
>> video ram frequency, gpu frequency, video ram refresh timing, ... which
>> are board specific and can vary from one vendor to the other for the
>> same asic). atombios also provide an API to perform mode setting and
>> thus helps in abstracting changes in mode setting part of the GPU.
>>
>> radeon_kms.c have code for wrapping around old ioctl and return invalid
>> anytime userspace try to call them if mode setting is enabled.
>>
>> radeon_device.c is where the initialization and resume/suspend path
>> starts.
>>
>> radeon_object.c/radeon_ttm.c are a thin layer for abstracting the
>> underlying memory manager used. Motivation is to allow to easily
>> modify/improve the underlying memory manager while not having to
>> update various files in the gpu driver. It also provide helper
>> functions to simplify common task often done by different component
>> of the code.
>>
>> radeon_display.c is the core of mode setting functionality
>>
>> radeon_legacy* holds code for doing mode setting on non atombios
>> hw (r1xx/r2xx/r3xx/r4xx).
>>
>> radeon_gem.c holds the userspace api of the memory manager
>>
>> radeon_cs.c holds the new userspace api for submitting command
>> to the GPU. This API is designed with memory management in mind
>> and is closer to what GPU can understand.
>>
>> radeon_asic.h holds the various asic specific functions callback
>> structure, if you want to know which functions is called on a given
>> asic for a given task it's where you should look.
>>
>> r100.c/r300.c/rs400.c/rv515.c/r520.c/rs600.c/rs690.c/... are files
>> holding asic specific functions, note that new asic often reuse some
>> part of older asic, for instance the r100 cp is the same up to r5xx
>> hw so you will see that r100_cp_* functions are used by large range
>> of hw. Idea here is to avoid duplication while allowing to clearly
>> spot differences btw asics.
>>
>> Jerome Glisse
>>
>>
>> Below is commit message :
>>
>> radeon: introduce kernel modesetting for radeon hardware
>>
>> 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 <[email protected]>
>> Dave Airlie <[email protected]>
>> Alex Deucher <[email protected]>
>>
>> Signed-off-by: Jerome Glisse <[email protected]>
>> Signed-off-by: Dave Airlie <[email protected]>
>> Signed-off-by: Alex Deucher <[email protected]>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
