On Wed, Jun 26, 2024 at 09:54:40AM +0200, Johan Hovold wrote:
On Mon, Jun 24, 2024 at 02:58:39PM -0700, Doug Anderson wrote:
- The function is named qcom_geni_serial_clear_tx_fifo() which
implies that when it finishes that the hardware FIFO will have nothing in it. ...but how does your code ensure this?
Yeah, I realised after I sent out the series that this may not be the case. I was under the impression that cancelling a command would discard the data in the FIFO (e.g. when starting the next command) but that was probably an error in my mental model.
I went back and did some more reverse engineering and have now confirmed that the hardware works as I assumed for v1, that is, that cancelling a command leaves data in the fifo, which is later discarded when a new command is issued.
- On my hardware you're setting the FIFO level to 16 here. The docs I
have say that if the FIFO level is "less than" the value you set here then the interrupt will go off and further clarifies that if you set the register to 1 here then you'll get interrupted when the FIFO is empty. So what happens with your solution if the FIFO is completely full? In that case you'd have to set this to 17, right? ...but then I could believe that might confuse the interrupt handler which would get told to start transmitting when there is no room for anything.
Indeed. I may implicitly be relying on the absence of hardware flow control as well so that waiting for one character to be sent is what makes this work.
I'm keeping the watermark level unchanged in v2 and instead restart tx by issuing a short transfer command to clear any stale data from the fifo which could prevent the watermark interrupt from firing.
Johan