fm10k/base: scale interrupt on PCIe link speed
authorWang Xiao W <xiao.w.wang@intel.com>
Thu, 10 Sep 2015 04:38:14 +0000 (12:38 +0800)
committerThomas Monjalon <thomas.monjalon@6wind.com>
Wed, 7 Oct 2015 11:25:07 +0000 (13:25 +0200)
commite18683f8ef6ce08fd587e3e8537e2030bcfe0825
treef52a80872467236697c9f4466a4c77b32533c9c6
parent76cf5b44b901de27502c1daaebcd0ee2f5756858
fm10k/base: scale interrupt on PCIe link speed

Red Rock Canyon's interrupt throttle timers are based on the PCIe link
speed. Because of this, the value being programmed into the ITR
registers must be scaled.

For the PF, this is as simple as reading the PCIe link speed and storing
the result. However, in the case of SR-IOV, the VF's interrupt throttle
timers are based on the link speed of the PF. However, the VF is unable
to get the link speed information from its configuration space, so the
PF must inform it of what scale to use.

Rather than passing this scale via mailbox message, we take advantage of
unused bits in the TDLEN register to pass the scale. It is the
responsibility of the PF to program this for the VF while setting up the
VF queues and the responsibility of the VF to get the information
accordingly. This is preferable because it allows the VF to set up the
interrupts properly during initialization and matches how the MAC
address is passed in the TDBAL/TDBAH registers.

A VF unload followed by a reload incorrectly left this value as 0.
If the VF driver blindly trusted this value it could cause a divide by
zero failure.
Fix this by having stop_hw_vf reset the ITR scale as the device goes
down, similar to the way we handle the MAC address.

To prevent divide-by-zero issues, ensure that we always have an ITR
scale. Default to Gen3 scaling if we don't know the speed. Also ensure
the VF checks the register value and ensures we use Gen3 if we are
provided a zero value.

Signed-off-by: Wang Xiao W <xiao.w.wang@intel.com>
drivers/net/fm10k/base/fm10k_pf.c
drivers/net/fm10k/base/fm10k_type.h
drivers/net/fm10k/base/fm10k_vf.c