Open shenki opened 3 years ago
From some cursory code inspection, it looks like this stems from the cycle-shaving optimization in ftgmac100_rx_packet()
added in commit 7b49cd1c9eca4acd4dc36b6c2c532cad3576171d:
#if defined(CONFIG_ARM) && !defined(CONFIG_ARM_DMA_USE_IOMMU)
/* When we don't have an iommu, we can save cycles by not
* invalidating the cache for the part of the packet that
* wasn't received.
*/
dma_unmap_single(priv->dev, map, size, DMA_FROM_DEVICE);
#else
dma_unmap_single(priv->dev, map, RX_BUF_SIZE, DMA_FROM_DEVICE);
#endif
(in contrast with the dma_map_single()
call in ftgmac100_alloc_rx_buf()
using RX_BUF_SIZE
). Should that part just be backed out, or might there be some reason that's a "legitimate" mangling of what I gather are the rules of the API?
With this patch applied I haven't seen any instances of the check_unmap()
warning:
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index e04bb9d6a9af..8391c7ae443e 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -540,16 +540,7 @@ static bool ftgmac100_rx_packet(struct ftgmac100 *priv, int *processed)
/* Tear down DMA mapping, do necessary cache management */
map = le32_to_cpu(rxdes->rxdes3);
-#if defined(CONFIG_ARM) && !defined(CONFIG_ARM_DMA_USE_IOMMU)
- /* When we don't have an iommu, we can save cycles by not
- * invalidating the cache for the part of the packet that
- * wasn't received.
- */
- dma_unmap_single(priv->dev, map, size, DMA_FROM_DEVICE);
-#else
dma_unmap_single(priv->dev, map, RX_BUF_SIZE, DMA_FROM_DEVICE);
-#endif
-
/* Resplenish rx ring */
ftgmac100_alloc_rx_buf(priv, pointer, rxdes, GFP_ATOMIC);
This is purely cycle shaving. I remember it making quite a measurable difference on the ast2400 and ast2500 chips though.
Unfortunately the API doesn't provide a way to specify how much data was actually DMAed, which for network tx would be a legitimate optimisation.
v5.11 with CONFIG_DMA_API_DEBUG on qemu, tacoma machine.