search for: dgpus

...the right thing to do. I haven't seen any issues after that change, but > I'm also not exactly sure I understand what BAR2 is used for, so I don't > know if I would've even covered those code paths (other than the one > causing the crash at probe time) in my tests. BAR2 on dGPUs is used to map kernel-level GPU objects in VRAM so they can be accessed by the driver. It's pretty much a smaller version of BAR1, but intended for a different purpose. On dGPUs, there's a couple of places (fault buffer address, and fault method buffer on volta) where the GPU wants PRI re...

From: Thierry Reding <treding at nvidia.com> Hi Ben, I messed up the ordering of patches in my tree a bit, so these two fixes got separated from the others. I don't consider these particularily urgent because the crash that the first one fixes only happens on gp10b which we don't enable by default yet and the second patch fixes a crash that only happens on module unload (or driver

...on the dGPU in a hybrid laptop. > I guess another option is to just disable polling on hybrid laptops. If we don't know for sure, applying patch [5/5] would seem to be the safest approach. (Assuming it doesn't break anything else.) Right now runtime PM is only used on hybrid graphics dGPUs by nouveau, radeon and amdgpu. Would it be conceivable that its use is expanded beyond that in the future? E.g. on a desktop machine, if DPMS is off on all screens, why keep the GPU in D0? If that is conceivable, chances that analog connectors are present are higher, and then the patch would be...

On 3 September 2015 at 17:11, Alexandre Courbot <gnurou at gmail.com> wrote: > On Thu, Sep 3, 2015 at 4:08 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 3 September 2015 at 16:32, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Some devices may not have a PMU. Avoid a NULL pointer dereference in >>> such cases. >>> >>>

This patch is needed by initramfs tools to detect the required firmware files for the module. This patch tests for NOUVEAU_PLATFORM_DRIVER and either TEGRA_124_SOC or TEGRA_132_SOC for the firmwares related to the Tegra K1 generation. Signed-off-by: Nicolas Chauvet <kwizart at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff

On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner <lukas at wunner.de> wrote: > On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote: >> On 12 February 2018 at 03:39, Lukas Wunner <lukas at wunner.de> wrote: >> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote: >> > > I've not been able to reproduce the original problem you're

https://bugs.freedesktop.org/show_bug.cgi?id=100139 Bug ID: 100139 Summary: [DRI2][PRIME] nouveau driver cannot find any connected connector Product: Mesa Version: 10.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

Due to the lack of implicit synchronization between CPU and GPU on Tegra systems (like what PCI provides for dGPUs), the instmem implementation of GK20A/GM20B relied on the slow, legacy PRAMIN so that CPU accesses used the same path as GPU, making sure we see the same data on both ends. The recent Nouveau refactoring introduced acquire/release functions on instmem that help us understand the bounds of accesses...

There might be some callers of nouveau_clock_astate(), and they are from inetrrupt context. So we must ensure that this function can be atomic in that condition. This patch adds one parameter which is subsequently passed to nouveau_pstate_calc(). Therefore we can choose whether we want to wait for the pstate work's completion or not. Signed-off-by: Vince Hsu <vinceh at nvidia.com> ---

....com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default aperture (0) is correct. However, on Tegra the buffers are allocated in system memory, and since the GPU actually cares about the aperture, we need to ensure that the aperture field is written in all the necessary places. This series of patches do...

https://bugs.freedesktop.org/show_bug.cgi?id=75985 Priority: medium Bug ID: 75985 Assignee: nouveau at lists.freedesktop.org Summary: HDMI audio device only visible after rescan QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: jean-louis at