summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/include
AgeCommit message (Collapse)AuthorFilesLines
2017-02-17drm/nouveau/core/object: support lookup of specific object typesBen Skeggs1-0/+5
It turns out we have a nice and convenient way of looking up a specific object type already, by using the func pointer as a key. This will be used to remove the separate object trees for each type we need to be able to search for. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/gr/nv50-mcp89: add defines for gr classesBen Skeggs1-0/+12
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/secboot: split reset functionAlexandre Courbot1-0/+5
Split the reset function into more meaningful and reusable ones. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/secboot: reorganize into more filesAlexandre Courbot1-5/+4
Split the act of building the ACR blob from firmware files from the rest of the (chip-dependent) secure boot logic. ACR logic is moved into acr_rxxx.c files, where rxxx corresponds to the compatible release of the NVIDIA driver. At the moment r352 and r361 are supported since firmwares have been released for these versions. Some abstractions are added on top of r352 so r361 can easily be implemented on top of it by just overriding a few hooks. This split makes it possible and easy to reuse the same ACR version on different chips. It also hopefully makes the code much more readable as the different secure boot logics are separated. As more chips and firmware versions will be supported, this is a necessity to not get lost in code that is already quite complex. This is a big commit, but it essentially moves things around (and split the nvkm_secboot structure into two, nvkm_secboot and nvkm_acr). Code semantics should not be affected. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/secboot: remove nvkm_secboot_start()Alexandre Courbot1-1/+0
Since GR has moved to using the falcon library to start the falcons, this function is not needed anymore. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/secboot: use falcon libraryAlexandre Courbot1-3/+1
Use the falcon library functions in secure boot. This removes a lot of code and makes the secure boot flow easier to understand as no register is directly accessed. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/secboot: fix functions definitionsAlexandre Courbot1-3/+3
These functions should use the nvkm_secboot_falcon enum. Fix this. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/gm20b: add dummy PMU deviceAlexandre Courbot1-0/+1
Add a dummy PMU device so the PMU falcon is instanciated and can be used by secure boot. We could reuse gk20a's implementation here, but it would fight with secboot over PMU falcon's ownership and secboot will reset the PMU, preventing it from operating afterwards. Proper handout between secboot and pmu is coming along with the actual gm20b PMU implementation, so use this as a temporary solution. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/pmu: instanciate the falcon in PMU deviceAlexandre Courbot1-0/+2
Have an instance of nvkm_falcon in the PMU structure, ready to be used by other subdevs (i.e. secboot). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/core: add falcon library functionsAlexandre Courbot1-4/+72
Falcon processors are used in various places of GPU chips. Although there exist different versions of the falcon, and some variants exist, the base set of actions performed on them is the same, which results in lots of duplicated code. This patch consolidates the current nvkm_falcon structure and extends it with the following features: * Ability for an engine to obtain and later release a given falcon, * Abstractions for basic operations (IMEM/DMEM access, start, etc) * Abstractions for secure operations if a falcon is secure Abstractions make it easy to e.g. start a falcon, without having to care about its details. For instance, falcons in secure mode need to be started by writing to a different register. Right now the abstractions variants only cover secure vs. non-secure falcon, but more will come as e.g. SEC2 support is added. This is still a WIP as other functions previously done by engine/falcon.c need to be reimplemented. However this first step allows to keep things simple and to discuss basic design. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/mc: add nvkm_mc_enabled() functionAlexandre Courbot1-0/+1
Add a function that allows us to query whether a given subdev is currently enabled or not. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/core: constify nv*_printk macrosAlexandre Courbot3-4/+4
Constify the local variables declared in these macros so we can pass const pointers to them. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/volt: pointers are 32-bitBen Skeggs1-4/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/vmap: pointers are 32-bitBen Skeggs1-4/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/timing: pointers are 32-bitBen Skeggs1-3/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/perf: pointers are 32-bitBen Skeggs1-3/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/fan: pointers are 32-bitBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/cstep: pointers are 32-bitBen Skeggs1-6/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/boost: pointers are 32-bitBen Skeggs1-6/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/disp/gp102: rename from gp104Ben Skeggs2-3/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/ce/gp102: rename from gp104Ben Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/fb/gp102: rename from gp104Ben Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/pmu/gp102: initial implementationBen Skeggs1-0/+1
GP102/GP104 require a harder reset of PMU prior to DEVINIT, or the IFR image will hang. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/pmu/gp100: initial implementationBen Skeggs1-0/+1
Just enough to hookup preinit reset(), which DEVINIT will depend on later. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/disp/sor/gf119-: add method to program mst payload informationBen Skeggs1-0/+10
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/disp/sor/gf119-: add method to control mst enableBen Skeggs1-0/+7
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/nvif: helper to match against supported class listBen Skeggs1-0/+29
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau: silence sparse warnings about symbols not being marked staticBen Skeggs1-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/fb: add gm20b deviceAlexandre Courbot1-0/+1
gm20b's FB has the same capabilities as gm200, minus the ability to allocate RAM. Create a device that reflects this instead of re-using the gk20a device which may be incorrect. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-By: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-28Merge branch 'linux-4.9' of git://github.com/skeggsb/linux into drm-nextDave Airlie7-9/+72
Karol's work which greatly improves volt/clock changes on a heap of boards, nothing too exciting beyond a random collection of fixes. * 'linux-4.9' of git://github.com/skeggsb/linux: (33 commits) drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit() hook drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit() hook drm/nouveau/pci: set streaming DMA mask early drm/nouveau/kms: add Maxwell to backlight initialization drm/nouveau/bar/nv50: fix bar2 vm size drm/nouveau/disp: remove unused function in sorg94.c drm/nouveau/volt: use kernel's 64-bit signed division function drm/nouveau/core: add missing header dependencies drm/nouveau/gr/nv3x: add 0x0597 kelvin 3d class support drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logo drm/nouveau/fb/ram: Use Kepler implementation on Maxwell drm/nouveau/volt: Make use of cvb coefficients drm/nouveau/volt/gf100-: Add speedo drm/nouveau/volt: Add implementation for gf100 drm/nouveau/bios/vmap: unk0 field is the mode drm/nouveau/volt: Don't require perfect fit drm/nouveau/clk: Allow boosting only when NvBoost is set drm/nouveau/bios: Add parsing of VPSTATE table drm/nouveau/clk: Respect voltage limits in nvkm_cstate_prog drm/nouveau/clk: Fixup cstate selection ...
2016-10-12drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logoMartin Peres1-0/+1
We received a donation of a Titan which has this useless feature allowing users to control the brightness of the LED behind the logo of NVIDIA. In the true spirit of open source, let's expose that to the users of very expensive cards! This patch hooks up this LED/PWM to the LED subsystem which allows blinking it in sync with cpu/disk/network/whatever activity (heartbeat is quite nice!). Users may also implement some breathing effect or morse code support in the userspace if they feel like it. v2: - surround the use of the LED framework with ifdef CONFIG_LEDS_CLASS v3: - avoid using ifdefs everywhere, follow the recommendations of /doc/Documentation/CodingStyle. Suggested by Emil Velikov. v4 (Ben): - squashed series of fixes from ml Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/volt/gf100-: Add speedoKarol Herbst1-0/+2
v5: Squashed speedo related commits. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/volt: Add implementation for gf100Karol Herbst1-0/+1
Since gf100 we need a speedo value for calculating the voltage. The readout will be added in a later patch. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/bios/vmap: unk0 field is the modeKarol Herbst1-1/+1
Depending on the value a different formular is used to calculated the voltage for this entry. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/clk: Allow boosting only when NvBoost is setKarol Herbst1-1/+8
0: base clock from the vbios is max clock (default) 1: boost only to boost clock from the vbios 2: boost to max clock available v2: Moved into nvkm_cstate_valid. v4: Check the existence of the clocks before limiting. v5: Default to boost level 0. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/bios: Add parsing of VPSTATE tableKarol Herbst1-0/+24
This table contains three important clocks: base clock: This is the non boosted max clock. tdp clock: The clock at wich the vbios guarentees the TDP won't ever be exceeded at max load (seems to be always the same as the base clock, but behaves differently). boost clock: The avg clock the gpu will stay boosted to. It doesn't seem to affect the behaviour of the nvidia driver at all though. v2: Make clear that base/boost/tdp fields are ids. v5: Rename Base clock to vpstate. Make vbios pointers 32bit. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/clk: Respect voltage limits in nvkm_cstate_progKarol Herbst1-0/+1
We should never allow to select a cstate which current voltage (depending on the temperature) is higher than 1. the max volt entries in the voltage map table. 2. what tha gpu actually can volt to. v3: Use find_best for all cstates before actually trying. Add nvkm_cstate_get function to get cstate by index. v5: Cstates with voltages lower then min_uv are valid. Move nvkm_cstate_get into the previous commit. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/clk: Fixup cstate selectionKarol Herbst1-0/+4
Now the cstatei parameter can be used of the nvkm_cstate_prog function to select a specific cstate. v5: Make a constant for the magic value. Use list_last_entry. Add nvkm_cstate_get here instead of in the next commit. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/volt: Add temperature parameter to nvkm_volt_mapKarol Herbst1-1/+2
The voltage entries actually may map to a different voltage depending on the current temperature. v2: Only read the temperature when actually needed. v5: Be smarter about using max(). Don't read the temperature anymore. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/clk: Let nvkm_clk_tstate take a temperature valueKarol Herbst1-2/+2
This way other subdevs can notify the clk subdev about temperature changes without the need of clk to poll that value. Also make this function safe to be called from an interrupt handler. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/clk: Add index field to nvkm_cstateKarol Herbst1-0/+1
It is better to read out the id out of the cstate struct directly instead of iterating over the list of cstates over and over again. Especially when we start saving pointers to a nvkm_cstate struct, it makes things easier. v5: Rename field to id. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/volt: Add min_id parameter to nvkm_volt_set_idKarol Herbst1-1/+1
Each pstate has its own voltage map entry like each cstate has. The voltages of those entries act as a floor value for the currently selected pstate and nvidia never sets a voltage below them. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/volt: Parse the max voltage map entriesKarol Herbst2-0/+13
There are at least three "max" entries, which specify the max voltage. Because they are actually normal voltage map entries, they can also be affected by the temperature. Nvidia respects those entries and if they get changed, nvidia uses the lower voltage from all three. We shouldn't exceed those voltages at any given time. v2: State what those entries do in the source. v3: Add the third max entry. v5: Better describe the entries. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/clk: Don't create cstates with voltages higher than what the gpu ↵Karol Herbst1-0/+1
can do nvkm_volt_map_min is a copy of nvkm_volt_map, which always returns the lowest possible voltage for a cstate. nvkm_volt_map will get a temperature parameter there later and also fix the voltage calculation, so that this functions will be completly different later. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/volt: Properly detect entry based voltage tablesKarol Herbst1-2/+3
There is a field in the voltage table which tells us if the VIDs are taken from the entries or calculated through the header. v2: Don't break older versions. v5: Reverse flag name. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Reviewed-by: Martin Peres <martin.peres@free.fr> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-10-12drm/nouveau/iccsense: Parse the resistors and config the right wayKarol Herbst1-2/+8
Previously we parsed that table a bit wrong: 1. The entry layout depends on the sensor type used. 2. We have all resitors in one entry for the INA3221. 3. The config is already included in the vbios. This commit addresses that issue and with that we should be able to read out the right power consumption for every GPU with a INA209, INA219 and INA3221. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-09-22drm/nouveau: Revert "bus: remove cpu_coherent flag"Karol Herbst1-0/+1
This reverts commit aff51175cdbf345740ec9203eff88e772af88059. The commit caused fence timeouts within nvc0_screen_destroy and most likely other places as well. The most obvious effect is, that userspace processes take minutes to actually quit. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bus: remove cpu_coherent flagAlexandre Courbot1-1/+0
This flag's only remaining function is to ignore the uncached flag for BOs on coherent architectures. However the reason for allocating an object uncache on a non-coherent architecture (namely because the cost of doing explicit flushes/ invalidations is higher than the benefit of caching the data because accesses are few and far between) should also apply on architectures for which coherency is maintained implicitly. Thus allocate coherent objects as uncached on all architectures. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ce/gp104: initial supportBen Skeggs2-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp104: initial supportBen Skeggs2-0/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-21 23:35:45 +0300