Linux CAN drivers development
 help / color / mirror / Atom feed
From: Pavel Pisa <pisa@cmp.felk.cvut.cz>
To: Matej Vasilevski <matej.vasilevski@seznam.cz>
Cc: Ondrej Ille <ondrej.ille@gmail.com>,
	Wolfgang Grandegger <wg@grandegger.com>,
	"Marc Kleine-Budde" <mkl@pengutronix.de>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-can@vger.kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v5 2/4] can: ctucanfd: add HW timestamps to RX and error CAN frames
Date: Sun, 16 Oct 2022 23:54:48 +0200	[thread overview]
Message-ID: <202210162354.48915.pisa@cmp.felk.cvut.cz> (raw)
In-Reply-To: <20221012062558.732930-3-matej.vasilevski@seznam.cz>

Thanks for the work

On Wednesday 12 of October 2022 08:25:56 Matej Vasilevski wrote:
> This patch adds support for retrieving hardware timestamps to RX and
> error CAN frames. It uses timecounter and cyclecounter structures,
> because the timestamping counter width depends on the IP core integration
> (it might not always be 64-bit).
> For platform devices, you should specify "ts" clock in device tree.
> For PCI devices, the timestamping frequency is assumed to be the same
> as bus frequency.
>
> Signed-off-by: Matej Vasilevski <matej.vasilevski@seznam.cz>

Acked-by: Pave Pisa <pisa@cmp.felk.cvut.cz>

It would be great if the code gets in as a basic level for CTU CAN FD
timestamping which we need for CAN latency test project.

In the longer term, it could be usesfull to discuss if rx_filter == HWTSTAMP_FILTER_ALL
and cfg.tx_type == HWTSTAMP_TX_ON should be divided to allow separate timestamping
enable and disable for transmit and receive. Our actual focus is to receive
and Tx is implemented by reading the timestamping counter in the message transmit
done interrupt. There is option (for newer core version) to loop Tx frames
into Rx loop which could allow to enhance precision of Tx timestamps
to 10 ns. But that requires newer IP core and I wait even for some minor changes
to allow identification of looped Tx frames into Rx queue.
Switch to such processing mode will have some overhead etc... So it should
stay configurable and used only when precise Tx timestamp are really required...

When the current timestamping patch is accepted I plan to discuss
use of clk_prepare_enable for the main IP core clocks.
These clocks are AXI bus ones on our FPGA integration so they
has to be up anyway and clk_prepare_enable etc.. does not change
behavior, but I want to make that correct in long term.
I hope/expect that it is not problem to call clk_prepare_enable twice
on same reference when the clocks are the same. As I read the code the
state is counted. If it is a problem then some if has to be put there
when the core and timestamp clock are the same.

Thanks for work and reviews,

                Pavel
-- 
                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.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


  reply	other threads:[~2022-10-16 21:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12  6:25 [PATCH v5 0/4] can: ctucanfd: hardware rx timestamps reporting Matej Vasilevski
2022-10-12  6:25 ` [PATCH v5 1/4] dt-bindings: can: ctucanfd: add another clock for HW timestamping Matej Vasilevski
2022-10-12 16:21   ` Rob Herring
2022-10-12  6:25 ` [PATCH v5 2/4] can: ctucanfd: add HW timestamps to RX and error CAN frames Matej Vasilevski
2022-10-16 21:54   ` Pavel Pisa [this message]
2022-10-17 12:11     ` Marc Kleine-Budde
2022-10-24 11:42       ` Pavel Pisa
2022-10-24 20:02   ` Marc Kleine-Budde
2022-10-25 22:22     ` Matej Vasilevski
2022-10-26  7:15       ` Marc Kleine-Budde
2022-10-25  8:18   ` Marc Kleine-Budde
2022-10-25  9:25   ` Marc Kleine-Budde
2022-10-12  6:25 ` [PATCH v5 3/4] doc: ctucanfd: RX frames timestamping for platform devices Matej Vasilevski
2022-10-12  6:25 ` [PATCH v5 4/4] can: ctucanfd: remove __maybe_unused from suspend/resume callbacks Matej Vasilevski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202210162354.48915.pisa@cmp.felk.cvut.cz \
    --to=pisa@cmp.felk.cvut.cz \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=matej.vasilevski@seznam.cz \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=ondrej.ille@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox