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

[Stefan Reinauer]

* Aaron Durbin <adurbin at chromium.org> [130509 00:02]:
> >> > Am Mittwoch, den 08.05.2013, 08:18 -0500 schrieb Aaron Durbin:
> >> 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.

i945 and i5000 don't have a constant TSC but need to take the FSB
frequency into regard. Not sure about Mobile 4 series.
Sandybridge/Ivybridge/Haswell have a fixed frequency TSC.

> > 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.
> 
> The delay_tsc.c could be used as the basis for all of these
> implementations. I was confusing myself thinking each of these cpus
> had the implementation. Not the northbridge. Apparently the gm45 and
> i945 serve as the basis for all the memory controller for most of
> those cpus.
> 
> So the current intel northbridge chipsets with a delay implementation are:
> src/northbridge/intel/gm45
> src/northbridge/intel/i945
> src/northbridge/intel/sandybridge
 
> The gm45 and i945 use the Intel Core architecture with the quad pumped
> FSB. Uses msrs 0x198 and MSR_FSB_FREQ. Note that the gm45 has a
> ns100delay() function for raminit.  The gm45 uses delay.c for romstage
> as well as SMM while i945 just uses udelay.c for SMM.

The code originally went in on i945 and the reason was that certain
delay operations were required to not create any front side bus traffic
(interesting, huh?) or random corruption could happen. Of course it is
almost impossible to get to that information, and even telling you the
mere fact might force me into killing you.

Whether this was an issue with any other chipset / CPU after the i945
generation? I don't know. I am happy that haswell was cleaned up to not
have that mess. Sandybridge/Ivybridge should/could probably be cleaned
up as well.

> Sandybridge's udelay for romstage and smm can be converted like
> haswell. As for having a seemingly-duplicate copy of a file for
> determining tsc freq doesn't bother me all that much. It's small and
> self contained.

Sometimes components seem very similar. Duplicating code because it
happens to be similar hardware (but maybe not, in ways you will never
actually know) is not the worst thing that can happen. And if it allows
a clean API, we should not worry much. This is not the IOCC or contest
for the shortest program, but a matter of how to create a maintainable
code base that covers nearly 300 mainboards with a fast paced
development team that moves on to the next set of boards every couple of
months.

Stefan