similar to: [PATCH] gr: fixup for legacy paths firmware lookup

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

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 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

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 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 >>>

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 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

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

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

Is this expected result for Chipset: G98 (NV98)? $ modinfo nvidia -F version 304.123 $ stat -c %s mmiotrace.log 134659197 $ file mmiotrace.log mmiotrace.log: ASCII text $ grep -i lost mmiotrace.log ; echo $? 1 $ ./envytools/rnn/demmio -f mmiotrace.log | perl -e 'open($fh409c, ">fuc409c"); open($fh409d, ">fuc409d"); open($fh41ac, ">fuc41ac");

On Tue, Dec 2, 2014 at 8:38 AM, poma <pomidorabelisima at gmail.com> wrote: > Is this expected result for Chipset: G98 (NV98)? Yep, 100% expected. [Perhaps you might glance at the wiki page you got that from for clues as to why.] > > $ modinfo nvidia -F version > 304.123 > > $ stat -c %s mmiotrace.log > 134659197 > > $ file mmiotrace.log > mmiotrace.log: ASCII

On 02.12.2014 14:40, Ilia Mirkin wrote: > On Tue, Dec 2, 2014 at 8:38 AM, poma <pomidorabelisima at gmail.com> wrote: >> Is this expected result for Chipset: G98 (NV98)? > > Yep, 100% expected. [Perhaps you might glance at the wiki page you got > that from for clues as to why.] > "You basically never need to do the mmiotrace, unless you're a nouveau

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

Any comments? I also think for developers, it's good to be able to see from someone's dmesg output whether or not external firmware was loaded. Unless there is some other way to do that without this log message? -- Dan On Sep 17, 2016, at 02:04 AM, Dan Moulding <dmoulding at me.com> wrote: In previous versions, it used to log an info message when loading external GR firmware. But

In previous versions, it used to log an info message when loading external GR firmware. But that info message was (inadvertently?) removed in commit 18cd5bc. This just adds it back. It's nice for users to be able to confirm whether external firmware was loaded or not. Signed-off-by: Dan Moulding <dmoulding at me.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 1 + 1 file

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

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: undo slight change to SKED stat handling, which would cause writes where there previously might not have been any. drm/nouveau/nvkm/engine/gr/gf100.c | 78 +++++++++++++++++++++++++++++++++----- 1 file changed, 69 insertions(+), 9 deletions(-) diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c

GR is similar to GP100, with a few unavailable registers. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/engine/gr.h | 1 + drm/nouveau/nvkm/engine/gr/Kbuild | 1 + drm/nouveau/nvkm/engine/gr/gf100.h | 4 +++ drm/nouveau/nvkm/engine/gr/gp100.c | 13 ++++++-- drm/nouveau/nvkm/engine/gr/gp102.c | 1 + drm/nouveau/nvkm/engine/gr/gp10b.c |

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/gr/gf100.c | 81 +++++++++++++++++++++++++++++++++----- 1 file changed, 71 insertions(+), 10 deletions(-) diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c b/drm/nouveau/nvkm/engine/gr/gf100.c index 414521b..794e249 100644 --- a/drm/nouveau/nvkm/engine/gr/gf100.c +++ b/drm/nouveau/nvkm/engine/gr/gf100.c @@

Hi, comments inline On 11/28/17 2:11 PM, Karol Herbst wrote: > Fixes secure boot on my gp107. No idea why. Otherwise the GPU enters > complete lockdown after starting the gpccs and fecs with the LS images > loaded. > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/nvkm/engine/gr/gf100.c | 7 +++++++ > 1 file changed, 7 insertions(+) >