All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Austin Schuh <austin@peloton-tech.com>,
	linux-can <linux-can@vger.kernel.org>,
	Philipp Schrader <philipp@peloton-tech.com>
Subject: Re: CAN message timestamping
Date: Wed, 30 Mar 2016 14:17:08 +0200	[thread overview]
Message-ID: <56FBC3C4.80400@hartkopp.net> (raw)
In-Reply-To: <CANGgnMaK0wXwsKJZB0SssPje9r6qCVYUQzbJsqW+BdSDCQ1iPA@mail.gmail.com>

Hi Austin,

On 03/29/2016 06:28 AM, Austin Schuh wrote:
> On Mon, Mar 28, 2016 at 8:42 PM, Austin Schuh <austin@peloton-tech.com> wrote:
>> On Mon, Mar 28, 2016 at 6:51 PM, Austin Schuh <austin@peloton-tech.com> wrote:
>>> Hi Oliver,
>>>
>>> I spent some time trying recvmsg, but it still only gives me
>>> timestamps with the real-time clock.  I do like the interface much
>>> better.  Thanks!
>>>
>>> I was able to get
>>>    setsockopt(socket_, SOL_SOCKET, SO_TIMESTAMPNS,
>>>        &enabled, sizeof(enabled))
>>> and
>>>    const int stamping_val = SOF_TIMESTAMPING_SOFTWARE |
>>>        SOF_TIMESTAMPING_SYS_HARDWARE |
>>>        SOF_TIMESTAMPING_RAW_HARDWARE;
>>>    setsockopt(socket_, SOL_SOCKET, SO_TIMESTAMPING, &stamping_val,
>>>        sizeof(stamping_val))
>>> to successfully timestamp values with recvmsg.

Great!

>> Turns out timestamping in the driver is pretty easy.  The following
>> seems to be working for me.  (comments welcome!)  I don't think this
>> is something that should be up streamed, but I'm including it here in
>> case there is other interest.  I'm reading both clocks in the ISR to
>> reduce the amount of time difference between when they are both read.
>>
>> $ git diff
>> diff --git a/drivers/net/can/sja1000/sja1000.c
>> b/drivers/net/can/sja1000/sja1000.c
>> index 76ef900..55d6583 100644
>> --- a/drivers/net/can/sja1000/sja1000.c
>> +++ b/drivers/net/can/sja1000/sja1000.c
>> @@ -370,6 +370,10 @@ static void sja1000_rx(struct net_device *dev)
>>          /* release receive buffer */
>>          sja1000_write_cmdreg(priv, CMD_RRB);
>>
>> +       struct skb_shared_hwtstamps *shhwtstamps =
>> +           skb_hwtstamps(skb);
>> +       shhwtstamps->syststamp = ktime_get();
>> +       skb->tstamp = ktime_get_real();
>>          netif_rx(skb);
>>
>>          stats->rx_packets++;

Yes. I was also thinking about doing the timestamping directly at hw 
interrupt time.

The point is, that timestamping is an option.
The timestamping is only done if someone requires timestamps - an then 
it is done in the net-rx softirq (which is not that precise which is 
probably the reason for rx hardware timestamping).

> I missed the TX timestamping.  I didn't see a clean way to get access
> to the echo skb.
>
> --- a/drivers/net/can/sja1000/sja1000.c
> +++ b/drivers/net/can/sja1000/sja1000.c
> @@ -518,10 +524,19 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
>                                  stats->tx_errors++;
>                                  can_free_echo_skb(dev, 0);
>                          } else {
> +                               struct can_priv *can_priv_struct =
> netdev_priv(dev);
>                                  /* transmission complete */
>                                  stats->tx_bytes +=
>                                          priv->read_reg(priv, SJA1000_FI) & 0xf;
>                                  stats->tx_packets++;
> +                               if (can_priv_struct->echo_skb[0]) {
> +                                       struct sk_buff *skb =
> can_priv_struct->echo_skb[0];
> +                                       struct skb_shared_hwtstamps
> *shhwtstamps =
> +                                               skb_hwtstamps(skb);
> +                                       shhwtstamps->syststamp = ktime_get();
> +                                       skb->tstamp = ktime_get_real();
> +                               }
> +
>                                  can_get_echo_skb(dev, 0);

I think a proper way would be to put this directly in 
can_get_echo_skb(), as poking into can_priv_struct->echo_skb[0] can just 
be a proof of concept for tx timstamping.

I'm fine with adding a more precise timestamping into CAN drivers but I 
wonder how other drivers implement this feature taking without killing 
the 'optional' feature.

Best regards,
Oliver


  reply	other threads:[~2016-03-30 12:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23  5:12 CAN message timestamping Austin Schuh
2016-03-23  7:00 ` Oliver Hartkopp
2016-03-29  1:51   ` Austin Schuh
2016-03-29  3:42     ` Austin Schuh
2016-03-29  4:28       ` Austin Schuh
2016-03-30 12:17         ` Oliver Hartkopp [this message]
2016-03-30 16:50           ` Austin Schuh
2016-04-04 19:45             ` Oliver Hartkopp
2016-04-04 20:32               ` Austin Schuh
2016-05-12  2:07                 ` Austin Schuh

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=56FBC3C4.80400@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=austin@peloton-tech.com \
    --cc=linux-can@vger.kernel.org \
    --cc=philipp@peloton-tech.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.