[coreboot] IORESOURCE_UMA_FB question

[Aaron Durbin]

On Wed, Mar 20, 2013 at 1:10 AM, Kyösti Mälkki <kyosti.malkki at gmail.com> wrote:
> On Tue, 2013-03-19 at 23:16 -0500, Aaron Durbin wrote:
>> Hi corebooters,
>>
>> I'm trying to understand the reason for the existence of
>> IORESOURCE_UMA_FB. Is this to allow one to carve out an uncacheable
>> MTRR region for the UMA framebuffer? If so, why was that ram added as
>> cacheable to begin with?
>>
>> Thanks for the help. Full disclosure: I'd like to get rid of it and
>> handle these concepts in a different manner.
>>
>> -Aaron
>>
>
> Hi Aaron
>
> Reasons are in the poor implementation of variable MTRRs and choice of
> defined IORESOURCE flags.
>
> Variable MTRR routine causes excessive use of MTRRs when the cacheable
> resources do not add to powers of 2. Try describing 3 GiB - 128 MiB
> cacheable memory, and current variable MTRR routines might use 5 MTRRs
> for that (2048+1024+512+256+128 MiB).

Understood. That 128MiB aligned UMA area met the 64MiB alignment
minimum in the current code which led to sub-optimal variable MTRR
usage.  If I understand correctly, the only way for this scheme to
work is to include 1 large resource as IORESOURCE_CACHEABLE and have a
smaller IORESOURCE_UMA_FB resource. Correct?

>
> I did quite a few changes on this topic last summer to fix issues with
> AMD boards with 4GB or more RAM. I believe I received enough change
> resistance to not touch MTRR further.

I'm not sure what 4GiB or more of RAM has to do w/ the non-optimal
variable MTRR usage. However, I've run into this very issue recently
(use too many MTRRs). Why wasn't a more suitable IO hole used? i.e.
largest memory address below 4GiB is 2^N + UMA memory size. Were you
then getting bit on the upper end (cacheable area above 4GiB) ?

>
> Also see: http://review.coreboot.org/#/c/1431

Thanks for the context. I'm looking into removing
IORESOURCE_IGNORE_MTRR as that is the wrong layer to deal with OS
reserved address space. However, I wanted to properly handle the
UMA_FB type as well. Longer term, I think we can get rid of UMA_FB
too, but that will require a smarter MTRR algorithm.

Thanks again.

-Aaron