summaryrefslogtreecommitdiff
path: root/nvkm/subdev/mc
Commit message (Collapse)AuthorAgeFilesLines
* mc/nv4c: disable msiIlia Mirkin2014-12-221-8/+0
| | | | | | | | | | | | | Several users have, over time, reported issues with MSI on these IGPs. They're old, rarely available, and MSI doesn't provide such huge advantages on them. Just disable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87361 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74492 Fixes: fa8c9ac72fe ("drm/nv4c/mc: nv4x igp's have a different msi rearm register") Cc: stable@vger.kernel.org Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* ltc: s/ltcg/ltc/ + cleanupBen Skeggs2014-08-101-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* gr/gk208-: stop touching 0x260 inappropriatelyBen Skeggs2014-08-057-3/+98
| | | | | | | As a side note.. It's a bit hard to figure out how to name this commit.. GK20A is NVEA, which is before NV108 (GK208).. Confusing. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc/nv50-: also pass PMGR interrupts onto I2C subdevBen Skeggs2014-06-113-3/+6
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc/nv50-: fix kms pageflip events by reordering irq handling order.Mario Kleiner2014-06-113-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever a single nouveau_mc_intr() main gpu irq-handler invocation was responsible for calling both, the vblank-irq handler (display engine irq) and kms-pageflip completion handler (from fifo irq), the order of invocation was wrong. nouveau_finish_flip() was called before drm_handle_vblank() for the vblank of pageflip completion, so the emitted pageflip event contained stale vblank count and timestamp from previous vblank. This caused failure in userspace to timestamp properly. Reorder order of invocation of engine irq handlers: Put NVDEV_ENGINE_DISP always on top, and thereby before NVDEV_ENGINE_FIFO, so that drm_handle_vblank() gets called to update vblank timestamps and count before potential pageflip events make use of that information. This works on nv-50 and later, where kms-pageflip completion triggers an irq either after a separate vblank irq, or both pageflip and vblank trigger one common irq invocation, but never before vblank irqs. v2 (Ben): - removed mods for nv04-nv40, it doesn't help there anyway - this is considered a hack, and a better solution should be found Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 3.13+
* support for platform devicesAlexandre Courbot2014-03-261-22/+33
| | | | | | | | | | | | | | | | | | | | | Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a nouveau_drm_platform_probe() function that takes a GPU platform device to be probed. Core code as well as engine/subdev drivers are updated wherever possible to make use of these functions. Some older drivers are too dependent on PCI to be properly updated, but all newer code on which future chips may depend should at least be runnable with platform devices. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc/nv4c: nv4x igp's have a different msi rearm registerIlia Mirkin2014-02-184-1/+48
| | | | | | | | | See https://bugs.freedesktop.org/show_bug.cgi?id=74492 Reported-by: Ronald <ronald645@gmail.com> Suggested-by: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* fb/nvc0-: hook up skeleton interrupt handlerBen Skeggs2014-01-231-0/+2
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* v3.13-rc1Ben Skeggs2013-12-041-2/+0
|
* pwr: initial implementationBen Skeggs2013-11-082-0/+2
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: fix (incorrect) reporting of unknown pending intr bitsBen Skeggs2013-11-051-6/+11
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc/nvaa: blacklist msi to off by defaultBen Skeggs2013-11-051-11/+19
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: enable msi by default (again)Ben Skeggs2013-11-051-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc/nv50-nv86,nv92: rearm msi via pci config space, rather than mmio mirrorBen Skeggs2013-11-054-2/+49
| | | | | | | | | This is what NVIDIA do on these chipsets, let's hope it works around the reported MSI failures for us on NV86. v2: updated to include G92, as per information provided by NVIDIA. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc/nvc0,nvc4: handle 0xc0's "special" msi rearmBen Skeggs2013-11-059-9/+108
| | | | | | | v2. updated to cover GF104, as per information provided by NVIDIA. Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: store static data in nouveau_mc class definitionBen Skeggs2013-11-057-139/+75
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: fetch NV_PMC_INTR again after re-arming MSIBen Skeggs2013-11-051-4/+6
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: bracket interrupt handler with NV_PMC_INTR_EN disable/re-enableBen Skeggs2013-11-051-0/+4
| | | | | | This looks to be what NVIDIA do pretty much everywhere, since forever. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: have single entry and exit points to the interrupt handlerBen Skeggs2013-11-051-20/+20
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: msi rearm write via subdev, not deviceBen Skeggs2013-11-051-2/+2
| | | | | | This way we can catch it with debugging on for PMC subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: fix runtime pm trigger conditionBen Skeggs2013-11-051-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* kms/nv10: add plane support for nv10-nv40Ilia Mirkin2013-11-051-0/+1
| | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: disable msi support by default, it's busted in tons of placesBen Skeggs2013-10-081-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* v3.12-rc1Ben Skeggs2013-09-171-0/+5
|
* mc: use MSI interrupts where possibleLucas Stach2013-09-171-0/+23
| | | | | | | | | | | MSIs were only problematic on some old, broken chipsets. But now that we already see systems where PCI legacy interrupts are somewhat flaky, it's really time to move to MSIs. v2 (Ben Skeggs): blacklist BR02 boards Signed-off-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* vdec: implement support for VP3 enginesIlia Mirkin2013-08-211-1/+2
| | | | | | | | | For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: fix race condition between constructor and request_irq()Ben Skeggs2013-08-216-11/+10
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc/nv50: include vp in the fb error reporting maskIlia Mirkin2013-07-301-1/+1
| | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* vp/nv84: initial vp2 engine implementationIlia Mirkin2013-06-271-0/+1
|
* ce/nve0: stub interrupt handlerBen Skeggs2013-06-131-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* mc: handle irq-related setup ourselvesBen Skeggs2013-04-246-9/+56
| | | | | | | | We need to be able to process interrupts before the DRM code is able to actually enable them, set it up ourselves. Also, it's less convoluted to *not* use the DRM wrappers it appears... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* therm: implement support for temperature alarmsMartin Peres2013-02-201-0/+1
| | | | | | | | | | | | | | | | | | | For now, we only boost the fan speed to the maximum and auto-mode when hitting the FAN_BOOST threshold and halt the computer when it reaches the shutdown temperature. The downclock and critical thresholds do nothing. On nv43:50 and nva3+, temperature is polled because of the limited hardware. I'll improve the nva3+ situation by implementing alarm management in PDAEMON whenever I can but polling once every second shouldn't be such a problem. v2 (Ben Skeggs): - rebased v3: fixed false-detections and threshold reprogrammation handling on nv50:nvc0 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* pbus: add a PBUS subdev that hands IRQs to the right subdevsMartin Peres2013-02-204-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are going to use PTHERM's IRQs for thermal monitoring but we need to route them first. On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs. It seems like nv10-31 GPIO interruptions aren't well handled. I kept the original behaviour but it is wrong and may lead to an IRQ storm. Since we enable all PBUS IRQs, we need a way to avoid being stormed if we don't handle them. The solution I used was to mask the IRQs that have not been handled. This will also print one message in the logs to let us know. v2: drop the shared intr handler because of was racy v3: style fixes v4: drop a useless construct in the chipset-dependent INTR v5: add BUS to the disable mask v6 (Ben Skeggs): - general tidy to match the rest of the driver's style - nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's not going to conflict - removed the peephole and user stuff, for the moment.. will handle them later if we find a good reason to actually care.. - limited INTR_EN to just what we can handle for now, mostly to prevent spam of unknown status bits (seen on at least nv4x) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* initial import of nouveau kernel module core, some simple tools, and drmBen Skeggs2013-01-097-0/+447
Ignore (or, if you're really keen, fix) any of the horrors that are part of the emulate-linux-on-libpciaccess (lib/) layer. When I started down this path I was only aiming to prototype the reworked driver core, and never actually intended on going quite this far with things, but it turns out that being able to develop and test the nouveau core from userspace is *very* useful. This tree is based on the code available as of Linux 3.8-rc2. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
View Lorry Controller Status