Re: [RFC PATCH 06/10] net: ti: prueth: Adds HW timestamping support for PTP using PRU-ICSS IEP module
From: Basharath Hussain Khaja
Date: Thu Jan 23 2025 - 02:24:18 EST
> 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