similar to: [PATCH 0/6] Improve GK20A and introduce GM20B support

Second version of this patchset. Not many changes since first version - I hope this means the changes are not too controversial. Changes since v1: - Removed lookup for previous FW files in "nouveau/" - Went back to using request_firmware() since we only try to load one file Original cover letter follows: GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support

Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path if they cannot be found in the new, "official" path. User setups were broken by the switch, which is bad. There are only 4 firmware files we may want to look up that way, so hardcode them into the lookup function. All new firmware files should use the standard "nvidia/<chip>/gr/" path.

On 11/02/2016 02:07 PM, Ilia Mirkin wrote: > On Wed, Nov 2, 2016 at 12:54 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: >> Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path >> if they cannot be found in the new, "official" path. User setups were >> broken by the switch, which is bad. >> >> There are only 4

Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path if they cannot be found in the new, "official" path. User setups were broken by the switch, which is bad. There are only 4 firmware files we may want to look up that way, so hardcode them into the lookup function. All new firmware files should use the standard "nvidia/<chip>/gr/" path.

On 19 June 2015 at 00:47, Alexandre Courbot <gnurou at gmail.com> wrote: > NVIDIA will officially start providing signed firmwares through > linux-firmware. Change the GR firmware lookup function to look them up > in addition to the extracted firmwares. I wonder if perhaps we should just replace the mechanism entirely, and remove the support for nouveau/fuc* as we add

Here are a few small fixes for issues we found while implementing support for GM20B. The first two are specific to Tegra/GK20A, but the last 3 patches may have a broader (hopefully beneficial) effect. Note that the newly introduced gf100_gr_wait_idle() function on patch 5/5 is exported on purpose. GK20A and GM20B drivers will soon make use of it. Ben, since you seemed to like these changes, a

New version of the secure boot code that works with the blobs just merged into linux-firmware. Since the required Mesa patches are also merged, this set is the last piece of the puzzle to get out-of-the-box accelerated Maxwell 2. The basic code remains the same, with a few improvements with respect to how secure falcons are started. Hopefully the patchset is better split too. I have a

Hi there, Resending these now that they've had some more polish and testing, and I heard that Ben's vacation is over :-) These patches work as a starting point for more explicit error mechanisms and better robustness. At the moment, when a job hangs or faults, it seems that nouveau doesn't quite know how to handle the situation and often results in a hang. Some of these situations

Hello, This series exposes global performance counters (PCOUNTER) to the userspace through the nvif interface by reworking most of the code related to the PM engine. This interface will allow the userspace to control and monitor complex hardware events like the proprietary driver already does, for example with CUPTI and PerfKit. For now, this series only exposes performance counters on NV50,

From: Lauri Peltonen <lpeltonen at nvidia.com> Other methods in this file suggest this is the correct way to retrieve the engine pointer. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

This patchset centralizes the firmware-loading procedure to one set of functions instead of having each engine load its firmware as it pleases. This helps ensure that all firmware comes from the same place, namely nvidia/<chip>/. This changes where the firmware is fetched from for falcon/xtensa/bios, but these locations never seemed to have been official anyway. Also for most (all?) chips

Changes since v3: - Use a single dma_attr for all DMA-API allocations in instmem instead of one per allocation - Use device.info.ram_size instead of pfb->ram to check whether VRAM is present outside of nvkm Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into

Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to, and can trick

A series I have waited too long to submit, and the recent refactoring made me pay the price of my perfectionism, so here are the features that are at least completed Patches 1-3 make the presence of a RAM device optional, and remove GK20A's dummy RAM driver we were using so far. On chips using shared memory, such a device can confuse the driver into moving objects where there is no need to,

Thanks Ilia for the v2 review! Here is the v3 of this IOMMU support for GK20A series. Changes since v2: - Cleaner changes for ltc - Fixed typos in gk20a instmem IOMMU comments Changes since v1: - Add missing else condition in ltc - Remove extra flags that slipped into nouveau_display.c and nv84_fence.c. Original cover letter: Patches 1-3 make the presence of a RAM device optional, and remove

From: Deepak Goyal <dgoyal at nvidia.com> - Maps PMU firmware into PMU virtual memory. - Copy bootloader into PMU memory and start it. - Allow the PMU to interact with HOST via interrupts. PMU after successful configurations (to follow after this patch) will: 1.Autonomously power gate graphics engine when not in use.It will save us a lot of power. 2.Provide better way to scale frequencies

It adds PMU boot support.It loads PMU firmware into PMU falcon.RM/Kernel driver receives INIT ack (through interrupt mechanism) from PMU when PMU boots with success. Signed-off-by: Deepak Goyal <dgoyal at nvidia.com> --- drm/nouveau/include/nvkm/subdev/pmu.h | 26 +- drm/nouveau/nvkm/subdev/pmu/base.c | 108 ++ drm/nouveau/nvkm/subdev/pmu/gk20a.c | 2131

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous

This was the first step of the secure boot refactoring - as Ben asked for some fixes, I now submit it as its own series to make it easier to review (and also because rebasing secure boot on top of this takes time and I don't want to do it until this is validated!). This series attempts to factorize the duplicate falcon-related code into a single library, using the existing nvkm_falcon

On Fri, Nov 04, 2016 at 06:36:17PM +0900, Alexandre Courbot wrote: > Look for firmware files using the legacy ("nouveau/nvxx_fucxxxx") path > if they cannot be found in the new, "official" path. User setups were > broken by the switch, which is bad. > > There are only 4 firmware files we may want to look up that way, so > hardcode them into the lookup