similar to: [PATCH v4] pmu/gk20a: PMU boot support

- Maps PMU firmware into PMU virtual memory. - Copy bootloader into PMU memory and start it. - Allow the PMU to interact with HOST via interrupts. PMU after successful configurations (to follow after this patch) will: 1.Autonomously power gate graphics engine when not in use.It will save us a lot of power. 2.Provide better way to scale frequencies by reporting Perf counters. 3.Be critical for GPU

It adds PMU boot support.It loads PMU firmware into PMU falcon.RM/Kernel driver receives INIT ack (through interrupt mechanism) from PMU when PMU boots with success. Signed-off-by: Deepak Goyal <dgoyal at nvidia.com> --- drm/nouveau/include/nvkm/subdev/pmu.h | 26 +- drm/nouveau/nvkm/subdev/pmu/base.c | 108 ++ drm/nouveau/nvkm/subdev/pmu/gk20a.c | 2131

On 13 April 2015 at 20:42, Alexandre Courbot <acourbot at nvidia.com> wrote: > Ben, I guess our main remaining concern with this patch is how it should > integrate wrt. the existing PMU code. Since it is designed to interact with > the NVIDIA firmware, maybe we should use a different base code, or do you > think we can somehow share code and data structures? Hey Alexandre, Sorry

Hi Deepak, There's... a lot of stuff going on here. Can you describe the goal of this patch (which could then be used as the patch commit message)? The current one basically boils down to "Add support for loading PMU", but merely loading the fw into a fuc engine is just a handful lines of code. Also, except in rare cases, it's customary to split up patches of this size into

Hi Mirkin, Your observations are quiet correct. After the boot code is submitted successfully, I will submit the code to configure & enable features of PMU.(This will be done by sending cmds to PMU). Now talking about this patch: Apart from just the boot code, I have also included some things in this patch that I can remove for now(I will include these things in later digestible chunks): -

Reclocking of NVAA/NVAC is substantially different from NV50+, enough to justify a separate clock implementation. This code is a forward-port of reclocking code that has been sitting in a branch for a while, and has been tested on my NVAC. Traces show no significant reasons why this shouldn't work on NVAA, but testers are always welcome. And since these are IGPs without dedicated RAM to

From: Martin Peres <martin.peres at labri.fr> This patchset is mostly about fixing fdo bug #66177, reported by Dash Four. This bug is about fan/temp management not working after a suspend/resume cycle. Fan/therm management relies on ptimer's alarm feature to call periodically multiple callbacks that poll the temperature and update the fan speed if needed. The problem is that there is

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

Following a series of patches that implement memory reclocking for NVA3/5/8 with DDR2, DDR3 and GDDR3 on board. I tested these patches on 6 different graphics cards, but I expect reclocking now to work on many more. Testers can pick up these patches and test it by enabling pstate (nouveau.pstate=1). They should then be able to change clocks by writing to /sys/class/drm/card0/device/pstate. Correct

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

Some very trivial comments below: On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add support for initializing the priv ring of GK20A. This is done by the > BIOS on desktop GPUs, but needs to be done by hand on Tegra. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/Makefile

The patches contain some tidy-up work, and refactoring that has arisen as a by-product of my initial work on adding TV support to nv50. Joel Holdsworth (4): drm/nouveau: Removed unneeded include in nvc0_fence.c drm/nouveau: Replaced magic numbers with defines from nouveau_reg drm/nouveau: Replaced copy-pasted nv_wait with nv50_wait_dpms_ctrl helper drm/nouveau: Refactored encoder

Hi, this is continuation for the MMIO accessor rewrite and cleanup. I am currently running nv28 with these patches applied, but I cannot test on PPC. Please, review and comment. If the direction is good, I'll do the same to INSTANCE_{RD,WR} as I did for nv_{rd,wr}32, and change PRAMIN from drm_local_map to simple ioremap. Can the same be done for channel specific mappings, that is

Patch 1 and 2 implement wait-for-vblank, required to remove flicker when reclocking memory Patch 3 and 4 allow me to do things between waiting for VBLANK and disabling FB, like pause PFIFO and wait for the engines to idle. This minimises the time PFIFO is paused, thus maximises performance. The rest of the patches speak for themselves. As the actual memory reclocking script is still somewhat prone

Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open

https://bugs.freedesktop.org/show_bug.cgi?id=87554 Bug ID: 87554 Summary: [NV1A] 3.19-rc1 NULL dereference on modprobe in pramin_fini Product: xorg Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component:

- In the current situation the padding that is added is dangerous to write to, userspace could potentially overwrite parts of another bo. - Depth and stencil buffers are supposed to be large enough in general so the waste of memory should be acceptable. - Alternatives are hiding the padding from users or splitting vram into 2 zones. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com>

Hi everyone, Here is the second batch of patches to add GK20A support to Nouveau. This time we are adding the actual chip support, and this series brings the driver to a point where a slightly-tweaked Mesa successfully runs shaders and renders triangles on GBM! Many thanks to Thierry Reding and the people on the #nouveau IRC channel for their help without which we would not have reached this

From: Martin Peres <martin.peres at labri.fr> This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: <stable at vger.kernel.org> # 3.9+ Reported-by:

This will fix races between generated ctxprogs and interrupt handler. Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv50_grctx.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_grctx.c b/drivers/gpu/drm/nouveau/nv50_grctx.c index d105fcd..9f909ab 100644 ---