diff options
author | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2010-11-02 09:58:49 -0400 |
---|---|---|
committer | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2010-11-02 09:58:49 -0400 |
commit | 9e3be1edbe5ca57df51140b523168237b3a01f4d (patch) | |
tree | a72c0ec1ce0fbcdcd12ecb6aad9bedcc94b94f9d /Documentation/networking/timestamping.txt | |
parent | ASoC: Fix SND_SOC_ALL_CODECS typo for alc5623 (diff) | |
parent | Merge commit 'v2.6.37-rc1' into for-2.6.37 (diff) | |
download | linux-dev-9e3be1edbe5ca57df51140b523168237b3a01f4d.tar.xz linux-dev-9e3be1edbe5ca57df51140b523168237b3a01f4d.zip |
Merge branch 'for-2.6.37' into HEAD
WARN() fix from Joe moved.
Conflicts:
sound/soc/codecs/wm_hubs.c
Diffstat (limited to 'Documentation/networking/timestamping.txt')
-rw-r--r-- | Documentation/networking/timestamping.txt | 22 |
1 files changed, 13 insertions, 9 deletions
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt index e8c8f4f06c67..98097d8cb910 100644 --- a/Documentation/networking/timestamping.txt +++ b/Documentation/networking/timestamping.txt @@ -172,15 +172,19 @@ struct skb_shared_hwtstamps { }; Time stamps for outgoing packets are to be generated as follows: -- In hard_start_xmit(), check if skb_tx(skb)->hardware is set no-zero. - If yes, then the driver is expected to do hardware time stamping. +- In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) + is set no-zero. If yes, then the driver is expected to do hardware time + stamping. - If this is possible for the skb and requested, then declare - that the driver is doing the time stamping by setting the field - skb_tx(skb)->in_progress non-zero. You might want to keep a pointer - to the associated skb for the next step and not free the skb. A driver - not supporting hardware time stamping doesn't do that. A driver must - never touch sk_buff::tstamp! It is used to store software generated - time stamps by the network subsystem. + that the driver is doing the time stamping by setting the flag + SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with + + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS; + + You might want to keep a pointer to the associated skb for the next step + and not free the skb. A driver not supporting hardware time stamping doesn't + do that. A driver must never touch sk_buff::tstamp! It is used to store + software generated time stamps by the network subsystem. - As soon as the driver has sent the packet and/or obtained a hardware time stamp for it, it passes the time stamp back by calling skb_hwtstamp_tx() with the original skb, the raw @@ -191,6 +195,6 @@ Time stamps for outgoing packets are to be generated as follows: this would occur at a later time in the processing pipeline than other software time stamping and therefore could lead to unexpected deltas between time stamps. -- If the driver did not call set skb_tx(skb)->in_progress, then +- If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then dev_hard_start_xmit() checks whether software time stamping is wanted as fallback and potentially generates the time stamp. |