From: Basharath Hussain Khaja <basharath@couthit.com>
To: richardcochran <richardcochran@gmail.com>
Cc: nm <nm@ti.com>, vigneshr <vigneshr@ti.com>,
tony <tony@atomide.com>, edumazet <edumazet@google.com>,
krishna <krishna@couthit.com>, pmohan <pmohan@couthit.com>,
diogo ivo <diogo.ivo@siemens.com>, Rob Herring <robh@kernel.org>,
javier carrasco cruz <javier.carrasco.cruz@gmail.com>,
praneeth <praneeth@ti.com>, m-karicheri2 <m-karicheri2@ti.com>,
basharath <basharath@couthit.com>, kuba <kuba@kernel.org>,
pabeni <pabeni@redhat.com>,
devicetree <devicetree@vger.kernel.org>,
conor+dt <conor+dt@kernel.org>, schnelle <schnelle@linux.ibm.com>,
mohan <mohan@couthit.com>, prajith <prajith@ti.com>,
rogerq <rogerq@kernel.org>,
jacob e keller <jacob.e.keller@intel.com>,
ssantosh <ssantosh@kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
rogerq <rogerq@ti.com>, srk <srk@ti.com>,
pratheesh <pratheesh@ti.com>, m-malladi <m-malladi@ti.com>,
netdev <netdev@vger.kernel.org>, rdunlap <rdunlap@infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
danishanwar <danishanwar@ti.com>, afd <afd@ti.com>,
andrew+netdev <andrew+netdev@lunn.ch>,
parvathi <parvathi@couthit.com>, horms <horms@kernel.org>,
krzk+dt <krzk+dt@kernel.org>, davem <davem@davemloft.net>
Subject: Re: [RFC PATCH 06/10] net: ti: prueth: Adds HW timestamping support for PTP using PRU-ICSS IEP module
Date: Thu, 23 Jan 2025 12:53:50 +0530 (IST) [thread overview]
Message-ID: <717976963.391348.1737617030636.JavaMail.zimbra@couthit.local> (raw)
In-Reply-To: <Z4KdxQMBXmkF37KI@hoboy.vegasvil.org>
> On Fri, Jan 10, 2025 at 11:29:02AM +0530, Basharath Hussain Khaja wrote:
>
>> @@ -189,12 +190,37 @@ static void icssm_emac_get_regs(struct net_device *ndev,
>> regs->version = PRUETH_REG_DUMP_GET_VER(prueth);
>> }
>>
>> +static int icssm_emac_get_ts_info(struct net_device *ndev,
>> + struct kernel_ethtool_ts_info *info)
>> +{
>> + struct prueth_emac *emac = netdev_priv(ndev);
>> +
>> + if ((PRUETH_IS_EMAC(emac->prueth) && !emac->emac_ptp_tx_irq))
>> + return ethtool_op_get_ts_info(ndev, info);
>> +
>> + info->so_timestamping =
>> + SOF_TIMESTAMPING_TX_HARDWARE |
>> + SOF_TIMESTAMPING_TX_SOFTWARE |
>
> The driver advertises software Transmit time stamping, but where is
> the call to skb_tx_timestamp() ?
>
> I didn't see it in Patch #4.
>
Yes. This module always uses IEP HW time stamping for better precision.
We will clean this in the next version.
>> + SOF_TIMESTAMPING_RX_HARDWARE |
>> + SOF_TIMESTAMPING_RX_SOFTWARE |
>> + SOF_TIMESTAMPING_SOFTWARE |
>> + SOF_TIMESTAMPING_RAW_HARDWARE;
>> +
>> + info->phc_index = icss_iep_get_ptp_clock_idx(emac->prueth->iep);
>> + info->tx_types = BIT(HWTSTAMP_TX_OFF) | BIT(HWTSTAMP_TX_ON);
>> + info->rx_filters = BIT(HWTSTAMP_FILTER_NONE) |
>> + BIT(HWTSTAMP_FILTER_PTP_V2_EVENT);
>> +
>> + return 0;
>> +}
>
>> @@ -442,6 +482,173 @@ static void icssm_emac_adjust_link(struct net_device
>> *ndev)
>> spin_unlock_irqrestore(&emac->lock, flags);
>> }
>>
>> +static u8 icssm_prueth_ptp_ts_event_type(struct sk_buff *skb, u8 *ptp_msgtype)
>> +{
>> + unsigned int ptp_class = ptp_classify_raw(skb);
>> + struct ptp_header *hdr;
>> + u8 msgtype, event_type;
>> +
>> + if (ptp_class == PTP_CLASS_NONE)
>> + return PRUETH_PTP_TS_EVENTS;
>> +
>> + hdr = ptp_parse_header(skb, ptp_class);
>> + if (!hdr)
>> + return PRUETH_PTP_TS_EVENTS;
>> +
>> + msgtype = ptp_get_msgtype(hdr, ptp_class);
>> + /* Treat E2E Delay Req/Resp messages sane as P2P peer delay req/resp
>
> s/sane/in the same way/
>
This was a typo, We will address this in the next version. Firmware running in PRU
treats E2E Delay Req/Resp messages same as P2P peer delay req/resp.
>> + * in driver here since firmware stores timestamps in the same memory
>> + * location for either (since they cannot operate simultaneously
>> + * anyway)
>> + */
>> + switch (msgtype) {
>> + case PTP_MSGTYPE_SYNC:
>> + event_type = PRUETH_PTP_SYNC;
>> + break;
>> + case PTP_MSGTYPE_DELAY_REQ:
>> + case PTP_MSGTYPE_PDELAY_REQ:
>> + event_type = PRUETH_PTP_DLY_REQ;
>> + break;
>> + /* TODO: Check why PTP_MSGTYPE_DELAY_RESP needs timestamp
>> + * and need for it.
>> + */
>> + case 0x9:
>
> Delay response messages are PTP "general" messages and not event
> messages, and as such they do not require time stamps.
>
currently firmware sends back timestamp even for E2E Delay_response message
though this is a general message. To service that txts request we added this
here. We will revisit again and clean this in the subsequent versions.
Thanks & Best Regards,
Basharath
WARNING: multiple messages have this Message-ID (diff)
From: Basharath Hussain Khaja <basharath@couthit.com>
To: richardcochran <richardcochran@gmail.com>
Cc: basharath <basharath@couthit.com>,
danishanwar <danishanwar@ti.com>, rogerq <rogerq@kernel.org>,
andrew+netdev <andrew+netdev@lunn.ch>,
davem <davem@davemloft.net>, edumazet <edumazet@google.com>,
kuba <kuba@kernel.org>, pabeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>, krzk+dt <krzk+dt@kernel.org>,
conor+dt <conor+dt@kernel.org>, nm <nm@ti.com>,
ssantosh <ssantosh@kernel.org>, tony <tony@atomide.com>,
parvathi <parvathi@couthit.com>,
schnelle <schnelle@linux.ibm.com>,
rdunlap <rdunlap@infradead.org>,
diogo ivo <diogo.ivo@siemens.com>,
m-karicheri2 <m-karicheri2@ti.com>, horms <horms@kernel.org>,
jacob e keller <jacob.e.keller@intel.com>,
m-malladi <m-malladi@ti.com>,
javier carrasco cruz <javier.carrasco.cruz@gmail.com>,
afd <afd@ti.com>, s-anna <s-anna@ti.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
netdev <netdev@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
pratheesh <pratheesh@ti.com>, prajith <prajith@ti.com>,
vigneshr <vigneshr@ti.com>, praneeth <praneeth@ti.com>,
srk <srk@ti.com>, rogerq <rogerq@ti.com>,
krishna <krishna@couthit.com>, pmohan <pmohan@couthit.com>,
mohan <mohan@couthit.com>
Subject: Re: [RFC PATCH 06/10] net: ti: prueth: Adds HW timestamping support for PTP using PRU-ICSS IEP module
Date: Thu, 23 Jan 2025 12:53:50 +0530 (IST) [thread overview]
Message-ID: <717976963.391348.1737617030636.JavaMail.zimbra@couthit.local> (raw)
In-Reply-To: <Z4KdxQMBXmkF37KI@hoboy.vegasvil.org>
> On Fri, Jan 10, 2025 at 11:29:02AM +0530, Basharath Hussain Khaja wrote:
>
>> @@ -189,12 +190,37 @@ static void icssm_emac_get_regs(struct net_device *ndev,
>> regs->version = PRUETH_REG_DUMP_GET_VER(prueth);
>> }
>>
>> +static int icssm_emac_get_ts_info(struct net_device *ndev,
>> + struct kernel_ethtool_ts_info *info)
>> +{
>> + struct prueth_emac *emac = netdev_priv(ndev);
>> +
>> + if ((PRUETH_IS_EMAC(emac->prueth) && !emac->emac_ptp_tx_irq))
>> + return ethtool_op_get_ts_info(ndev, info);
>> +
>> + info->so_timestamping =
>> + SOF_TIMESTAMPING_TX_HARDWARE |
>> + SOF_TIMESTAMPING_TX_SOFTWARE |
>
> The driver advertises software Transmit time stamping, but where is
> the call to skb_tx_timestamp() ?
>
> I didn't see it in Patch #4.
>
Yes. This module always uses IEP HW time stamping for better precision.
We will clean this in the next version.
>> + SOF_TIMESTAMPING_RX_HARDWARE |
>> + SOF_TIMESTAMPING_RX_SOFTWARE |
>> + SOF_TIMESTAMPING_SOFTWARE |
>> + SOF_TIMESTAMPING_RAW_HARDWARE;
>> +
>> + info->phc_index = icss_iep_get_ptp_clock_idx(emac->prueth->iep);
>> + info->tx_types = BIT(HWTSTAMP_TX_OFF) | BIT(HWTSTAMP_TX_ON);
>> + info->rx_filters = BIT(HWTSTAMP_FILTER_NONE) |
>> + BIT(HWTSTAMP_FILTER_PTP_V2_EVENT);
>> +
>> + return 0;
>> +}
>
>> @@ -442,6 +482,173 @@ static void icssm_emac_adjust_link(struct net_device
>> *ndev)
>> spin_unlock_irqrestore(&emac->lock, flags);
>> }
>>
>> +static u8 icssm_prueth_ptp_ts_event_type(struct sk_buff *skb, u8 *ptp_msgtype)
>> +{
>> + unsigned int ptp_class = ptp_classify_raw(skb);
>> + struct ptp_header *hdr;
>> + u8 msgtype, event_type;
>> +
>> + if (ptp_class == PTP_CLASS_NONE)
>> + return PRUETH_PTP_TS_EVENTS;
>> +
>> + hdr = ptp_parse_header(skb, ptp_class);
>> + if (!hdr)
>> + return PRUETH_PTP_TS_EVENTS;
>> +
>> + msgtype = ptp_get_msgtype(hdr, ptp_class);
>> + /* Treat E2E Delay Req/Resp messages sane as P2P peer delay req/resp
>
> s/sane/in the same way/
>
This was a typo, We will address this in the next version. Firmware running in PRU
treats E2E Delay Req/Resp messages same as P2P peer delay req/resp.
>> + * in driver here since firmware stores timestamps in the same memory
>> + * location for either (since they cannot operate simultaneously
>> + * anyway)
>> + */
>> + switch (msgtype) {
>> + case PTP_MSGTYPE_SYNC:
>> + event_type = PRUETH_PTP_SYNC;
>> + break;
>> + case PTP_MSGTYPE_DELAY_REQ:
>> + case PTP_MSGTYPE_PDELAY_REQ:
>> + event_type = PRUETH_PTP_DLY_REQ;
>> + break;
>> + /* TODO: Check why PTP_MSGTYPE_DELAY_RESP needs timestamp
>> + * and need for it.
>> + */
>> + case 0x9:
>
> Delay response messages are PTP "general" messages and not event
> messages, and as such they do not require time stamps.
>
currently firmware sends back timestamp even for E2E Delay_response message
though this is a general message. To service that txts request we added this
here. We will revisit again and clean this in the subsequent versions.
Thanks & Best Regards,
Basharath
next prev parent reply other threads:[~2025-01-23 7:25 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 10:55 [RFC PATCH 00/10] PRU-ICSSM Ethernet Driver Basharath Hussain Khaja
2025-01-09 10:55 ` [RFC PATCH 01/10] dt-bindings: net: ti: Adds device tree binding for DUAL-EMAC mode support on PRU-ICSS2 for AM57xx SOCs Basharath Hussain Khaja
2025-01-09 14:16 ` Andrew Lunn
2025-01-09 14:16 ` Andrew Lunn
2025-01-22 13:21 ` Basharath Hussain Khaja
2025-01-22 13:21 ` Basharath Hussain Khaja
2025-01-09 16:02 ` Andrew Lunn
2025-01-09 16:02 ` Andrew Lunn
2025-01-22 13:26 ` Basharath Hussain Khaja
2025-01-22 13:26 ` Basharath Hussain Khaja
2025-01-22 13:43 ` Andrew Lunn
2025-01-22 13:43 ` Andrew Lunn
2025-01-22 15:03 ` Basharath Hussain Khaja
2025-01-22 15:03 ` Basharath Hussain Khaja
2025-01-10 16:15 ` Rob Herring
2025-01-10 16:15 ` Rob Herring
2025-01-22 13:43 ` Basharath Hussain Khaja
2025-01-22 13:43 ` Basharath Hussain Khaja
2025-01-10 16:16 ` Rob Herring
2025-01-10 16:16 ` Rob Herring
2025-01-22 13:46 ` Basharath Hussain Khaja
2025-01-22 15:28 ` Basharath Hussain Khaja
2025-01-22 15:28 ` Basharath Hussain Khaja
2025-01-09 10:55 ` [RFC PATCH 02/10] net: ti: prueth: Adds ICSSM Ethernet driver Basharath Hussain Khaja
2025-01-09 15:59 ` Andrew Lunn
2025-01-09 15:59 ` Andrew Lunn
2025-01-22 15:33 ` Basharath Hussain Khaja
2025-01-22 15:33 ` Basharath Hussain Khaja
2025-01-09 10:55 ` [RFC PATCH 03/10] net: ti: prueth: Adds PRUETH HW and SW configuration Basharath Hussain Khaja
2025-01-09 16:10 ` Andrew Lunn
2025-01-09 16:10 ` Andrew Lunn
2025-01-22 15:57 ` Basharath Hussain Khaja
2025-01-22 15:57 ` Basharath Hussain Khaja
2025-01-09 10:55 ` [RFC PATCH 04/10] net: ti: prueth: Adds link detection, RX and TX support Basharath Hussain Khaja
2025-01-09 16:24 ` Andrew Lunn
2025-01-09 16:24 ` Andrew Lunn
2025-01-23 7:02 ` Basharath Hussain Khaja
2025-01-23 7:02 ` Basharath Hussain Khaja
2025-01-23 7:16 ` Christophe JAILLET
2025-01-23 12:30 ` Basharath Hussain Khaja
2025-01-23 12:30 ` Basharath Hussain Khaja
2025-01-09 14:11 ` [RFC PATCH 00/10] PRU-ICSSM Ethernet Driver Andrew Lunn
2025-01-09 14:11 ` Andrew Lunn
2025-01-22 13:17 ` Basharath Hussain Khaja
2025-01-22 13:17 ` Basharath Hussain Khaja
2025-01-10 5:59 ` [RFC PATCH 05/10] net: ti: prueth: Adds ethtool support for ICSSM PRUETH Driver Basharath Hussain Khaja
2025-01-10 5:59 ` [RFC PATCH 06/10] net: ti: prueth: Adds HW timestamping support for PTP using PRU-ICSS IEP module Basharath Hussain Khaja
2025-01-11 16:35 ` Richard Cochran
2025-01-11 16:35 ` Richard Cochran
2025-01-23 7:23 ` Basharath Hussain Khaja [this message]
2025-01-23 7:23 ` Basharath Hussain Khaja
2025-01-11 23:38 ` Jason Xing
2025-01-11 23:38 ` Jason Xing
2025-01-23 7:25 ` Basharath Hussain Khaja
2025-01-23 7:25 ` Basharath Hussain Khaja
2025-01-10 5:59 ` [RFC PATCH 07/10] net: ti: prueth: Adds support for network filters for traffic control supported by PRU-ICSS Basharath Hussain Khaja
2025-01-10 7:13 ` [RFC PATCH 08/10] net: ti: prueth: Adds support for RX interrupt coalescing/pacing Basharath Hussain Khaja
2025-01-10 7:13 ` [RFC PATCH 09/10] net: ti: prueth: Adds power management support for PRU-ICSS Basharath Hussain Khaja
2025-01-10 7:13 ` [RFC PATCH 10/10] arm: dts: ti: Adds device tree nodes for PRU Cores, IEP and eCAP modules of PRU-ICSS2 Instance Basharath Hussain Khaja
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=717976963.391348.1737617030636.JavaMail.zimbra@couthit.local \
--to=basharath@couthit.com \
--cc=afd@ti.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=diogo.ivo@siemens.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=javier.carrasco.cruz@gmail.com \
--cc=krishna@couthit.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=m-karicheri2@ti.com \
--cc=m-malladi@ti.com \
--cc=mohan@couthit.com \
--cc=netdev@vger.kernel.org \
--cc=nm@ti.com \
--cc=pabeni@redhat.com \
--cc=parvathi@couthit.com \
--cc=pmohan@couthit.com \
--cc=prajith@ti.com \
--cc=praneeth@ti.com \
--cc=pratheesh@ti.com \
--cc=rdunlap@infradead.org \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=rogerq@kernel.org \
--cc=rogerq@ti.com \
--cc=schnelle@linux.ibm.com \
--cc=srk@ti.com \
--cc=ssantosh@kernel.org \
--cc=tony@atomide.com \
--cc=vigneshr@ti.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.