similar to: [PATCH v2] gr: fallback to legacy paths during firmware lookup

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

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

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 firmware files we may want to look up that way, so > hardcode them

On 11/02/2016 03:52 PM, Alexandre Courbot wrote: > 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 >>>

Hello everyone, GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial support for it, based on a rework of the already-supported GK20A. It also introduces support for NVIDIA-provided firmware files, which is why I have added a few NVIDIA people who are relevant to this discussion. The first patch adds support for loading the FECS and GPCCS firmwares from firmware files

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

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

The following functions are not declared outside of the file they are in, so make them static to avoid these warnings: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:745:1: warning: symbol 'gf100_gr_fecs_start_ctxsw' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:760:1: warning: symbol 'gf100_gr_fecs_stop_ctxsw' was not declared. Should it be

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

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

The code would print a NULL string if no legacy firmware was found. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> Reported-by: Peter Wu <peter at lekensteyn.nl> --- Hi Ben, Sorry about the obvious mistake (and thanks Peter for reporting it!). You may want to squash this one into the previous patch if there still is time. drm/nouveau/nvkm/engine/gr/gf100.c | 7 ++----- 1

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 26/02/16 17:19, Karol Herbst wrote: > currently there is no change, because nobody uses those macros yet, but they > shouldn't stay broken > > Signed-off-by: Karol Herbst <nouveau at karolherbst.de> > --- > drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

Hi Alexandre, On 18 January 2016 at 06:07, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add two functions nvkm_firmware_get() and nvkm_firmware_put() to load a > firmware file and free its resources, respectively. Since firmware files > are becoming a necessity for new GPUs, and their location has been > standardized to nvidia/chip/, this will prevent duplicate and >

On 01/03/16 23:38, Ilia Mirkin wrote: > On Tue, Mar 1, 2016 at 4:36 PM, Martin Peres <martin.peres at free.fr> wrote: >> On 26/02/16 17:19, Karol Herbst wrote: >>> currently there is no change, because nobody uses those macros yet, but >>> they >>> shouldn't stay broken >>> >>> Signed-off-by: Karol Herbst <nouveau at

On Fri, Nov 30, 2018 at 5:30 PM Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> wrote: > > In order to comply with the CoC, replace **** with a hug. > > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen at linux.intel.com> > --- > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +- > drivers/gpu/drm/nouveau/nvkm/subdev/pmu/fuc/macros.fuc | 2 +- >

Signed-off by: Rosen Penev <rosenp at gmail.com> --- drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c b/drm/nouveau/nvkm/subdev/fb/ramgf100.c index 4a9bd4f1..feb8820c 100644 --- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c +++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c @@ -717,7 +717,7 @@

This is fixed in a different nouveau branch. from Ben Skeggs last I remember. On Fri, Dec 29, 2017 at 1:37 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > The typo is still present in master. > Not sure whether it will help you Ben, regarding Fermi reclocking, but it > shouldn’t harm in reducing possible errors. :-) > > Regards, > Pierre > > On 2017-07-27 —

fixes compilation issues with recent envytools, because movw was removed from fuc5, because it doesn't exist there anymore. The current code is most likely broken for fuc5 hardware as well and might have triggered all kinds of random memory reclocking fails. Changes in fuc3 binaries are tue do opcode optimizations using shorter opcodes when possible. Signed-off-by: Karol Herbst <kherbst