stm32h7-eth: Properly maintain Tx tail pointer #1495
Conversation
There was a problem hiding this comment.
This is a very good fix. The previous mental model was that the OWN bit was the key concept driving IO progress and that the tail pointer was just used to tell the HW to look at descriptors again.
In fact, without proper use of the tail pointer, it is probable that the HW is constantly polling the descriptor for a change in the OWN bit, thereby wasting power and memory bandwidth. Dan observes that the HW was never entering the SUSPEND state.
dancrossnyc
force-pushed
the
fixtx
branch
7 times, most recently
from
553d8f7
to
ea3f505
Compare
There was a problem hiding this comment.
The code looks good and I tested it for a while locally.
There are a bunch of comments in ring.rs that are now outdated, talking about how we're careful to handle memory ordering with a RELEASE store. I'm going to pre-approve this now, but can you go through and update those comments before merging?
(apologies for not catching this during the Rx PR)
Analagous to #1493, we should maintain the Tx tail pointer properly, as well. Note that since the device won't examine a Tx descriptor until the tail pointer is set appropriately, we can relax stores and rely on the barrier in `tx_notify` to flush everything to RAM properly before writing the tail pointer and kicking off a DMA.
I believe I've gotten them all; mind taking another quick look?
No worries! |
|
Looks good, thanks! |
Analagous to #1493, we should maintain the Tx tail pointer properly, as well. Note that since the device won't examine a Tx descriptor until the tail pointer is set appropriately, we can relax stores and rely on the barrier in
tx_notifyto flush everything to RAM properly before writing the tail pointer and kicking off a DMA.