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 <daniel.lezcano@linaro.org> 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 <daniel.lezcano@linaro.org> 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 <daniel.lezcano@linaro.org> wrote:
On 06/12/2021 07:00, Muni Sekhar wrote:
On Sat, Dec 4, 2021 at 3:18 AM Daniel Lezcano <daniel.lezcano@linaro.org> 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 <daniel.lezcano@linaro.org> 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.
participants (3)
-
Daniel Lezcano -
Muni Sekhar -
Valdis Klētnieks