aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau/nvkm
Commit message (Collapse)AuthorAge
* drm/nouveau/gr/gm204: remove a stray printkBen Skeggs2015-05-28
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/devinit/gm100-: force devinit table execution on boards without ↵Ben Skeggs2015-05-28
| | | | | | | | PDISP Should fix fdo#89558 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/devinit/gf100: make the force-post condition more obviousBen Skeggs2015-05-28
| | | | | | And also more generic, so it can be used on newer chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bios: fix fetching from acpi on certain systemsJan Vesely2015-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | nvbios_extend() returns 1 to indicate "extended the array" and 0 to indicate the array is already big enough. This is used by the core shadowing code to prevent re-fetching chunks of the image that have already been shadowed. The ACPI fetching code may possibly need to extend this further due to requiring fetches to happen in 4KiB chunks. Under certain circumstances (that happen if the total image size is a multiple of 4KiB), the memory allocated to store the shadow will already be big enough, causing the ACPI code's nvbios_extend() call to return 0, which is misinterpreted as a failure. The fix is simple, accept >= 0 as a successful condition here. The core will have already made sure that we're not re-fetching data we already have. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89047 v2 (Ben Skeggs): - dropped hunk which would cause unnecessary re-fetching - more descriptive explanation Signed-off-by: Jan Vesely <jano.vesely@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gm206: initial init+ctx codeBen Skeggs2015-04-14
| | | | | | | | Uncertain whether the GPC pack change is due to a newer driver version, or a legitimate difference from GM204. My GM204 has broken vram, so can't currently try a newer binary driver on it to confirm. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/ce/gm206: enable support via gm204 codeBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/gm206: enable support via gm204 codeBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gm204: initial init+ctx codeBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/ce/gm204: initial supportBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/gm204: initial supportBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gk104-: prevent reading non-existent regs in intr handlerBen Skeggs2015-04-14
| | | | | | | | | Under certain circumstances the trapped address will contain subc 7, which GK104 GR doesn't have anymore. Notice this case to avoid causing additional priv ring faults. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gm107: very slightly demagic part of attrib cb setupBen Skeggs2015-04-14
| | | | | | | No idea if "3" is a constant or derived from something else, but the value is unchanged in the limited traces of gm107/gm204 I have here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gk104-: correct crop/zrop num_active_fbps settingBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gf100-: add symbolic names for classesBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gm107: support tpc "strand" ctxsw in gpccs ucodeBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gf100-: support mmio access with gpc offset from gpccs ucodeBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/pmu/gk20a: add some missing staticsAlexandre Courbot2015-04-14
| | | | | | | 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>
* drm/nouveau/gr/gk104-gk20a: call pmu to disable any power-gating before ctor()Ben Skeggs2015-04-14
| | | | | | | | On some of these chipsets, reading NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK can trigger a PRI fault and return an error code instead of a TPC mask, unless PGOB has been disabled first. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/pmu/gk208: implement gr power-up magic with gk110_pmu_pgob()Ben Skeggs2015-04-14
| | | | | | | | 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>
* drm/nouveau/pmu/gk110: implement gr power-up magic like PGOB on earlier chipsBen Skeggs2015-04-14
| | | | | | | 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>
* drm/nouveau/pbus/hwsq: Make code size u16Roy Spliet2015-04-14
| | | | | | | So we can actually use the full 512 byte code space Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/pbus/hwsq: Support strided register writesRoy Spliet2015-04-14
| | | | | Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/instmem/gk20a: fix crash during error pathAlexandre Courbot2015-04-14
| | | | | | | | | | | | | If a memory allocation fails when using the DMA allocator, gk20a_instobj_dtor_dma() will be called on the failed instmem object. At this time, node->handle might not be NULL despite the call to dma_alloc_attrs() having failed. node->cpuaddr is the right member to check for such a failure, so use it instead. Reported-by: Vince Hsu <vinceh@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/disp/gf110-: fix base channel update debug/error outputBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/disp/nv50-: fix push buffers in vramBen Skeggs2015-04-14
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/instmem/gk20a: add IOMMU supportAlexandre Courbot2015-04-14
| | | | | | | | | | Let GK20A's instmem take advantage of the IOMMU if it is present. Having an IOMMU means that instmem is no longer allocated using the DMA API, but instead obtained through page_alloc and made contiguous to the GPU by IOMMU mappings. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/instmem/gk20a: use DMA attributesAlexandre Courbot2015-04-14
| | | | | | | | | | | instmem for GK20A is allocated using dma_alloc_coherent(), which provides us with a coherent CPU mapping that we never use because instmem objects are accessed through PRAMIN. Switch to dma_alloc_attrs() which gives us the option to dismiss that CPU mapping and free up some CPU virtual space. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gk20a: remove RAM deviceAlexandre Courbot2015-04-14
| | | | | | | | Now that Nouveau can operate even when there is no RAM device, remove the dummy one used by GK20A. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/instmem/gk20a: move memory allocation to instmemAlexandre Courbot2015-04-14
| | | | | | | | | GK20A does not have dedicated RAM, thus having a RAM device for it does not make sense. Move the contiguous physical memory allocation to instmem. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* make RAM device optionalAlexandre Courbot2015-04-14
| | | | | | | | | | | | | | | Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the longer term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be allocated from the TT domain, allowing Nouveau to handle GPUs for which pfb->ram == NULL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gf100: Clear notify interruptLauri Peltonen2015-04-14
| | | | | | | | | Notify interrupt is only used for cyclestats. We can just clear it and avoid an "unknown stat" error that gets printed to dmesg otherwise. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/graph/nvc0: Fix engine pointer retrievalLauri Peltonen2015-04-14
| | | | | | | | | Other methods in this file suggest this is the correct way to retrieve the engine pointer. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/devinit/nv04: change owner to intBen Skeggs2015-04-14
| | | | | | | We use -1 to mean "not read from hw yet" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mxm: indent an if statementDan Carpenter2015-04-14
| | | | | | | | This if statement is correct but it wasn't indented, so it looked like some code was missing. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fuse/gm107: simplify the return logicMartin Peres2015-04-14
| | | | | | | | | Spotted by coccinelle: drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified Signed-off-by: Martin Peres <martin.peres@free.fr> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bios: fix i2c table parsing for dcb 4.1Stefan Huehner2015-03-16
| | | | | | | | | Code before looked only at bit 31 to decide if a port is unused. However dcb 4.1 spec says 0x1F in bits 31-27 and 26-22 means unused. This fixed hdmi monitor detection on GM206. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)Stefan Huehner2015-03-16
| | | | | | | Enough to get VGA monitor on DVI-I output have output. HDMI output not yet working Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switchBen Skeggs2015-03-16
| | | | | | fdo#88868 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addressesBen Skeggs2015-03-16
| | | | | | fdo#83992 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/nv04: remove the loop from the interrupt handlerBen Skeggs2015-03-16
| | | | | | | | | | | | | | | Complete bong hit (and not the last...), the hardware will reassert the interrupt to PMC if it's necessary. Also potentially harmful in the face of interrupts such as the non-stall interrupt, which remain active in NV_PFIFO_INTR even when we don't care about servicing it. It appears (hopefully, fdo#87244), that under certain loads, the methods may pass quickly enough to hit the "100 spins and kill PFIFO" thing that we had going on. Not ideal ;) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: finalise nvkm namespace switch (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/device: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/vp: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/sw: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/sec: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/pm: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/msvld: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/msppp: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/mspdec: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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>
* drm/nouveau/mpeg: namespace + nvidia gpu names (no binary change)Ben Skeggs2015-01-21
| | | | | | | | | | | | | | | | 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.2 (git 2.25.0) at 2025-04-06 13:44:47 -0400