[coreboot] Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`

Paul Menzel paulepanter at users.sourceforge.net
Wed May 8 23:12:04 CEST 2013


Am Mittwoch, den 08.05.2013, 09:07 -0500 schrieb Aaron Durbin:
> On Wed, May 8, 2013 at 8:50 AM, Paul Menzel wrote:

> > 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?

Of `udelay.c`? Besides the register differences it is the same. Sandy
Bridge (and Haswell) define `fsb` to 100 MHz, where i945 and i5000 use
400 MHz and divide it by four later on.

> > 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?

As no code has been written yet, I do not know. But judging from the
three `udelay.c` files I looked at, they should be.

> 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.

I am still wondering why originally four `udelay.c` were enough and now
it has to be done for each CPU model. I think a lot of the CPU models
are similar in the TSC regard.

Not sure, what I am missing.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130508/12118889/attachment.sig>


More information about the coreboot mailing list