Same conversion as with resources from static arrays to lists, except there is no free list.
Converting resource arrays to lists reduced the size of each device struct from 1092 to 228 bytes. Converting link arrays to lists reduced the size of each device struct from 228 to 68 bytes.
fam10_pci.diff makes fam10 and k8 northbridge code a little more similar before the conversion.
The next step for fam10 and k8 would be to reorganize the links so that the southbridge link is always first. This would make some of the code a lot easier to follow. Something to consider would be adding link numbers to the device tree, since that would allow the southbridge link to start in the correct place.
Signed-off-by: Myles Watson mylesgw@gmail.com
Abuild tested. Boot tested on serengeti_cheetah, serengeti_cheetah_fam10, and qemu.
Thanks, Myles
On Wed, Jun 9, 2010 at 8:57 AM, Myles Watson mylesgw@gmail.com wrote:
Same conversion as with resources from static arrays to lists, except there is no free list.
Converting resource arrays to lists reduced the size of each device struct from 1092 to 228 bytes. Converting link arrays to lists reduced the size of each device struct from 228 to 68 bytes.
fam10_pci.diff makes fam10 and k8 northbridge code a little more similar before the conversion.
The next step for fam10 and k8 would be to reorganize the links so that the southbridge link is always first. This would make some of the code a lot easier to follow. Something to consider would be adding link numbers to the device tree, since that would allow the southbridge link to start in the correct place.
Signed-off-by: Myles Watson mylesgw@gmail.com
Removed some warnings and fixed static.c generation when the southbridge link is not 0.
Thanks, Myles
On 6/9/10 11:49 PM, Myles Watson wrote:
Signed-off-by: Myles Watson mylesgw@gmail.com
Removed some warnings and fixed static.c generation when the southbridge link is not 0.
I didn't test this, but assuming we're not planning on getting rid of malloc anymore, this is
Acked-by: Stefan Reinauer stepan@coresystems.de
On Wed, Jun 9, 2010 at 4:14 PM, Stefan Reinauer stepan@coresystems.de wrote:
On 6/9/10 11:49 PM, Myles Watson wrote:
Signed-off-by: Myles Watson mylesgw@gmail.com
Removed some warnings and fixed static.c generation when the southbridge link is not 0.
I didn't test this, but assuming we're not planning on getting rid of malloc anymore, this is
I'm willing to listen more before committing. I remember you brought up getting rid of malloc, but I don't see how you can get away from it. Are you suggesting a static global pool of resources and lists that devices can use? Am I totally missing your point?
Thanks, Myles
On 6/10/10 12:27 AM, Myles Watson wrote:
On Wed, Jun 9, 2010 at 4:14 PM, Stefan Reinauer stepan@coresystems.de wrote:
On 6/9/10 11:49 PM, Myles Watson wrote:
Signed-off-by: Myles Watson mylesgw@gmail.com
Removed some warnings and fixed static.c generation when the southbridge link is not 0.
I didn't test this, but assuming we're not planning on getting rid of malloc anymore, this is
I'm willing to listen more before committing. I remember you brought up getting rid of malloc, but I don't see how you can get away from it. Are you suggesting a static global pool of resources and lists that devices can use? Am I totally missing your point?
I believe it was easy when a device was just a fixed size huge array, but the more dynamic this gets it becomes more complex. We'd indeed need a fixed number of every "dynamic" data structure we have. Which makes little sense when we're looking into making coreboot use less memory and be more flexible. So I believe keeping malloc and having 68byte sized devices is better than dropping malloc and having 1KB big devices.
Stefan
getting rid of malloc was a beautiful theory that was killed by a brutal gang of facts.
Don't you just hate it when that happens :-)
ron
On Wed, Jun 9, 2010 at 4:14 PM, Stefan Reinauer stepan@coresystems.de wrote:
On 6/9/10 11:49 PM, Myles Watson wrote:
Signed-off-by: Myles Watson mylesgw@gmail.com
Removed some warnings and fixed static.c generation when the southbridge link is not 0.
I didn't test this, but assuming we're not planning on getting rid of malloc anymore, this is
Acked-by: Stefan Reinauer stepan@coresystems.de
Rev 5626
Thanks, Myles