Hi All,
We have a Digital PLL with 64 bit timer counter hardware and the
counter is accessible from the CPU over the PCIe bus.
Is it possible to add this timer counter hardware as new clocksource
driver? To do this, can someone please point me to the existing
reference source code(or patch) for this task.
Suppose if it is possible to add a new clocksource driver for this
hardware then does any userspace get_timestamp* API would get the time
from this new hardware?
--
Thanks,
Sekhar
Hi Sekhar,
On 03/12/2021 17:50, Muni Sekhar wrote:
> Hi All,
>
> We have a Digital PLL with 64 bit timer counter hardware and the
> counter is accessible from the CPU over the PCIe bus.
>
> Is it possible to add this timer counter hardware as new clocksource
> driver? To do this, can someone please point me to the existing
> reference source code(or patch) for this task.
You can refer to the drivers located in drivers/clocksource
git annotate on one of the driver can give you the initial commit where
recent submissions explain the timer internals.
> Suppose if it is possible to add a new clocksource driver for this
> hardware then does any userspace get_timestamp* API would get the time
> from this new hardware?
It should if the timer is selected as the clocksource
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano <[email protected]> wrote:
>
> Hi Sekhar,
>
> On 03/12/2021 17:50, Muni Sekhar wrote:
> > Hi All,
> >
> > We have a Digital PLL with 64 bit timer counter hardware and the
> > counter is accessible from the CPU over the PCIe bus.
> >
> > Is it possible to add this timer counter hardware as new clocksource
> > driver? To do this, can someone please point me to the existing
> > reference source code(or patch) for this task.
>
> You can refer to the drivers located in drivers/clocksource
I don't see the option in menuconfig to build the clocksource driver
as a loadable kernel module, for example CONFIG_X86_PM_TIMER=m instead
of CONFIG_X86_PM_TIMER=y.
So a clocksource driver should always be part of the kernel built-in
module? If so, what's the reason for that?
>
> git annotate on one of the driver can give you the initial commit where
> recent submissions explain the timer internals.
>
> > Suppose if it is possible to add a new clocksource driver for this
> > hardware then does any userspace get_timestamp* API would get the time
> > from this new hardware?
>
> It should if the timer is selected as the clocksource
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
--
Thanks,
Sekhar
On 06/12/2021 07:00, Muni Sekhar wrote:
> On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano <[email protected]> wrote:
>>
>> Hi Sekhar,
>>
>> On 03/12/2021 17:50, Muni Sekhar wrote:
>>> Hi All,
>>>
>>> We have a Digital PLL with 64 bit timer counter hardware and the
>>> counter is accessible from the CPU over the PCIe bus.
>>>
>>> Is it possible to add this timer counter hardware as new clocksource
>>> driver? To do this, can someone please point me to the existing
>>> reference source code(or patch) for this task.
>>
>> You can refer to the drivers located in drivers/clocksource
> I don't see the option in menuconfig to build the clocksource driver
> as a loadable kernel module, for example CONFIG_X86_PM_TIMER=m instead
> of CONFIG_X86_PM_TIMER=y.
> So a clocksource driver should always be part of the kernel built-in
> module?
Yes, that is the case today.
> If so, what's the reason for that?
The timer is a component needed at boot time, so a module version does
really not make sense.
So I would return back the question : what is the reason for a module?
>> git annotate on one of the driver can give you the initial commit where
>> recent submissions explain the timer internals.
>>
>>> Suppose if it is possible to add a new clocksource driver for this
>>> hardware then does any userspace get_timestamp* API would get the time
>>> from this new hardware?
>>
>> It should if the timer is selected as the clocksource
>>
>>
>> --
>> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>>
>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>> <http://twitter.com/#!/linaroorg> Twitter |
>> <http://www.linaro.org/linaro-blog/> Blog
>
>
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
On Mon, Dec 6, 2021 at 11:59 AM Daniel Lezcano
<[email protected]> wrote:
>
> On 06/12/2021 07:00, Muni Sekhar wrote:
> > On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano <[email protected]> wrote:
> >>
> >> Hi Sekhar,
> >>
> >> On 03/12/2021 17:50, Muni Sekhar wrote:
> >>> Hi All,
> >>>
> >>> We have a Digital PLL with 64 bit timer counter hardware and the
> >>> counter is accessible from the CPU over the PCIe bus.
> >>>
> >>> Is it possible to add this timer counter hardware as new clocksource
> >>> driver? To do this, can someone please point me to the existing
> >>> reference source code(or patch) for this task.
> >>
> >> You can refer to the drivers located in drivers/clocksource
> > I don't see the option in menuconfig to build the clocksource driver
> > as a loadable kernel module, for example CONFIG_X86_PM_TIMER=m instead
> > of CONFIG_X86_PM_TIMER=y.
> > So a clocksource driver should always be part of the kernel built-in
> > module?
>
> Yes, that is the case today.
>
> > If so, what's the reason for that?
>
> The timer is a component needed at boot time, so a module version does
> really not make sense.
>
> So I would return back the question : what is the reason for a module?
For built-in module we need to compile the whole kernel, but we are
currently using the kernel via linux-image-4.15.0-54-generic.deb file
installation.
>
>
> >> git annotate on one of the driver can give you the initial commit where
> >> recent submissions explain the timer internals.
> >>
> >>> Suppose if it is possible to add a new clocksource driver for this
> >>> hardware then does any userspace get_timestamp* API would get the time
> >>> from this new hardware?
> >>
> >> It should if the timer is selected as the clocksource
> >>
> >>
> >> --
> >> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
> >>
> >> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> >> <http://twitter.com/#!/linaroorg> Twitter |
> >> <http://www.linaro.org/linaro-blog/> Blog
> >
> >
> >
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
--
Thanks,
Sekhar
On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano <[email protected]> wrote:
>
> Hi Sekhar,
>
> On 03/12/2021 17:50, Muni Sekhar wrote:
> > Hi All,
> >
> > We have a Digital PLL with 64 bit timer counter hardware and the
> > counter is accessible from the CPU over the PCIe bus.
> >
> > Is it possible to add this timer counter hardware as new clocksource
> > driver? To do this, can someone please point me to the existing
> > reference source code(or patch) for this task.
>
> You can refer to the drivers located in drivers/clocksource
>
> git annotate on one of the driver can give you the initial commit where
> recent submissions explain the timer internals.
>
> > Suppose if it is possible to add a new clocksource driver for this
> > hardware then does any userspace get_timestamp* API would get the time
> > from this new hardware?
>
> It should if the timer is selected as the clocksource
/var/log/kern.log file use a absolute time, like "Nov 29 12:26:13", as
well as relative time in seconds and microseconds since startup , like
"[1263900.984287]
Is the relative time calculated by the clocksource driver module (tsc
or acpi_pm)?
Which module is responsible for resulting in the absolute time? Is
absolute time synchronized across multiple systems connected on the
network?
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
--
Thanks,
Sekhar
On Tue, 07 Dec 2021 13:03:07 +0530, Muni Sekhar said:
> Which module is responsible for resulting in the absolute time? Is
> absolute time synchronized across multiple systems connected on the
> network?
man -k ntp
Keeping the system clock in sync with external timesources and reality is too
complicated and messy to be done inside the kernel, so it's usually done with a
userspace daemon which on Linux boxes is usually ntpd.
Depending on the clock stability of the hardware, whether you have an RTC chip
that keeps track of time even when powered down, and the timing tolerances you
want on your network (synced to the same minute, or same second, or same 0.001
seconds), it may be sufficient to run ntpdate at an appropriate time during
system boot, or from inside a cron job, or you may want to have a continually
running ntpd process.
Most sane distros have ntpd enabled by default with a reasonable set of
defaults - systems that have non-broken clocks will fairly quickly figure out
the clock drift rate, and your network load to keep the clocks within a few
milliseconds of a national time standard drops to a few packets every 20
minutes or so. In case of a network outage, it will continue to correct the
system clock according to the last known drift rate.
And if you need better than millisecond sync, you're going to be springing
for a GPS receiver with a PPS output and/or a cesium or rubidium clock.