On Wed, May 8, 2013 at 8:50 AM, Paul Menzel <[email protected]> wrote: > Dear Aaron, > > > Am Mittwoch, den 08.05.2013, 08:18 -0500 schrieb Aaron Durbin: > >> I think what you'll find is that determining this is cpu specific. > > understood. > >> I'm fairly sure it's not worth trying to generalize it. The >> implementations are already associated with the chipset/cpu code. Why >> move them? > > Because there would be a lot of copies. 19 if I am not mistaken. > > $ ls src/cpu/intel/ > car model_65x model_f2x socket_mFCPGA478 > ep80579 model_67x model_f3x socket_mPGA478 > fit model_68x model_f4x socket_mPGA479M > haswell model_69x slot_1 socket_mPGA603 > hyperthreading model_6bx slot_2 socket_mPGA604 > Kconfig model_6dx socket_441 socket_PGA370 > Makefile.inc model_6ex socket_BGA956 socket_rPGA989 > microcode model_6fx socket_FC_PGA370 speedstep > model_1067x model_6xx socket_LGA771 thermal_monitoring > model_106cx model_f0x socket_LGA775 turbo > model_206ax model_f1x socket_mFCBGA479A989 > > I guess that is also the reason, why `udelay.c` was put into the > northbridge code beforehand?
The reason udelay was put in northbridge was for SMM if I am not mistaken. How similar are the implementations? > > For example the `udelay.c` in Sandy Bridge could use the `tsc_freq.c` > from Haswell. I know sandy/ivy and haswell are the same (they happen to use the same blck). But are all the other ones? And is it 19 copies of the *same* code? What you would be getting rid of is 19 copies of the udelay logic. Not necessarily the tsc frequency implementation. I was talking about the latter w.r.t. keeping that code (tsc freq) associated w/ the chipset/cpu. We can definitely cleanup the tsc udelay copies though. -Aaron -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
