similar to: Unavailable Resolutions and Falcon 4.0

Some firmware images may be large (64K), so using kmalloc memory is inappropriate for them. Use vmalloc instead, to avoid high-order allocation failures. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at vger.kernel.org --- Couldn't get video decoding started on a long-running system due to high-order allocation failures. This seems like a fine use-case for vmalloc.

Make the msgqueue_0148cdec_acr_func and msgqueue_0148cdec_func static to avoid the following sparse warnings: drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0148cdec.c:230:1: warning: symbol 'msgqueue_0148cdec_acr_func' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue_0148cdec.c:241:1: warning: symbol 'msgqueue_0148cdec_func' was not declared.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c b/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c index 816ccaedfc73..8675613e142b 100644 ---

From: Ilia Mirkin <imirkin at alum.mit.edu> [ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7

From: Ilia Mirkin <imirkin at alum.mit.edu> [ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7

From: Ilia Mirkin <imirkin at alum.mit.edu> [ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7

On Sat, Sep 27, 2014 at 3:19 AM, Andy Ritger <aritger at nvidia.com> wrote: > > Hi, all. Hey Andy, > > Below is a link to a brief document describing some changes in NVIDIA > Falcon processors ("fuc", in Nouveau-speak, IIUC) We started trying to use your names where we know them a while back. I personally think of "fuc" as short-hand for "falcon

From: Colin Ian King <colin.king at canonical.com> There are a few statements that are indented incorrectly. Fix these. Signed-off-by: Colin Ian King <colin.king at canonical.com> --- drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c

Hello Alexandre Courbot, This is a semi-automatic email about new static checker warnings. The patch 9b536e9d5251: "drm/nouveau/falcon: add msgqueue interface" from Jan 19, 2017, leads to the following Smatch complaint: drivers/gpu/drm/nouveau/nvkm/falcon/msgqueue.c:514 nvkm_msgqueue_recv() error: we previously assumed 'queue' could be null (see line 513)

Falcon processors are used in various places of GPU chips. Although there exist different versions of the falcon, and some variants exist, the base set of actions performed on them is the same, which results in lots of duplicated code. This patch consolidates the current nvkm_falcon structure and extends it with the following features: * Ability for an engine to obtain and later release a given

From: Thierry Reding <treding at nvidia.com> The low-level Falcon bootstrapping callbacks are expected to return 0 on success or a negative error code on failure. However, the implementation on Tegra returns the ID or mask of the Falcons that were bootstrapped on success, thus breaking the calling code, which treats this as failure. Fix this by making sure we only return 0 or a negative

Have an instance of nvkm_falcon in the PMU structure, ready to be used by other subdevs (i.e. secboot). Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/include/nvkm/subdev/pmu.h | 2 ++ drm/nouveau/nvkm/subdev/pmu/base.c | 4 ++++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drm/nouveau/include/nvkm/subdev/pmu.h

Hi all, I'd like to add Falcon, the Java JIT compiler we've been working on at Azul Systems for the last few years, to Users.html. I've attached a patch, please take a look. Thanks! -- Sanjoy -------------- next part -------------- A non-text attachment was scrubbed... Name: falcon.patch Type: application/octet-stream Size: 681 bytes Desc: not available URL:

So now I'm to looking to implement NVDec and as far as I know the game submits a series of commands to the service. This commands are processed by Falcon and then it does its magic. Do you guys got any RE on Falcon commands and how they execute different workloads ? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, all. Below is a link to a brief document describing some changes in NVIDIA Falcon processors ("fuc", in Nouveau-speak, IIUC) that happened in Maxwell: certain aspects of the chip will only be available to Falcon firmware images signed by NVIDIA. So far, the set of restricted things is pretty small, but I expect this list will slowly grow over future hardware generations.

https://bugs.freedesktop.org/show_bug.cgi?id=110931 Bug ID: 110931 Summary: Timeout initializing Falcon after cold boot Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee:

The IRQ mask of the PMU falcon was left - replace it with the proper irq_mask variable. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/secboot/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/secboot/base.c b/drm/nouveau/nvkm/subdev/secboot/base.c index b718ba79177c..05c62549c39b 100644 ---

Valeri Galtsev wrote: > > On Thu, June 30, 2016 2:59 pm, m.roth at 5-cent.us wrote: >> I've been googling, and haven't yet found the answer: does anyone here >> know if a MegaRAID SAS 2008 (falcon) (rev 03) can handle drives bigger >> than 2TB? > > One way to find out is to plug 4TB drive and take a look. Another is to > ask one who has the same controller

Make sure we are not disturbed by spurious interrupts, as we poll the halt bit anyway. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/subdev/secboot/gm200.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drm/nouveau/nvkm/subdev/secboot/gm200.c b/drm/nouveau/nvkm/subdev/secboot/gm200.c index 4932757ab1a2..5801babdf959 100644 ---

On Thu, June 30, 2016 2:59 pm, m.roth at 5-cent.us wrote: > I've been googling, and haven't yet found the answer: does anyone here > know if a MegaRAID SAS 2008 (falcon) (rev 03) can handle drives bigger > than 2TB? > One way to find out is to plug 4TB drive and take a look. Another is to ask one who has the same controller to do the same for you. I am going to play with