- Accept either 32-bit or 64-bit mappings for all devices.
- Let the device always dictate size of the mapping.
- Explain why we don't have a statically fixed mapping size.
Fixes the main part of PR kern/50060. Still a display mode issue
from one submitter, but it is almost certainly an unrelated issue.
I had assumed for ages this would increase the amount of caching and
thereby increase the chance of stale caches leading to rendering
glitches. But apparently I was wrong, and failing to pass these
through was causing all sorts of problems!
Linux never used to do this...until a month:
https://bugs.freedesktop.org/show_bug.cgi?id=88191
commit 983d308cb8f602d1920a8c40196eb2ab6cc07bd2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jan 26 10:47:10 2015 +0000
agp/intel: Serialise after GTT updates
This was split up so we could map the GTT prefetchable without
interfering with the MMIO registers, but it interferes with old drm
which tries to map the whole region and which is still hooked up for
the moment.
Once we unhook old drm for good we can put this back.
- Set mem->am_nseg, particularly before trying to use it.
- Avoid error-prone local copies in agp_i810_bind_memory_main.
- Omit missing DMA unload/free in agp_i810_unbind_memory.
Previously this read the MSAC register from the wrong PCI device.
Experiments reveal that even on the right PCI device, per the
datasheet, the GMADR BAR size is correct.
Not clear that the driver has any business reading any of these GMCH
registers to discern the aperture size -- seems to me they are meant
to be written by the BIOS to determine the GMADR BAR size. Lacking a
variety of hardware to test, though, I'll leave this as is for now...
Principal reason is that the GTT size is not necessarily the same as
the aperture size: the GPU may have a bigger virtual address space
than the CPU can see through the aperture.
While here, factor the code a little more legibly and name some magic
constants.
- Make struct agp_i810_softc::gatt specific to i810 chipsets; use other
members of struct agp_i810_softc for non-i810 chipsets.
- agp_i810_init detects and sets isc->gtt_size.
- Map GTT based on the GTT size detected by agp_i810_init.
- Sprinkle some comments particularly about questionable calculations.
- Fix up error branches in agp_i810_attach.
- Use a separate bus space handle for the GTT, whether it is in a
separate BAR or a subregion of the MMIO device registers, so that
(a) agp_i810_write_gtt_entry and agp_i810_post_gtt_entry are easier to
follow, and
(b) we can map the GTT prefetchable eventually.
While here, fix the use of the I915 PCI MSAC register: it lies on the
bridge device (bus 0 dev 0 func 0), not the graphics device (bus 0
dev 2 func 0). I'm not sure we ever need to consult this register,
really -- the PCI BARs should be sized. But I'll leave a rototill of
this mess for another day.
pci_find_rom(), pci_intr_map(9), pci_enumerate_bus(), nor the match
predicate passed to pciide_compat_intr_establish() should ever modify
their pci_attach_args argument, so make their pci_attach_args arguments
const and deal with the fallout throughout the kernel.
For the most part, these changes add a 'const' where there was no
'const' before, however, some drivers and MD code used to modify
pci_attach_args. Now those drivers either copy their pci_attach_args
and modify the copy, or refrain from modifying pci_attach_args:
Xen: according to Manuel Bouyer, writing to pci_attach_args in
pci_intr_map() was a leftover from Xen 2. Probably a bug. I
stopped writing it. I have not tested this change.
siside(4): sis_hostbr_match() needlessly wrote to pci_attach_args.
Probably a bug. I use a temporary variable. I have not tested this
change.
slide(4): sl82c105_chip_map() overwrote the caller's pci_attach_args.
Probably a bug. Use a local pci_attach_args. I have not tested
this change.
viaide(4): via_sata_chip_map() and via_sata_chip_map_new() overwrote the
caller's pci_attach_args. Probably a bug. Make a local copy of the
caller's pci_attach_args and modify the copy. I have not tested
this change.
While I'm here, make pci_mapreg_submap() static.
With these changes in place, I have tested the compilation of these
kernels:
alpha GENERIC
amd64 GENERIC XEN3_DOM0
arc GENERIC
atari HADES MILAN-PCIIDE
bebox GENERIC
cats GENERIC
cobalt GENERIC
evbarm-eb NSLU2
evbarm-el ADI_BRH ARMADILLO9 CP3100 GEMINI GEMINI_MASTER GEMINI_SLAVE GUMSTIX
HDL_G IMX31LITE INTEGRATOR IQ31244 IQ80310 IQ80321 IXDP425 IXM1200
KUROBOX_PRO LUBBOCK MARVELL_NAS NAPPI SHEEVAPLUG SMDK2800 TEAMASA_NPWR
TEAMASA_NPWR_FC TS7200 TWINTAIL ZAO425
evbmips-el AP30 DBAU1500 DBAU1550 MALTA MERAKI MTX-1 OMSAL400 RB153 WGT624V3
evbmips64-el XLSATX
evbppc EV64260 MPC8536DS MPC8548CDS OPENBLOCKS200 OPENBLOCKS266
OPENBLOCKS266_OPT P2020RDB PMPPC RB800 WALNUT
hp700 GENERIC
i386 ALL XEN3_DOM0 XEN3_DOMU
ibmnws GENERIC
macppc GENERIC
mvmeppc GENERIC
netwinder GENERIC
ofppc GENERIC
prep GENERIC
sandpoint GENERIC
sgimips GENERIC32_IP2x
sparc GENERIC_SUN4U KRUPS
sparc64 GENERIC
As of Sun Apr 3 15:26:26 CDT 2011, I could not compile these kernels
with or without my patches in place:
### evbmips-el GDIUM
nbmake: nbmake: don't know how to make /home/dyoung/pristine-nbsd/src/sys/arch/mips/mips/softintr.c. Stop
### evbarm-el MPCSA_GENERIC
src/sys/arch/evbarm/conf/MPCSA_GENERIC:318: ds1672rtc*: unknown device `ds1672rtc'
### ia64 GENERIC
/tmp/genassym.28085/assym.c: In function 'f111':
/tmp/genassym.28085/assym.c:67: error: invalid application of 'sizeof' to incomplete type 'struct pcb'
/tmp/genassym.28085/assym.c:76: error: dereferencing pointer to incomplete type
### sgimips GENERIC32_IP3x
crmfb.o: In function `crmfb_attach':
crmfb.c:(.text+0x2304): undefined reference to `ddc_read_edid'
crmfb.c:(.text+0x2304): relocation truncated to fit: R_MIPS_26 against `ddc_read_edid'
crmfb.c:(.text+0x234c): undefined reference to `edid_parse'
crmfb.c:(.text+0x234c): relocation truncated to fit: R_MIPS_26 against `edid_parse'
crmfb.c:(.text+0x2354): undefined reference to `edid_print'
crmfb.c:(.text+0x2354): relocation truncated to fit: R_MIPS_26 against `edid_print'
