On Sat, Nov 24, 2018 at 5:39 PM Bin Meng <bmeng...@gmail.com> wrote:
> On Fri, Nov 23, 2018 at 5:13 PM Bernhard Messerklinger
> <bernhard.messerklin...@br-automation.com> wrote:
> > > APL means ApolloLake? Could you please spell it out?
> > I will fix this.
> > > > --- a/drivers/timer/tsc_timer.c
> > > > +++ b/drivers/timer/tsc_timer.c
> > > > @@ -64,6 +64,8 @@ static struct freq_desc freq_desc_tables[] = {
> > > > 80000, 93300, 90000, 88900, 87500 } },
> > > > /* Ivybridge */
> > > > { 6, 0x3a, 2, { 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
> > > > + /* Intel Atom processor E3900 series */
> > > > + { 6, 0x5c, 2, { 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
> > >
> > > Please avoid hardcoding TSC freq this way. Isn't calibrating from MSR
> > > not working for ApolloLake?
> > I found two ways to get the TSC freq.
> > 1. Read the necessary parameters with cpuid(instruction 15) like it is
> > done in
> > the kernel.
> > The problem with this way is that for some reason my core crystal clock is
> > always set to zero, so I would need to add the crystal frequency
> > somewhere.
> The TSC timer supports 3 ways of calibrating frequency:
> cpu_mhz_from_cpuid(), cpu_mhz_from_msr() and quick_pit_calibrate().
>
> Are you saying that if doing cpu_mhz_from_cpuid() you can't get
> correct frequency? Can you investigate why your core crystal clock is
> always zero?
Yes, this has to be investigated.
> Can we do it something like VLV2?
Please, don't. I see no evidence in the latest Linux kernel sources
that Apollo Lake has such issue as Intel MID family of Atom SoCs.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
