On Thursday, August 18, 2011 13:01:56 Marek Vasut wrote: > On Thursday, August 18, 2011 04:31:09 PM Mike Frysinger wrote: > > On Thursday, August 18, 2011 06:07:06 Marek Vasut wrote: > > > On Tuesday, August 16, 2011 08:03:54 PM Mike Frysinger wrote: > > > > On Monday, August 15, 2011 05:09:42 Valentin Longchamp wrote: > > > > > On 08/14/2011 09:07 PM, Mike Frysinger wrote: > > > > > > On Wednesday, August 03, 2011 08:37:00 Valentin Longchamp wrote: > > > > > >> --- a/include/post.h > > > > > >> +++ b/include/post.h > > > > > >> > > > > > >> +/* > > > > > >> + * some ARM implementations have to use gd->ram_size, since > > > > > >> POST_WORD is + * defined in RAM > > > > > >> + */ > > > > > >> +DECLARE_GLOBAL_DATA_PTR; > > > > > > > > > > > > i'm not sure about this. no other header has been allowed to do > > > > > > this in the past, and i dont think we should start now. > > > > > > > > > > OK. Then we should move the post_word_load and post_word_store > > > > > function to post/post.c. Would this be accepted ? > > > > > > > > that would add overhead that most people dont need. i guess the only > > > > other option would be to add a CONFIG_POST_EXTERNAL_WORD_FUNCS and > > > > then post.h would just define the two funcs as externs. it'd be up > > > > to the board porters to define them however they want. > > > > > > We don't want externs. Why would moving it into post.c introduce any > > > overhead ? > > > > because the current code expands into a single memory read/write for many > > arches. moving it into post.c already means making it into an extern and > > now people have to call an external function instead of inlining the > > memory access. > > I don't think I follow you here ... why won't you be able to inline that > stuff if it's in post.c ?
grep the tree. post.c isnt the only consumer of these funcs. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
