similar to: Building Nouveau DRM for a recent kernel (linux-2.6.35-rc1)

fb_do_apertures_overlap is returning wrong value when one aperture is completely whithin the other. Add generic ranges_overlap macro (probably kernel.h candidate) and use it here. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc: Andrew Morton <akpm at linux-foundation.org> ---

It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com>

It simplifies nouveau code by removal of detection which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc:

On Mon, 02 June 2014 Bruno Pr?mont <bonbons at linux-vserver.org> wrote: > With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)") > Matthew Garrett introduced a efifb vga_default_device() so that EFI > systems that do not load shadow VBIOS or setup VGA get proper value for > boot_vga PCI sysfs attribute on the corresponding PCI device. > > Xorg

Hello! I have spent some time on the issue. I'm not sure it's a nouveau bug. I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only. GRUB actually uses graphic mode on my card. That mode is supported by simplefb. However, the resource conflict happens regardless of whether simplefb is enabled. It's sysfb_simplefb that causes it, a completely different driver. If GRUB

Subject: Obtain VESA capabilities and attributes of VESA mode Also, move some more common code to dom0_init_screen_info(). This was tested on 2.6.22.1, and only made apply to 2.6.18 without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-08-07/arch/i386/kernel/setup-xen.c =================================================================== ---

Hello! I'm getting this backtrace every time I boot: resource map sanity check conflict: 0xf0000000 0xf1ffffff 0xf1000000 0xf112bfff BOOTFB ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 at /home/proskin/src/linux/arch/x86/mm/ioremap.c:171 __ioremap_caller+0x372/0x380() Info: mapping multiple BARs. Your kernel is fine. Modules linked in: CPU: 6 PID: 1 Comm: swapper/0 Not tainted

From: Sui Jingfeng <suijingfeng at loongson.cn> This patch adds the aperture_contain_firmware_fb() function to do the determination. Unfortunately due to the fact that apertures list will be freed dynamically, the location and size information of the firmware fb will be lost after dedicated drivers call aperture_remove_conflicting_devices(), aperture_remove_conflicting_pci_devices() or

We don't want vga16fb to mess with hardware initialized by other driver. Detect it and refuse to load. It fixes nouveau interrupt storm on some machines. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/video/vga16fb.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c index

Linus' tree has a space-tab sequence for a few lines in these files, causing an unnecessary delta. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 7c753dbe7467f0d5ff6904f1bf5840350527e3c4 tree c40a68f6556a702a836d9a6e90f5d632eed0bc0c parent 0f5a324d655ad582246b6830843114d09835f593 author H. Peter Anvin <hpa at zytor.com> Thu, 06 Apr 2006 14:15:53 -0700 committer H.

ROOT_DEV carries a root device number communicated in an architecture- specific way. We now pass it to kinit via the real-root-dev sysctl call. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit 0f5a324d655ad582246b6830843114d09835f593 tree fd3a96a69b6d74ee33dcd54a58b8666c02139a3a parent f3e41698e540a7d39658d6590fde1379c0f5bab0 author H. Peter Anvin <hpa at zytor.com> Thu,

From: Sui Jingfeng <suijingfeng at loongson.cn> On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the

Currently vesafb/efifb/... is kicked when hardware driver is registering framebuffer. To do it hardware must be fully functional, so there's a short window between start of initialisation and framebuffer registration when two drivers touch the hardware. Unfortunately sometimes it breaks nouveau initialisation. Fix it by kicking firmware driver(s) before we start touching the hardware.

Hi all, these are the remaining unapplied patches of the ARM HDLCD patch series. Changes in v7: - rebased on b61ed421d2c85b5b106c63f2c14f8aa162b282f0; - turn more printk and panic into early_printk and early_panic. Changes in v6: - rebased on 77d3a1db3196b1b5864469f8d3f41d496800c795; - remove useless initializations to NULL in lfb_init; - more compact checks in lfb_init. Changes in v5: - move

Hi all, I'm terribly sorry that I cannot follow emails in my gmail inbox, since gmail is blocked by China govement, as many of you may have already known. I'm a HP employee in China and we are going through the splitting process, so the blade server I was using were packed up and should be moved into a new room. I will try the latest source if possible. Thank you very much for your works.

This set of patches adds the support for acceleration plugins to the netfront/netback drivers. These plugins are intended to support virtualisable network hardware that can be directly accessed from the guest, bypassing dom0. This is in response to the RFC we posted to xen-devel with an outline of our approach at the end of September. To follow will be another set of patches to provide our

Hi David, On Thu, 3 Oct 2013 00:19:56 +0200 David Herrmann <dh.herrmann at gmail.com> wrote: > >> And your PCI-BAR adjustment doesn't change > >> anything either, sorry. > > > > I simply tried another approach to pacify the resource checker. > > > > However, there is some difference. nvidiafb cannot access the > > resources if

This allows other boot loaders such as the Xen domain builder the opportunity to extract the ELF file. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: virtualization@lists.linux-foundation.org ---

This allows other boot loaders such as the Xen domain builder the opportunity to extract the ELF file. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: virtualization@lists.linux-foundation.org ---

This allows other boot loaders such as the Xen domain builder the opportunity to extract the ELF file. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: virtualization@lists.linux-foundation.org ---