Hi Simon,
On 08/01/12 09:33, Simon Glass wrote:
Hi Andreas,
On Wed, Dec 28, 2011 at 11:47 PM, Andreas Bießmann andreas.devel@googlemail.com wrote:
Dear Simon,
On 28.12.11 07:35, Simon Glass wrote:
We want to unify the global_data structure. Most fields are common across architectures, but there are a fair number of SOC-specific additions. It isn't clear how best to deal with these, but for now we just use #ifdef.
Sorry your email got a little buried this week.
I would like to see some more 'clustering' here. Especially the timer stuff is implementation specific and should therefore not coded directly but with some pointer to the specific stuff i.e. introduce some timer_t which is specific for arm in general and maybe has some more specialization for atmel devices or what else and just save a pointer to that struct in gd_t like it is done with bd_t.
Actually I wonder if we should an architecture-specific structure, something like
struct global_data { /* generic things first */ ulong baud_rate; ulong ram_size; /* hopefully lots of other things that are mostly common */
/* architecture-specific things */ struct arch_global_data arch; };
This makes auto-generated asm offsets a little trickier I think
struct arch_global_data can be defined in include/asm/global_data.h before it includes include/asm-generic/global_data.h, or the other way around might be better.
include/asm-generic/global_data.h would include include/asm/global_data.h
But what of the corner case that an arch has no specific global data?
One thing I notice is that some architectures share some fields, and others omit them.I feel we should include them at the global level if at least 2 architectures need them. This means that the 'minimal' architectures with hardly any fields will have quite a few unused fields in global_data. I don't think that matters, and the use will
I would not bank on that, and I think you will get strong objection from Wolfgang if you try to litter global data with members that are not strictly necessary
increase as that arch gets more functionality.
Well maybe having a pointer here is stated critical so we could just insert the struct directly and let the compiler decide about the size (BTW this could be done with bd_t now too cause we have a pre-calculated size of gd_t since some time, saves some little steps when instantiating gd_t when running).
Yes I agree that just including the structure seems better. A pointer is slower and we just point to a place very close anyway.
Not so fast - The idea is that gd is writeable pre-relocation and therefore can be instantiated in the very limit pre-SDRAM environment such as the CPU cache. bd is not needed until after SDRAM has been initialised, so it's size constraints aren't so bad.
It would be nice to subsume bd_t into global_data.
NAK
Beside that we could also introduce some more structs holding specific stuff i.e. console_t, reloc_t, ... (but yes, it should be done in a second step ...)
What do you think about that?
Certainly agree for reloc and perhaps there are other cases too. It is far too long at present. Something to think about.
I agree that gd could be cleaned up - particularly the types - sub-structuring it is probably a bit over the top though (as I mentioned, how will this impact asm-offsets?
For now I would prefer to do nothing on either point, since bringing everything into one place shows up the conflicts and similarities. Part of the purpose of the generic board effort is to minimise these, and they are hard to spot if they are all in separate files.
Hmm, I'm starting to wonder if we should instead have:
struct gd_generic { /* Relocation stuff */
/* pre-console stuff */
/* Jump table stuff */ }
struct gd { struct gd_generic common;
/* Arch specific stuff */ }
This eliminates the 'no arch specific global data' corner case
But when we get through this, and find that there are things which genuinely are specific to a single arch, then I think breaking them out is reasonable, hopefully combined with joining global_data and bd_t.
Regards,
Graeme