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

[Paul Menzel]

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?

For example the `udelay.c` in Sandy Bridge could use the `tsc_freq.c`
from Haswell.

Thanks,

Paul

Intel: How to share `tsc_freq.c` to select `UDELAY_TSC`

[Aaron Durbin]

On Wed, May 8, 2013 at 8:50 AM, Paul Menzel
 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