Re: [PATCH 1/3] Re: Radeon kernel modesetting patch (as staging) please review

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

commit f2475176fbf8590a5d9c029ec08fa05c5bde5860
Author: Ryan Hope <rm...@gm...>
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 <rm...@gm...> 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 <gl...@fr...>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 <jg...@re...>
>>        Dave Airlie <ai...@re...>
>>        Alex Deucher <ale...@gm...>
>>
>>    Signed-off-by: Jerome Glisse <jg...@re...>
>>    Signed-off-by: Dave Airlie <ai...@re...>
>>    Signed-off-by: Alex Deucher <ale...@gm...>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to maj...@vg...
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
>
