Averatec 6240 pcmcia_socket0: unable to apply power

[Linus Torvalds]

On Thu, 8 Sep 2005, Daniel Ritz wrote:
>
> something like the attached patch...
> 
> cc:ing linus as he is the one that added the "find the largest gap" code
> that comes handy here...

You've got typos there ("rounded up to a multiple of 6 MB" - it should be 
64). Also, I really think you'd be much better off keeping the old gap 
code, and rounding _later_.

The "round later" approach allows you to look at the size of the gap, and
use that to decide whether to round or not. That's what the question in
the comment is talking about, how we "now have the technology" for it.

Also, while it's wonderful to round up in general, there really would be
an advantage to have a gap _offset_ too: it's safer than rounding up to a
big area, if only because it might help against people doing prefetches
etc offset off the last few pages of RAM and into a PCI mapping..

So I'd really prefer to see the gap-finding remain the same, and 
then have just the pci_mem_start calculations be something like

	/*
	 * See how much we want to round up: start off with
	 * rounding to the next 1MB area.
	 */
	round = 0x100000;
	while ((gapsize >> 4) > round)
		round += round;
	/* Fun with two's complement */
	pci_mem_start = (gapstart + round) & -round;

which will not really "round up" but actually "gap up" (ie it's guaranteed
to leave a gap) to the next power-of-two, where we select the rounding 
size depending on how much space we have in the gap.

The above should result in a "rounding gap" of 64MB if the real gap is 
1GB..

The other alternative is to make PCI allocations generally start at the
high range of the allowable - judging by the lspci listings I've seem from
people under Windows, that seems to be what Windows does, which might be a
good idea (ie the closer we match windows allocation patterns, the more
likely we're to not hit some unmarked region - because windows testing
would have hit it too).

Hmm?

		Linus