summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/include/nvkm/subdev
AgeCommit message (Collapse)Author
2017-02-17drm/nouveau/pci/g92: Fix rearmKarol Herbst
704a6c008b7942bb7f30bb43d2a6bcad7f543662 broke pci msi rearm for g92 GPUs. g92 needs the nv46_pci_msi_rearm, where g94+ gpus used nv40_pci_msi_rearm. Reported-by: Andrew Randrianasulu <randrianasulu@gmail.com> Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2017-02-17drm/nouveau/iccsense: Parse max and crit power levelKarol Herbst
Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/bios/power_budget: Add basic power budget parsingKarol Herbst
v2: Set entry to 0xff if not found Add cap entry for ver 0x30 tables Rework to fix memory leak v3: More error checks Simplify check for invalid entries v4: disable for ver 0x10 for now move assignments after the second last return Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/top: add function to translate subdev index to mmu fault idBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/pci: Rename g94 to g92Karol Herbst
Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/core/mm: replace region list with next pointerBen Skeggs
We never have any need for a double-linked list here, and as there's generally a large number of these objects, replace it with a single- linked list in order to save some memory. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/secboot: split reset functionAlexandre Courbot
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 Courbot
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 Courbot
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 Courbot
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 Courbot
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 Courbot
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 Courbot
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/mc: add nvkm_mc_enabled() functionAlexandre Courbot
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>
2016-11-28drm/nouveau/bios/volt: pointers are 32-bitBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/vmap: pointers are 32-bitBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/timing: pointers are 32-bitBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/perf: pointers are 32-bitBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/fan: pointers are 32-bitBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/cstep: pointers are 32-bitBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-28drm/nouveau/bios/boost: pointers are 32-bitBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/fb/gp102: rename from gp104Ben Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/pmu/gp102: initial implementationBen Skeggs
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 Skeggs
Just enough to hookup preinit reset(), which DEVINIT will depend on later. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau: silence sparse warnings about symbols not being marked staticBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/fb: add gm20b deviceAlexandre Courbot
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-12drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logoMartin Peres
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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 Herbst
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-07-14drm/nouveau/fb/gp104: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ltc/gp100: initial supportBen Skeggs
Due to the GPU preventing us from touching NV_PLTCG_LTCS_LTSS_CBC_BASE, we cannot provide CBC/ZBC support without signed PMU firmware to handle the task for us... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gp100: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/pci/gp100: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mc/gp100: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gf100-: allow selection of an alternate big page sizeBen Skeggs
GFxxx/GM1xx support the selection of 64/128KiB big pages globally. GM2xx supports the same, as well as another mode where the page size can be selected per-instance. We default to 128KiB pages (With per-instance for GM200, but the current code selects 128KiB there already) as the MMU code isn't currently able to handle otherwise. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bios: pointers beyond end of first image need special handlingBen Skeggs
Makes common the code that was previously used by the PMU table parsing, as it appears other tables need this too. Not much of an idea what this is all about... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bios: guard against out-of-bounds accesses to imageBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-04 15:01:26 +0000