Patchwork pci resource allocation overlaps config_mmconf_base_address

login
register
about
Submitter Myles Watson
Date 2010-10-18 19:47:19
Message ID <AANLkTin=mUjYZsz+dYKMiajxcZMrQnVp2owa7xHTXzeQ@mail.gmail.com>
Download mbox | patch
Permalink /patch/2139/
State New
Headers show

Comments

Myles Watson - 2010-10-18 19:47:19
On Mon, Oct 18, 2010 at 1:11 PM, Arne Georg Gleditsch
<arne.gleditsch@numascale.com> wrote:
> Myles Watson <mylesgw@gmail.com> writes:
>> On Mon, Oct 18, 2010 at 6:48 AM, Arne Georg Gleditsch
>> <arne.gleditsch@numascale.com> wrote:
>>> On a similar note: I'm looking at a southbridge that has its own notion
>>> of what constitutes TOP_OF_DRAM.  Apparently, the IOMMU aperture needs
>>> to be below this boundary, or DMA transactions towards the aperture are
>>> terminated with master abort.  From the CPU's side, though, the IOMMU
>>> aperture should be above TOP_OF_MEM, in order to avoid wasting the DRAM
>>> behind it, no?  So, as well as being able to allocate posted and
>>> non-posted memory resources in separate hunks: in this instance it would
>>> be good to be able to allocate the GART aperture in a third hunk that
>>> was placed below the other two, so that the SB TOM register could be
>>> programmed to include it when needed.
>>>
>>> Is this feasible, or should I approach this from a different angle?
>>
>> It sounds like overkill to include this as a special case for the
>> resource allocator.  At first glance, the code would seem to be very
>> simple for that register.  Is this a one-time, one-resource problem?
>> Are there other hunks that need to be allocated together with it?
>
> I'm not aware of any others, so arranging for a full "resource group"
> might be overkill.  But as for very simple, I'm afraid I don't really
> see it.  To be clear, I'm talking about the GART aperture that's
> allocated in
> src/northbridge/amd/amdfam10/misc_control.c:mcf3_read_resources.
Thanks for the clarification.  I misunderstood and spoke too quickly.

> What
> would be the easy way to make sure this resource is allocated at the
> lowest possible address in the IO hole (for this board)?

I guess I'm not sure.  It seems like you'll create a hole any way you do it...

By create a hole, I mean that since the resource allocator starts with
the largest areas and allocates until it reaches the smallest, trying
to put a resource that isn't the largest at the bottom will cause
larger ones to be shifted (leaving a gap) so that they can still be
aligned correctly.

Maybe the easiest thing to do is to make the GART aperture look like
the largest resource to the resource allocator, so that it gets
allocated first.  As long as you correctly store the resource, it
shouldn't break anything.

I've attached a patch to do it.  The size I picked was too large, but
I thought the patch would probably communicate the idea better than my
email.

Thanks,
Myles

Patch

Index: src/northbridge/amd/amdfam10/misc_control.c
===================================================================
--- src/northbridge/amd/amdfam10/misc_control.c	(revision 5923)
+++ src/northbridge/amd/amdfam10/misc_control.c	(working copy)
@@ -68,7 +68,7 @@ 
 	if (iommu) {
 		/* Add a Gart apeture resource */
 		resource = new_resource(dev, 0x94);
-		resource->size = iommu?CONFIG_AGP_APERTURE_SIZE:1;
+		resource->size = 0x10000000; /* 256MB */
 		resource->align = log2(resource->size);
 		resource->gran  = log2(resource->size);
 		resource->limit = 0xffffffff; /* 4G */
@@ -88,6 +88,10 @@ 
 		/* Remember this resource has been stored */
 		resource->flags |= IORESOURCE_STORED;
 
+		resource->size = CONFIG_AGP_APERTURE_SIZE;
+		resource->align = log2(resource->size);
+		resource->gran  = log2(resource->size);
+
 		/* Find the size of the GART aperture */
 		gart_acr = (0<<6)|(0<<5)|(0<<4)|((resource->gran - 25) << 1)|(0<<0);