Message-Id: <202207181220.06765.pisa@cmp.felk.cvut.cz>
Date:   Mon, 18 Jul 2022 12:20:06 +0200
From:   Pavel Pisa <pisa@....felk.cvut.cz>
To:     "Marc Kleine-Budde" <mkl@...gutronix.de>
Cc:     Matej Vasilevski <matej.vasilevski@...nam.cz>,
        Appana Durga Kedareswara rao <appana.durga.rao@...inx.com>,
        Naga Sureshkumar Relli <naga.sureshkumar.relli@...inx.com>,
        Wolfgang Grandegger <wg@...ndegger.com>,
        linux-can@...r.kernel.org, netdev@...r.kernel.org,
        Martin Jerabek <martin.jerabek01@...il.com>,
        Vikram Garhwal <fnu.vikram@...inx.com>
Subject: Re: [PATCH] can: xilinx_can: add support for RX timestamps on Zynq

Hello Marc,

On Monday 18 of July 2022 10:33:12 Marc Kleine-Budde wrote:
> On 16.07.2022 14:04:09, Matej Vasilevski wrote:
> > This patch adds support for hardware RX timestamps from Xilinx Zynq CAN
> > controllers. The timestamp is calculated against a timepoint reference
> > stored when the first CAN message is received.
> >
> > When CAN bus traffic does not contain long idle pauses (so that
> > the clocks would drift by a multiple of the counter rollover time),
> > then the hardware timestamps provide precise relative time between
> > received messages. This can be used e.g. for latency testing.
>
> Please make use of the existing cyclecounter/timecounter framework. Is
> there a way to read the current time from a register? If so, please
> setup a worker that does that regularly.
>
> Have a look at the mcp251xfd driver as an example:

Matej Vasilevski has looked at the example. But there is problem
that we know no method how to read actual counter value at least for
Xilinx Zynq 7000. May be we overlooked something or there
is hidden test register.

So actual support is the best approach we have found so far.
It is usable and valuable for precise relative time measurement
when bus is not idle for longer time. With expected clock
precision there should be no skip when at least one message
for each second or more is received.

The precision degrades to software software timer with
one half of timestamp counter period jitter for really
long gaps between messages. 

I understand that you do not like the situation,
if you think that it is not acceptable for mainline
even with config option under experimental then
never mind. We want to document this work on Linux
CAN mailing list. It worked for us in far past
when we used XCAN for CAN latency testing.

We have CTU CAN FD now which has in the default config
64 bits timestamps. It is readable and synchronized
(single counter) over all channels in our can latency
tester design for Zynq. 100 MHz timestamps base is
shared even over all CTU CAN FD cores when they
are integrated to PCIe card.

It could be intersting if XCAN or followups
on later Xilinx systems has additional registers
to read time base.

But I pose no UltraScale or later board at the
moment. I have organized the purchase of more
ones in 2016, but they stay in group which
break cooperation on the projects long time ago.

Best wishes,

                Pavel
-- 
                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@....felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home

Powered by blists - more mailing lists