On 10/17/2015 11:50 AM, Simon Glass wrote:
At present we add a new resource entry for every range entry. But some range
entries refer to configuration regions. To make this work, avoid adding two
regions of the same time. The later ranges will overwrite the earlier
(configuration) ones.
s/time/type/ in the last-but-one line.
What's wrong with having two regions of the same type? Equally, if we
can "get away" with not storing some of the regions that happen to have
a duplicate type, why not recast the function so that it only stores
regions of specific (useful/desired) types, and simply dropping all of
the other regions. That'd be a lot more consistent than only storing a
somewhat arbitrary subset of the regions.
There does not seem to be a way to distinguish the configuration ranges
other than by ordering.
Well, they do have different addresses too. But yes, the DT binding is
written so that the entries in ranges must appear in a specific order,
so order is the correct way to index the entries.
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
@@ -720,9 +721,15 @@ static int decode_regions(struct pci_controller *hose,
const void *blob,
} else {
continue;
}
- debug(" - type=%d\n", type);
- pci_set_region(hose->regions + hose->region_count++, pci_addr,
- addr, size, type);
+ pos = -1;
+ for (i = 0; i < hose->region_count; i++) {
+ if (hose->regions[i].flags == type)
+ pos = i;
and break too?
+ }
+ if (pos == -1)
+ pos = hose->region_count++;
+ debug(" - type=%d, pos=%d\n", type, pos);
+ pci_set_region(hose->regions + pos, pci_addr, addr, size, type);
}
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
