bf5ab950e3
allocation. Notably, in this case, the driver tries to allocate several pieces of memory and then fails if the pieces allocated after the first do not come after it physically, and within a specific range (8MB I believe). Of course, this could just as easily fail for any number of reasons, but it almost always fails now that contiguous allocations start at the end of possible specified memory locations rather than the beginning. Allocate all the possibly-needed memory up front, even though it's a waste, to get around this. The least bogus solution would be to take the physical address from the first allocation and create a new tag that specified that further allocations must follow it within that 8MB window, then use that when allocating new channels, but that's left for anyone else that really feels like doing it. Tested by: Erwin Lansing <erwin@lansing.dk> |
||
---|---|---|
.. | ||
als4000.c | ||
als4000.h | ||
au88x0.c | ||
au88x0.h | ||
aureal.c | ||
aureal.h | ||
cmi.c | ||
cmireg.h | ||
cs4281.c | ||
cs4281.h | ||
csa.c | ||
csapcm.c | ||
csareg.h | ||
csavar.h | ||
ds1-fw.h | ||
ds1.c | ||
ds1.h | ||
emu10k1.c | ||
es137x.c | ||
es137x.h | ||
fm801.c | ||
ich.c | ||
ich.h | ||
maestro3.c | ||
maestro_reg.h | ||
maestro.c | ||
neomagic-coeff.h | ||
neomagic.c | ||
neomagic.h | ||
solo.c | ||
t4dwave.c | ||
t4dwave.h | ||
via82c686.c | ||
via82c686.h | ||
via8233.c | ||
via8233.h | ||
vibes.c | ||
vibes.h |