similar to: [PATCH] drm/nouveau/xtensa: firmware size needs to be 0x40000 no matter what

On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These chipsets include the VP2 engine which is composed of a bitstream > processor (BSP) that decodes H.264 and a video processor (VP) which can > do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are > driven by separate xtensa chips embedded in the hardware. This patch > provides the

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

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

Can you give me some insights to implement the windowed calling convention in this xtensa backend : https://github.com/afonso360/llvm-xtensa/tree/xtensa/lib/Target/Xtensa ? For now, only the simpler CALL0 calling convention is implemented. In order to implement the windowed calling convention, every routines must start with the ENTRY instruction which increments the register window pointer. Do

Hello, I'm from Espressif Systems company, software department. Our company develops processors based on Xtensa architecture like ESP32 and ESP8266. We propose the integration of a backend targeting Xtensa architecture. We started to develop LLVM Xtensa backend almost a year ago. The reason was that we saw a demand from our large developers community. Currently only GNU compiler supports

Hello, James, Thank you very much for your advices! The next step in compiler development on Espressif is object file generation. There are no essential problems with this step, it will be implemented in nearest future. Currently Xtensa backend is able to print and parse assembly, I used about 1300 tests from gcc torture testsuite and GNU binutils to debug assembly output and now all tests

Hello, I am kernel engineer working on PV-OPS kernel trying to get it work in Dom0 with an NVidia (NV30 right now) card. But there are issues, such as that the pv-ops kernel has a different understanding of memory (for details check out: http://wiki.xensource.com/xenwiki/XenPVOPSDRM). I've fleshed out most of them (like GART had the wrong phys addresses, ouch!), but the one that I am

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() function that allows to make PCI-dependent code conditional, - providing a

On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Hey, > > Op 04-06-13 20:38, Ilia Mirkin schreef: >> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>> These chipsets include the VP2 engine which is composed of a bitstream >>> processor (BSP) that decodes H.264 and a video

All the video decoding firmware was *pretty* standard... I suspect ~everyone used my extraction script and it's sitting in /lib/firmware/nouveau for everyone who uses VDPAU. There are packages in several distributions which grab the nvidia blob, my script, and run the extraction on the end user's computer to avoid licensing complications. Please support the existing locations. Thanks,

Hey, Op 04-06-13 20:38, Ilia Mirkin schreef: > On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> These chipsets include the VP2 engine which is composed of a bitstream >> processor (BSP) that decodes H.264 and a video processor (VP) which can >> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are >> driven by separate

http://bugs.freedesktop.org/show_bug.cgi?id=11868 Summary: Starting X for the second time fails (without reloading drm modules) Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

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

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 101

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 115

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

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() function that allows to make PCI-dependent code conditional, - providing a

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

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