summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/nvkm/subdev/pmu
AgeCommit message (Collapse)AuthorFilesLines
2017-02-17drm/nouveau/gm20b: add dummy PMU deviceAlexandre Courbot2-0/+35
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/gk20a: use falcon library functionsAlexandre Courbot1-9/+22
Use the falcon library functions where relevant. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/pmu/gk20a: simplify code a bitAlexandre Courbot1-22/+8
Some functions always succeed - change their return type to void and remove the error-handling code in their caller. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau/pmu/gk20a: use nvkm_pmu_ctor()Alexandre Courbot1-21/+14
Use the PMU constructor so that all base members (in particular the falcon instance) are initialized properly. 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-1/+3
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/pmu: add nvkm_pmu_ctor() functionAlexandre Courbot2-5/+14
Add a PMU constructor so implementations that extend the nvkm_pmu structure can have all base members properly initialized. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/pmu/gp102: initial implementationBen Skeggs2-0/+44
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 Skeggs2-0/+36
Just enough to hookup preinit reset(), which DEVINIT will depend on later. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/pmu: execute reset before running devinitBen Skeggs1-0/+8
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau/pmu: move ucode handling into gt215 implementationBen Skeggs9-184/+304
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau: silence sparse warnings about symbols not being marked staticBen Skeggs4-8/+8
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/pmu: remove reset() hookAlexandre Courbot2-11/+0
The reset hook of pmu_func is never called, and gt215 was the only chip to implement. Remove this dead code. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/core: remove pmc_enable argument from subdev ctorBen Skeggs2-2/+2
These are now specified directly in the MC subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/pmu: be more strict about lockingKarol Herbst1-3/+5
When we start communicating with the pmu a bit more, the current code is a real issue. I encountered a dead lock here, while testing my dynamic reclocking code Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14drm/nouveau/pmu/fuc: use imm32 in ld/st macrosKarol Herbst1-2/+2
Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14drm/nouveau/pmu/fuc: use the call macro instead of using the call ↵Karol Herbst2-9/+9
instruction directly the macro deals with target specific differences and so we should always use this Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14drm/nouveau/pmu/fuc: replace mov+sethi with imm32Karol Herbst7-3148/+3140
on gk208+ we can simply mov 32bits, so we should have a single mov there v2: use or operator instead of add Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14drm/nouveau/pmu/fuc: fix imm32 for gk208+Karol Herbst2-442/+442
Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-01-11drm/nouveau/pmu: prevent falcon from acking interrupts routed to the hostBen Skeggs5-2266/+2252
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-12-09drm/nouveau/pmu: remove whitelist for PGOB-exit WAR, enable by defaultBen Skeggs1-3/+1
NVIDIA have indicated that the workaround is required on all GK10[467] boards that have the PGOB fuse set. I've left the commandline option in place for now, as paranoia. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pmu/gk104: check fuse to determine presence of PGOBBen Skeggs1-0/+4
Not 100% confirmed, but seems to match from the few boards I've looked at so far. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-11-03drm/nouveau/pmu: do not assume a PMU is presentAlexandre Courbot1-1/+1
Some devices may not have a PMU. Avoid a NULL pointer dereference in such cases by checking whether the pointer given to nvkm_pmu_pgob() is valid. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/device: import pciid list and integrate quirks with itBen Skeggs1-4/+2
PCI IDs taken from the NVIDIA binary driver, with permission. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/tmr: convert to new-style nvkm_subdevBen Skeggs1-3/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/pmu: convert to new-style nvkm_subdevBen Skeggs14-193/+190
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/clk: convert to new-style nvkm_subdevBen Skeggs1-3/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/subdev: rename some functions to avoid upcoming conflictsBen Skeggs2-4/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/pmu: switch to subdev printk macrosBen Skeggs4-34/+42
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/pmu: switch to new-style timer macrosBen Skeggs3-10/+32
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/pmu: switch to device pri macrosBen Skeggs6-120/+133
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/pmu: cosmetic changesBen Skeggs2-46/+44
This is purely preparation for upcoming commits, there should be no code changes here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/device: include core/device.h automatically for subdevs/enginesBen Skeggs1-2/+0
Pretty much every subdev/engine is going to need access to nvkm_device shortly to touch registers and/or output messages. The odd placement of the includes is necessary to work around some inter-dependencies that currently exist. This will be fixed later. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/subdev: add direct pointer to nvkm_deviceBen Skeggs1-3/+2
Will be utilised in upcoming commits to remove the need for heuristics to lookup the device a subdev belongs to. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-08-28drm/nouveau/pmu/gk104: implement a hackish workaround for a hw bugBen Skeggs1-0/+51
Only a handful of machines have this enabled by default, where it's been proven to work. The workaround can be explicitly enabled with a module option also. Still waiting on feedback from NVIDIA for a proper idea of exactly what this fix is doing, and how to implement it properly. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/pmu/gk20a: add some missing staticsAlexandre Courbot1-3/+4
Make static a few functions and structures that should be. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/pmu/gk208: implement gr power-up magic with gk110_pmu_pgob()Ben Skeggs3-1/+4
Before we moved gk110's implementation of this to pmu, the functions were identical. This commit just switches GK208 to use the new (more complete) implementation of the power-up sequence. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/pmu/gk110: implement gr power-up magic like PGOB on earlier chipsBen Skeggs2-0/+96
Turns out the PTHERM part of this dance is bracketed by the same PMU fiddling that occurs on GK104/6, let's assume it's also PGOB. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-22drm/nouveau/pmu: namespace + nvidia gpu names (no binary change)Ben Skeggs18-203/+187
The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-01-22drm/nouveau/pmu: rename from pwr (no binary change)Ben Skeggs28-0/+10709
Switch to NVIDIA's name for the device. The namespace of NVKM is being changed to nvkm_ instead of nouveau_, which will be used for the DRM part of the driver. This is being done in order to make it very clear as to what part of the driver a given symbol belongs to, and as a minor step towards splitting the DRM driver out to be able to stand on its own (for virt). Because there's already a large amount of churn here anyway, this is as good a time as any to also switch to NVIDIA's device and chipset naming to ease collaboration with them. A comparison of objdump disassemblies proves no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-22 16:35:41 +0300