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
ini
It simplifies nouveau code by removal of detection which
region to pass to kick vesafb/efifb.
Signed-off-by: Marcin Slusarz
Cc: Eric Anholt
Cc: Ben Skeggs
Cc: Thomas Hellstrom
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
---
drivers/gpu/drm/i915/intel_fb.c
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
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
---
drivers/video/fbmem.c | 24
Hi devs,
The first attached patch fixes the calculation of mipmapped 3D texture sizes
in the CS checker, the 3rd dimension (depth) should be minified too. This
should probably go to 2.6.34.
The second patch adds 2 new regs:
- VAP_ALT_NUM_VERTICES, along with an update to the CS checker.
- VAP_IND
I haven't been following this very closely, so apologies if I'm going
over established ground.
This patch appears to create new libraries from some subset of Mesa's
internals. At a guess you're selecting some internal interface(s)
within mesa to become the public API of those libraries? I'm pret
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
ini
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
Cc: Dave Airlie
Cc: Peter Jones
Cc: Andrew Morton
---
drivers/video/fbmem.c | 24
I haven't been following this very closely, so apologies if I'm going
over established ground.
This patch appears to create new libraries from some subset of Mesa's
internals. At a guess you're selecting some internal interface(s)
within mesa to become the public API of those libraries? I'm pret
Patch cherry-picked from my dri-sdk-7.8 branch against current head
(edb5253dfa). An earlier full build through of all drivers (except
nouveau, i will play with its expansive libdrm dependencies later)
showed it to be an exact match still.
This patch, while not harming or hampering anything or
