- 08 Nov, 2013 13 commits
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
User control of this has been hard-coded as disabled for now. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Internal use only at this point. Userspace later. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
These will diverge further in the future. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
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>
-
Ilia Mirkin authored
The nv31/nv40 impls are actually fairly nv44-specific, since they assume the presence of the instance register/context switching. Create a copy before nv31/nv40 get fixed. Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 05 Jul, 2013 2 commits
-
-
Maarten Lankhorst authored
Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Generated context verified to be the same for all supported chipsets. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 01 Jul, 2013 5 commits
-
-
Ilia Mirkin authored
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ilia Mirkin authored
Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Not really "core" per-se. About to merge Ilia's work adding another similar class for the VP2 xtensa engines, so, seems like a good time to move all these to engine/. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
These are pretty much useless for reclocking purposes. Lets make it clearer what they're for and move them to DEVINIT to signify they're for the very simple PLL setting requirements of running the init tables. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 02 May, 2013 1 commit
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 26 Apr, 2013 4 commits
-
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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>
-
Ben Skeggs authored
It'd be pretty awesome if someone would care enough to port this all properly to a class interface, perhaps submitting a command stream to the core via a sw object on PFIFO (emulating how EVO works basically, and also what nvidia have done forever..).. But, this seems unlikely given how old this hardware is now, so, lets just hide it away. There's a heap of other bits and pieces laying around that are still tangled. I'll (re)move them in pieces. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
This is needed because temperature management on nv50 can be enabled and it looks about the same as nv40. Signed-off-by:
Martin Peres <martin.peres@labri.fr> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
- 20 Feb, 2013 15 commits
-
-
Marcin Slusarz authored
Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com>
-
Ben Hutchings authored
If I build nouveau on ia64, Kconfig warns: warning: (DRM_NOUVEAU) selects ACPI_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI) warning: (DRM_NOUVEAU) selects MXM_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI_WMI) Make all the ACPI support depend on X86 and select X86_PLATFORM_DEVICES. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We need to be able to do link training for PIOR-connected ANX9805 from the third supervisor handler (due to script ordering in the bios, can't have the "user" call train because some settings are overwritten from the modesetting bios scripts). This moves link training for SOR-connected DP encoders to the second supervisor interrupt, *before* we call the modesetting scripts (yes, different ordering from PIOR is necessary). This is useful since we should now be able to remove some hacks to workaround races between the supervisor and link training paths. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This removes the nastiness with the interactions between display and software engines when handling vblank semaphore release interrupts. Now, all the semantics are handled in one place (sw) \o/. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
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>
-
Martin Peres authored
v2: change percent from int to atomic_t v3: random fixes v4 (Ben Skeggs): - adapted for split-out fan-control "protocol" structure - removed need for timer resched - support for forcing 'toggle' control on PWM boards Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Martin Peres <martin.peres@labri.fr>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Martin Peres <martin.peres@labri.fr>
-