Aye, I had that in mind -- a hook from the resource allocator. Ugly I
know. Perhaps it is less ugly if the MTRR driver maintains a "best
effort" list, and it's job is to program the CPU as best it can at any
time to satisfy the list. If resource allocations change, that changes
the MTRR programming.
> Definately not something I'd want in the MTRR driver. But a support
> function would be OK.
>
> Still, it might be easier to change vesafb instead.
I don't see how vesafb can do this without doing exactly what you
wrote. vesafb cannot assume it has a PCI region. It cannot assume
power of 2 alignment.
So vesafb would have to scan the resource tree looking for a parent
region. And then how can it be sure the remaining 1.5MB of resource
isn't allocated? Hook the tree so the MTRR is removed if the parent
region is allocated, or allocate the extra portion (may not be safe).
But the real point is: should vesafb be making assumptions about MTRR
alignment requirements? That may change with another CPU, so I think it
is the responsibility of the MTRR driver.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/