History log of /drivers/gpu/drm/nouveau/core/core/client.c
Revision Date Author Comments
996f5a08235b27a7adcd01fe2b3f79e2f0f20ced 11-Aug-2014 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/core: pass related object into notify constructor

The event source types/index might need to be derived from it.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
7caa63c04029c5882865867470c106ef73eafb2b 11-Aug-2014 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/nvif: fix a number of notify thinkos

Note to self: more sleep

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
803c1787efd379110963db360fbe06ed0b41197e 09-Aug-2014 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/client: add method to retrieve device list

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
d01c3092f065810b9f6cd8cc9918713f48884f46 09-Aug-2014 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/device: add method to retrieve some basic device info

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
8ec2a6ec6e229d67b19737f9b603eef478fa955d 09-Aug-2014 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/core: import ioctl/event interfaces

This forms the basis for the new APIs that will be exposed to userspace,
giving it access to:

- Object method calls, the immediately useful of which is performance
counters and the abiity to manipulate the ZBC tables.
- Information on the child classes an object supports, in order to avoid
having to try all supported classes until successful.
- Notifications, which will be used in the future to inform the client
if its channel was killed due to a lockup, etc.

This commit imports the interfaces, but are not currently used. The DRM
portion of the driver will be ported to speak to the core using these
interfaces as much as possible.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
9aecbada751e6343e47cbefade718e571a8ecbbc 25-Apr-2013 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/device: have engine object initialised before creation

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
dded35dee323e286ef444f148abaf88adb58d4f3 25-Apr-2013 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/device: convert to engine, rather than subdev

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
a2896cede08ddeed4f2c4fca616943a63dff5fa8 09-Dec-2012 Marcin Slusarz <marcin.slusarz@gmail.com> drm/nouveau: prepare for reporting channel owner

- record channel owner process name
- add some helpers for accessing this information
- let nouveau_enum hold additional value (will be needed in the next patch)

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
dd5700ea98ad0b375a72525ce7d7edddf15b2693 10-Dec-2012 Marcin Slusarz <marcin.slusarz@gmail.com> drm/nouveau: fix nouveau_client allocation failure path

Depending on the point of failure, freed object would be returned
or memory leak would happen.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
fa6df8c163ddf1fba658059695ab9587f344712c 12-Sep-2012 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/core: have client-id be a string, rather than an integer

Can be somewhat more informative that way...

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
9274f4a9ba7e70d1770e237fca16d52f27f0c728 05-Jul-2012 Ben Skeggs <bskeggs@redhat.com> drm/nouveau/core: pull in most of the new core infrastructure

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: Ben Skeggs <bskeggs@redhat.com>