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

[Aaron Durbin]

On Wed, May 8, 2013 at 4:14 PM, Paul Menzel
<paulepanter at users.sourceforge.net> wrote:
> 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.

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.

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.

As for the gm45 and i945. You could make a
src/cpu/intel/tsc/core_arch_tsc_freq.c that uses the 0x198 and
MSR_FSB_FREQ msrs. It could be used for SMM in that case. The romstage
case for gm45 is obviously different because its constraints are 100ns
while udelay() is 1us.

So, there could be the following with a Kconfig option that both
implement tsc_freq_mhz().

src/cpu/intel/tsc/core_arch_tsc_freq.c
stc/cpu/intel/tsc/platform_info_tsc_freq.c

Does that help/make sense?

-Aaron