summaryrefslogtreecommitdiff
path: root/include/drm/i915_pciids.h
diff options
context:
space:
mode:
authorJeff Kirsher <jeffrey.t.kirsher@intel.com>2015-04-11 03:20:17 +0300
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>2015-04-15 01:47:28 +0300
commit9de15bda37bd9b86378afd82e6fc52e82dc89ac3 (patch)
tree0a9352eb81f5ca5d3ae86b3d99dfab4c3c858809 /include/drm/i915_pciids.h
parentb382bb1b3e2d498ee7ce8976afa7737d407a4f11 (diff)
downloadlinux-9de15bda37bd9b86378afd82e6fc52e82dc89ac3.tar.xz
fm10k: don't handle mailbox events in iov_event path and always process mailbox
Since we already schedule the service task, we can just wait for this task to handle the mailbox events from the VF. This reduces some complex code flow, and makes it so we have a single path for handling the VF messages. There is a possibility that we have a slight delay in handling VF messages, but it should be minimal. The result of tx_complete and !rx_ready is insufficient to determine whether we need to process the mailbox. There is a possible race condition whereby the VF fills up the mbmem for us, but we have already recently processed the mailboxes in the interrupt. During this time, the interrupt is disabled. Thus, our Rx FIFO is empty, but the mbmem now has data in it. Since we continually check whether Rx FIFO is empty, we then never call process. This results in the possibility to prevent PF from handling the VF mailbox messages. Instead, just call process every time, despite the fact that we may or may not have anything to process for the VF. There should be minimal overhead for doing this, and it resolves an issue where the VF never comes up due to never getting response for its SET_LPORT_STATE message. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Matthew Vick <matthew.vick@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Diffstat (limited to 'include/drm/i915_pciids.h')
0 files changed, 0 insertions, 0 deletions