summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau/nvkm
Commit message (Collapse)AuthorAgeFilesLines
* drm/nouveau/tmr: fully separate alarm execution/pending listsBen Skeggs2017-06-061-3/+4
| | | | | | | | | | | | Reusing the list_head for both is a bad idea. Callback execution is done with the lock dropped so that alarms can be rescheduled from the callback, which means that with some unfortunate timing, lists can get corrupted. The execution list should not require its own locking, the single function that uses it can only be called from a single context. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
* drm/nouveau/fifo/gk104-: Silence a locking warningDan Carpenter2017-05-171-1/+2
| | | | | | | | Presumably we can never actually hit this return, but static checkers complain that we should unlock before we return. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: plug memory leak in ls_ucode_img_load_gr() error pathChristophe JAILLET2017-05-171-1/+3
| | | | | | | | | | The last goto looks spurious because it releases less resources than the previous one. Also free 'img->sig' if 'ls_ucode_img_build()' fails. Fixes: 9d896f3e41a6 ("drm/nouveau/secboot: abstract LS firmware loading functions") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/therm: remove ineffective workarounds for alarm bugsBen Skeggs2017-05-124-4/+4
| | | | | | | | These were ineffective due to touching the list without the alarm lock, but should no longer be required. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
* drm/nouveau/tmr: avoid processing completed alarms when adding a new oneBen Skeggs2017-05-121-3/+13
| | | | | | | | | | | The idea here was to avoid having to "manually" program the HW if there's a new earliest alarm. This was lazy and bad, as it leads to loads of fun races between inter-related callers (ie. therm). Turns out, it's not so difficult after all. Go figure ;) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
* drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarmBen Skeggs2017-05-121-7/+10
| | | | | | | | | | | At least therm/fantog "attempts" to work around this issue, which could lead to corruption of the pending alarm list. Fix it properly by not updating the timestamp without the lock held, or trying to add an already pending alarm to the pending alarm list.... Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
* drm/nouveau/tmr: handle races with hw when updating the next alarm timeBen Skeggs2017-05-121-10/+16
| | | | | | | | | | If the time to the next alarm is short enough, we could race with HW and end up with an ~4 second delay until it triggers. Fix this by checking again after we update HW. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
* drm/nouveau/tmr: ack interrupt before processing alarmsBen Skeggs2017-05-121-1/+1
| | | | | | | | Fixes a race where we can miss an alarm that triggers while we're already processing previous alarms. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
* drm/nouveau/core: fix static checker warningBen Skeggs2017-05-121-1/+1
| | | | | | | | | | object->engine cannot be NULL, it's either valid, or an error pointer. This particular condition shouldn't actually be possible, but just in case, we'll keep it. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fb/ram/gf100-: remove 0x10f200 readBen Skeggs2017-05-121-1/+0
| | | | | | | | This reg has moved on Pascal, and causes a bus fault. We never use the value anyway, so just remove the read. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detectionMario Kleiner2017-04-291-1/+1
| | | | | | | | | | A missing u64 cast causes a 32-Bit wraparound from 4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected if card has 4096 Mib per FBP. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot/gm20b: fix the error return code in ↵Wei Yongjun2017-04-291-1/+1
| | | | | | | | | | gm20b_secboot_tegra_read_wpr() The error return code PTR_ERR(mc) is always 0 since mc is equal to 0 in this error handling case. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bios/bitP: check that table is long enough for optional pointersBen Skeggs2017-04-295-5/+5
| | | | | | Fixes OOB VBIOS accesses on some boards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engineIlia Mirkin2017-04-291-0/+2
| | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
* drm/nouveau/gpio: enable interrupts on cards with 32 gpio linesAdam Borowski2017-04-061-1/+1
| | | | | | | | | | | | | | The code attempts to enable them, but hits an undefined behaviour by shifting by the entire register's width: int lines = 32; u32 mask = (1 << lines) - 1; // 00000000 on x86 u32 mask = (1 << lines) - 1; // ffffffff on arm (32) u32 mask = (1 << lines) - 1; // 00000000 on arm64 u32 mask = (1ULL << lines) - 1; // ffffffff everywhere Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gp107: initial supportBen Skeggs2017-04-068-8/+119
| | | | | | | | | | Forked from GP106 implementation. Differences: - 1 PPC/GPC - Slightly different grctx magics Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: recognise GP10B chipsetAlexandre Courbot2017-04-061-0/+24
| | | | | Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/platform: make VDD regulator optionalAlexandre Courbot2017-04-061-9/+22
| | | | | | | | GP10B's power is managed by generic PM domains, so it does not require a VDD regulator. Add this option into the chip function structure. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr: support for GP10BAlexandre Courbot2017-04-065-2/+76
| | | | | | | GR is similar to GP100, with a few unavailable registers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/ibus: add GP10B supportAlexandre Courbot2017-04-062-0/+60
| | | | | | | | GP10B requires a specific initialization sequence due to the absence of devinit. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mc: add GP10B supportAlexandre Courbot2017-04-064-5/+68
| | | | | | | | GP10B's MC is compatible with GP100's, but engines need to be explicitly put out of ELPG during init. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fb: add GP10B supportAlexandre Courbot2017-04-062-0/+39
| | | | | | | GP10B's FB is largely compatible with the GP100 implementation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo: add GP10B supportAlexandre Courbot2017-04-064-1/+44
| | | | | | | GP10B's FIFO is similar to GP100's, but only allows 512 channels. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/msgqueue: support for GP10B PMU firmwareAlexandre Courbot2017-04-063-0/+117
| | | | | | | | | | The GP10B firmware is very close to GM20B's. The only difference is that it supports booting multiple falcons. In order to avoid having too much functions and structures shared, implement its support in the same source file as GM20B firmware. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: add GP10B supportAlexandre Courbot2017-04-062-0/+94
| | | | | | | | GP10B's secboot is largely similar to GM20B's. Only differences are MC base address and the fact that GPCCS is also securely managed. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot/gm20b: specify MC base address as argumentAlexandre Courbot2017-04-062-8/+12
| | | | | | | | | Allow the MC base address to be specified as an argument for the WPR region reading function. GP10B uses a different address layout as GM20B, so this is necessary. Also export the function to be used by GP10B. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: start LS firmware in post-run hookAlexandre Courbot2017-04-062-49/+47
| | | | | | | | | The LS firmware post-run hook is the right place to start said LS firmware. Moving it here also allows to remove special handling in the ACR code. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: let LS post_run hooks return errorAlexandre Courbot2017-04-064-10/+26
| | | | | | | | A LS post-run hook can meet an error meaning the failure of secure boot. Make sure this can be reported. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: pass instance to LS firmware loadersAlexandre Courbot2017-04-0611-33/+41
| | | | | | | | | | | | Having access to the secboot instance loading a LS firmware can be useful to LS firmware handlers. At least more useful than just having an out-of-context subdev pointer. GP10B's firmware will also need to know the WPR address, which can be obtained from the secboot instance. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: allow to boot multiple falconsAlexandre Courbot2017-04-066-25/+52
| | | | | | | | | | | | Change the secboot and msgqueue interfaces to take a mask of falcons to reset instead of a single falcon. The GP10B firmware interface requires FECS and GPCCS to be booted in a single firmware command. For firmwares that only support single falcon boot, it is trivial to loop over the mask and boot each falcons individually. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/imem/gk20a: Turn instmem lock into mutexThierry Reding2017-04-061-11/+8
| | | | | | | | | | | | | The gk20a implementation of instance memory uses vmap()/vunmap() to map memory regions into the kernel's virtual address space. These functions may sleep, so protecting them by a spin lock is not safe. This triggers a warning if the DEBUG_ATOMIC_SLEEP Kconfig option is enabled. Fix this by using a mutex instead. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: initial support (display-only) for GP107Ben Skeggs2017-04-061-0/+30
| | | | | | | | | | Forked from GP106 implementation. Split out from commit enabling secboot/gr support so that it can be added to earlier kernels. Cc: stable@vger.kernel.org [4.10+] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 oneIlia Mirkin2017-04-061-1/+1
| | | | | | | | | | | | | | | | | | The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP and PCI varieties, rather than a core PCIE chip with a bridge for AGP/PCI as necessary. As a result, it appears that the MMU is also non-functional. For AGP cards, the vast majority of the NV4A lineup, this worked out since we force AGP cards to use the nv04 mmu. However for PCI variants, this did not work. Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for the suggestion. This should be a no-op for NV4A AGP boards, as they were using it already. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mpeg: mthd returns true on success nowIlia Mirkin2017-04-062-2/+2
| | | | | | | Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: stable@vger.kernel.org # v4.3+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/secboot: fix NULL pointer dereferenceAlexandre Courbot2017-03-173-3/+15
| | | | | | | | | The msgqueue pointer validity should be checked by its owner, not by the msgqueue code itself to avoid this situation. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau/secboot: fix inconsistent pointer checkingAlexandre Courbot2017-03-171-1/+2
| | | | | | | | | | We were returning PTR_ERR() on a NULL pointer, which obviously won't work. nvkm_engine_ref() will return an error in case something went wrong. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-nextDave Airlie2017-03-0867-556/+4358
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Re-architecture of the code to handle proprietary fw, more abstracted to support the multitude of differences that NVIDIA introduce - Support in the said code for GP10x ACR and GR fw, giving acceleration support \o/ - Fix for GTX 970 GPUs that are in an odd MMU configuration * 'linux-4.12' of git://github.com/skeggsb/linux: (60 commits) drm/nouveau/fb/gf100-: rework ram detection drm/nouveau/fb/gm200: split ram implementation from gm107 drm/nouveau/fb/gf108: split implementation from gf100 drm/nouveau/fb/gf100-: modify constructors to allow more customisation drm/nouveau/kms/nv50: use drm core i2c-over-aux algorithm drm/nouveau/i2c/g94-: return REPLY_M value on reads drm/nouveau/i2c: modify aux interface to return length actually transferred drm/nouveau/gp10x: enable secboot and GR drm/nouveau/gr/gp102: initial support drm/nouveau/falcon: support for gp10x msgqueue drm/nouveau/secboot: add gp102/gp104/gp106/gp107 support drm/nouveau/secboot: put HS code loading code into own file drm/nouveau/secboot: support for r375 ACR drm/nouveau/secboot: support for r367 ACR drm/nouveau/secboot: support for r364 ACR drm/nouveau/secboot: workaround bug when starting SEC2 firmware drm/nouveau/secboot: support standard NVIDIA HS binaries drm/nouveau/secboot: support for unload blob bootloader drm/nouveau/secboot: let callers interpret return value of blobs drm/nouveau/secboot: support for different load and unload falcons ...
| * drm/nouveau/fb/gf100-: rework ram detectionBen Skeggs2017-03-077-101/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit reworks the RAM detection algorithm, using RAM-per-LTC to determine whether a board has a mixed-memory configuration instead of using RAM-per-FBPA. I'm not certain the algorithm is perfect, but it should handle all currently known configurations in the very least. This should fix GTX 970 boards with 4GiB of RAM where the last 512MiB isn't fully accessible, as well as only detecting half the VRAM on GF108 boards. As a nice side-effect, GP10x memory detection now reuses the majority of the code from earlier chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/fb/gm200: split ram implementation from gm107Ben Skeggs2017-03-074-1/+44
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/fb/gf108: split implementation from gf100Ben Skeggs2017-03-075-1/+86
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/fb/gf100-: modify constructors to allow more customisationBen Skeggs2017-03-074-52/+81
| | | | | | | | | | | | | | GF108/GM107 implementations will want slightly different functions for the upcoming RAM detection improvements. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/i2c/g94-: return REPLY_M value on readsBen Skeggs2017-03-072-0/+2
| | | | | | | | | | | | | | This value represents the actual number of bytes recieved on the AUX channel as the result of a read transaction. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/i2c: modify aux interface to return length actually transferredBen Skeggs2017-03-075-21/+21
| | | | | | | | | | | | | | | | Apparently sinks are allows to respond with ACK even if they didn't fully complete a transaction... It seems like a missed opportunity for DEFER to me, but what do I know :) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/gp10x: enable secboot and GRAlexandre Courbot2017-03-071-0/+15
| | | | | | | | | | | | | | | | All the bricks are in place for secure boot to be enabled. This in turn makes GR usable so enable them all. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/gr/gp102: initial supportBen Skeggs2017-03-077-4/+180
| | | | | | | | | | | | | | | | | | | | | | Differences from GP100: - 3 PPCs/GPC. - Another random reg to calculate/write. - Attrib CB setup a little different. - PascalB - PascalComputeB Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/falcon: support for gp10x msgqueueAlexandre Courbot2017-03-074-0/+268
| | | | | | | | | | | | | | | | Add support for the msgqueue firmware used to process SEC2 commands for gp10x chips. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: add gp102/gp104/gp106/gp107 supportAlexandre Courbot2017-03-072-0/+252
| | | | | | | | | | | | | | | | | | | | | | These gp10x chips are supporting using (roughly) the same firmware. Compared to previous secure chips, ACR runs on SEC2 and so does the low-secure msgqueue. ACR for these chips is based on r367. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: put HS code loading code into own fileAlexandre Courbot2017-03-075-124/+182
| | | | | | | | | | | | | | | | We will also need to load HS blobs outside of acr_r352 (for instance, to run the NVDEC VPR scrubber), so make this code reusable. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: support for r375 ACRAlexandre Courbot2017-03-073-0/+167
| | | | | | | | | | | | | | | | r375 ACR uses a unified bootloader descriptor for the GR and PMU firmwares. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/secboot: support for r367 ACRAlexandre Courbot2017-03-074-0/+425
| | | | | | | | | | | | | | | | | | | | r367 uses a different hsflcn_desc layout and LS firmware signature format, requiring a rewrite of some functions. It also makes use of the shadow region, and uses SEC as the boot falcon. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-02 05:17:16 +0000