search for: request_firmwar

...ame, + struct gf100_gr_fuc *fuc) +{ + struct nvkm_subdev *subdev = &gr->base.engine.subdev; + struct nvkm_device *device = subdev->device; + const struct firmware *fw; + char f[32]; + int ret; + + snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname); + ret = request_firmware(&fw, f, device->dev); + if (ret) { + snprintf(f, sizeof(f), "nouveau/%s", fwname); + ret = request_firmware(&fw, f, device->dev); + if (ret) { + nvkm_error(subdev, "failed to load %s\n", fwname); + return ret; + } + } + + fuc->size = fw->size; + fuc-...

...; >> + struct nvkm_device *device = subdev->device; >> + const struct firmware *fw; >> + char f[32]; >> + int ret; >> + >> + snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname); >> + ret = request_firmware(&fw, f, device->dev); >> + if (ret) { >> + snprintf(f, sizeof(f), "nouveau/%s", fwname); >> + ret = request_firmware(&fw, f, device->dev); >> + if (ret) { >> + nvkm_error(sub...

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

...nvkm_error(subdev, "failed to load %s\n", fwname); + return ret; + } + + /* yes, try to load from the legacy path */ + nvkm_debug(subdev, "%s: falling back to legacy path\n", fwname); + + snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname); + ret = request_firmware(&fw, f, device->dev); + if (ret) { + snprintf(f, sizeof(f), "nouveau/%s", fwname); + ret = request_firmware(&fw, f, device->dev); + if (ret) { + nvkm_error(subdev, "failed to load %s\n", fwname); + return ret; + } + } + + fuc->size = fw->size; + fuc-...

...ivers/gpu/drm/nouveau/core/engine/falcon.c +++ b/drivers/gpu/drm/nouveau/core/engine/falcon.c @@ -119,7 +119,7 @@ _nouveau_falcon_init(struct nouveau_object *object) snprintf(name, sizeof(name), "nouveau/nv%02x_fuc%03x", device->chipset, falcon->addr >> 12); - ret = request_firmware(&fw, name, &device->pdev->dev); + ret = request_firmware(&fw, name, nv_device_base(device)); if (ret == 0) { falcon->code.data = vmemdup(fw->data, fw->size); falcon->code.size = fw->size; @@ -138,7 +138,7 @@ _nouveau_falcon_init(struct nouveau_object *o...

...Kind regards, Peter > + return ret; > + } > + > + /* yes, try to load from the legacy path */ > + nvkm_debug(subdev, "%s: falling back to legacy path\n", fwname); > + > + snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname); > + ret = request_firmware(&fw, f, device->dev); > + if (ret) { > + snprintf(f, sizeof(f), "nouveau/%s", fwname); > + ret = request_firmware(&fw, f, device->dev); > + if (ret) { > + nvkm_error(subdev, "failed to load %s\n", fwname); > + return ret; > + } > +...

On 12/02/14 05:38, Alexandre Courbot wrote: > Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead > of PCI to which Nouveau is tightly dependent. This patch allows Nouveau > to handle platform devices by: > > - abstracting PCI-dependent functions that were typically used for > resource querying and page mapping, > - introducing a nv_device_is_pci()

...mp;gr->base.engine.subdev; > + struct nvkm_device *device = subdev->device; > + const struct firmware *fw; > + char f[32]; > + int ret; > + > + snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname); > + ret = request_firmware(&fw, f, device->dev); > + if (ret) { > + snprintf(f, sizeof(f), "nouveau/%s", fwname); > + ret = request_firmware(&fw, f, device->dev); > + if (ret) { > + nvkm_error(subdev, "failed to...

On Mon, Feb 10, 2014 at 8:50 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote: > [...] >> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c > [...] >> +resource_size_t >> +nv_device_resource_start(struct nouveau_device *device,

...t nvkm_device *device = subdev->device; >>> + const struct firmware *fw; >>> + char f[32]; >>> + int ret; >>> + >>> + snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname); >>> + ret = request_firmware(&fw, f, device->dev); >>> + if (ret) { >>> + snprintf(f, sizeof(f), "nouveau/%s", fwname); >>> + ret = request_firmware(&fw, f, device->dev); >>> + if (ret) { >>> +...

...ivers/gpu/drm/nouveau/core/engine/falcon.c +++ b/drivers/gpu/drm/nouveau/core/engine/falcon.c @@ -119,7 +119,7 @@ _nouveau_falcon_init(struct nouveau_object *object) snprintf(name, sizeof(name), "nouveau/nv%02x_fuc%03x", device->chipset, falcon->addr >> 12); - ret = request_firmware(&fw, name, &device->pdev->dev); + ret = request_firmware(&fw, name, nv_device_base(device)); if (ret == 0) { falcon->code.data = vmemdup(fw->data, fw->size); falcon->code.size = fw->size; @@ -138,7 +138,7 @@ _nouveau_falcon_init(struct nouveau_object *o...

...rmware file names in > the kernel for all cards. > > Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs, > card boot is initiated via the "state" sysfs entry. The host driver then > obtains the contents of the firmware and ramdisk via the standard > request_firmware(..) interface, copies the contents to card memory and > interrupts the card BIOS to initiate boot. So this is really a "filename" that might contain some directories as well, right? The fact you used "path" confused me, as that doesn't usually imply a filename. And is...

...rmware file names in > the kernel for all cards. > > Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs, > card boot is initiated via the "state" sysfs entry. The host driver then > obtains the contents of the firmware and ramdisk via the standard > request_firmware(..) interface, copies the contents to card memory and > interrupts the card BIOS to initiate boot. So this is really a "filename" that might contain some directories as well, right? The fact you used "path" confused me, as that doesn't usually imply a filename. And is...

On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote: > +What: /sys/class/mic/mic(x)/firmware > +Date: August 2013 > +KernelVersion: 3.11 > +Contact: Sudeep Dutt <sudeep.dutt at intel.com> > +Description: > + When read, this sysfs entry provides the path name under > + /lib/firmware/ where the firmware image to be booted on the > + card can be found. The

On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote: > +What: /sys/class/mic/mic(x)/firmware > +Date: August 2013 > +KernelVersion: 3.11 > +Contact: Sudeep Dutt <sudeep.dutt at intel.com> > +Description: > + When read, this sysfs entry provides the path name under > + /lib/firmware/ where the firmware image to be booted on the > + card can be found. The

...and then copy it in in init, due to some potentially bogus >> suspend/resume concerns. Also e.g. mplayer likes to create/destroy >> decoders at startup a few times. The downside is that ~200KB of >> memory is gone. Let me know if I should change it to do the >> request_firmware in init. >> >> There's obviously a userspace piece to this, which I'm still working >> on. But right now I have it working within certain parameters >> (e.g. 1280x544 videos), and I'm relatively confident it can be >> completed without further kernel-side...

...v_device(priv); > const struct firmware *fw; > - char f[32]; > - int ret; > + char f[64]; > + int ret = -EINVAL; > + int i; > > - snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname); > - ret = request_firmware(&fw, f, nv_device_base(device)); > - if (ret) { > - snprintf(f, sizeof(f), "nouveau/%s", fwname); > - ret = request_firmware(&fw, f, nv_device_base(device)); > - if (ret) { > - nv_error(priv, &qu...

...ad the fw into memory in the ctor, and then copy it in in init, due to some potentially bogus suspend/resume concerns. Also e.g. mplayer likes to create/destroy decoders at startup a few times. The downside is that ~200KB of memory is gone. Let me know if I should change it to do the request_firmware in init. There's obviously a userspace piece to this, which I'm still working on. But right now I have it working within certain parameters (e.g. 1280x544 videos), and I'm relatively confident it can be completed without further kernel-side changes. There's also a hypothetical co...

...the ctor, > and then copy it in in init, due to some potentially bogus > suspend/resume concerns. Also e.g. mplayer likes to create/destroy > decoders at startup a few times. The downside is that ~200KB of > memory is gone. Let me know if I should change it to do the > request_firmware in init. > > There's obviously a userspace piece to this, which I'm still working > on. But right now I have it working within certain parameters > (e.g. 1280x544 videos), and I'm relatively confident it can be > completed without further kernel-side changes. > > T...

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