Searched hist:"60 d13d3b" (Results 1 – 4 of 4) sorted by relevance
| /openbsd/sys/dev/pci/ |
| H A D | agpvar.h | 60d13d3b Sat Jul 12 17:31:06 GMT 2008 oga <oga@openbsd.org> Right now agp_generic_enable() is wrong. It has been since 2006. It
assumes that the display device and the agp bridge are the same device.
In almost all cases this is incorrect.
In order to correctly enable the agp device with the correct mode, we
need to set the AGP_COMMAND register on both the display and the bridge
with the right bits. Since agp is currently attaching at vga(4), due to
the problems with the intel integrated graphics (a problem that I still
need to solve, to be honest), for now just provide both pci_attach_args
to the agp init, and get what we need from there to do the enable.
This fixes the "agp bug" which i have been known to rant about, a lot.
So agp radeons now work with dri without needing to be forced to pci
mode.
This wasn't detected before, since the only non-drm consumer of agp is
the intel X driver, the i810 agp driver has its own enable function.
tested by many. ok kettenis@.
|
| H A D | agp.c | 60d13d3b Sat Jul 12 17:31:06 GMT 2008 oga <oga@openbsd.org> Right now agp_generic_enable() is wrong. It has been since 2006. It
assumes that the display device and the agp bridge are the same device.
In almost all cases this is incorrect.
In order to correctly enable the agp device with the correct mode, we
need to set the AGP_COMMAND register on both the display and the bridge
with the right bits. Since agp is currently attaching at vga(4), due to
the problems with the intel integrated graphics (a problem that I still
need to solve, to be honest), for now just provide both pci_attach_args
to the agp init, and get what we need from there to do the enable.
This fixes the "agp bug" which i have been known to rant about, a lot.
So agp radeons now work with dri without needing to be forced to pci
mode.
This wasn't detected before, since the only non-drm consumer of agp is
the intel X driver, the i810 agp driver has its own enable function.
tested by many. ok kettenis@.
|
| H A D | vga_pci.c | 60d13d3b Sat Jul 12 17:31:06 GMT 2008 oga <oga@openbsd.org> Right now agp_generic_enable() is wrong. It has been since 2006. It
assumes that the display device and the agp bridge are the same device.
In almost all cases this is incorrect.
In order to correctly enable the agp device with the correct mode, we
need to set the AGP_COMMAND register on both the display and the bridge
with the right bits. Since agp is currently attaching at vga(4), due to
the problems with the intel integrated graphics (a problem that I still
need to solve, to be honest), for now just provide both pci_attach_args
to the agp init, and get what we need from there to do the enable.
This fixes the "agp bug" which i have been known to rant about, a lot.
So agp radeons now work with dri without needing to be forced to pci
mode.
This wasn't detected before, since the only non-drm consumer of agp is
the intel X driver, the i810 agp driver has its own enable function.
tested by many. ok kettenis@.
|
| H A D | agp_i810.c | 60d13d3b Sat Jul 12 17:31:06 GMT 2008 oga <oga@openbsd.org> Right now agp_generic_enable() is wrong. It has been since 2006. It
assumes that the display device and the agp bridge are the same device.
In almost all cases this is incorrect.
In order to correctly enable the agp device with the correct mode, we
need to set the AGP_COMMAND register on both the display and the bridge
with the right bits. Since agp is currently attaching at vga(4), due to
the problems with the intel integrated graphics (a problem that I still
need to solve, to be honest), for now just provide both pci_attach_args
to the agp init, and get what we need from there to do the enable.
This fixes the "agp bug" which i have been known to rant about, a lot.
So agp radeons now work with dri without needing to be forced to pci
mode.
This wasn't detected before, since the only non-drm consumer of agp is
the intel X driver, the i810 agp driver has its own enable function.
tested by many. ok kettenis@.
|