similar to: [PATCH] drm/nouveau: Do not leak client objects

There's a short window between module load and fbcon initalization when it's possible for vgacon to write to VGA RAM. Nouveau uses this memory for different purposes, so if we are unlucky, it causes mysterious memory corruptions. For me, booting with nv_printk debug levels set to 5 was enough to trigger it. It manifested as long stream of: "trapped write at ... on channel 0x0001fea0

After a full device powerdown via the optimus power switch, we seem to lose the HDMI device completely on power on, this keep track of whether we had a hdmi audio sub function device at power on, and pokes a magic register to make it reappear after the optimus power switch is thrown. This at least works on my NVC4 machine, probably needs testing on a few other laptops with other nvidia GPUs.

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

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. > >

*RESEND* due to exceeding the mailinglists limit for attachment size. Hi, I''m trying to get secondary vga-passthrough on a HVM guest to work with a AMD HD6570 and the native kernel radeon driver and kernel modesetting. So the guest still gets the emulated stdvga or cirrus device(used in my case here) as primary/boot vga adapter. - When i don''t passthrough the radeon card, the

Op 24-07-13 09:13, Dave Airlie schreef: > After a full device powerdown via the optimus power switch, we seem > to lose the HDMI device completely on power on, this keep track of > whether we had a hdmi audio sub function device at power on, and > pokes a magic register to make it reappear after the optimus power > switch is thrown. > > This at least works on my NVC4 machine,

https://bugs.freedesktop.org/show_bug.cgi?id=58087 Priority: medium Bug ID: 58087 Assignee: nouveau at lists.freedesktop.org Summary: [-next] nouveau corrupts kernel mm allocator QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: peter at

Complete migration of nouveau_event_get/_put from add/remove semantics to enable/disable semantics. Introduce nouveau_event_handler_install/_remove interface to add/remove non-local-scope event handlers (ie., those stored in parent containers). This change in semantics makes explicit the handler lifetime, and distinguishes "one-of" event handlers (such as gpio) from "many

From: Markus Elfring <elfring at users.sourceforge.net> Date: Wed, 20 Jul 2016 19:43:27 +0200 The pci_dev_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring at users.sourceforge.net> ---

There was a proliferation of duplicated checks for runpm == -1 && optimus. Instead of continuing that tradition, get rid of all of them, only doing the optimus computation once on load. This should hopefully fix secondary cards suspending and then being unable to come back in non-optimus setups. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: <stable at

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()

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,

Latest patches for GK20A, taking comments received for v3 into account. Changes since v3: - use only pfn_to_page() and page_to_pfn() in GK20A's FB. These functions are present on every arch and the physical address to page frame number conversion is also consistently a shift of PAGE_SHIFT. This part will probably be replaced by something nicer in the future anyway. - fixed a warning on

Hi everyone, Way overdue v2 of the final patches that enable basic GK20A support. Hopefully all the issues raised with v1 have been addressed. Changes since v1: - Use gk20a clock driver by Ben instead of twiddling nv04's - Name new classes after gk20a instead of nvea - Addressed comments about BAR initialization code factorization - Removed non-essential code which only purpose was to avoid

https://bugs.freedesktop.org/show_bug.cgi?id=60007 Priority: medium Bug ID: 60007 Assignee: nouveau at lists.freedesktop.org Summary: BUG: nouveau crashes in various ways in 32-bits Fedora 18 QA Contact: xorg-team at lists.x.org Severity: critical Classification: Unclassified OS: Linux (All)

Changes since v2: - Enabled software class - Removed unneeded changes to nouveau_accel_init() - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with the portable page_to_phys()/phys_to_page() - Fixed incorrect comment/commit log talking about bytes instead of words Hope this looks good! Once this gets merged the next set will be to use this driver on Jetson and Venice2

This series was originally motivated by a deadlock, introduced in commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b 'drm/nouveau/disp: port vblank handling to event interface', due to inverted lock order between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() (the complete lockdep report is included in the patch 4/5 changelog). Because this series fixes the vblank event

nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check

[ Normally I'd have replied to the original email but I couldn't figure out a way to subscribe to a list, and then reply to an email already posted to the list.] I have this very problem (with a different card): http://lists.freebsd.org/pipermail/freebsd-stable/2009-April/049618.html It looks like drm_open_helper() gets a NULL dev parameter and a panic occurs when it attempts to set

Lockdep report [1] correctly identifies a potential deadlock between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due to inverted lock order of event->lock with drm core's dev->vblank_time_lock. Fix vblank event deadlock by converting event handler list to RCU. List updates remain serialized by event->lock. List traversal & handler execution is lockless which