RE: [PATCH 3/8] x86/apic: allow use of lapic timer earlycalibration result

[Pan, Jacob jun]

> 
> We do not have access to the clocksource at that point. But we do a
> calibration loop for TSC and for lapic timer. There is no reason why
> we can't do that in one go.
> 
I have a simple patch that uses HPET to calibrate both tsc and lapic timers in one
loop in native_calibrate_tsc(). Will send out for RFC.

The question I have is the reference clock used for calibrating those local timers,
PIT, HPET, PM timer how should they be ranked. Can we make those known freq
clocksource devices available at this point so that we can use the clocksource
abstraction and its ranking automatically?


> > > Aside of my general objection it'd be not a good idea to make this
> > > global w/o renaming it to something sensible like
> > > lapic_timer_frequency.
> > >
> > perhaps, the calibration data can directly be assigned to lapic timer
> > clock_event_device.mult? There is no need for the device specific
> result
> > scale (e.g. bus clocks per tick)
> 
> No. That needs an accessor function.
> 
Agreed, so you are ok with bypassing the existing calibration_result variable and use .mult
to carry the result?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/