From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sun, 08 Jan 2012 21:48:22 +1100 Subject: [U-Boot] [RFC PATCH 01/19] Introduce generic global_data In-Reply-To: References: <1325054160-24894-1-git-send-email-sjg@chromium.org> <1325054160-24894-2-git-send-email-sjg@chromium.org> <4EFC1B02.1070607@googlemail.com> Message-ID: <4F097476.9090803@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > 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